Multiple entities on map and sf::Texture

[lafoniz]

Hello back again, I got a little problem that I wanted to discuss with many clever and experienced users from this forum.

Let's say that I have class like this for an enemy:

class Enemy
{
sf::Texture texture;
sf::Sprite sprite;

void setProperSpriteRect();

};

I have seen in many little productions classes like this, but I have found an very anxious problem with them.
Let's see another short code:

std::vector<Enemy> enemies;
for(unsigned i{0}; i < enemies.size(); ++i)
{
enemies.push_back(Enemy(x,y,z));
}

This code may look okay, but it's not. Every time I create enemy or I delete it, I have to create or delete one texture! Which for example in my game is like 3000x128 size (I'm using setSpriteRect function to get proper frame of animation). It's not okay, when I need only 1 texture for every entity on the map.

There I need your expertise guys! What is the best way to implement a shared texture for every kind of entity? Personally, I was thinking of:

a) making separate class only for texture loading and returning pointer to texture to every class which needs this texture
b) trying to do something with 'static'?

However, I'm not sure which will be the best to improve performance and reduce memory requisition. Thanks for every reply and helpful tip, good luck!

[Ixrec]

The answer depends entirely on your program, but you're right that you do not want every Enemy object to directly contain its own separate sf::Texture.

First off, sf::Sprite already has a pointer to an sf::Texture.  The setTexture() method sets that pointer.  So in the case of a one-file super-simple game, the best option is to simply have the sf::Texture live in main() and give every Enemy a reference to it (preferably on construction) so they can give it to their sf::Sprite members.

From there, how far up the complexity ladder you want to go depends on how complex your game is.  If you're sure you want to go up a few rungs, thor::ResourceCache is a really good place to start.  I would be very surprised if you felt the need to write your own resource management class considering that one already exists.

With regards to performance, as long as you have a single texture object being shared by all the entities that use it, you're not converting between sf::Texture and sf::Image, and you mostly stick to only one draw() call per texture (ie, you've done the vertex array optimization if it's appropriate), then performance should not be a serious issue for you.  At least not until your game gets *very* complicated.


P.S. A static member might be okay if you are absolutely sure that there is a perfect one-to-one mapping between textures and Enemy classes.  The biggest problem is this wouldn't be a very flexible design; the moment it's no longer one-to-one, you have to do something else.  I think this would be a good idea if you were going nuts with the Component pattern and had a DragonEnemyTextureComponent that did nothing but provide access to a static texture with dragon.png loaded into it.  Otherwise, probably not.

[Jesper Juhl]

Take a look at the resource module from Thor: http://www.bromeon.ch/libraries/thor/v2.0/tutorial-resources.html