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.

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.

Wow.

[wow]

I wish I could help, man. That is wierd.

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.

Help someone heh..

Should I Upload the code?

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.

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: