GLint dataSize;
if(bmp.bmiHeader.biSizeImage == 0){
if(bmp.bmiHeader.biBitCount == 24)
dataSize = bmiHeader.biWidth*bmiHeader.biHeight*3;
else
dataSize = bmiHeader.biWidth*bmiHeader.biHeight*4;
}
else
dataSize = bmiHeader.biSizeImage;
//allocate and clear memory for the image data
GLubyte *mData = new GLubyte[dataSize];
memset(mData, 0, dataSize);
//now read in the data
GLubyte *tempData = mData;
GLubyte pad;
file.seekg(bmfHeader.bfOffBits, ios::beg);
//file.read((char*) mData, dataSize);
for(int i=0; i < dataSize; tempData+=3, i+=3){
file >> tempData[0];
file >> tempData[1];
file >> tempData[2];
if(bmp.bmiHeader.biBitCount == 32){
file >> pad;
++i;
}
}
🔒 Locked
Question: loading bitmap...
Advertisement
Original Post
Ok, I am writing a routine to load bitmap images from .bmp files in GL_RBG format and have run into a problem: in the code below I determine the size of and allocate an array of bytes to hold the rgb values of the bitmap and then attempt to read them in from the file. The "file.read(..." line that I have commented out works fine while the for loop version doesn't. Why not?
In the for loop I am reading in 3 bytes (one R, one G, one B) every iteration and optionally reading in an extra byte for padding if the bitcount value in the bitmap header info structure is 32 instead of 24 per iteration with dataSize/3 iterations which is one iteration per pixel. Why am I getting different data than doing straight read on the file stream?
peace and (trance) out
Mage
[edited by - Mage2k on May 9, 2003 2:25:00 PM]
Bitmap data is DWORD-aligned. Were the extra bytes stored in the bmp file?
Ok, on the tempData thing, I just forgot in the post to set it to mData like it is in my actual code -- fixed it. As far as the DWORD alignment I'll have to go with an example of an actual bitmap I am using: when reading in the header for the bitmap I get bitmap file and info header structures that indicate a 640x480 bitmap with a 24bit (=3 bytes) bitcount per pixel and an image size of 921600 bytes which is equal to 640x480x3 which would seem to indicate that there isn't any padding for DWORD alignment -- or, am I wrong about how this works? If there was wouldn't the image size 640x480x32=9,953,280?
[edited by - Mage2k on May 9, 2003 2:35:34 PM]
[edited by - Mage2k on May 9, 2003 2:35:34 PM]
If you are using the loading code for textures in OpenGl, DWORD padding should not come into play, as each scanline should end on a DWORD as a textures width and height has to be complient to openGL standards, ie a power of 2.
That possibly didnt make a whole lot of sense, but its true.
That possibly didnt make a whole lot of sense, but its true.
Well, I haven''t even gotten to using the bitmaps for textures, yet. Right now, I''m just testing the data loading with glDrawPixels(...). Use glDrawPixels with the data from file.read(...), and everything is fine, use the data read in the for loop, which steps thru the input stream rather than reading it in in a chunck, and glDrawPixels produces garbage. Meaning theres'' something (probably will seem obvious once I (or, someone else) sees it) wrong in the for loop. I''m just not seeing it.
peace and (trance) out
Mage
peace and (trance) out
Mage
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement