Fonts all messed up

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
Post Reply
Jaral
Posts: 3
Joined: Thu Jan 17, 2008 4:00 pm

Fonts all messed up

Post by Jaral »

Ok I'm hoping someone can tell me what might be causing this:

In my font file, everything looks normal. I used the old font tool, pasted it into Gimp and saved it as .bmp:
Image

But when I draw the font on the screen, it is all goofed up. It looks like it is bolded(which I don't think is supported), and the letters are all crammed tightly together. It also looks smaller.
Image

It even does this on the included examples, so Im pretty sure it isn't my code. The only thing in the IGUIEnvironment that I am modifying is

guienv->getSkin()->setFont(myfont);

It looks the same on OpenGL and the software driver. I didnt compile DX into the dll, so I have no idea how it looks on DX8/9.

Also, when I run other examples, the default font is TINY. Its basicly unreadable. I think it is supposed to be an 8 or 10-pt font, but it looks like a 4-6pt font. It also looks bold and smashed together like this one. Is this being caused by using the old font tool? I don't think so, since the font looks fine in the file, and the default font is screwed up too.

Lastly, when I run the GUIEditor tool, the fonts look normal(!). But as soon as I go to env and change skin, they go super-tiny and bold again. Changing back to the previous skin does not fix the problem.

Thanks for any help here.
Jaral
Posts: 3
Joined: Thu Jan 17, 2008 4:00 pm

Post by Jaral »

Ok this is getting frustrating. I used font->draw() to put text on a brighter background, and saw that there are little dots and crap around the letters. the getFont() method cannot properly read fonts from the old font tool apparently.

It gets worse. I compiled the new font tool to try it, and getFont() cant read them AT ALL. Its completely broken. I get a message saying that the amount of upper corener or lower corner pixels is == 0, and the font may be corrupted. It happens regardless of which picture format I use. Also the new font tool cant write XML vector fonts, it just writes half the file and hangs when I try.

Why is the font system broken/snarked up? Should I go try to download SVN or something and see if it is fixed? Or should I go find a previous version of Irrlicht when these things still worked?

EDIT: I suppose I should specify: I am using Irrlicht 1.4 on Dev-C++ 4.9.9.2, win xp.
bitplane
Admin
Posts: 3204
Joined: Mon Mar 28, 2005 3:45 am
Location: England
Contact:

Post by bitplane »

With the new font tool, load the XML file not the image.
The bold problem looks like it's because antialiasing is enabled in your font, but not picked up by the loader. The new font loader shouldn't have this problem, as it doesn't edit the image data at all (the rectangles are stored in the XML)
Vector fonts don't load yet, and they take a very long time to generate. Also there's holes in them, which is why I didn't write the loader yet. I apologise for this, I should have removed the option for the release.
Submit bugs/patches to the tracker!
Need help right now? Visit the chat room
Jaral
Posts: 3
Joined: Thu Jan 17, 2008 4:00 pm

Post by Jaral »

Thanks, I didnt realize the new font tool was generating an XML file to load. That does fix my problem with the new font tool, but old one is still broken, the fonts from it look funny and have artifacts. It should either be removed or fixed?

Suggestion for releases in the future: Have the font tool generate a new directory with the name of the font, and put all the pics+XML in the directory so that they are not mixed into the other files in the directory. Better yet, put everything into a single compressed(zip or something) file, and write a loader that automaticly reads the XML file +bmps in it. Last suggestion: You can embed binary data into XML, and put binary gziped font data straight into the file(<bindata xysize="256"> binarydata </bindata>), which removes the necessity for multiple files alltogether. That seems like the best way to do it to me.

Does the antialiasing thing have anything to do with why the default font is so incredibly tiny? Its like a 4-6pt font, I cant even read it on my 1280x1024 screen, which is not a big screen nowadays. Many people are running 1680 or higher resolutions - I cant imagine how small it would be with that.
bitplane
Admin
Posts: 3204
Joined: Mon Mar 28, 2005 3:45 am
Location: England
Contact:

Post by bitplane »

I still haven't looked into the antialiasing problem yet, I suspect it's because the background is black and not transparent.
The Irrlicht filesystem doesn't have a way to create a directory at present, nor is there a way to write to a zip file, and I don't think there's a legal way of putting binary data inside an XML file.
The reason the built-in font is so small is because it's actually embedded into the dll and to make it any bigger would cause a huge increase in the size of the library. It has to be a bitmap as the other loaders might not be compiled in, so it's a very small 256 colour one to keep the size a minimum.
Submit bugs/patches to the tracker!
Need help right now? Visit the chat room
Ico
Posts: 289
Joined: Tue Aug 22, 2006 11:35 pm

Post by Ico »

Not sure right now but I think within CDATA sections binary data is allowed as well as <, >, etc. just nothing that looks like the end of the CDATA section.
drewbacca
Posts: 38
Joined: Tue Jan 30, 2007 6:49 pm

Post by drewbacca »

Looking at the first post of this thread, the font graphic created by the old font tool is messed up because he has windows anti-aliasing enabled (cleartype). You need to goto desktop appearance->effects and uncheck it. Then create the font again.


The old font tool has dots and other info encoded in the image, which is fine, but the font itself should be black or white. Since yours isn't its because of your windows setting.
Post Reply