Archived

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

16 Bit color limits?

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
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

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

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 this post


Link to post
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:

BYTE *pMem = some_buffer_start_address
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);
BYTE *pMem = some_buffer_start_address
*((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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites