FreeOrion

Met all the dependancies, freetype fonts, boost etc etc,
Compiled on Fedora 16, the compile log was pretty much clean, not a single error, FO svn checkout revision 5096 and used GIGI from the source in the FO svn , GIGI revision 1074 in the externals link GG/

But on running freeorion, font's in all controls and dialogs are a little glitchy, readable and all, but something is glitching at the bottom of all the lines, image attached.

This is a longstanding known issue:
http://sourceforge.net/tracker/?func=de ... tid=544942
viewtopic.php?p=34755#p34755

It's likely some incompatibility between drivers, GiGi, and FreeType. It sometimes depends on font size or seemingly irrelevant modification to the stringtable, like making a particular (but not other) strings slightly longer, or changing the location of the game.

I have the same problem on my openSUSE 12.1 x86_64 system (with freeorion 0.4.0); however, I stumbled upon this:

http://stackoverflow.com/questions/4035 ... and-opengl

See the first answer about changing the pixel byte alignment. Could this have anything to do with it?

Try rebuilding the latest SVN with the attached patch applied, which wraps the font render calls with calls to glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

It seems to work for me, but I don't know what would or wouldn't have reproduced the problem before the change for me, so I can't really test...

Note that in the latest SVN, GG code is in the FreeOrion repository, rather than pulled in as an external. Updating might not work right from an older repository version if you don't delete the GG directory first.

Looks like the simple solution was to remove the .ttf files included with the game, from the shared data directory.

Random changes like adding or removing a few characters to the stringtable file, or changing its location, or using a different font, have been reported to seemingly fix cause the issue, only to have it return later, so don't assume it's really fixed until you've tested fairly extensively.

I found a clue as to why removing the fonts from the data directory and moving the game works:

If the font file paths pointed to in the config.xml are nonexistent, then the game displays fonts just fine.

I'm not sure what this means, or even what it could mean...

Perhaps you have another copy of the font files that FO uses somewhere in your system path directories? As I said, random changes seem to intermittently fix the issue for others, so using a slightly different font file could do it.

There is an equivalent DejaVuSans.ttf in a system directory; however, it md5sums the exact same as the one included with FO.

Using different font files does not fix it either - so far all that I have tested produced the artifacts; the only consistent pattern so far is if they are found in that config.xml or not. If not, then some default (which looks like DejaVuSans.ttf) is loaded from somewhere and renders properly.

I'll still try to see if I can narrow it further.

What happens if you rename / remove that file as well?

Most interesting: the in-game fonts still work just fine. Are there other font files that I'm not aware of?

Sorry to reply to myself -

Even more interesting:

I ran the 'lsof' command to grab any open resource handles that freeorion may be using - it has libfreetype loaded, but there is not a single font file being used by the game. Is there a built-in one?

The plot thickens...

Yes, GiGi has a built-in Vera font in DefaultFont.h. I'd have expected an exception to be thrown and possibly a crash if a font file was requested that didn't exist, though... Crashes due to not being able to find font files were quite commonly reported for a while, before the files were moved around.

So this now means that as long as you don't load any other font, then the default one is used, and is the only that works without artifacts.

So I wonder what the difference is between loading the default and loading a font from a file (maybe only on Linux)?