• Advertisement

Archived

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

blue tint in 16-bit?

This topic is 6378 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

when i display a 16-bit bitmap in 640x480x16 all the colors have a blue tinge(?) to them. anybody have this happen? (im using lamothes bitmap loading functions to do this)

Share this post


Link to post
Share on other sites
Advertisement
I havent had this happen to me but I know other people who have had this problem. I think its because there is something wrong in one of his macros RGB macros.

Share this post


Link to post
Share on other sites
Yup, Lamothe got lots of bugs in his code.
Here's the right macros: (The 565 is good, not sure about the 555)

#define RGB16_555(r,g,b) ((b & 31) + ((g & 31) << 5) + ((r & 31) << 10))
#define RGB16_565(r,g,b) ((b & 31) + ((g & 63) << 5) + ((r & 31) << 11))

(I changed the names of the macros a bit, but you get the point)

Then in Load_Bitmap_File() you should find the place where Lamothe converts a 24bit bitmap to 16bit.
Something like this:

USHORT color;
UCHAR red = temp_buffer[index*3+0]>>3,
green = temp_buffer[index*3+1]>>3,
blue = temp_buffer[index*3+1]>>3;

color = RGB16_565(red,green,blue);

The green shift is wrong, it should be:
UCHAR green = temp_buffer[index*3+1]>>2;

Goodluck


The road to success is always under construction

Edited by - Tornado on September 3, 2000 6:45:57 AM

Share this post


Link to post
Share on other sites
thanks tornado you were right... well almost. i just needed to convert the macro from _RGB16BIT((r%32)+((g%32)>>5)+((b%32)>>10))
to >>6 and >>11 but as for the Load_Bitmap_File function that works fine... at least so for it does. when i decide to check the computer for its color format i''ll have to change it.

Share this post


Link to post
Share on other sites
_RGB16BIT((r%32)+((g%32)>>5)+((b%32)>>10)) is from Lamoth code? You sure? I havn''t seen it
I should have mentioned that the part where you change Load_Bitmap_File() stands for the 565 part. I havn''t touched 555.
Have fun coding

Share this post


Link to post
Share on other sites
I have seen some strange things here.

Tornado your macro looked lie this:
((b & 31) + ((g & 31) << 5) + ((r & 31) << 10))

while xtrmntr''s code looked like this:
((r%32)+((g%32)>>5)+((b%32)>>10)).

So my question is: is x&31 the same as x%32?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If you''re going to be using 0-255 for you min-max color ranges, it would probably be best to use macros somewhere along the lines of these:

//(555) used to convert from rgb values (0 - 255) to 15 bit color
#define _RGB15BIT( r, g, b ) ((b>>3)+((g>>3)<<5)+((r>>3)<<10))

//(565) used to convert from rgb values (0 - 255) to 16 bit color
#define _RGB16BIT( r, g, b ) ((b>>3)+((g>>2)<<5)+((r>>3)<<11))


With the ones you are using (which mods by 32): 31, 63, 95, 127, 159, 191, 223, and 255 all come out as being max intensity in your colors. Of course this really only matters if you are using your macros to convert from other bitmap resolutions to 16bit.

Share this post


Link to post
Share on other sites
quote:
So my question is: is x&31 the same as x%32?


Actually, I think it is.

89 & 31 = 25 = 89 %32




The road to success is always under construction

Share this post


Link to post
Share on other sites
Anonymous: i tried both of your macros and the first one makes my colors look wacked while the second one makes all the colors alot darker then the way i drew them. can you explain a little more about why i would choose yours over mine?

Share this post


Link to post
Share on other sites
Anonymous: i tried both of your macros and the first one makes my colors look wacked while the second one makes all the colors alot darker then the way i drew them. can you explain a little more about why i would choose yours over mine?

Once I thought i was wrong but i was mistaken...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
What colour values are you supplying? The macro that the above Anonymous Poster (not me gave you expects a value of 0-255, with 0 being dark and 255 being maximum brightness. The one you have is just plain weird, it will have maximum brightness at 31,63,95,127,.... etc. or 63,127... depending on whether it is green or not. If you supply values of 127 for example, his macro will be medium brightness (correct) yours will be full brightness (wrong)

Share this post


Link to post
Share on other sites
Something bugs me about those macros. Aren't they grabbing the lowest bits? I'd think you'd want the highest bits to make the closest match. For example:

DWORD red = green = blue = 0x7F;
// In 24-bit, this is 0x7F7F7F = medium grey
// (Used DWORD to avoid possible type-casting problems)


#define RGB16_555(r,g,b)((b & 31) + ((g & 31) << 5) + ((r & 31) << 10))    


Now, let's take a look at this:

When the following is declared:

DWORD rgb555 = RGB16_555(red,green,blue);    


This makes:

rgb555 = ((blue & 31) + ((green & 31) << 5) + ((red & 31) << 10))
rgb555 = ((0x7F & 0x1F) + ((0x7F & 0x1F) << 5) + ((0x7F & 31) << 10))
rgb555 = ((0x1F) + ((0x1F) << 5) + (0x1F) << 10))


Note that each component is 0x1F, the maximum intensity for 5-bit values! This creates white, not medium gray.

Now, if you take the highest five bits instead:

#define RGB16_555(r,g,b) = (((b & 248) >> 3) + ((g & 248) << 2) + ((r & 248) << 7))    


This makes:

rgb555 = (((0x7F & 0xF8) >> 3) + ((0x7F & 0xF8) >> 2) + ((0x7F & 0xF8) << 7))
rgb555 = ((0x78 >> 3) + (0x78 << 2) + (0x78 << 7))


Since (0x78 >> 3) = 0x0F, let's rewrite the above statement so that the components are obvious:

rgb555 = ((0x0F) + (0x0F << 5) + (0x0F << 10));    


Each component is 0x0F, which is medium intensity. This creates medium gray.
(Of course, the bottom 3 bits of the original values were lost, so this is
equivalent to 24-bit 0x7C7C7C, but its as close as it gets without
rounding.)

I typed this up just now so I haven't debugged it, but my current library runs
on the same algorithm--take the highest five bits of the value, not the lowest.

Does this make any sense, or am I just spewing math out of my ass?
I hope not--my wrists hurt.

Edited by - SkyDruid on September 4, 2000 4:32:25 PM

Share this post


Link to post
Share on other sites
I just realized that someone else said the same thing in fewer words.

No offense intended to Mr. LaMothe, but this wasn''t the only code I had to
rewrite from Tricks of the Windows Game Programming Gurus.

Share this post


Link to post
Share on other sites

  • Advertisement