# three into one variable does go?

• 09-28-2009
rogster001
three into one variable does go?
in the example below i can't understand how the variable 'color' can apparently store the indivdual RGB values, in the header file it describes this function as
Quote:

Maps an RGB triple to an opaque pixel value for a given pixel format
could anybody please enlighten me on this?

and the Uint32, is that some kind of SDL variable type or just an alternative way of writing unsigned 32bit integer? i mean would simply 'int color' have worked here too?

Code:

```SDL_Rect rect;     Uint32 color;     color = SDL_MapRGB (screen->format, 50, 50, 50);     SDL_FillRect (screen, NULL, color);```
• 09-28-2009
rogster001
actually i think this makes sense really, the call carries the R G B values into the function which then returns them as a single value that can be referenced as a colour. understanding how this works is another matter
• 09-28-2009
Sebastiani
Well, since each RGB value here is constrained within the range 0-255, it fits perfectly into a single byte. So obviously, you can pack all 3 of them into a 32-bit integer, with 1 byte to spare (often this extra one is used to carry the 'alpha' (opacity) channel).
• 09-28-2009
Dae
This is commonly shown when converting RGB to hex (binary to operate per byte):

Code:

```rgb = (a << 24)         + (r << 16)         + (g << 8)         + b; ... rgb = ((r & 0xFF) << 16)         | ((g & 0xFF) << 8)         | (b & 0xFF);```
Code:

```a = (color & 0xFF000000) >> 24; r = (color & 0x00FF0000) >> 16; g = (color & 0x0000FF00) >> 8; b = (color & 0x000000FF); ... r = (color & 0xFF0000) >> 16; g = (color & 0x00FF00) >> 8; b = (color & 0x0000FF);```
Something like that, I guess. I took it from an AS project. RGBA would include the last byte (24 bits into a 32 bit byte).
• 09-28-2009
Sebastiani
Well, the important thing to remember is that the color data in compact format should be treated strictly as an 'opaque' value. The implementation could choose to change the format at any point in the future, for whatever reason, and moreover, the internal representation might actually map to a completely different color model (a pallete index, for instance), altogether. So the safest way to approach it is to simply consider it a handle to some abstract color type.
• 09-28-2009
quzah
Code:

```union rgbquad {     struct     {         unsigned char r;         unsigned char g;         unsigned char b;         unsigned char a;     } rgba;     uint32 quad; }; ... uint32 foo( unsigned char r, unsigned char g, unsigned char b, unsigned char a = 0 ) {     union rgbquad bar;     bar.rgba.r = r;     bar.rgba.g = g;     bar.rgba.b = b;     bar.rgba.a = a;     return bar.quad; }```
There you go. Swap out 'uint32' for some unisgned 32 bit integer type of your choosing.

Quzah.
• 09-28-2009
rogster001
Quote:

simply consider it a handle to some abstract color type.
Does this mean like in the old sense of enumerated type colours, like Magenta, = 9, high intensity white = 7 etc?
• 09-28-2009
Sebastiani
Quote:

Originally Posted by rogster001
Quote:

simply consider it a handle to some abstract color type.
Does this mean like in the old sense of enumerated type colours, like Magenta, = 9, high intensity white = 7 etc?

Or rather like a pointer to some implementation-defined type. In other words, it may very well be simply 3 bytes packed onto an integer, but then again, it could also be an index into a pallette entry, or even a pointer to some complex object. RGB isn't the only way to represent colors, after all. The internal system may choose to use floats for better precision, or perhaps the HSV color space, or whatever. Besides that, different systems have their own capabilities/limitations. Some displays are monochrome, for instance, so RGB might be meaningless in that context. So the bottom line is, by separating the 'handle' from the RGB has more uses than just a handy place to stuff three bytes into. It makes portability more straightforward.