I've spent a little time upgrading the bitmap font generator. This time I added support for unicode character sets and an option for packing 4 pages into 1 32bit texture. This latter will require a special shader to render with, but you're saving a lot of space with it. The added support for unicode, has shown that the naïve algorithms that I used without problem before are having serious performance issues. I still need to work on those. Until I get around to that you'll have to be patient if you try to generate the entire chinese character set, but smaller sets are still fast enough. I'd like to thank Manu Evans and other users for the feedback on this little program. You're the ones that give me the inspiration and ideas to continue improving my products.

The chinese set problem is understandable. It's got how many characters again?

The combined Chinese, Japanese, and Korean unified ideographs character set has over 20.000 characters in it. So, while it is understandable that it takes a while to generate this set I still think BMFont is at least 10 times slower than it has to be.

I'll improve the algorithms, but for now I'll be working on the next version of AngelScript. :)

Hi, thanks for the great tool, however I've found some serious problem with it.

When I try to generate fonts with just ASCII encoding instead of unicode, and I thought that should be fast, as it got fewer chars to generate, on the contrary the process is sooooooo much slower(and it seems to go forever, i was never patient enough to wait till it finishes).

Althogh the status bar correctly shows the number of chars selected, but when generating, the numerator goes far more than denominator, and writing chars to textures is painfully slow.

Unicode font generation works fine, but non-unicode is almost unusable.

You're right. This is a bug in the program that slipped through. I'll fix the code and update the program as soon as possible.

Thanks for letting me know.

Regards,
Andreas

What was causing this? It's just as fast as always for me.

Try visualizing the texture for Arial, with charset ANSI (not unicode). The generation of the texture pages enters what seems to be an endless loop; The counter goes far beyond the 228 characters that are available in the character set.

I'll try to look at the code when I get home today, but I'm not sure if I'll get the time.

Indeedly. It worked fine with the font I generated. Terribly odd.

[edit] Or it could be because I didn't install the new version over the old like I thought, and was still running the old one. Never mind. [/edit]

[edit2] And while were on the topic, any chance of a command-line version? I'd like to be able to add font generation as a build step. [/edit2]

I've fixed the bug. The new version is available from the site.

Just before reading your post I came up with a satisfying solution for generating fonts through a command line option. What I intend to do is to allow the user to save the font configuration from the GUI in an XML file. Through a command line argument the app can automatically generate a new font file from the XML file without user interaction. The XML file can of course also be generated by a third party tool, if that should be preferred.

This will hopefully be in the next version.

Thanks for the update, here is another minor problem.

When using Ascii font generation, kerning info for variable-width fonts(like Verdana) still consists of unicode chars.

Of course, they can be easily discarded while parsing, but just a little bit of inperfection :)