Small sprite displayed, not correct pixels shown

[Ganado]

Using SFML 2.1, Code::Blocks 12.11, minGW gcc-4.7.1-tdm, "ThinkPad Display 1366x768" monitor

My issue is how a certain sprite looks by default when generated on the screen.

Here's the necessary code:

    const int WINDOW_WIDTH = 1024;
    const int WINDOW_HEIGHT = 576;

    sf::RenderWindow Window;
    Window.create(sf::VideoMode(WINDOW_WIDTH, WINDOW_HEIGHT), "azertyqwerty", sf::Style::Close);

    sf::Texture playerTexture;
    sf::Sprite playerSprite;
    if (!playerTexture.loadFromFile("player.png"))
        std::cout << "Error: Could not load player image" << std::endl;
    playerSprite.setTexture(playerTexture);
    playerSprite.setOrigin(playerSprite.getLocalBounds().width/2, playerSprite.getLocalBounds().height/2);
    playerSprite.setPosition(WINDOW_WIDTH/2, WINDOW_HEIGHT/2);

    while (Window.isOpen())
    {
        Window.clear();
        Window.draw(playerSprite);
        Window.display();
    }

Here's the original image file used: http://i1093.photobucket.com/albums/i434/GanadoFO/player.png

It is a 5x5 square image. The border is red and the center pixel is a golden color.

Here's what the sprite looks like when displayed, no scaling or other transformations:

Here's the same picture enlarged (externally in Paint, not via the scale function) to clearly show the error:

You can see the weird displacement of the pixels compared to the original image. This is the problem.

If I use the scale function to blow-up the image in program run-time, it becomes the intended look, albeit very big:


So, my questions:
Why does it not correctly display the image file the way it is? Why does it displace the border pixels, and how can I fix it?
Is it due to SFML itself or my monitor/gpu?

If someone can test my image to see if it does the same thing on their program, I would appreciate it, thanks.

[eXpl0it3r]

Make sure to round the position of the sprite to integer.

[Ganado]

That does appear to be the problem, but could you explain why? Considering 1024 and 576 are both divisible by 2, why does it still make a round-off error? If I make the initial position, for example,

    playerSprite.setPosition(512, 288);

it does display the sprite correctly. Sorry if that's a more basic C++ question as opposed to SFML.

Anyway, so I changed it to

    playerSprite.setPosition(int(WINDOW_WIDTH/2 + 0.5), int(WINDOW_HEIGHT/2 + 0.5));

and it also displays the sprite correctly, thanks.

EDIT:
Also, obviously the round-off issue applies to the origin as well.

playerSprite.setOrigin(playerSprite.getLocalBounds().width/2, playerSprite.getLocalBounds().height/2);

If I comment this line, the sprite shows up correctly, but if I keep it active, then it's the old problem again. Why does the origin position affect what my sprite looks like when it is displayed?

[eXpl0it3r]

It's the way OpenGL's rasterization works. If you're not on an integer value it's unfortunately very probable that things will be rasterized strangely. Since the origin of a sprite sets where the relative position, it is affected by this issue as well. The + 0.5 fix is sometimes happening if the origin sets you in between pixels.

[binary1248]

OpenGL 2.1 Specification: http://www.opengl.org/registry/doc/glspec21.20061201.pdf

Chapter 3 is about rasterization, including nice pictures and the same theory you will learn about in any computer graphics lecture.

The spec is one thing, vendor implementations are another. I highly doubt modern GPUs still employ the algorithms described in the spec e.g. Bresenham’s algorithm, more likely they use highly optimized versions of said algorithms that make most often valid assumptions about the data that they have to render. Since most of the work a GPU has to do nowadays is in 3D, such issues with pixel centres are probably not of much concern any more. As such, the 0.5 trick might work sometimes, but other times it might not work, be it because a different GPU is used to do the rendering, or because the data was optimized differently by a different driver etc. If I were you I would make sure my application was independent of such intricacies so that it looks the same on all systems. You just have to assume that if the GPU does something with a single pixel it will do so with all other pixels as well. As such the whole screen will be shifted by half a pixel for example, but in the end you won't even notice. You also have to ask yourself, can the player really notice all the pixel level detail? Especially on today's screen pixel densities...

[Ganado]

Thanks for the replies and the info, I think I understand now.