# SFML fail to load image as texture

I have come to a problem with the code below ... Using SFML 2.0

#include <SFML/Graphics.hpp>

#include <iostream>
#include <list>

int main()
{
float speed = 5.0f;

// create the window
sf::RenderWindow window(sf::VideoMode(sf::VideoMode::getDesktopMode().height - 300, 800), "Bricks");

// Set game window position on the screen
window.setPosition( sf::Vector2i(sf::VideoMode::getDesktopMode().width/4 + sf::VideoMode::getDesktopMode().width/16 , 0) );

// Allow library to accept repeatitive key presses (i.e. holding key)
window.setKeyRepeatEnabled(true);

// Hide mouse cursor
//window.setMouseCursorVisible(false);

// Limit 30 frames per sec; the minimum for all games
window.setFramerateLimit(30);

sf::Texture texture;
if (!texture.loadFromFile("tile.png", sf::IntRect(0, 0, 125, 32)))
{
return -1;
}

// Empty list of sprites
std::list<sf::Sprite> spriteContainer;
bool gameFocus = true;

// run the program as long as the window is open
while (window.isOpen())
{
sf::Vector2i mousePos = sf::Mouse::getPosition(window);

// check all the window's events that were triggered since the last iteration of the loop
sf::Event event;
while (window.pollEvent(event))
{
float offsetX = 0.0f, offsetY = 0.0f;

if(event.type == sf::Event::GainedFocus)
gameFocus = !gameFocus;
else if(event.type == sf::Event::LostFocus)
gameFocus = !gameFocus;

if(event.type == sf::Event::KeyPressed)
{
if (event.key.code == sf::Keyboard::Space)
{
if(gameFocus)
{
// Create sprite and add features before putting it into container
sf::Sprite sprite(texture);
sprite.scale(.9f,.7f);
sf::Vector2u textSize = texture.getSize();

sprite.setPosition(sf::Vector2f(mousePos.x-textSize.x/2.0f, mousePos.y - textSize.y/2.0f));

spriteContainer.push_front(sprite);
}
}

if(event.key.code == sf::Keyboard::P)
std::cout << spriteContainer.size() << std::endl;

if( event.key.code == sf::Keyboard::W )
offsetY -= speed;

if( event.key.code == sf::Keyboard::A )
offsetX -= speed;

if( event.key.code == sf::Keyboard::S )
offsetY += speed;

if( event.key.code == sf::Keyboard::D )
offsetX += speed;
}

// "close requested" event: we close the window
if (event.type == sf::Event::Closed || event.key.code == sf::Keyboard::Escape)
window.close();

// Move all sprites synchronously
for (std::list<sf::Sprite>::iterator sprite = spriteContainer.begin(); sprite != spriteContainer.end(); ++sprite)
sprite->move(offsetX, offsetY);

//sprite.move(offsetX,offsetY);
}

// clear the window with black color
window.clear(sf::Color::Black);

// draw everything here...
// window.draw(...);
// Draw all sprites in the container
for (std::list<sf::Sprite>::iterator sprite = spriteContainer.begin(); sprite != spriteContainer.end(); ++sprite)
window.draw(*sprite);

// end the current frame
window.display();
}

return 0;
}


A couple weeks ago it worked flawlessly to my expectation, but now that I come back to it and I am having problems importing the image as a texture "tile.png". I don't understand why this is evening happening and the only message I get via the terminal is "Cannot load image ..." then a bunch of random characters. My libraries are for sure working, but now I am not sure why the image is not loading. My image is in the same directory as with my .h and .cpp files.

This is an irritating problem that keep coming up for some reason and is always a problem to fix it.

I import my libraries via my own directory "locals" which contain many APIs, but I specifically get SFML, and done appropriately as I am able to open a window and many other stuff.

• Why are you passing 125,32 as the size? That image is square, and 125 is a bad choice (non-power-of-two) for a texture, if you have the option. Jun 27 '13 at 7:18
• Simply, it was just to get the smaller squares from within the tile. The rect I get is the top most left tiles. 3 straight done from the top. Nonetheless this worked before and didn't cause any conflicts, but now it does for some reason. Jun 27 '13 at 7:35
• Are you mixing debug and release libraries? If you're compiling in debug, use the debug (-d) libraries. If you're in release, use the relase ones. Jun 27 '13 at 10:06
• I don't really know but Visual Studio doesn't like when you mix them. BTW, it's written in red in the official tutorial: sfml-dev.org/tutorials/2.0/start-vc.php Jun 28 '13 at 16:49
• This might happen just due to structures (such as STL stuff) having different alignments or optimizations. For example, one build might expect an offset of +5 byte while the other build would have an offset of +6 bytes. It's just one byte off, but might already screw something up (overwriting something else). Sep 25 '13 at 10:16

OpenGL does not like loading in textures that are not to the power of 2, some loaders add padding to make up to these numbers, but you cannot account for all libraries you use to achieve this. Try scaling the image to 512x512 as opposed to 510x510 and change 125 to 128, usually the texture will load in this instance in graphics libraries and you will experience tearing and distortion across the surface of the model, as it moves in relation to the view port.

To ensure completely that your project is finding the specified file, type the absolute path destination, instead of just the file name. This will eliminate any possibility that the project is unable to find the file.

• What is a better way in finding this absolute path, when lets say this gets distributed to multiple people. The path wont always be the same. Does Microsoft provide a library for handling OS related stuff in finding current directory. Jun 27 '13 at 8:59
• I have done the absolute path. So failing. sf::Texture texture; if (!texture.loadFromFile("C:\\Users\\Samsung\\Documents\\Visual Studio 2010\\Projects\\teest\\tile.png", sf::IntRect(0, 0, 128, 32))) { return -1; } Jun 27 '13 at 9:11
• simply Microsoft Visual Studios throws this at me "Unhandled exception at 0x778e15de in teest.exe: 0xC0000005: Access violation reading location 0x00566000." At the above code section I sent. Jun 27 '13 at 9:12
• You won't be using the absolute path upon distribution, this was purely for the purposes of testing, to ensure the library(and your project) are able to find the correct file. Jun 27 '13 at 9:19
• Ok, understood, but I still fail to load the image. Have any ideas why this is occuring? Jun 27 '13 at 16:00

From the documentation of sf::Texture:

"Like sf::Image, sf::Texture can handle a unique internal representation of pixels, which is RGBA 32 bits. This means that a pixel must be composed of 8 bits red, green, blue and alpha channels – just like a sf::Color."

I think SFML forces RGBA pixels, because this way, it doesn't have to care about 4 byte aligment when uploading to OpenGL, and also working with data aligned to 4 bytes is usually faster despite the memory overhead.

Your image doesn't have an alpha channel, and probably this is the source of the error.

• SFML automatically changes these RGB pixels to RGBA pixels under the hood, I'm pretty sure (since they are just pixels with 100% alpha).
– Pip
Dec 19 '14 at 21:46