Understanding the pixel formats in SDL (ABGR or RGBA). |
ShiroAisu
|
I'm sorry, I meant:
|
|||||||||||||||
|
Understanding the pixel formats in SDL (ABGR or RGBA). |
Sik
|
SDL_PIXELFORMAT_RGBA8888 takes the current endianess, if I recall
correctly (so indeed it'll be ABGR... but AGBR, huh?). Also err, are you sure this is correct? 2 * sizeof(ILuint) (note: didn't check the function documentation and I don't remember exactly what it wants right now, have to do other things right now - that looks suspicious though) 2013/9/16, ShiroAisu:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Re: Understanding the pixel formats in SDL (ABGR or RGBA). |
ShiroAisu
|
I meant ABGR yes, sorry, I'm tired.
Yes, it is the size in bytes of the first row of pixels in the image, it is static like that just for testing purposes. I honestly find it kind of a strange argument tho, never have I had to pass anything like this before.
So... wait... if that is the case, does it only respect little endian byte wise and not bit wise? If yes, why would it do that? I don't get it. Once again, that isn't very common is it? I never had to take such a thing into account before. |
|||||||||||||||||
|
Understanding the pixel formats in SDL (ABGR or RGBA). |
Sik
|
2013/9/16, ShiroAisu:
When you use that format you're supposed to use 32-bit integers, not bytes, so it takes whatever endianness the current CPU has. Note that there are variants of that format that have a specific endianness, so if you want to pass bytes, consider using those instead. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Understanding the pixel formats in SDL (ABGR or RGBA). |
John Tullos
Guest
|
Why does SDL take such a trivial approach to this? Endianness should have nothing to do with this really. If I tell it I have a pixel format of ARGB8888 its dead obvious where the bits are regardless of what CPU I'm using. It's explicit. Why make it more complicated than it needs to be? This is somewhat of a rant and I wouldn't mind hearing an answer on this. OpenGL did not do this and I do not recall Direct3D doing this either.
|
|||||||||||||||
|
Understanding the pixel formats in SDL (ABGR or RGBA). |
Rainer Deyke
Guest
|
On 17.09.2013 14:44, John Tullos wrote:
ARGB8888 means that the color is encoded as 0xAARRGGBB or 0bAAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB, i.e. alpha in the most significant 8 bits, red in the next most significant 8 bits, and so on. To see why this is the only correct interpretation, consider any pixel format that doesn't allocate exactly 8 bits - for example, RGB565 is correctly stored as 0bRRRRRGGGGGGBBBBB, not as the byte-swapped 0bGGGBBBBBRRRRRGGG. -- Rainer Deyke _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Understanding the pixel formats in SDL (ABGR or RGBA). |
Sik
|
No, it isn't obvious. Hardware sees each pixel as a word (in this case
32-bit words), so it has endianness issues, and software tends to follow along, especially for performance reasons. SDL lets you take either approach. You can treat pixels as words and take the platform-dependent type (which changes endianness depending on the system), or you can treat them as bytes and take the platform-independent types. Since the only thing you really need to do is choose the appropriate format, this really isn't as complex as it sounds (moreover, the platform-dependent types are just aliases to the platform-independent ones). 2013/9/17, John Tullos:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
Re: Understanding the pixel formats in SDL (ABGR or RGBA). |
ShiroAisu
|
I still have one question tho, if it is supposed to read a full 32 bit string, they why does it only switch the order of the individual components and not of the entire string? For instance, if I have 2 components RG, why does: 01000000 10000000 become 10000000 01000000 and not 00000001 00000010 ?
How would I treat them as bytes then? What format would I use for that? The documentation is really lacking IMO. |
|||||||||||||||
|
Understanding the pixel formats in SDL (ABGR or RGBA). |
Sik
|
2013/9/17, ShiroAisu:
Because endianness works at the byte level, not at the bit level. This is a legacy we inherited from old 8-bit processors which were all little endian (which was easier to implement), and the most successful processor series started as one (8088 had an 8-bit bus) ._.' Personally I'd prefer if we stuck to big endian, but it's too late to change that.
*looks at wiki* WTF, the processor-independent types used to be specified there, I swear, what happened to them? o_o *looks in the headers* Ugh, looks like they got rid of that -_-' Guess it has been quite a while since I looked at this (like, when I had started working on my game). It seems now everything is little endian now (for whatever reason). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Re: Understanding the pixel formats in SDL (ABGR or RGBA). |
ShiroAisu
|
How would I work around this then? I have a series of bytes representing each pixel component, do I have to do everything differently for each system? |
|||||||||||||
|
Understanding the pixel formats in SDL (ABGR or RGBA). |
Sik
|
No, it seems SDL now takes little endian always (i.e. lowest byte first).
If somebody spots an error tell me, going by what I've seen in the header. 2013/9/17, ShiroAisu:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Understanding the pixel formats in SDL (ABGR or RGBA). |
Jonas Kulla
Guest
|
2013/9/17 ShiroAisu
Because there would be no point, it would completely change the numerical value. Little endianness is not just some "hardware quirk" it is designed for specific purposes, such as eg. being able to address values < 256 stored in a 32bit int through an 8bit char pointer. The endianness on the bit level is completely transparent to the user, as the octet is the smallest addressable data unit on current CPUs. Jonas |
|||||||||||||
|
Re: Understanding the pixel formats in SDL (ABGR or RGBA). |
ShiroAisu
|
Correct me if I'm wrong, but does that mean that I dont need to work around it? Will it be little endian on every system? |
|||||||||||||
|
Understanding the pixel formats in SDL (ABGR or RGBA). |
Sik
|
Yeah, that seems to be the case if I understood the headers correctly.
Just so you know: this means the bytes are in reverse order (i.e. RGBA has alpha first and red last), so you'll probably still need to deal with that. 2013/9/18, ShiroAisu:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Re: Understanding the pixel formats in SDL (ABGR or RGBA). |
ShiroAisu
|
Alright, Ill just use ABGR when I want RGBA then, if anyone has any observations it would be appreciated, but for now thank you very much for your help. |
|||||||||||||
|