I''ve written a bmp loader that only works well when the bitmap has a width evenly divisible by 4 (same as on a DWORD boundary). If it''s not, then the image displayed is skewed and wrapped around. I''ve gone over and over the code, but I can''t find what''s wrong with it. To help you, the following will explain very shortly what I''m trying to do. If a bmp does not have a width on a DWORD boundary, then the file specs say that extra padding will be put into the file to make it so. In my function, I load the image that has the padding, and then copy everything but the padding to another temp pointer. I know it does it correctly because of a file dump I did. The problem occurs when copying the image that does not have the padding to a DirectDraw surface. The following is the code that does it when using the 16-bit mode (all bmps that are loaded are 24-bit): unsigned long red, green, blue; // For a pixels color components. // Read through pixel by pixel, converting the 24-bit pixel to a 16-bit pixel and // storing it into the ddraw surface. for (index = 0; index < (bmp.infoheader.biWidth * bmp.infoheader.biHeight); index++) { blue = temp[index * 3]; // Get blue byte. green = temp[(index * 3) + 1]; // Get green byte. red = temp[(index * 3) + 2]; // Get red byte. // The following does 24- to 16-bit conversion. red *= vid_redMask; green *= vid_greenMask; blue *= vid_blueMask; red /= 256; green /= 256; blue /= 256; red &= vid_redMask; green &= vid_greenMask; blue &= vid_blueMask; // Write pixel into the ddraw surface. ((unsigned short*)ddsd.lpSurface)[index] = (unsigned short)(red / green / blue); } This is might be a bit hard to read, but I can post additional messages to questions. - Thanks, Densun

Your indexing is still off.
Whenever your index increases by a multiple of the number of pixels in your scanline, pad the index number by the scanline pad. Or more appropiately add an offset equal to padding * number of scanlines traversed to your (index * 3).
I hope that was at least somewhat coherent.