|
rgb order |
Geoman
Member #6,873
February 2006
|
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)); }
|
GullRaDriel
Member #3,861
September 2003
|
And so ? What is the question ? "Code is like shit - it only smells if it is not yours" |
Jonatan Hedborg
Member #4,886
July 2004
|
Im guessing Geoman just wanted to share, which is good i guess
|
GullRaDriel
Member #3,861
September 2003
|
[edited] I'm dumb today "Code is like shit - it only smells if it is not yours" |
Geoman
Member #6,873
February 2006
|
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. |
23yrold3yrold
Member #1,134
March 2001
|
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. -- |
Tobias Dammers
Member #2,604
August 2002
|
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); }
--- |
Geoman
Member #6,873
February 2006
|
Darn it, you're right |
Tobias Dammers
Member #2,604
August 2002
|
_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. --- |
Kitty Cat
Member #2,815
October 2002
|
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. -- |
Geoman
Member #6,873
February 2006
|
You have a point... |
Kitty Cat
Member #2,815
October 2002
|
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: -- |
Geoman
Member #6,873
February 2006
|
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. |
Kitty Cat
Member #2,815
October 2002
|
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. -- |
Geoman
Member #6,873
February 2006
|
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 ? |
Kitty Cat
Member #2,815
October 2002
|
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. -- |
Tobias Dammers
Member #2,604
August 2002
|
int c = makeacol32(1, 2, 3, 4); // now find the 1 for red, the 2 for green, and so on.
--- |
|