Jump to content
  • Advertisement

Archived

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

An Irritable Gent

Help! Totwpg's loading bitmaps

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

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

Share this post


Link to post
Share on other sites
Advertisement
Program 7_11 works fine for me. But I havent been able to get his 16 bit engine to load a 24 bitmap.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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
========

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!