I looked through the allegro sources (namely the function makeacol32), and noticed that there's a way to determine the active rgb-order, as follows:

bool RGB_direction()
{
  // true: for r-g-b
  // false: for b-g-r
  return ((_rgb_r_shift_32 == 16) && (_rgb_g_shift_32 == 8) && (_rgb_b_shift_32 == 0));
}

And so ? What is the question ?

Im guessing Geoman just wanted to share, which is good i guess

[edited]

I'm dumb today

It can come in handy in case someone wants to write a color-byte directly to the screen memory, so I thought I'd mention it.

I remember that once biting me in the butt when I was making my own bitmap loading code; I could have used that once upon a time.

It's pretty trivial, but when you need it, you don't usually think of it.

Another way, using only the public allegro api (thus api compatible) would be:

// assuming 24 bpp
bool rgb_ordering() {
  int c = makecol(255, 0, 0);
  return ((c & 0xFF) != 0);
}

Darn it, you're right
The example I gave also only requires the public API, btw.

_rgb_r_shift_32 isn't in the public api AFAIK. At least at a quick glance, I couldn't find it in the docs.

It starts with an _, so it isn't public. It's in the user headers because there's some inline code and macros that use it, but you aren't supposed to use it directly.

You can't really go around assuming any order, anyway. RGBA and ABGR isn't the only combination there may be, after all. ARGB, BGRA, etc, are also valid.

You have a point...

It appears DIB's are given to you with a specific color ordering (which makes sense, since it's Device Independant (Bitmap)). As you can see, it checks to see if the dest is the same order as the source, and just does a straight copy if so, otherwise it pulls out the individual colors and reconstructs them with makecol32. You can't simply check where the red value ends up to determine the order for all 4 values, though.

EDIT:
Sure, edit while I'm typing a reply. There's no love for the cats.

Yeah... well, I noticed that too after rereading the gdi.c file, so I edited my post. I didn't realize this earlier.

Yet, having the A located in the lower byte is kinda unusual isn't it ?

For now, I'll simply write some code that does not support videocards that have A values in the low byte. It's good to know that this limitation exists, though Those hardware designers really don't have software issues in mind when they design their stuff, do they.

Part of the problem is CPU endianesse. Since, for example 32-bit modes are stored as 4 bytes, it's usually packed into a 32-bit int. However, the bytes in a 32-bit int can be stored in a different order between different types of CPUs.

I happen to be very fond of cats

If I'd summarize, then if I target pentium-compatible computers (which is my main interest), then the location of A should always be the high byte ?

Yet the R and B location are video-card dependent ?

Is the G value always in the center of the rgb/bgr triplet ?

I suppose that the endianness is really only a problem on apples and unixes ?

You'll typically find RGB or BGR with A on one side or the other. But this isn't gauranteed. I believe there are some cards that do RBG (and thus GBR). It's best not to assume at all.