   Tracking down texture corruption
  I'm playing with integrating a closed source OpenGL based game engine into the SFML framework. I've run into one problem so far that I've not been able to resolve. I do not know what to look for. When using the font system of SFML (it uses FreeType and OpenGL textures) I get texture corruption as seen in the image below. (The text should read "Hello")I've had to modify some things in SFML to get this working, but since it is working, I know the OpenGL context and that low level side of things are correct. Using the native drawing commands of SFML also works fine, so the problem is only with the OpenGL side of things. I do know the engine maintains its own OpenGL state and sets all sorts of OpenGL commands and I am thinking it has to do something with that. However, I do not know what type of settings would result in this problem.So, are there any specific OpenGL settings when enabled or used out of order that would result in this behavior? I've tried moving the font creation code around in the app, but where it's at now is correct because when it is not, I get solid white text. I'm pretty sure the engine itself uses display lists to draw its own text, if that helps any. I've seen one thread so far in the archives here that someone had a similar problem, but no real solution. SFML has an OpenGL state preservation setting that I use as well to make sure the state is correct for both libraries.Thanks!   
  Doesn't look like an OpenGL problem. It looks more like a typical wrong-stride situation, if you ask me. The glyphs are probably incorrectly uploaded to the GL texture, ie. using incorrect dimensions, horizontal stride and/or incorrect colour format. It might be something simple like trying to treat RGB data as single channel luminance data, or treating byte data as float. That's what I would check first. Also check the pixel unpacking state, ie. the alignment and stride offsets OpenGL will use to access the supplied memory when uploading a texture (GL_UNPACK_ALIGNMENT and friends).;Quote:Original post by Yann LThat's what I would check first. Also check the pixel unpacking state, ie. the alignment and stride offsets OpenGL will use to access the supplied memory when uploading a texture (GL_UNPACK_ALIGNMENT and friends).Yann, you're the best! I used glIntercept to first make sure the engine was calling those functions and it was. I added in some glGetFloatv calls with all of the possible defines and checked against the default values table. It turns out I need to call:glPixelStoref(GL_UNPACK_IMAGE_HEIGHT, 0);glPixelStoref(GL_PACK_ROW_LENGTH, 0);glPixelStoref(GL_UNPACK_ROW_LENGTH, 0);each time I draw the text to get the right results.Thanks!   ;  You're welcome.