When I switched my game to using my bitmap class (which basically just packaged what I was using before, only I didnt have to re-implement everywhere... yea yea pretty much the idea of OOP), the magenta background of the "transparent" bitmaps shows up on the screen as yellow. Green grass tiles look like blue water tiles, and orange rocks look green on the screen. Something is getting hosed! I''ve been digging through MSDN and have found only one maybe helpful nugget. The (RGBQUAD) bmiColors member of the BITMAPINFO struct has the following members: rgbBlue Specifies the intensity of blue in the color. rgbGreen Specifies the intensity of green in the color. rgbRed Specifies the intensity of red in the color. rgbReserved Reserved; must be zero. When stepping through in the debugger, rgbGreen is 0 and the others are 255 (which shows up as a y with dots over it). I placed the following code in my bitmap class to correct it:

bmp.pbmi->bmiColors[0].rgbGreen = bmp.pbmi->bmiColors[0].rgbRed;
bmp.pbmi->bmiColors[0].rgbRed = bmp.pbmi->bmiColors[0].rgbReserved;
bmp.pbmi->bmiColors[0].rgbReserved = 0;
 

But that didn''t do anything... Here''s the code from operator>> of my bitmap class:

ifstream& operator>>(ifstream& in, BitmapFile& bmp)
{
   in.read((UCHAR*) &bmp.bmfh, sizeof(BITMAPFILEHEADER));

   //check to see if the file really is a bitmap
   if(bmp.bmfh.bfType != bmp.BitmapID)
   {
      //set the fail bit if not
      in.fail();

      return in;
   }
	
   in.read((UCHAR*) bmp.pbmi, sizeof(BITMAPINFO));

//INSERT ABOVE CODE HERE, BUT DOESNT WORK

   //check bit depth.  if 8, allocate and read in the rest of bmi.bmiColors
   if(bmp.pbmih->biBitCount == 8)
   {
      (LPBITMAPINFO)LocalAlloc(LPTR, sizeof(BITMAPINFO) + (255 * sizeof(RGBQUAD)));
      in.read((UCHAR*) &bmp.pbmi->bmiColors[1], (255 * sizeof(RGBQUAD)));
   }

   //get the value for iNumBits, this is the actual size of the image data
   bmp.iNumBits = bmp.bmfh.bfSize - bmp.bmfh.bfOffBits;

   //allocate space for buffer
   if(!(bmp.buffer = new UCHAR[bmp.iNumBits]))
   {
      in.fail();

      return in;
   }

   in.read(bmp.buffer, bmp.iNumBits);

   return in;
}


When this wasn''t part of the bitmap class it worked ok so I''m not quite sure what could be causing it.  I''ll keep looking into it, but Im somewhat stumped at the moment.  Thanks!!    

The ''bmiColors'' member is just a convenient method of handling colour data for palettised images; and doesn''t actually do anything unless you use the data provided therein. It isn''t used with RGB images, though your code already copes with that.

Sounds to me like something somewhere is flipping/skipping over bytes... The code neglects the fact that the start of the image data is in the header, and not necessarily directly after the palette. You use ''BITMAPFILEHEADER::bfOffBits'' to calculate the size of the data, but don''t seek specifically to that point before you start reading, it may be RGB values out of step.

If it''s a palettised image, are you selecting in the palette?

Though really, I haven''t a clue what''s wrong without seeing it used in context...

Jans.


-----------------
Janucybermetaltvgothmogbunny

Thanks d00d, using bfOffbits was the cure... like I said before Ive had and fixed this bug before, but when I changed to using a class to handle bitmaps I forgot to include that. It''s kinda wierd cuz sometimes its ok, like with 8bpp bitmaps.