May sprites vs 1 sprite ?

[smurf]

Question about how to efficiently draw a lot of small images.

I've already built a texture atlas consisting of about 100 small images so that I only have 1 large texture loaded to the graphics card.

I've been using a single sprite to draw subsections of this texture atlas at different positions on the screen.

At some point I got the idea to use many sprites instead of just one. Basically, one sprite per image within the texture atlas. I think I actually got the idea from these forums.

But now that I'm nearly done making this change, I'm questioning whether it was actually a good idea, and if so, how does it actually improve things?

Because even though I have a single sprite dedicated to each actual image within the texture atlas, I'm still changing the properties of each sprite every frame. In particular, the images are moving so I'm at least changing the Position of each sprite each frame. And sometimes the color and the scale too. So does this defeat the purpose of having 100 different sprites instead of just 1? Because with just 1 sprite I was also changing the properties of it before making the draw call.... so it feels like the only real difference is that now I  have 99 extra sprites I might not actually need.

Hope that made sense. Thoughts?

[AnhBao]

It might be the time you call sf::RenderTarget::draw() right? It is the only thing that matters. I would prefer using only 1 sprite to save GPU resource.  Just wonder why you want to separate it like that? To optimise performance and only draw whats on the view right? Hmm anyway try using Task Manager if you re using Windows and see which way benefits you the most.

[eXpl0it3r]

If you don't notice any measurable performance impacts (i.e. use a profiler), then this is a perfectly valid way to do it. With one sprite per image, you at leas won't have to recalculate the texture rect every time and it can make things a bit easier to manage.

If you start drawing thousands of images, then you may want to consider using vertex arrays instead, as you can reduce the draw calls to one (per texture).

[smurf]

@AnhBao I swear I saw a thread on these forums way back saying that an individual sprite per sub-image would be more efficient. It wasn't until I was 75% done implementing it that I realized actually this doesn't seem more efficient for any particular reason, so this post was a sanity check. I guess the idea is that if you only use a single sprite, then you constantly have to change the position, scale, color, etc before drawing anything with that sprite.
However I found that even with many sprites, I'm still changing many of those properties before drwaing.

@eXpl0it3r True but my old code had a dictionary of all the TextureRects within my atlas, so I was just looking it up instead of creating a new one each time.

Once nice improvement would be if the sprite position property was writeable. Currently I have to do this A LOT:
sprite.Position = new Vertex2f(posX, posY);
but it would be much nicer if I could just do this:
sprite.Position.X = posX;
sprite.Position.Y = posY;


Also, I see that Vertex Arrays are mentioned A LOT when performance is discussed... would it be possible for SFML to use Vertex Arrays under the hood, even if the dumb user (me) is not explicitly using them in code?

[AnhBao]

Hmm... then I think we have to trade CPU resources right. I think unless you're having a serious and heavy project then GPU performance doesn neccessarily need to be optimised, since most devices are capable of drawing multiple sprites and calculate stuffs at an suficent speed. But would setFrameLimit or V-sync be good choices?