I'm making an 8bit color game, and, as such, have spent alot of time creating a personlized palette and a method of my bitmap images all using that same palette. Here's where I stand: I have programs that will convert any 24bit bitmap into an 8bit bitmap which only uses my personalized palette. I also have drawn a color bar (saved as a 24bit bitmap) so that others may use paint's color selection tool to select from colors that are in my palette. This basically allows me to create 8bit bitmap images which only use my palette colors.
But there's a catch, allegro won't read my 8bit bitmaps correctly. If necessary, I'll show my code later, but I don't think it's necessary right now. I noticed that after I convert a 24bit bitmap to an 8bit one (using a program I wrote, but not using allegro), if I am in explorer, and highlight the 8 bit file, the preview it brings up is all wierd. Basically, there is some junk at the bottom of the picture (bmp's are stored upside down, so this junk is from the beginning of the file). My guess is that it is showing the palette data and/or bmp headers as part of the picture. But why? The image preview is using the correct palette. Anyways, when I open the file in paint, it is displayed just fine. When I use allegro to display it, though, I get the SAME EXACT results as with the image preview. Obviously, my bmp file format has a hole in it. I've also noticed that sometimes when I download a 24bit bitmap off the internet, and use my program to convert it to use my colors, the resulting image is messed up, even in paint. I've checked, and they don't use compression, and are linear bitmaps. So, for some reason, is there another bitmap file format or something. Here's the format I am using (if you'd like to see my code and get examples of the pictures I'm talking about, I'd be glad to attach them):

2 bytes: bm signature
4 bytes: file size
2 bytes: reserved(must be set to 0)
2 bytes: reserved(must be set to 0)
4 bytes: byte offset from header to start of image
(start of image includes the palette)
4 bytes: size of bm info header
4 bytes: bm width
4 bytes: bm height
2 bytes: planes
2 bytes: color depth
4 bytes: compression
4 bytes: size of image
4 bytes: hor pixels per meter
4 bytes: vert pixels per meter
4 bytes: # colors actually used
4 bytes: # colors important for displaying bitmap

That's it. One theory that I have is that the offset from header to image also includes the size of the palette. This would explain why allegro is treating the palette as part of the image, because it thinks that the image starts there. Also, when I load an 8bit bitmap and use it's palette, the palette is messed up. This is only with my 8bit bitmaps. So I think the key to this problem is the location of the palette. Can anyone help out? Thanks for your time.

Okay, thanks for your help. I'm gonna show part of my code, because some parts are irrelevant and a mess. But rest assure they have no effect on saving a bitmap.

Here's my combined header (meaning I put the file header an info header into one big thing)

struct bmpHeaderType
{
char magic1, magic2; // identity 'BM'
long fileSize; // size of file in bytes
long reserved; // always 0
long pixelOffset; // offset of data
long bmiSize; // remaining size of header in file
long cols, rows; // width and height of image
int nPlanes; // number of color planes
int bitsPerPixel; // number of bits used to represent a pixel
long compression, cmpSize; // compressed image?
long xScale, yScale;
long colors, impColors;
};

For saving a 24bit bitmap to an 8bit one:
read 24bit bitmap header
put same contents in 8bit one, then my code:

Hope this helps. Although, I don't think it is necessary to actually see my code, but you never know. You see, paint understands my bmp file, but allegro and explorer image preview do not. So what assumption do these make that paint doesn't?

Nevermind, I fix it. Like you said, it was my an incorrectness in my bitmap header, so I'll give you credit for that. It was a combination of things. To solve my problem, I converted a correct 8bit image to integer values for each byte, so I could compare it with my own 8 bit image of the incorrect type. Problems with my methods:
offset does include palette: 54+256*4
my filesize was way too small (I neglected to count the palette data as well as the image data, the only thing I did count were the blank pixels to make the columns divisible by four)
the cmpSize field is not supposed to be 0 (I thought this was for compression only), it is supposed to be the number of pixels in the image.

So everything works just fine now. Thanks for your help 23.

The OS2 version also stores the lines top-down instead of bottom-up.

Yeah. God forbid that they build in the possibility for expansion of the format, or, at the very least, user-defined data.

Almost. That means that the problem is sitting in front of the computer you're using.
Replace user, then hit any key to continue.

EDIT:
I gave it another thought and came to the conclusion that you're right. It sucks. You should not waste your time with it.

That's part of the voodoo magic.

Just because I'm curious... let's assume that you run that program, passing the path to the image as a parameter... is it still messed up?

Ok, that raises the question why you're not using allegro to convert the bitmaps?

Yes, I know about the padding thing. That's not the reason, unless my calculations for how many blank bytes to put at the end of a line are incorrect.

Packed. Otherwise the aforementioned padding would be pointless