Question about life time of sf::Texture

[marCOmics]

 ;DHello everybody,

first post by me.

In my project, I have a class that should handle Sprites that are made of a pixel array.
The class has a vector of Sprites, which is looped over and the individual Sprites should be drawn every update cycle. Now I made a method that creates new sprites of the pixel array and pushes them onto the vector.

sth like this (shortened pseudocode version):

void CSpriteHandleClass::createButton(/*params*/){
sf::Image image;
sf::Sprite sprite;
sf::Texture texture;

//create UInt8 pixel array & fill it
//create image from the pixel array
//set texture from the image
//set sprite from the texture

global_spritevector.push_pack(sprite);

}

(in main it loops over the vector and draws every sprite)

When I then run the code, everything seemed okay except that the texture of the sprite had no color (it should've been red, as I filled it that way). I found out, that if I declare the Texture in the pseudocode as a pointer (sf::Texture* texture = new sf::Texture) it would work and the colors showed up.

I guess the Sprite is only storing a pointer to the texture which dies when getting out of the scope (method)?

But why does the Sprite itself live on and the Texture not? They should both be copied into the vector I thought, so technically even as a non-pointer the data should be there, doesn't it?? I looked up the reference (https://www.sfml-dev.org/documentation/2.4.2/classsf_1_1Texture.php#details) but except "it lives in the graphics card" nothing regarding the life time of the texture object is said. I'm really confused, would love if someone could help me understand whats going on.

Greetings!

[Hapax]

Generally, the objects live only as long as they last in their local scope.

When your function ends, both the local sprite and the local texture are destroyed. Pushing back the sprite copies that sprite into your vector of sprites. The sprite inside the vector is outside of the function's scope so continues to live on. However, since the sprite is a direct copy of the local sprite, it copied its pointer to the local texture, which was destroyed. That means that you have your sprite but it's texture's pointer is now incorrect.

The texture lives on inside the graphics card for as long as the texture object lives.

You may want to consider storing texture, as it is a resource, outside of the internal classes and pass it to them via a reference (or pointer) and then store that. That way, the texture will live on and your new sprite can access still use it. Also, that texture can be used by other classes/functions if you pass it to them.

[marCOmics]

hmm..
I think I will stick with the current method, even if I have to consider to afterwards delete the textures properly as working with pointers tends to lead to memory leaks if I remember correctly..

Or I just make another static vector living on the class scope which just holds the textures, that would be what you said if I understood correctly..

Thanks for the quick response, it kinda makes sense now in hindsight, but okay: It always does afterwards !

[Hapax]

If you "stick with the current method" (is that storing a pointer to texture?), you still have to make sure the pointer continues to exist or pass it around.

If you were to store the textures within the same class, you could store them in a similar way to the sprites: a vector of textures as a class member.
This works but I was suggesting a more global approach where they're stored separately and accessed and passed around when needed. Note this is not a suggestion to store resources in global scope.