[SOLVED] texture from an image -> white sprite

[Geheim]

Hey guys,
I try to load a texture from an image, set it to a sprite and draw it on the screen.
The image gets created and the colors are set "by hand", however the sprite always is white, no matter which color I set.

blockImage.create(BLOCK_SIZE, BLOCK_SIZE);
for(size_t x = 0; x != BLOCK_SIZE; ++x)
        for(size_t y = 0; y != BLOCK_SIZE; ++y)
                blockImage.setPixel(x, y, sf::Color::Blue);
blockTexture.loadFromImage(blockImage);
block.setTexture(blockTexture);

blockImage, blockTexture and block (the sprite) are members of a class and this class is stored in a std::vector in another one (maybe it has something to do with it)

I tried to print out blockImage.getPixel(0, 0).b after I set it to blue, but I get no number, so I think I make something wrong with the image, but what is it?
Thanks and Greetings

[eXpl0it3r]

My guess is that your texture runs out of scope before it gets drawn to the screen. But without a minimal and complete example we can only guess.

[Geheim]

Yes this was my first guess too, but afaik member variables are global for the class and don't get destroyed until the destructor gets called?

Here is the code that pruduces the behaviour for me: http://pastebin.com/WLqWnWue

[Ixrec]

I *think* you can fix this by using a vector of pointers to blocks instead of just a vector of blocks, though it's been a while since I had to debug texture scope so I may be wrong.

[Geheim]

Yes this does work, but can you explain why? I don't see a reason why just a normal vector shouldn't work too 

[Ixrec]

Basically, the STL containers may move around the stuff inside them at any time.  I only learned about this when I found that gcc complained when I put const objects inside STL containers since it knew that was unsafe (VC++ allowed it for some reason).  Whether and when they actually do it is implementation-dependent.  So if you put pointers in there instead, the pointers will get moved around instead of the objects they point to.

You might be able to get the same effect by using pointers to Texture/Image/etc inside the Block class, but I do not fully understand the scope rules involved.  I just know adding more indirection/pointers tends to solve this kind of problem.

[Geheim]

Hmm I still don't understand it, but thanks

You might be able to get the same effect by using pointers to Texture/Image/etc inside the Block class

Nope, I tried this, thats why it doesn't make sence to me 

[eXpl0it3r]

The issue here is that sf::Sprite keeps a reference to the texture, thus when copying the texture or moving its location, the reference will get invalid and the sprite shows white.
There are two ways to fix it.
1) Set the texture after your done copying.
2) Don't make/allow copies of the texture after you've set it.

What goes wrong in your code:
- When you push_back an object a copy will be made. With C++11 you can use emplace_back to prevent that.
- At "any" time you call push_back on a vector all its content might get moved. A different design for textures handling with e.g. a ResourceHolder that uses a std::map.

[Geheim]

Alright this makes sence now. Thanks for the explanation!