pouët.net

refonter: truetype fonts for 64k intros

category: code [glöplog]
 
Ugly fonts have been a staple of 64k intros forever.

NO MORE!

refonter converts a truetype font to a simpler, smaller format, and provides means to generate triangles out of that in your 64k intro.

https://github.com/revivalizer/refonter

Your milage may generally vary, but its open source and I'm happy to look at pull requests. Proven to work at least in some cases in this prod: http://www.pouet.net/prod.php?which=62018.
added on the 2013-12-13 00:33:12 by revival revival
Do you have any stats on how well it works?
added on the 2013-12-13 01:44:41 by Gargaj Gargaj
With regard to size? That 's highly font dependent.

However, for 'leaves', EVERYTHING font related is around 5800 bytes. This includes refonter code, font data, text strings and retarded drawing code.

The original ttf is 9kb, but that is an unusually lean ttf, so that's not really a good point for comparison. I've found that what really counts is the visual complexity of the font. The 'leaves' font has low complexity, but not unreasonably so.
added on the 2013-12-13 02:57:12 by revival revival
Compressed bytes, I should say.
added on the 2013-12-13 03:01:46 by revival revival
also possible: use typeface fonts (http://typeface.neocracy.org/) which is json, convert that to binary representation in an offline run; in your 64k use hole removal algorithm (http://code.google.com/p/polypartition/) and do cheap triangulation (http://www.sunshine2k.de/coding/java/Polygon/Kong/Kong.html).

I think size should be nearly the same to pregenerated triangles, but you can do different sizes and still have good curves (droid sans mono regular is binary (with a not very clever format) packed to .gz around 5k)

I can provide sourcecode (c++) if it's helpful for anybody...
added on the 2013-12-13 10:33:47 by questor questor
Excellent!
added on the 2013-12-13 10:37:04 by Adok Adok
Cool! Will have a look when/if I ever start with a 64k.
added on the 2013-12-13 10:58:04 by Optimus Optimus
Nice!

In the past I used a tool called "Pixel Font" which exported fonts as C style header files with the 0/1's represented by BYTE/WORD/DWORD depending upon the resolution required.

Unfortunately the link I had for its homepage no longer works :(
added on the 2013-12-13 11:05:08 by Canopy Canopy
BB Image Would thumb up if i could
added on the 2013-12-13 11:05:52 by Tigrou Tigrou
yay. time for masagin in 64k! ;)
added on the 2013-12-13 11:19:56 by Maali Maali
that sounds good because there are many ugly fonts out there :D
Finally! Neuropol in 64k!!!
added on the 2013-12-14 09:58:14 by v3nom v3nom
So, you're trying to solve a style-problem with technology? Good luck :P

Anyway, this looks promising, thanks a lot for making it public.
added on the 2013-12-14 16:43:45 by kusma kusma
I see you use the glu tesselator, I learnt the hard way by writing my own for a SPU implementation of a font tesselator many moons ago, testing with Kanji.. world of hurt! Holes within polys with polys in holes with holes in polys.. bOOM! My algorithm worked mostly though, just some edge cases broken.

Btw. why not render fonts on GPU using distance fields directly from the truetype data? Much smaller. :) Just a thought..
added on the 2013-12-15 12:14:57 by dv$ dv$
Nice! Thanks a lot for releasing this.
Quote:
Btw. why not render fonts on GPU using distance fields directly from the truetype data? Much smaller. :) Just a thought..


That's an interesting idea. I am aware of the thread here discussing it, which gave some nice results.

Some thoughts:

1) Only qudratic beziers were solved analytically, not cubic ones, which is used in the truetype contours. A numerical solution is hinted at in the thread, but would probably complicate matters significantly. (i.e. making it not so small)

2) AFAIR, only outlines were traced, they didn't fill out the characters. So you could only have font outlines, unless you could solve that problem.

3) It would only generate pixels, not geometry. Which might be a bit of downside, depending on the application.

Thoughts?
added on the 2013-12-16 14:01:00 by revival revival
True, I think tesselated approach if small enough is useful cos you can apply deformations or extrusions etc at realtime. you could use the ttf data and tessellate during precalc, also doing transforms and whatnot.. I always dreamt about coding a procedural graffiti writer, tesselated and deformed in realtime, but style is hard to describe, you'd need too much meta data to make anything look good heh.
added on the 2013-12-16 22:57:41 by dv$ dv$
revival: cubic beziers can be approximated quite well by subdividing into quadrics. But I somehow doubt that the distance field itself is smaller than the glyph-outlines.
added on the 2013-12-16 23:15:41 by kusma kusma
It could be possible to try something like proposed rendering-representation from Rendering Vector Art on the GPU or something to try and store the glyphs in a different representation. I doubt it'll be more compact than raw glyph-outlines, but I could be wrong. Just don't try to use that representation for rendering if you need anti-aliasing ;)
added on the 2013-12-16 23:20:23 by kusma kusma

login