texture.update() crash

[Foaly]

Hi there!
I am trying to fill a texture with some gray color. My very simple test code crashes... The code:

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(500, 500), "SFML works!");
    window.setFramerateLimit(60);

    sf::Uint8 pixelBuffer [250000];

    sf::Texture texture;
    texture.create(500, 500);


    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
                window.close();

            if(event.type == sf::Event::KeyReleased && event.key.code == sf::Keyboard::Escape)
                window.close();

        }


        for(int i = 0; i < 249999; i++)
        {
            sf::Uint8 color = 128;
            pixelBuffer[i] = (color << 16) | (color << 8) | color;
        }
        texture.update(pixelBuffer, 500, 500, 0, 0);  //<---- crash happens here


        window.clear();
        window.draw(sf::Sprite(texture));
        window.display();
    }

    return 0;
}
 

I get a SIGSEGV fault. I haven't used the update() method of sf::Texture before, so I don't really know if I handle everything correct. Does somebody know what I'm doing wrong? I'm using the latest source with MinGW 4.7.2 on windows 7.
Thanks, Foaly

[eXpl0it3r]

What happens if you insert this, before calling update:

if(sf::Texture::getMaximumSize() < 250000/4)
    return -1;

Your GPU most probably doesn't support textures of size 6250px.

The question is, if there should be an assert at least in debug mode, that checks for the value, rather than letting SFML crash...

No additional check is performed on the size of the pixel array or the bounds of the area to update, passing invalid arguments will lead to an undefined behaviour.

Then again maybe it's just your false calucaltions, because one pixel consists of 4 sf::Uint8 (R G B A), so you for a 500x500px = 25000px image you'll need a array of 4x500x500 = 1000000 uint8.

[Foaly]

If I insert your code the program returns -1 of course. But I'm not trying to make a texture of size 6250px. I want a 500x500 texture. I guess I mixed up some math... What did I do wrong though?

The question is, if there should be an assert at least in debug mode, that checks for the value, rather than letting SFML crash...

I'd say so! (for debug that is)

[eXpl0it3r]

See above (was too fast and then too slow)...

[Foaly]

Haha awesome thanks! That was it! Makes total sense now that you explain it. Thank you very much.

I know the doc says, that passing invalid arguments results in undefined behaviour, but I think it would be a good idea to add an assert in debug mode.

[Foaly]

After reading your explanation and the doc again I'm still a little bit confused. The "pixel" array doesn't actually contain pixels, does it? It contains the pixel components in uint8 in the order RGBA for each pixel, right? If that's the case then I think the parameter should be renamed to pixelComponents or something like that. Also the (otherwise awesome) doc should make this a bit clearer. Right now it's says: "it must contain 32-bits RGBA pixels" maybe it could say something like: "it must contain an array of pixel components of sf::uint8. Four components per pixel in the order RGBA." I think this would clear things up

edit: also does this mean that I should fill the array like this, if I want a medium gray texture?

for(int i = 0; i < 249999; i += 4)
{
    sf::Uint8 color = 128;
    pixelBuffer[i] = color;     // r
    pixelBuffer[i +1] = color;  // g
    pixelBuffer[i + 2] = color; // b
    pixelBuffer[i + 3] = 255;   // a
}
texture.update(pixelBuffer, 500, 500, 0, 0);

[Foaly]

Where my assumptions right? Also am I the only one who is confused by the documentation of this method?

[eXpl0it3r]

it must contain 32-bits RGBA pixels

Which already implies that you need 4*8 bits = 4*sf::Uint8, it's clear enough imho.

edit: also does this mean that I should fill the array like this, if I want a medium gray texture?

Should be correct. Also you could've just tested it...

[Nexus]

The "pixel" array doesn't actually contain pixels, does it? It contains the pixel components in uint8 in the order RGBA for each pixel, right?

What is a pixel, if not an RGBA value?

[Foaly]

Alright well i guess I just got it wrong then... If it's clear to eveybody else then it's fine.
I did test the code, but i got some wierd vertical lines. I can't find it anymore though, so i can't post it.