Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Rendering large number of sprites with similar characteristics  (Read 2716 times)

0 Members and 1 Guest are viewing this topic.

Midleiro F

  • Newbie
  • *
  • Posts: 14
    • View Profile
Rendering large number of sprites with similar characteristics
« on: November 20, 2012, 01:18:13 am »
Say I have a very large number of game elements that share the same sprite properties (size, textureRect, linear transforms, etc), except that they differ only in texture in position.

I want to render all of them. So say I have a vector where all of them are stored, like
std::vector<sf::Sprite>;
. So I would just iterate throw this vector and call draw on all of them, like this.
for (int i = 0; i < sprites.size(); ++i)
        window.draw(sprites[i]);

Now, I've been thinking, what if I created only one static sprite instance, and stored only the position and the texture for each given game element? So, maybe I would have something like
std::vector<std::pair<sf::Vector2f, sf::Texture>> spriteInfos;
static sf::Sprite staticSprite;
. Then it would go like this:
for (int i = 0; i < spriteInfos.size(); ++i)
{
        staticSprite.setPosition(spriteInfos[i].first);
        staticSprite.setTexture(spriteInfos[i].second);
        window.draw(staticSprite);
}

It seems to me that the above method saves up a lot of memory from underlying properties inside each sprite that would have been duplicated on the first method, especially if I have a very large number of sprites active at the same time.


My question is, what do you make of this approach? Is it worth it, and if not, why, and do you think it may affect my performance?

Thanks!!

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10822
    • View Profile
    • development blog
    • Email
Re: Rendering large number of sprites with similar characteristics
« Reply #1 on: November 20, 2012, 01:33:06 am »
My question is, what do you make of this approach? Is it worth it, and if not, why, and do you think it may affect my performance?
There's never the best way, it always depends on what you really want to do. If you're really concernded about the performance you should test the different versions and use the one that performed best, but keep in mind that it might run differently on other machines (due to different graphics cards/drivers/CPU/etc.).

I don't know how big your textures are, but in most of the cases it would be probably better to save them all into one image and load this once, instead of having x different textures lying around. You then can simply move the texture rect instead of changing the texture. Performance wise the two operation are quite equal, but if I'm not mistaken the switching between different textures (on the GPU) isn't the cheapest operation.
You can use one sprite, which will use a bit less memory. For the performance, if you use the sprites a lot then you might want to have them all in memory, this way you'd only have to set the position ones and not every iteration for every image, but it also won't have a hug influence.
You could also think about using a VertexArray for this kind of task. Not sure how the performance will be though. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Rendering large number of sprites with similar characteristics
« Reply #2 on: November 20, 2012, 01:56:06 am »
Quote
but if I'm not mistaken the switching between different textures (on the GPU) isn't the cheapest operation.
Right(as always  :)). Refer to this thread for more info about how crazy performance gain from sheeting/atlasing is: http://en.sfml-dev.org/forums/index.php?topic=9250.0
std::vector<std::pair<sf::Vector2f, sf::Texture>> spriteInfos;
 
Textures shouldn't be kept in vectors(may want to keep pointers to them or list of them).
Back to C++ gamedev with SFML in May 2023

 

anything