I just recently read some of the articles on 16 bit color in the DirectX/DirectDraw section of the articles page, and I was wondering about one person's approach. In the article "16 Bit Color" by TANSTAAFL, he computes the number of bits to left shift the red, green, and blue components of a 16 bit RGB color by using the the bitmask values provided in a DDPIXELFORMAT structure (that was filled out, of course, by the GetPixelFormat method). I understand how the left shift values are computed just fine. But later on in the article he computes a number to shift bits to the RIGHT. TANSTAAFL writes that this is so one can create a 16 bit color from a 24 bit color. Although I'm still not quite sure how the right shift values are computed (I just need to work it out on paper) my question is WHY do you need right shift values? I worked out a simple example on paper and, assuming the red, green, and blue color components are each stored in an unsigned char, I was able to come up with the correct RGB WORD value after doing just left shifts and ORing each component together. Is there any real reason to compute right shift values (or any reason to right shift at all) when composing a 16 bit RGB color? Edit: Just another thing I was wondering about... in another article on the same subject called "Bit Depth Independent Pixel Plotting in Direct Draw" by Ron Hiler, he presents a similar idea. Here's just a snip of the code he uses along with an explanation:
"This part of the routine only comes into play in 16 bpp mode. In 24 and 32 bpp, the precision is greater than or equal to 8, so no shift occurs. But in 16 bpp, the three RGB bytes must be compressed into two bytes. To achieve this, the low order bits are dropped until the color component fits into it’s designated bit size (usually 5 or 6 bits)." Is it true that if the number of bits you want to shift by is negative that no shift occurs? I read in a book somewhere that if the number of bits to shift is negative that the result is undefined. Just looking for some clarification. [edited by - MRom on October 30, 2002 5:09:43 PM]

You may want to read this thread as well.

***********************
          

Thank you very much. Those were some very informative and detailed posts you made. I appreciate the amount of info you gave, yet presenting it in a very simple to understand manner. Hats off.

No problem. Glad I could help

***********************
          

I''m sorry about bumping this back up to the top, but I have one final question/problem. I use the final copy of the bitmap loading routine you posetd on the other thread you showed me, making sure I didn''t miss anything out. Only problem I have now is that whenever I load the bitmap onto a offscreen surface, blit it to the backbuffer, then flip the primary and backbuffer, my bitmap turns out all screwed up. Instead of the actual images, it''ll have narrow vertical lines going across it, usually of two alternating colors, mainly a pink and a blue. I''ve tried different bitmaps (all of them being 24 bit) but I get the same results. Does anyone know why my bitmap might turn out to be a series of vertical lines of alternating colors?

Can you post a picture?

***********************
          

I just snipped out what the bitmap looked like when displayed on the screen....



Here's a screenshot of the fullscreen, with the bitmap in the upper left corner of the screen.



[edited by - MRom on November 2, 2002 5:48:52 PM]

I probably should have asked you to post what it originally looked like too. Could you please post the original bitmap as well?

***********************
          

I had to find someone else to host my picture for me, so that''s why it took me a while to respond. But hopefully this will help you.

Orignal bitmap