GL_RGB

OpenGL OpenGL: Basic Coding
1

i am writing my own bitmap loading function as gluax is well… and devil doesnt work with dev-cpp

anyway

when making the call

gluBuild2DMipmaps(GL_TEXTURE_2D, 3, TextureImage.iWidth, TextureImage.iHeight, GL_RGB, GL_UNSIGNED_BYTE, TextureImage.cpData);

where cpData is char *
i formatted the bitmap data pointed to by cpData in the following for
(each letter is a byte)
R G B R G B
R G B R G B

and so on. now this works for bitmaps that fit into a 4 byte boundary, and thus have no padding bits at the end of each line.
however, the bitmaps that DO have this dont load correctly.

does openGL want (under windows) RGB without padding? cause if it does ive no idea why my code is going wrong

struct SDDBData
{
int iWidth;
int iHeight;
char *cpData;
};

SDDBData SLoadBitmap(const char *cpData)
{
ASSERT(cpData);
fstream CFile(cpData, ios::in | ios::binary);
ASSERT(CFile);

BITMAPFILEHEADER SBmpFileHeader;
CFile.read(&SBmpFileHeader, sizeof(BITMAPFILEHEADER));
BITMAPINFOHEADER SBmpInfoHeader;
CFile.read(&SBmpInfoHeader,sizeof(BITMAPINFOHEADER));

//Check that the bitmap is in a useable format. (Debug only)
ASSERT(SBmpInfoHeader.biBitCount == 24);
ASSERT(SBmpInfoHeader.biPlanes == 1);
ASSERT(SBmpInfoHeader.biCompression == BI_RGB);

SDDBData SReturn;
SReturn.iWidth = SBmpInfoHeader.biWidth;
SReturn.iHeight = SBmpInfoHeader.biHeight;

//go to the Data
CFile.seekp(sizeof(BITMAPFILEHEADER) +sizeof(BITMAPINFOHEADER)) ;

//Calculate number of bytes that will are attached to the end of
//Each line to align to 4 byte boundary
// the bitwise and with 3 means that it is never larger than 3

int iPadding = (4-((SReturn.iWidth)%4)) & 3;
int iArraySize = (SReturn.iWidth *3+iPadding)*SReturn.iHeight;
SReturn.cpData = new char[iArraySize];

  //of course only true for 24bpp bitmaps
int iScanWidth = 3 * SReturn.iWidth;

char *cpCopyLoc = SReturn.cpData;

for (int iCol =0; iCol<SReturn.iHeight; iCol++)
{
//Read Row Data.
for(int iRow=0; iRow<SReturn.iWidth; iRow++)
{
//bitmaps are friggin BGR, arent they. (WHY!)
//we want RGB so we need to flip it. :confused:
//cpCopyloc+2 = Blue Destination
//cpCopyLoc+1 = Green Destination
//cpCopyLoc = Red Destination
CFile.read(cpCopyLoc+2,1);
CFile.read(cpCopyLoc+1,1);
CFile.read(cpCopyLoc,1);
cpCopyLoc+=3;
}
if(iPadding)
{
//Should I Read in Padding, apparently
cpCopyLoc+=iPadding;
CFile.seekp(iPadding, ios::cur);
}
}

return SReturn;
}

Thanks

2

I have also been using DEV-C++, most of my problems have been with how my TGA loader is setting up memory space. Works on other compilers, strange with the problems I am having…

But I got a render to texture to work, with just GL_RGB without any problems.

I guess this really don’t answer your question, but just what I have encountered.

[This message has been edited by nexusone (edited 02-08-2003).]

3

oops i gave the version where i have accounted for padding…
well that one doesnt work either.

if you want to not pad the bytes in RAM just change some lines

to not use RAM padding it should read
int iArraySize = SReturn.iWidth 3SReturn.iHeight;

and the if should read
if(iPadding)
CFile.seekp(iPadding, ios::cur);

4

i got it working in the end

for those (very) few who might care
for a 1*3 image the bytes need to be in the following order when calling
gluBuild2DMipmaps(…)

r g b P
r g b P
r g b P

where P is a padding byte

my problem was that my padding formula was incorrect

the correct formula is

int iPadding = (4-(iScanWidth%4)) & 3;

where iScanWidth = 3* BitmapWidth.

Wasnt that fun.