Forums » Code » Plugin for Angel Code Font Support

Hey guys first time posting on the forum. I come from a background of using couple different engines cocos2d, unity3d, and UDK.

I've created a plugin for loading Angel code format font (txt and png file). Basically adds support for using tools like hiero, angel code, glyph designer, etc... to design fonts for games..

It's still a very experimental plugin since I haven't cleaned the code up or performed any optimizations but it's up and running. Code is available at https://github.com/tato123/impactplugins/blob/master/plugins/extfont/hfont.js. It can be used in a similar fashion to the existing font class.

var myFont = new hFont( 'media/Gill_EZGUI_font.png', 'media/Gill_EZGUI_font.txt');
myFont.draw("A B C D", 10, 100);

I haven't added any support for alignments or anything yet but I just put this plugin together in an hour or so. Sample font formats are available under:
https://github.com/tato123/impactplugins/tree/master/samples

I'd love to hear feedback, thanks!

Pretty cool. That format does give a great deal more control over a font (at least if/once it is all supported). I'll have to give it a try sometime.

My question about fonts (in general) is why don't we just use the text drawing methods native to Canvas 2D? The whole drawing one character at a time is very expensive.

From the standpoint of game development it allows for greater control and flexibility on the final output of the font. Game fonts are generally highly stylized and cater to the specific look and feel of your game.

From what I understand native canvas 2d fonts wrap the font classes associated with rendering text in standard DOM elements. It ultimately delegates out to the system installed fonts and their appearance can differ from system to system. This would be problematic for having a consistent look, feel, and styling / layout.

As for drawing one character at time, that's actually no different than what the system does. It's just normally handled by a low level of the OS. Mac SDK provides a good bit of info on it in their core text classes. There are some tricks to make it more efficient to render like video layer buffering. Overall though it's not really that expensive since the image data associated with the glyphs is cached once in memory and a hash lookup is performed to retrieve that data.

I do think there are plenty of ways though to optimize the code I've created. For starters I think impactjs needs different update/draw cycles. Preferably a FixedUpdate like unity3d which is performed once per second. The impactjs framework attempts to perform 30 iterations of draw and updates per second which is way more often then is needed to render static elements.

Don't quote me on this but I could also create some sort of image data buffer after the first write. It would essentially require writing to a separate canvas, capturing the pixel data, and then if you attempt to write the same text I display the buffered image data rather than iterating through your text again and displaying one at a time. Then again if memory serves me right and impactjs were using webgl most of this sort of data could be batched together.

Also another advantage of using bitmap fonts is having tools like glyph designer which I use on most of my projects and lets devs create some nice looking fonts. http://glyphdesigner.71squared.com/

The problem with using the native text facilities in Canvas are that they're not that fast - not really much faster from what I've seen than using ig.Font - and you don't get the ability to do things you can do with image fonts (like the stylising as mentioned above, e.g. multi-coloured letters)

Oh, and iOSImpact doesn't support it either (and doesn't really like the idea of the whole extra canvas thing so much either) which can be a blow if that's your kind of thing.

Impact is pretty much forced to render everything at the same FPS. Canvas is cleared after each frame so changing the draw rate for something else simply wouldn't work unless you get creative and leave persistent areas alone and only draw elsewhere.

This is getting a bit off topic but there is an interesting project that uses stacked canvases to separate elements that don't need to be drawn as often and do other things to enhance performance. http://www.kineticjs.com/

Buffering a draw to a off-screen canvas might help but probably only if there is a great deal of text. I dunno, best we can really hope for is browsers to get better at draws so we don't have to be so creative about something so simple.

shrug If I'm drawing text on as part of the UI, I tend to bake the text into the UI anyway to get around this kind of problem and only deal with the per-frame changing bits anyway ;)