0
\$\begingroup\$
  • I am drawing a game in 2D (isometric)

  • My objects have their own arrays. (i.e. Tiles[], Objects[], Particles[], etc)

  • I want to have a draw[] array to hold anything that will be drawn.

  • Because it is 2D, I assume I must prioritise depth over any other sorting or things will look weird.

  • My game is turn based so Tiles and Objects won't be changing position every frame. However, Particles probably will.

So I am thinking I can populate the draw[] array (probably a vector?) with what is on-screen and have it add/remove object, tile & particle references when I pan the screen or when a tile or object is specifically moved. No idea how often I'm going to have to update for particles right now. I want to do this because my game may have many thousands of objects and I want to iterate through as few as possible when drawing.

I plan to give each element a depth value to sort by.

So, my questions:

  1. Does the above method sound like a good way to deal with the actual drawing?

  2. What is the most efficient way to sort a vector? Most of the time it wont require efficiency. But for panning the screen it will. And I imagine if I have many particles on screen moving across multiple tiles, it may happen quite often.

For reference, my screen will be drawing about 2,800 objects at any one time. When panning, it will be adding/removing about ~200 elements every second, and each new element will need adding in the correct location based on depth.

\$\endgroup\$
  • \$\begingroup\$ If you have a lot of transparency in your sprites, you may want to look into a topological sort for your draw order. \$\endgroup\$ – XNargaHuntress Jun 30 '14 at 12:18
1
\$\begingroup\$

What you're describing is called (view frustum) culling and is something that almost everyone has to do. Doing that efficiently on large scenes often requires some sort of tree based approach if you want to do it dynamically in a 3D world, e.g. octree or bounding volumes. In your case you can probably get away with a static 2d grid of the world where each cell contains a list of items that's inside it (an object can be in multiple cells at the same time). Then you can find all the cells that the camera overlaps and only draw those objects.

Unless you've profiled your code and are seeing performance issues with the sorting, I shouldn't worry about it. You will most likely start seeing problems with the amount of draw calls before the sorting becomes an issue. Sorting 2800 floats on my old Core 2 Quad using std::sort takes 0.000182 seconds.

So yes, in general it sounds like a good plan. I would start with doing everything each frame (i.e. find all objects in camera view and sort them) and wait with keeping lists between frames until you really have to. Making sure everything is in sync can be a nightmare.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.