Problem with SDL_ttf under windows

SDL Development
1

Hello.

I am fairly new to programming in OpenGL and even newer to programming in
OpenGL using SDL. What I am currently having problems with is when using
SDL_ttf under Windows I get some strange results. I am in the process of
setting up a simple menu system that uses the SDL_ttf library to display the
text of the menu. Most of the rendering code has been taken straight from
the glfont.c example and chopped up into my ttfhandler.cc and ttftext.cc
files.
I have compiled the code on the latest stable release of Debian Linux (on
two machines, an AMD K3 450 with a Voodoo3 3000 video card and a Sony XG-38
laptop) and it works fine, the text is always drawn, and drawn correctly.
Under windows 2000 (on the AMD and on a Dell Dual 2.2GHz Xeon with a 3Dlabs
Wildcat 6110 video card) the font does not always show up, and sometimes it
only two parallel lines show up at the top and bottom of where the font
should be. As I add more code to the various classes and recompile (with the
latest stable versions of mingw32 and msys) the three words I have ( all
rendered separately ) will alternate which ones show up. More specifically,
I can comment out a chunk of code that does absolutely nothing and it will
only render 2 out of the 3 words, but when I put back in the code that does
absolutely nothing it only renders 1 of the 3 words.

I am using SDL-1.2.4 and SDL_ttf-2.0.5.

The code and 2 screenshots demonstrating this can be found at
http://minorepic.net/~guy/badcode/ and the code that I am taking out and
putting back in to get these changes is:

if( 0 )
{
fprintf( stderr, “Never should have gotten here anyways.\n” ); int i;
for( i = 48; i < 123; i++ )
{
SDL_Surface* glyph = NULL;

  glyph = TTF_RenderGlyph_Shaded( font, i, *forecol, *backcol );

  if( glyph )
  {
    char outname[64];
    sprintf( outname, "glyph-%d.bmp", i );
    SDL_SaveBMP( glyph, outname );
  }

}

}

which hopefully as you can see should have no effect whatsoever on the
program as the if statement will never be true.

If anyone could help me with this problem it would be very helpful.
Hopefully someone will have an idea of what the problem is without having to
resort to looking at the actual source code.

Sorry to bug you all with such a long email mesage.

Jon Wilsdon [@Jon_Wilsdon]

2

Hello.

This is just an update that I managed to find the problem I was having that
was giving me those weird errors. I was never initializing the pointer to
the minimum x coordinate of the texture, which means sometimes I got the
desired value of 0, and sometimes I got some weird values that were in that
memory location. A very sloppy error. I wanted to thank everyone who looked
at the screenshots and/or downloaded the code in an effort to help.

Jon Wilsdon <@Jon_Wilsdon>