sf::Texture out of scope?

[Tacostamp]

Hi All,

Running into a problem with my texture, and I believe it's because the texture is going out of scope when I try and draw the sprite in another function. How do you generally get around this, as I'm sure most would want to initialize the sprite and its properties before using it later.

Here is the "initializer":

void Unit::setImage(string unitFP){
        if (!localTexture.loadFromFile(unitFP)){
                return;}
        localSprite.setTexture(localTexture); }
 

And here is the code that will determine where to draw the sprite:

void Unit::displaySprite(sf::RenderWindow& window){
        localSprite.setPosition(xLoc, yLoc);
        window.draw(localSprite); }
 

The instance is what I expect it to be, since xLoc and yLoc are set correctly, but the texture is lost and instead only a white quad is shown.

Can anyone lend a hand with their own personal ideas as to how to solve this problem? Thanks!!!

NOTE: I have declared localSprite and localTexture in the header file.

[cire]

I think it's a pretty common solution for people to use some sort of resource manager.

You may look to http://en.sfml-dev.org/forums/index.php?topic=9670.0  for inspiration.  I wouldn't be surprised if there were other similar code posted around here.  There's an interesting resource manager implementation on the wiki, although I believe it uses v1.6 of SFML so it may require some adjustments -- still a good source for ideas.

[Nexus]

Running into a problem with my texture, and I believe it's because the texture is going out of scope when I try and draw the sprite in another function. How do you generally get around this

Don't let it go out of scope?

Keep the textures in a class that exists longer than your sprites. And don't use global variable or singletons, they're unnecessary.

There's an interesting resource manager implementation on the wiki, although I believe it uses v1.6 of SFML so it may require some adjustments -- still a good source for ideas.

For a generic resource manager compatible to SFML 2, you can also take a look at my library Thor. Tutorial and API documentation.

[Tacostamp]

I tinkered a little more and it looks more like I cannot use multiple class instances with the same texture ... is there a limit on accessing a resource?

[masskiller]

Not that I know of. You can perfectly have lots of sprites/drawables using the same texture without problems.

[eXpl0it3r]

I tinkered a little more and it looks more like I cannot use multiple class instances with the same texture ... is there a limit on accessing a resource?

No there isn't, since there's no reference counting or similar going.
If you had posted a minimal and complete example, we could've helped you in no time... ;

[ichineko]

Hey Tacostomp, I went through the same pain.  The API doesn't really feel like it communicates the behavior very well.

If you let the texture object get destructed, it destroys the underlying texture.

Keep the textures in a class that exists longer than your sprites. And don't use global variable or singletons, they're unnecessary.

Personally, I disagree with this.  If Tacostomp is just trying to learn SFML, building a use-able resource manager (even a super simple one) is solving a problem that isn't getting him to his goal.  If using a global eases his pain and doesn't get in his way, then it's a good solution.

Granted, it isn't generally sound *practice*, but when the code isn't supposed to be super robust or professional, who cares.

[cire]

Personally, I disagree with this.  If Tacostomp is just trying to learn SFML, building a use-able resource manager (even a super simple one) is solving a problem that isn't getting him to his goal.  If using a global eases his pain and doesn't get in his way, then it's a good solution.

While I agree with the sentiment, initialization order of global objects can be problematic with SFML, so I would keep away from them for that reason.

[Tacostamp]

Exploiter, I had an example at the top. Here's another shot at being more thorough:

EDIT: More code...

This is from Player class. units is a vector of all units a player will have.

void Player::PlayerInit(){
        Unit newUnit("Alien.png");
        units.push_back(newUnit);
}
 

Unit::Unit(string FP){
        filePath = "images/" + FP;
        if (!localTexture.loadFromFile(filePath)){
                return;}
}
 

void Unit::displaySprite(sf::RenderWindow& window){
        localSprite.setPosition(xLoc, yLoc);
        localSprite.setTexture(localTexture);
        window.draw(localSprite);
}
 

Both snippets are from the class "Unit.cpp" I know that I am using the correct class instances because xLoc and yLoc are being set correctly in another function.

Now, let me be clear - the above works, but only the FIRST time I create a new "Unit" instance. When I create more units, the picture is just ... gone. I call loadFromFile on localTexture, it does not fail, which is why it seems like something is stopping me from accessing the same resource   

I am trying my best to follow the guidelines ... minimal and complete.

[cire]

I am trying my best to follow the guidelines ... minimal and complete.

Minimal - smallest amount of code that reproduces the problem.
Complete - You can toss it into the compiler and have it work.

Guess which one you're short on?  =)

There would be no need to reload the texture every time you create a new "Unit" and it doesn't look like there should be a need for you to use setTexture on the sprite every time you draw it either.  But, there's not much to go on here.

[ichineko]

While I agree with the sentiment, initialization order of global objects can be problematic with SFML, so I would keep away from them for that reason.

I'm curious about this.  What aspects of SFML are sensitive to the order of initialization of objects?

[eXpl0it3r]

I'm curious about this.  What aspects of SFML are sensitive to the order of initialization of objects?

It's not directly a SFML problem. The destruction order of global instances (i.e. the objects get initialized globally) are undefined, thus if X would depend on Y, then it might happen that Y gets destroyed before X gets destroyed, which can obviously lead to problems.

[ichineko]

I believe the standard requires in order initialization w/i a translation unit, and I know of no compiler that does not implement it that way.  The standard also guarantees initialization before main is called, which means using a pointer solves the problem entirely (as does handing the global texture to anything during execution).

But cire seemed to be implying SFML itself was sensitive to init order as a result of the implementation.  Is that not the case?

[Laurent]

But cire seemed to be implying SFML itself was sensitive to init order as a result of the implementation.  Is that not the case?

Nope, everything within SFML is on control. But if user code has globals, the order of initialization between his globals and SFML globals is undefined.