Creating Fonts and Bitmaps

More work on fonts. Jeff’s solution for creating PackedFont fonts is fantastic - instead of mucking around with u16 arrays, he subclasses the fonts and does all of the work for you. Instead of this:

PackedFont1* myFont = new PackedFont(somearray, somewidth, someheight, blah, blah);

…you have this:

NewTopaz* myFont = new NewTopaz();

So much easier.

I’ve shamelessly stolen this idea and reworked the existing “FontBitPacker” application so that it follows this pattern. I’ve heavily modified it so that the app will convert BMP files to either MonoFont, Font, PackedFont1 or PackedFont16 font classes. As long as they have version 3.5 of the .NET framework, Windows users no longer need to faff about with PAGfx or the bmp2font Python script. The new “bmp2font” .NET console application (which the FontBitPacker has become) will do all of the font conversion work needed for Woopsi.

This pattern seemed like such a good idea I’ve used it for bitmaps, too. Instead of converting BMP files with PAGfx, then using the “all_gfx” files to include the bitmap data before wrapping them up in a BitmapWrapper class, it is now possible to use a new “bmp2bitmap” .NET app to convert straight from a BMP file to a BitmapWrapper subclass.

These new programs have enabled me to delete the PAGfx binary and the files it converted from the Woopsi demo folder. I’ve replaced the converted files with classes converted with bmp2bitmap.


Jeff on 2009-12-13 at 20:12 said:

I suspect you means “NewTopaz *myFont = new NewTopaz()”

Also, the reason I did it in Python rather than .NET was so that it was all cross-platform. Making it dependent on .NET cuts off Mac and Linux users.

Ant on 2009-12-13 at 22:59 said:

Yep, I did mean that. Fixed it. You can tell I’ve been working in C# instead of C++ lately…

And yep, .NET does cut off those users. It’s great for prototyping, though, as it is so easy to put applications together using it. I’m planning to port the utilities to C or C++ at some point. The Python script is fantastic, but it is dependent on Python 2. I’m working with Python 3, so using the script requires me to have Python 2 installed too. Plus, grit appears to have gone through an upgrade in the latest dkp release (27) and requires the FreeImage.dll library (which isn’t included in the dkp distro; I think that’s probably a mistake). Not a problem, but it introduces more dependencies into the chain of apps that Woopsi relies on.

Chase-san on 2009-12-14 at 03:39 said:

I personally use BMFont, from angelcode and wrote a C wrapper for the binary output it produces, I convert the outputted png to gif and import that (I change the png to gif in the binary file as well). I use BMFont because I rarely ever need the entirety of a font, and instead just want a subset of. This is what I use to support just Japanese Kana from MS Gothic, but leave out all the Kanji (Chinese characters) and Korean. It also packs it to save space.

Its very useful for me, since my wrapper does similar and does most the work for me. I keep all the information from the imported binary font definition file in a C Struct which I just pass the pointer around.