Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am making a game, and I just started to think about how I am going to update and render all the sprites on the screen. Should I store all sprites in some type of list (vector or something?) and then call the draw and render method on all those? I'm using SFML and C++ if that helps.

share|improve this question
up vote 8 down vote accepted

The answer to your question is: yes, you will generally have a render list that you draw during the draw phase of the game loop.

After saying that, I must mention something I am seeing in your post... most notably that you are thinking of the sprites(the graphics representing your game object) as the things in the game(the game object themselves). This is a common misconception early on in game development that eventually leads to all manners of woe and gnashing of teeth. I recommend attempting to think separately in terms of game objects (the things represented in the game work with classes and code) and the sprites (the things that get rendered to the screen to give the player the illusion that the game objects exist). While there is certainly a relationship between these two things, they are not the same.

share|improve this answer
Great advice that also opens the way to providing different representations of your game objects in a very clean way. – Patrick Hughes Mar 6 '12 at 23:51
That's what I was talking about, but I couldn't think of the right word :P. Anyway, thanks for the answer. – zachy64 Mar 7 '12 at 0:24

That depends on how many sprites you have in your world at a given time. If it's in the hundreds or low thousands, you should be fine just using a set, and shoving all sprites into that set. (I'd use a set rather than a list because you will probably need to add and remove sprites frequently.)

If you have hundreds of thousands of sprites in your world, and only a few are visible at once, you have more work. Obviously you don't want to render sprites that aren't in the current view.

In that case, keep things simple. Split up your world into chunks based on X-Y coordinates. Identify which chunks are visible in the current view. Only render sprites from those.

You should be able to identify the visible chunks very quickly -- if you have them in a 2d array and they're of fixed size, just divide the viewport rectangle by the chunk size. Otherwise, keep the list of visible chunks in memory; whenever the viewport moves, look at the neighbors for all the currently visible chunks to see if they're now visible and clear the no-longer-visible ones from your list.

Like moving a picture frame over graph paper.

share|improve this answer

What is your concern, exactly? Performance, or code beauty?

With C#/XNA, a common, simple, practical solution is to have a sprite manager component, which subscribes to the main class (and thus its update/draw methods get called regularly). You can easily duplicate this code without having the actual component API.

Speaking of components, occasionally the question of making every single instance a component comes up. It seems a reasonable enough idea, and it's always mentioned that you shouldn't do it, but I could never figure out why. Anyway, point is, that's an option too.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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