Hi, I''m getting a little frustrated with the little bugs here and there in Andre LaMothe''s "Tricks of the Windows Programming Gurus", both in the book (and in the code which is fairly sloppy overall, and could use a trainload of simple and obvious optimization, IMHO). Normally I can figure them out and/or clean them up pretty quick, but this one has me stumped. I''m trying to load a 24-bit bitmap and display it on a 16-bit (565) surface (I''ve verified that ddpixel.dwRGBBitCount is 16.) The colors end up being a bit too green, and I can''t figure out why. I eventually looked at LaMothe''s code, and ran it, and it''s even worse. If some of you could try out demo7_11.exe from the book and let me know if it displays right for you, I''d appreciate it. For me, it''s only displays for a second (and way too green), and then goes black. Also, here is a snip of my code where I''m converting the 24-bitmap to a 16-bit surface. Any help or even ideas would be great.

#define RGB16_565(r,g,b) ((((r)&31) << 11) | (((g)&63) << 5) | ((b)&31))

....
int x, y;
BYTE red, blue, green;
BYTE *source;
WORD *dest;

source = (BYTE *)bmpimagedata;
dest = (WORD *)ddsd.lpSurface;

for(y=0;y> 3 for green rather than >> 2 for some weird
           reason (page 355, and in demo7_11.cpp). I tried >> 3
           just for kicks, but obviously that results in way too
           little green, as you''re basically only getting half
           of the green that you should be (5 bits instead of
           6). */
	blue = source[0] >> 3;   // results in 5 bits
	green = source[1] >> 2;  // results in 6 bits
	red = source[2] >> 3;    // results in 5 bits
	dest[0] = RGB16_565(red, green, blue);

	// inc the pointers
	dest++;  // past current 16-bit pixel on the surface
	source += 3; // past current 24-bit RGB in the BMP info
    }
    
    // skip over the padding at the end of each BMP line
    source += (bmppitch - (3*bmpwidth));
    // skip over the padding at the end of each surface line
    dest += ((ddsd.lPitch - (bmpwidth * sizeof(WORD))) / 2);
}
...
 

Basically, I think the little bugs here and there in LaMothe''s book and code have gotten me confused. Has any one here run into the same problem? Thanks, The Gent

Program 7_11 works fine for me. But I havent been able to get his 16 bit engine to load a 24 bitmap.

What is demo7_11 supposed to look like? Either it runs just like it''s supposed to or it fails miserably on my computer, because all I get is a black screen with the mouse pointer on it.

The macros he gave for _RGB16BIT565 and _RGB16BIT555 weren''t correct. I think the problem was with the 565 one.

That made all my colours look too purple on my 565 video card. They worked out fine on my other 555 card. Guess which vid card Andre uses .

The macros I use are:

#define _RGB16BIT565(r,g,b) ((b & 31) + ((g & 63) << 6) + ((r & 31) << 11))

#define _RGB16BIT555(r,g,b) ((b%32) + ((g%32) << 5) + ((r%32) << 10))

Hope that helps.

Regards,
David Stubbs

Yep, Andre''s got his macros wrong, but that''s not just it.

Take a look at this snippet from demo7_11.cpp:

           UCHAR blue  = (bitmap.buffer[index_y*SCREEN_WIDTH*3 + index_x*3 + 0]) >> 3,              green = (bitmap.buffer[index_y*SCREEN_WIDTH*3 + index_x*3 + 1]) >> 3,              red   = (bitmap.buffer[index_y*SCREEN_WIDTH*3 + index_x*3 + 2]) >> 3;        // this builds a 16 bit color value in 5.6.5 format (green dominant mode)        USHORT pixel = _RGB16BIT565(red,green,blue);    

The point is that the RGB values (0-255) must be scaled down, i.e. shifted right by 3 (>>3). When I tried this, it worked.

If you don''t, the bitmap should load, but the colours will look funny.

BTW, sorry to disappoint you, but TGA files would be a better alternative .



========
Smidge
www.smidge-tech.co.uk
========

Hi, and thanks for the replies so far. I''m still stuck, but getting closer.

quote: Original post by n0p3x
#define _RGB16BIT565(r,g,b) ((b & 31) + ((g & 63) << 6) + ((r & 31) << 11))

Why are you, like LaMothe, shifting green by 6? Shouldn''t this be 5?

Later,
The Gent

Hi Smidge_tech

quote: Original post by smidge_tech
The point is that the RGB values (0-255) must be scaled down, i.e. shifted right by 3 (>>3). When I tried this, it worked.

I understand that, but shouldn''t green only be scaled down by 2 bits instead of 3? In 565 mode, red and blue have to go from 8 bits to 5 (thus a shift of 3), but green only has to go to 6 bits.

What''s going on?

The Gent

Did you make sure that the image that you are using has the EXACT same dimensions as the screen width and screen height? If not, then make sure they are.

There are three types of people in the world; those who can count, and those who can't.

quote: Original post by Fredric

Did you make sure that the image that you are using has the EXACT same dimensions as the screen width and screen height? If not, then make sure they are.

Yes, the images are displaying correct except for the coloring.

The Gent

Yup, Andre''s got his macros mixed up, you should shift the green only 5 times not 6 (#define RGB16_565(r,g,b) ((b & 31) + ((g & 63) << 5) + ((r & 31) << 11)))

Now the colors will show up funny, to fix this you just read the green value from the bitmap like this:

green = temp_buffer[index*3+1]>>2;

Instead of >>3.



The road to success is always under construction