Sign in to follow this  

HELP 8-Bitmap problems. [Pic Included] !!!

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

Right now I am doing lessons from Game Programing in 24 hours by Michael Morrison. I am currently on Hour 11 Fore 2 program and since the begining when I constructed the bitmap class which he says can only load 8 bit (256 color) bitmaps. So I tested it and edited a bit map and added a line, then it just screws up. Below is an image of what I am talking about, the RIGHT picture is what it's suppose to look like and the left image is the actual program. I am learning GDL. [img]http://s94834192.onlinehome.us/helpme.JPG[/img]

Share this post


Link to post
Share on other sites
I didn't change any of the code.. the images that come with the code works perfectly.

I even right clicked to look at the properties after I added the line, their was no difference I put it at 256 and the bits said 8 and stuff.. exactly the same.

But when I run the program again it does that.

Share this post


Link to post
Share on other sites
No no no.. Sorry if I couldn't explain my problem correctly.

If you notice in the right picture.. their is a black line. In the Center. That is the same image used in the program Fore 2, however if you look at the image in Fore 2 the background bitmap (forest) is stretched.

The balls are irrelevant (They're sprites in Fore 2). I am talking about the background. Look closely in the Fore 2 compiled program it's stretched and messed up. The original or when opened in MSPAINT the one to the right is what the background is supposed to look like (Line in center).

All I did was added a black line (Look in the right picture, that's the same picture that is being used in Fore 2.) but the one in the Fore 2 program when compiled is stretched and messed up.

Share this post


Link to post
Share on other sites
no don't upload the code. you said you didn't make any code
changes, and the _pForestBitmap variable is of type Bitmap*,
which doesn't do any wrapping. but if you did make code
changes, and you made _pForestBitmap into a Sprite* with
the BA_WRAP flag... then that could happen.

but first, check the bitmap file you edited with the one
on the CD. are they the same file size? what program you
use to edit the image (where you drew that line)? sometimes
an improperly saved palette can cause shifts like that...

what i would do is analyze the BITMAPFILEHEADERs and
BITMAPINFOHEADERs of the original forest bitmap and
the one you edited. then i would look at the RGBQUAD
palette data to see if those are the same too. then
i'd look to make sure that the color bits start where
they are supposed to. sometimes people fill out the
BITMAPFILEHEADER::bfOffBits parameter improperly,
which would also cause a shift.

Share this post


Link to post
Share on other sites
Lol how silly of me, I've seen this before. The program is definitely reading the bits from the incorrect position. Zoom in on the shifted picture and pay attention to the first two lines from the bottom. There's alot of black and whites and junk. You can tell the position at which the junk stops about 3/4 of the way down the second row. The image is 600 pixels wide and 256*sizeof(RGBQUAD) = 1024. And 1024/600 = 1.7, about 3/4 of the way down the second row ;).

I don't know what you used to save the bitmap, but whatever saved it probably set the BITMAPFILEHEADER::bfOffBits parameter to sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER). Which means it reads about 1024 bytes from the color table that it thinks is color data. It should really be: sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + 256*sizeof(RGBQUAD)

You can take the Bitmap class and force it to read from
sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + 256*sizeof(RGBQUAD)
instead of using bfOffBits directly. Also, use another photoeditor, as
whatever you used boinked the off bits.

Here's a pic for proof:

Share this post


Link to post
Share on other sites

This topic is 4660 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this