   Buggy creation of OpenGL texture from BMP
  Hey. I've been working on a 2d game engine in OpenGL, and so far reading these forums has been very helpful with sorting out bugs. I've hit a dead end with this one, though.For my textures, I'm reading in 24-bit BMPs in binary mode. It works fine most of the time, but certain cases produce a corruption in the resulting texture, and I'm having a really hard time establishing a pattern. The most reliable way to reproduce it is to make a BMP of entirely one color, then fill in pixels of single other color until the loading no longer fails.For example: I have a 16x16 image of pure green. If I make the bottom-left pixel and the two above it pure red, it will load just fine, but as soon as you remove the top red pixel, it fails. As far as I can tell, what I get in these cases is an incomplete interlacing of the image's negative, with some of the gaps filled in by blue.I'm pretty sure it's related to how OpenGL is handling the pixel data I'm giving it, but why does a difference of one pixel cause a problem? I'm changing nothing else.Here's my BMP loading code:int TextureHandler::LoadBMP(char *filename)  {    GLuint texture;    tIndex++;    FILE *bmp;    unsigned char *pdata;    BITMAPFILEHEADER fileheader;    BITMAPINFOHEADER infoheader;    RGBTRIPLE rgb;    if((bmp = fopen(filename, "rb"))==NULL)   { MessageBox(NULL, "Error while loading texture", "Error", MB_OK | MB_ICONERROR);  return (-1);    }   fread(&fileheader, sizeof(fileheader), 1, bmp);   fseek(bmp, sizeof(fileheader), SEEK_SET);    fread(&infoheader, sizeof(infoheader), 1, bmp);    pdata = (byte *) malloc(infoheader.biWidth * infoheader.biHeight * 4);    memset(pdata, 0, infoheader.biWidth * infoheader.biHeight * 4);for (int i = 0, j = 0; i < infoheader.biWidth*infoheader.biHeight; i++, j += 4)    {    fread(&rgb, sizeof(rgb), 1, bmp);   pdata[j+0] = rgb.rgbtRed;  pdata[j+1] = rgb.rgbtGreen;  pdata[j+2] = rgb.rgbtBlue;  if (rgb.rgbtRed == 0 && rgb.rgbtGreen == 0 && rgb.rgbtBlue == 0)  {    pdata[j+3] = 0;   // Black is used for transparency  } else {    pdata[j+3] = 255;  }    }    fclose(bmp);    glGenTextures(1, &texture);    glBindTexture(GL_TEXTURE_2D, texture);    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);    glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_NEAREST);    glTexImage2D(GL_TEXTURE_2D, 0, 4, infoheader.biWidth, infoheader.biHeight, 0, GL_RGBA, GL_UNSIGNED_BYTE, pdata);    gluBuild2DMipmaps(GL_TEXTURE_2D, 4, infoheader.biWidth, infoheader.biHeight, GL_RGBA, GL_UNSIGNED_BYTE, pdata);    free(pdata);    sTexture newTexture;    newTexture.Texture = texture;    newTexture.Width = infoheader.biWidth;    newTexture.Height = infoheader.biHeight;    TextureMap.insert(std::make_pair(tIndex, newTexture));    return tIndex;}[This is a somewhat heavy revision of code from a spacesimulator.net tutorial]I'm having a very hard time pinpointing this. It all comes down to one pixel, so is there some strange nuance of uncompressed 24-bit BMPs that I'm missing?Thanks for any help you can offer.Edit - It may be useful to know the state I'm using when I draw these textures:  glEnable(GL_TEXTURE_2D);  glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);  glEnable(GL_BLEND);  glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
  Could you post a screenshot of the original image and the corrupted one please?   ;  This might not solve your problem, but in BMPs the pixels are usually stored upside down for some bizarre reason. The code you posted will produce upside down textures when you get it to work and you might find it easier to diagnose the problem (at least you'll get a better visual presentation of what you actually loaded) if you read them in the right way.You might also want to change the way you're seeking; currently you're just seeking past the two header blocks but AFAIK there is nothing to prevent programs from doing padding or other interesting things with the bitmap data (palettes and other interesting things.) Instead, you should seek to sizeof(fileheader) + fileheader.bfOffBits (where fileheader is the BITMAPFILEHEADER) before starting to read pixel data.You might also want to examine the biBitCount member of the BITMAPINFOHEADER struct to make sure that the image is in the format you're expecting, and that the biHeight member of BITMAPINFOHEADER is positive; if it's positive you're dealing with an upside down image, if it's negative the pixels are stored in the "normal" way.   ;  Here's what I'm getting:http://img269.imageshack.us/img269/1548/bugsjx.png(I'm not sure if there's a better way to post images here.) The bottom texture is generated from a bitmap identical to that of the top except for one pixel, which in the top image has been added to the top of the right-most red column. The bottom texture is what I expect, i.e. it is correct, but the top is quite plainly wrong.Valderman, I've actually handled most of those problems already. Right now I'm just reversing texture coordinates to solve the upside down problem, though I'll get a better fix eventually. As for the padding, bitmaps pad to 4 bytes, and I'm strictly using dimensions of powers of 2 for OpenGL, so that shouldn't come up. In fact, I just did a test with the two bitmaps in my image and their headers are identical, so I don't think that's it.Thanks for the suggestions, but I'm getting the feeling that OpenGL is handling things differently from how I expect it to. As I said, all I'm doing is changing one pixel - it doesn't even have to be the other of the two colors to cause the problem.   ;  Did u tried adding glPixelStorei(GL_UNPACK_ALIGNMENT, 1);at the end of your opengl initialisation function? This might solve some problems with non standart sized texture.