First of all don't think I'm making a "SFML and/or C++ performance Issue" type question. I'm not satisfied with the performance of this map editor I've been working on and I'm 99% percent sure I'm at fault for it.
Currently how I place tiles on the map is basically I have a function that loops through every single tile on the map and checks if the mouse is hovering over it. I call this function inside another function simply titled handleMouseClick()
This is plenty functional if you were just clicking each time you wanted to place a tile, however I have it sort of like a paintbrush. Even if there's only 500 tiles on the map, it will skip tiles if you drag it across the screen quickly. I need to be able to create maps that have 5000+ tiles and I can't afford so-so performance.
I've looked over my code and made sure I'm not making unnecessary copies. I'm pretty sure that the best way to increase performance would be to change how I check which tile the mouse is changing.
The only idea I have is to have the map in "chunks" so that it will check the tiles of the "chunk" the mouse is in.
Use math. Lets say you have tiles with pixel dimensions {tile.width, tile.height}. And your application's window is a view of the map, and the top left corner of the window is on pixel {view.x, view.y}. And the mouse position, relative to the top left corner of the window is {mouse.x, mouse.y}. You can calculate which tile the mouse is pointing to with the following:
transformed_mouse.x = mouse.x + view.x;
transformed_mouse.y = mouse.y + view.y;
mouse_tile.x = transformed_mouse.x / tile.width;
mouse_tile.y = transformed_mouse.y / tile.height;
For handling a dragging effect where the event system doesn't update fast enough, keep track of where the mouse was for the previous iteration, and use Bresenham's line algorithm to fill in all the tiles between the tile which the mouse is currently pointing to, and the tile which the mouse was pointing to previously.
Related
I am currently working on a new RPG game using Pygame (my aim here is really to learn how to use object oriented programming). I started a few days ago and developed a movement system where the player clicks a location and the character sprite goes to that location and stops when it get's there by checking if the sprite 'collides' with the mouse position.
I quickly found however that this greatly limited the world size (to the app window size).
I started having a look into making a movement system where the background would move with respect to the player, hence providing the illusion of movement.
I managed to achieve this by creating a variable keeping track of my background map position. The map is much bigger than the app window. And each time I want my player to move I offset the background by the speed of the player in the opposite direction.
My next problem now is that I can't get my character to stop moving... because the character sprite never actually reaches the last position clicked by the mouse, since it is the background that is moving, not the character sprite.
I was thinking of spending some time coding in a variable that would keep track of how many displacements it would take the character sprite to reach the mouse clicked position if it was to move. Since the background moves at the character sprite's speed it would take as many displacement of the background in the x and y directions to center the clicked position on the background to the character sprite at the center of the screen.
It would be something like that:
If MOUSEBUTTON clicked:
NM = set number of moves needed to reach the clicked position based on character sprite distance to click and character sprite speed.
If NM != 0:
Move background image
Else:
pass
This would mean that when my background has moved enough for the character sprite to now be just over the area of the background that was originally clicked by the player, the movement would stop since NM == 0.
I guess that my question is: Does that sound like a good idea or will it be a nightmare to handle the movement of other sprites and collisions ? And are there better tools in Pygame to achieve this movement system ?
I could also maybe use a clock and work out how many seconds the movements would take.
I guess that ultimately the whole challenge is dealing with a fixed reference point and make everything move around it, both with respect to this fixed reference, but also to their own. e.g. If two other sprites move toward one another, and the character of the player also "moves" then the movement of the other two sprites will have to depend both on the position of the other sprite and also on the offset of the background caused by the movement of the player's character.
An interesting topic which has been frying my brain for a few nights !
Thank you for your suggestions !
You actually asking for an opinion on game design. The way I look at it, nothing is impossible so go ahead and try your coding. Also it would be wise to look around at similar projects scattered around the net. You may be able to pick up a lot of tips without re inventing the wheel. Here is a good place to start.
scrolling mini map
I am working on a window which displays a number of objects (a graph) (C++/Win32API). This is in GDI+ and I have written a test piece of code with Direct2d as I want to improve the performance when dragging objects in the window. The best approach I have found (to date) is the following (using a graph of 1000 nodes and 999 edges).
(bascially buffer static content to a bitmap buffer and only draw whats moving)
When dragging starts (e.g lbuttondown state), create a base rendertarget with the full graph excluding the node being dragged and the attached edges, call GetBitmap and store for later use. When I need to draw (due to mousemove event and lbuttondown state true), then clear the current hwndrendertarget (background wash white), then draw the edges that are connected to the node being moved into the hwndrendertarget, then copy the save bitmap to the hwndrendertarget, then copy the node bitmap (created when the node is first created in the DB, saves actually drawing it) being moved to the hwndrendertarget, then call EndDraw.
Now this works ok (ish), what I don't like it that, when the node is dragged quickly the mouse cursor moves ahead of the node being dragged (distance depending on speed of drag/mousemove bu worst case up to about 1/2 inch). My reference app is MS Visio, dragging a single object on this shows the cursor staying in the same position over the object being dragged maybe +/- 1/2 pixels.
What I have not tried yet is moving all the (and only) the drawing operations to a separate thread, but before I try this I would like to research other methods if other single threaded approaches would trump this way.
Update:
I have optimized this a bit more with improvement, I found I was allocating and de-allocating the edge brush in the draw function which I have moved out to a class wide object and initialize for the life of the class as with other brushes etc. The cursor now only gets a little way (2 pixels or so) outside of the object being dragged when being dragged quickly, the object is a 15px radius circle. so the cursor is able to move up to 17px away from the middle of the object (the point the cursor should stick to) when being dragged. In testing I found an interesting thing, on my main monitor the drag is worse in that the cursor can get ahead of the object being dragged by more than 17px, say up to maybe 25px from the center point of the object where the cursor should be fixed. On the second monitor for the extended desktop (i.e. no taskbar) the drag is better in that described previously. If I hide the taskbar on the main monitor and run the app on that monitor and drag, the performance is the same as the second monitor.
In a view of my MFC application, I can select certain rectangular area with click & drag. But when user wants to select larger area than current screen, he can't do that because the view does not automatically scroll when mouse pointer is near bound of the client area.
How can I resolve this problem? Any reference would suffice.
Normally you only do this when the user has the mouse button held down. That being the case, you normally want to capture the mouse when the click. You'll then handle WM_MOUSEMOVE messages. In your case, you'll compare the current position of the mouse to the border of your window, and when it gets close enough (e.g., within 10 pixels) you start to scroll in that position.
I feel obliged to add that I'd control scrolling speed pretty carefully when you do this -- some programs scroll so far so fast that this becomes nearly unusable, because the moment you've gotten close to the edge of the window, you've already scrolled way past where you intended. Others tend toward the opposite: no matter what you do, they scroll so slowly that moving even a short distance seems like it takes forever.
I doubt there's an easy answer to getting the "right" speed. You do generally want a gradient, so as they get sort of close to the border, it scrolls slowly, and as they get closer, the scrolling gets faster. You still need to be fairly careful about the upper and lower bounds of that though, so they get a reasonable range of speeds, not just jumping from "oh, am I ever going to get there", directly to "whoa, back up, that's way too far already!".
Is there any way to change the touch priority for cocos2d iOS sprites? What I have are multiple cards on the screen and they are arrayed in an arc, just like it would when you hold them in your hands. So in this setup, they overlap, and I need to recognize on which card the touch was made. I could measure the coordinates of each vertex of cards and determine the visible area of a card and then check if the touch was made inside that area (couldn't I?) but I thought there would be an easier way to deal with this, say changing the touch priority? Which means that the card closest to the screen would have the highest priority and it'll keep decreasing along the way into the background, so that even if the touch was made on 2 sprites at once (the above and below one), it would be registered only on the sprite with higher priority.
Reading on the internet only revealed ways to change the priority for a sprite and layer so that it defines whether the touch was made on the layer or the sprite, but that's not what I want.
As far as I know, by default you get exactly that behavior, the sprites closer (on the z ax) to you have priority. However, I think they pass down the event to the ones behind them as well. So, what i think you need to do is to eat the event when it gets to any of your sprites. To do that, just return NO when overwriting the "touchBegin" method. Hope it helps.
This is related to one of my other questions.
If I am tiling a large image by creating a separate QGraphicsItem (with the raster data as its pixmap), how do I keep track of the QGraphicsItem's position within the scene? Obviously for raster data, it is important to keep all the tiles "touching" to make a continuous image and they also have to be in the right place so the image doesnt look jumbled.
Does each tile have to have positioning methods that move it in relation to it's neighbors on the top/left/bottom/right? This seems kind of clunky. Is there a better way to make them all move together?
In other words, if I pan the scene with scroll bars, or pick up the image and drag/move it around in the scene, I want all the tiles to also move and stay in the right position relative to each other.
What is the best approach for controlling the layout, which tiles need to be rendered (i.e. only the visible ones), and populating the data only once it is needed? Also, once a tile has been rendered, is the data from it ever dropped, and repopulated from the image file, say if it stays out of view for a while, then comes back later if someone pans to that section?
There are (more than) 2 ways of doing this:
Use QGraphicsItemGroup which
handles grouping of your tile items
for you. It moves, selects, updates
it's group members as if they are
one. I've never used it but from the
doc, it seems to work with typical
applications.
Paint the tiles yourself in the
paint() of one custom item. This
gives you total control on how to
place and draw the tiles while the
item truly acts as one item since it
is, well, one item. This is what I
do.