#### Archived

This topic is now archived and is closed to further replies.

# 16 Bit color limits?

This topic is 6663 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey, I just started progrmaming 3D and I decided to use DX Just to get the system set up to the res I want, I am NOT using D3D, I just set everything up and lock the surface once per frame, and unlock right before the flip. I''m running in 640x480x16b mode. I downloadd some code a while ago, i have no idea where I got it from, but it seemed to work. It can get an R, G, or B value from a 16bit color and make one using RGB16(r, g, b). You must initialize it first with a surface so it knows whether it''s 556 or 565 or whatever, which I do. So here''s the problem, it took me a while to find it cause i just thought my lighting function was messed up. I realized that every 32 numbers, the color goes back to black. So, for instance RGB16(0,0,0) is black, RGB16(31 or 32 [i forget], 0, 0) is bright red, then RGB16(32 or 33, 0, 0) is black again, and so on till 255 which is bright red. So, anyone know what the dilly is? Can you only choose numbers form 0->32 per color component in 16b mode? And one more semi-related question. Let''s say i skip 16b and go into 24b mode. Right now I plot pixels like so I have unsigned short *buffer, and lock the back buffer to that. then I do buffer[y*ddsd.lPitch + x] = RGB16(bla bla bla) (btw, lPitch is divided by 2 when i lock the surface) That works fine since buffer is declared as a two byte integer What if i wanted to plot in 24 bit mode and make it = RGB(bla bla bla). 1) Would i get to use values from 0 to 255? 2) What type should i use for buffer? 3) Should i just do 32b mode and use a long type for buffer? Any help would be appreciated Thanks guys - Rob ByteMe95::~ByteMe95()

##### Share on other sites
The problem might be that your RGB16(r,g,b) function is defined as:

(red << 10) | (green << 5) | (blue)

or even

Or something to that effect; both the above, while looking ok, neglect the fact that the colour range in 16 bit is not 0->255 per component, but 0-31 per component (in 555)...

To solve this you should scale your R,G and B value before plugging it into your RGB16 function (or alter your RGB16 function). The simplest method would be:

RGB16(red >> 3, green >> 3, blue >> 3)

which would expand to:

(((red >> 3) << 10) & rmask) | (((green >>3) << 5) & gmask) | ((blue >> 3) & bmask)

and you can optimise out the shifts...

Hope that helps...

Jans.

-----------------
Janucybermetaltvgothmogbunny

##### Share on other sites
Oh, missed a bit:

For a 24 bit plot you''ll have to find some way of getting your DWORD into memory correctly. Either put the components in separately e.g. Simplest case:

pMem[0] = blue
pMem[1] = green
pMem[2] = red

(wrap it in a loop with indices of course)

Or mask the dword into memory

DWORD dwMyColor = RGB24(red, green, blue);
*((DWORD*)pMem) = (*((DWORD*)pMem) & 0xFF000000) | dwMyColor;

Which asumes there''s no crap in the upper byte of your DWORD

I think that''s it...

Jansic.

-----------------
Janucybermetaltvgothmogbunny

##### Share on other sites
JAnsic, thanks a lot for all the info, I could really use it.
So, one more question. For 24b mode, which is faster to plot a pixel from the methods you should me?

Or would it just be faster to do 32b mode all together?

ByteMe95::~ByteMe95()

##### Share on other sites
It depends on your source data:
For a simple putpixel, it depends on your source pixel data. If you''re going to be specifying your function as (x,y,R,G,B) then place the components in individually. If you''re passing in an RGB value in a DWORD (x,y,color) then use the masking method. I personnally only use 16 bit mode and 32 bit mode in my programs; though this has a lot to do with the lack of 24bpp modes on my video card. I do have a 24 bit memory surface implementation though...

Jans.

-----------------
Janucybermetaltvgothmogbunny

##### Share on other sites
well, if i do use 16bit mode, do you think 32 shades of light (that sounds funny) should be good enough?

ByteMe95::~ByteMe95()

1. 1
2. 2
3. 3
4. 4
Rutin
15
5. 5

• 14
• 9
• 10
• 12
• 17
• ### Forum Statistics

• Total Topics
632910
• Total Posts
3009174
• ### Who's Online (See full list)

There are no registered users currently online

×