Help! My Bitmap Drawing Function is Insane!
Can anyone find anything wrong with this bitmap drawing function? Sometimes it works, like if the bitmap is 64 by 64, but if i change it to 50 by 50, it doesn''t. It draws the map all sideways. I can''t figure it out.
Here it is:
// DrawBitmap
int DrawBitmap(int x, int y, int width, int height, LPDIRECTDRAWSURFACE7 lpdds, char *filename, int cx, int cy)
{
// clean the surface
Fill_Surface(lpdds,0);
// load the 8-bit image
if (!Load_Bitmap_File(&bitmap,filename))
return(0);
// clear ddsd and set size
DDRAW_INIT_STRUCT(ddsd2);
// copy the bitmap image to the primary buffer line by line
// lock the primary surface
lpdds->Lock(NULL,&ddsd2, DDLOCK_SURFACEMEMORYPTR | DDLOCK_WAIT,NULL);
// get video pointer to primary surfce
USHORT *primary_buffer = (USHORT *)ddsd2.lpSurface;
// compute starting location on surface
//primary_buffer += (x+y*(ddsd2.lPitch/2));
if(SCREEN_BPP == 16 && bitmap.bitmapinfoheader.biBitCount == 24)
{
// process each line and copy it into the primary buffer
for (int index_y = 0; index_y < height; index_y++)
{
for (int index_x = 0; index_x < width; index_x++)
{
// rip out the UCHAR boundried 8-bit color segments for passing to the 16-bit color word macro
int pos = (index_y)*(bitmap.bitmapinfoheader.biWidth)*3 + (index_x)*3; // compute position
UCHAR blue = (bitmap.buffer[pos]>>3), // 5 bits for blue
green = (bitmap.buffer[pos+1]>>2), // 6 bits for green
red = (bitmap.buffer[pos+2]>>3); // 5 bits for red
// this builds a 32 bit color value in A.8.8.8 format
USHORT pixel = _RGB16BIT565(red,green,blue);
// write the pixel
primary_buffer[index_x + (index_y*ddsd2.lPitch/2)] = pixel;
} // end for index_x
} // end for index_y
}
// now unlock the primary surface
if (FAILED(lpdds->Unlock(NULL)))
return(0);
// unload the bitmap file, we no longer need it
if(!Unload_Bitmap_File(&bitmap))
return(0);
return(1); // return success
}// end DrawBitmap
Does it work if the Bitmap is 32 * 32 ?
Or 16*16 ?
If so, there have been a few threads recently, try searching the archive. It is to do with bitmaps being packed up to a word boundary IIRC.
If it doesn''t work then I apologise
Or 16*16 ?
If so, there have been a few threads recently, try searching the archive. It is to do with bitmaps being packed up to a word boundary IIRC.
If it doesn''t work then I apologise
I beleive the bitmap width has to be divisible by 4 (or was it 8) otherwise it adds padding.. so you''d have to do something like this...
*Note This is untested, but should work. By your description I think this was the problem (makes each line look off a bit since it''s adding padding to each line). Also, it may just be easier to simply make sure you''re Bitmap widths are divisible by 4 (or was it 8?)... then you don''t have to worry about it :D
Billy - BillyB@mrsnj.com
int leftover = width&3; //how many left after 4? (same as width%4.. except faster)unsigned long pos=0; //Starts at 0for (int index_y = 0; index_y < height; index_y++){for (int index_x = 0; index_x < width; index_x++){// rip out the UCHAR boundried 8-bit color segments for passing to the 16-bit color word macro//Lets not compute pos within our loops with multiplication..//Instead, we just start at 0 and increment...//Gives the exact same results!UCHAR blue = (bitmap.buffer[pos]>>3), // 5 bits for bluegreen = (bitmap.buffer[pos+1]>>2), // 6 bits for greenred = (bitmap.buffer[pos+2]>>3); // 5 bits for red pos+=3; //Increment pos by 3 (R,G,B)/* Your comment says it builds a 32-bit color value?But aren''t you building a 16 bit value? 5.6.5?*/// this builds a 32 bit color value in A.8.8.8 format USHORT pixel = _RGB16BIT565(red,green,blue);// write the pixelprimary_buffer[index_x + (index_y*ddsd2.lPitch/2)] = pixel;} // end for index_xpos+=leftover*3; //Increment by the padding!} // end for index_y
*Note This is untested, but should work. By your description I think this was the problem (makes each line look off a bit since it''s adding padding to each line). Also, it may just be easier to simply make sure you''re Bitmap widths are divisible by 4 (or was it 8?)... then you don''t have to worry about it :D
Billy - BillyB@mrsnj.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement