Sprites not displaying properly

[Azaral]

I seem to have a problem getting sprites to display properly. The sprites know where they should be and their size, but they don't show the actual graphic. If I change the color to something not white, the box will show up, but the actual graphic won't. I'm trying to load .png images. What does this usually mean? If you need more info ask cause I'm stumped as to what is going wrong.

[eXpl0it3r]

So something is working, but it actually isn't, but with something else, something else happens?

Give details

Provide as much relevant information as possible to people who will help you -- it saves time and posts.

• What's your OS? Graphics card?
• Which version of SFML are you using? Static or dynamic? If you're using a development snapshot, which revision is it?
• Are you showing all the relevant source code?
• Have you ran the debugger? What does the call stack look like? Don't know how the debugger works? Find a tutorial, seriously, this is the most important tool for a developer
• Is it a compiler or linker error? A crash? What's the exact message?

...

[massive_potato]

Is the sf::Texture that you're binding to the Sprite still in scope? If not, that could be what is causing your problem.

[Azaral]

What I'm doing is trying to get the filename of the sprite for use in a sprite sheet for a level builder. Something isn't working the way I think it should be working...

I'm using SFML 1.6, Windows 7, Visual Studio 2010 express. I've recompiled SFML for use with 2010.

The user creates a new level, and then creates a new room in that level. Then when a new room is created, they can create new tile layers (background, foreground, etc). When they do this, they specify the image file they want to use for that layer. I can get the filenames just fine. However, there are two problems. First, here is the new layer creation code:

Code: [Select]

void Room::AddNewLayer(std::string spriteFileToUse, int position, float scaleModifier)
{
tileLayers.push_back(LevelLayer(spriteFileToUse, width, height, scaleModifier));
}

the tileLayers variable is a std::vector. It's size is 0 to begin with and right now I'm just pushing them to the back of the vector to try and get something working.

Here is the LevelLayer constructor being used:

Code: [Select]


LevelLayer::LevelLayer(std::string setSpriteFile, int setWidth, int setHeight, float setScaleModifier)
{
spriteFile = setSpriteFile;

width = setWidth;
height = setHeight;

visible = true;
halfVisible = false;

scaleModifier = setScaleModifier;

tile.resize(width);

for(unsigned int i = 0; i < tile.size(); i++)
{
tile[i].resize(height);
}

spriteImage.LoadFromFile(spriteFile);

spriteSheet.SetImage(spriteImage);
}

Using the AddNewLayer function as shown does not produce an image in the tile selection window. However, if I change it to:

Code: [Select]

void Room::AddNewLayer(std::string spriteFileToUse, int position, float scaleModifier)
{
tileLayers.push_back(LevelLayer(spriteFileToUse, width, height, scaleModifier));
tileLayers[tileLayers.size() - 1].ChangeSpriteSheet(spriteFileToUse);
}

The inclusion of the second line causes the sprite to show up on the screen. Here is ChangeSpriteSheet function:

Code: [Select]

void LevelLayer::ChangeSpriteSheet(std::string newSpriteFile)
{
spriteFile = newSpriteFile;

spriteImage.LoadFromFile(newSpriteFile);

spriteSheet.SetImage(spriteImage);
}

It does the same thing as far as generating the sprite goes as the constructor but this causes it to show up. However, if another new layer is added, then the previous sprite fails to show up. The newest layer added is the only one that has it's image show up if you cycle through the layers.

This is the rendering code for getting the sprite to show up in the tile selection window (not an sf::Window):

Code: [Select]

void Editor::DrawSpriteWindow()
{
if(currentRoom != NULL && currentRoom->GetNumberOfLayers() > 0)
{
sf::Sprite temp = currentRoom->GetLayerSpriteSheet(currentLayer);

temp.SetPosition(spriteWindow.GetX(), spriteWindow.GetY());

app->Draw(temp);
}
}

I've got to be missing something but I can't see where it's going wrong.

[Azaral]

Fixed this problem. Had to implement a copy constructor (probably something that should be done every time but for me its usually not an issue, till now)

[Nexus]

Fixed this problem. Had to implement a copy constructor (probably something that should be done every time but for me its usually not an issue, till now)

Actually not. In a well-designed program, it is very rarely necessary to implement the Big Three (copy constructor, copy assignment operator, destructor). Doing so often is a good indicator that your members are badly encapsulated, and thus don't have value semantics.

Further tips:

• Prefer the constructor initializer list over assignments
• Pass big objects like std::string per const reference
  

[Laurent]

Actually not. In a well-designed program, it is very rarely necessary to implement the Big Three (copy constructor, copy assignment operator, destructor). Doing so often is a good indicator that your members are badly encapsulated, and thus don't have value semantics.

... however in this specific case, it has to do it

[Nexus]

With his current design, yes.

The question is if it's a good idea to copy the textures unnecessarily. But the alternative would be more complicated, so as long as it's not critical, there should be no problem.

[Azaral]

I was passing the std::strings by reference, i had turned it to by value just to see if it was going to change anything.  This doesn't happen except when the user makes it happen so it's not like it's a big deal.

I think it has something to do with the way that sf::Image and sf::Sprite work. I was trying to keep them stored inside of their respective layer classes, but I think the program was losing the reference to the image when a new layer was created. It could remember its size, but it couldn't access the pixel data so it just made it white.  so when it pushed the new layer to the vector, the info wasn't correct transfered. I made the copy constructor reload the image from file. Probably not the best way to do it, but it works and expense isn't an issue because this operation is something that won't occur very often.