Sprite and Texture errors

[sparkon]

Ok this might seem another post like : "The RenderWindow draws a sprite as a white box" and actually that's what is happening, but it's different!. I have got a simple std::vector<sf::Texture> that contains ~20 textures and it is stored in the class so it's not destroyed at the end of the scope. Then i've got a class for each Sprite, i'm using a class because i need to store a lot of thing.
The constructor from my sprite class is :

SpaceElement::SpaceElement(sf::Texture& t,unsigned short int Level) // don't look at Level is a game variable
{
        // Getting values
        Sprite.setTexture(t);
}
 

i'm simply setting the texture to the sprite withOUT losing the reference, because the Texture t is saved in a std::vector in my main class.
Great! everything is fine until here. Every frame i call the _draw() method from each sprite class

SpaceElement::_draw(sf::RenderWindow& Window)
{
    Window.draw(Sprite); // The sprite is the same of the initialization
}
 

and this is supposed to work, and it works! but just for 5-6 sprites, while i have almost 20 sprites in the vector, for the first ~12 textures it displays a white box, for the other 8 it displays the actual Texture, how is that possible?
I was thinking about some memory change but i have no clue... i'm in your hands

[FRex]

Derive from sf::drawable for easier syntax. than your _draw.
Do you add textures to vector after setting some sprites? If yes then vector might realocated your textures already before you drew them.

[Mario]

How is your vector defined? And when do you pass the reference to the texture (do you pass the vector's entry or the texture you copy into the vector)?

I think you're storing a copy of the texture in the vector, but you're somehow still referencing the original texture object, that's been destroyed.

[FRex]

Content of vectors realocate after push_back if they run out of reserved memory(invalidates all pointers and references). Try using list, map or vector of pointers instead.

[sparkon]

Frex so i shoul use a vector of pointer to the textures? Anyway after i created all the sprites after filling the vector with textures

[Nexus]

Anyway after i created all the sprites after filling the vector with textures

Assuming the first "after" is there by accident: Make sure the sprites really refer to the textures in the vector, and that this vector remains untouched as soon as you assign the first textures to the sprites.

Otherwise, minimize your code until the error becomes obvious. You can also use a debugger.

[FRex]

Try use std::list instead of vector and see if it fixes anything. Just replace std::vector<sf::Texture> with std::list<sf::Texture>, they have same interfaces, it shouldn't break any code.

[sparkon]

Frex. with list it works! is there anyway to make it working with vectors, because i need indexing ( i know i could make it without indexing but it would be much slower)

[FRex]

Use vector of raw pointers or smart pointers or try do: vector.reserve() with int amount of textures you will ever load(but if you load more than that the vector will realocate and any removal will invalidate pointers to all elements after removed element). If reserve doesn't work then just go with some pointers.

[sparkon]

ok i'll go for that. But can you briefly explain me why that happened?

[FRex]

Vectors are guaranteed to lay their contents like c-style arrays did(one after another, so random acess is fast) and they reserve a bit of extra space for few objects when they get constructed but if you add too many they will run out of this extra space and then realocate their content to another chunk of space, bigger than the last to prepare for next push_backs.
You can check how many objects there are with size() and how much more space is ready for next objects with capacity().

[eXpl0it3r]

Vectors are guaranteed to lay their contents like c-style arrays did(one after another, so random acess is fast) and they reserve a bit of extra space for few objects when they get constructed but if you add too many they will run out of this extra space and then realocate their content to another chunk of space, bigger than the last to prepare for next push_backs.
You can check how many objects there are with size() and how much more space is ready for next objects with capacity().

Well just a reallocation shouldn't drop the validity of the content (I class won't get newly initialized).
The part the problems appears (I guess) is when the textures get copied from the old space to the new space and OpenGL somehow releases the texture, but I'm not quite sure...

Often one uses a std::map (or std::unordered_map) so one can connect a logical key to each texture.

[FRex]

OpenGL somehow releases the texture

Don't be cussin like that around me.

void Sprite::draw(RenderTarget& target, RenderStates states) const
{
    if (m_texture)
    {
        states.transform *= getTransform();
        states.texture = m_texture;
        target.draw(m_vertices, 4, Quads, states);
    }
}

But sprite holds pointer to sf texture not anything opengl and draws like that so there is garbage in the space where old texture pointer points to(maybe)?

[sparkon]

FRex you said i should use drawable instead of passing the window reference, what do you mean?

[FRex]

http://www.sfml-dev.org/documentation/2.0/classsf_1_1Drawable.php#details