Help! My Bitmap Drawing Function is Insane!

Started by
1 comment, last by Reticle 22 years ago
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
Advertisement
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
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...


  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