im trying to write a pixel format converter, so that no matter what color depth (only true color, 16bit & up) the screen is, drawing routines will work. but what i dont understand is the color bitmasks. i think i remember seeing an example where the red bit mask was 0x00FF0000 and im guessing that means where in the value the red goes? i dont know, thats why im asking. what are the color bitmasks, and how are they used to get the color''s bit size & shift?

It works like this. A 32-bit color value is in the format:

AAAAAAAARRRRRRRRGGGGGGGGBBBBBBBB       

Where A is alpha, R is red, G is green, and B is blue. To get the red value out of a color, you have to eliminate the green, blue, and alpha values. You do this with a bitmask. Say you had the following color (in binary):

0000 0000 1101 1111  1000 0000 0111 1111       

(R = 224, G = 128, B = 127)

As you can see, the red value (bold) is 11011111. To get the red value in your program, you have to get rid of the green and blue values. Remember that the & operater will set a bit to 1 if both operands are one. So if you were to AND the above color with this bitmask, you would be left with only the red:

00000000110111111000000001111111 (color)00000000111111110000000000000000 (bitmask, 0x00FF0000 in hex)--------------------------------00000000110111110000000000000000 (result from AND)       

What this does is leaves you with only the red value. Then you can bit shift it to the right to get it on the right side:

00000000110111110000000000000000 (result from AND)00000000000000000000000011011111 (result from bitshift right of 16)       

00000000000000000000000011011111 is 224 in decimal. You shift it 16 because that's the amount of bits that need to be shifted to get the red value to right. I hope you can see how it works now. You should be able to figure out how to get green and blue on your own.

Actually converting them is a little different. If you need help with the conversions, I'll try to explain.

Edited by - Midnight Coder on August 24, 2001 4:16:57 PM

i understand now! the bitmasks are what they say, masks. kinda like having a mask of a bitmap for blitting so only letting part of the bitmap (one of the colors) showing up.

i could use some help with the pixel conversion though. i know how to make a 24 and 32 bit pixel, but i have yet to find a good algorithm for 15 and 16 bit pixels. if you could show me one, id be very greatful. btw, also i guess this is more for your opinion, but for alpha blending, should i use floating point math and make it easier or should i stick to integers to make it faster?

any help appreciated
Rocket05

quote:

---

Original post by Rocket05
i understand now! the bitmasks are what they say, masks. kinda like having a mask of a bitmap for blitting so only letting part of the bitmap (one of the colors) showing up.

i could use some help with the pixel conversion though. i know how to make a 24 and 32 bit pixel, but i have yet to find a good algorithm for 15 and 16 bit pixels. if you could show me one, id be very greatful. btw, also i guess this is more for your opinion, but for alpha blending, should i use floating point math and make it easier or should i stick to integers to make it faster?

any help appreciated
Rocket05

---

Actually, depending on your program floating point math could actually be faster. On the Pentium line of processors (II, III and I believe Athlons as well), floating point math is just as fast as integer math. The only slowdown is conversion, so either use all integer math or all floating point math. (Exception: the Pentium 4 by default sends integer ops in pairs, so you can complete two integer operations in the time it would have taken one)

If you use MMX, SSE, SSE 2, or 3DNow you send floating point operations in batches that can go much faster than using the standard floating point ops.

And 16 bit color:

1. ARRRRRGGGGGBBBBB
2. XRRRRRGGGGGBBBBB (X = unused)
3. RRRRRGGGGGGBBBBB (1 extra green bit)

Check the card, because it can use any of the three.


Edited by - gph-gw on August 25, 2001 7:45:21 PM