pouët.net

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.

Do you have any stats on how well it works?

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.

Compressed bytes, I should say.

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...

Excellent!

Cool! Will have a look when/if I ever start with a 64k.

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 :(

Would thumb up if i could

yay. time for masagin in 64k! ;)

that sounds good because there are many ugly fonts out there :D

Finally! Neuropol in 64k!!!

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.

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..

Nice! Thanks a lot for releasing this.

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?

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.

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.

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 ;)