SDL_PIXELFORMAT_RGBA32 confusion

SDL_PIXELFORMAT_RGBA32 is an alias for for SDL_PIXELFORMAT_RGBA8888 on big endian machines and for SDL_PIXELFORMAT_ABGR8888 on little endian machines

Ok.

But it worked counter-intuitively for me, and I’m kind of confused.

I made an array of 32-bit values (pixelformats) formatted as RGBA, written as 0x01020304
And put them in a texture with the SDL_PIXELFORMAT_RGBA32 flag.

The result was that the texture was displayed as ABGR (because my computer is little endian, like everyone elses)

The solution was to just change the pixelformat to SDL_PIXELFORMAT_RGBA8888

But I’m still confused why in my scenario it didn’t work, and I’m curious what is the scenario where this works properly. When I manually write a hex number, it is logical for the computer to store it in memory in reverse (little endian). This means the flags don’t take the value byte by byte from memory, but as a 32 bit chunk, interpreted into the normal (big-endian) value.

So in what scenario do bytes come one by one where they need to be reversed and where SDL_PIXELFORMAT_RGBA32 makes sense?

In short, am I ok with my current setting of SDL_PIXELFORMAT_RGBA8888, and RGBA ordered hardcoded 32-bit hex values like 0x01020304 ? Will this work properly on big endian as well?

I think SDL_PIXELFORMAT_RGBA32 means that the byte order will be RGBA (regardless of the endianess of the computer).

byte1=Red, byte2=Green, byte3=Blue, byte4=Alpha


I think SDL_PIXELFORMAT_RGBA8888 means the byte order you would get if you wrote RGBA, in that order, using an integer literal. This means the byte order of this format would differ depending on the endianness of the computer.

0xRRGGBBAA
=>
Big-endian: byte1=0xRR, byte2=0xGG, byte3=0xBB, byte4=0xAA
Little-endian: byte1=0xAA, byte2=0xBB, byte3=0xGG, byte4=0xRR


I made an array of 32-bit values (pixelformats) formatted as RGBA, written as 0x01020304

On little-endian this gives you:

byte1=0x04, byte2=0x03, byte3=0x02, byte4=0x01

And put them in a texture with the SDL_PIXELFORMAT_RGBA32 flag.

If what I wrote above is correct this is saying first byte in memory should be interpreted as red, the second as green, etc.

Red=0x04, Green=0x03, Blue=0x02, Alpha=0x01

The solution was to just change the pixelformat to SDL_PIXELFORMAT_RGBA8888

If you want 0x01020304 to be interpreted as
Red=0x01, Green=0x02, Blue=0x03, Alpha=0x04
then this format is probably what you want.