Hacker News: 4RH1T3CT0R

New comment by 4RH1T3CT0R in "Show HN: TTF-DOOM – A raycaster running inside TrueType font hinting"

4RH1T3CT0R — Tue, 07 Apr 2026 07:55:47 +0000

Thanks!

New comment by 4RH1T3CT0R in "Show HN: TTF-DOOM – A raycaster running inside TrueType font hinting"

4RH1T3CT0R — Tue, 07 Apr 2026 07:51:00 +0000

Then only windows :(

New comment by 4RH1T3CT0R in "Show HN: TTF-DOOM – A raycaster running inside TrueType font hinting"

4RH1T3CT0R — Tue, 07 Apr 2026 04:14:37 +0000

technically yes, most constrained-platform ports (as I remember) do the same though (DOOMQL, the TI-84 version, the Excel one) since BSP is hard to fit into a limited VM. "DOOM-style" here is more about the genre than the rendering technique

New comment by 4RH1T3CT0R in "Show HN: TTF-DOOM – A raycaster running inside TrueType font hinting"

4RH1T3CT0R — Tue, 07 Apr 2026 04:06:08 +0000

This is a FreeType issue - it uses auto-hinter by default on Linux and doesn't run the TT bytecode. No fix from CSS side unfortunately. Works on Windows/macOS where DirectWrite/CoreText run the bytecode

New comment by 4RH1T3CT0R in "Show HN: TTF-DOOM – A raycaster running inside TrueType font hinting"

4RH1T3CT0R — Mon, 06 Apr 2026 21:26:44 +0000

Frame rate depends on the browser - Chrome gives around 30-60fps on my machine, but the bottleneck is actually Chrome deciding whether to re-run hinting at all (had to add axis jitter to force it). The TT bytecode itself executes fast, it's maybe a few thousand instructions per frame

  The recursive FDEF thing is the worst part honestly. Every while loop is a function that calls itself, and FreeType kills you at ~64 deep. So you're constantly juggling how many columns vs how many ray steps you can afford

Show HN: TTF-DOOM – A raycaster running inside TrueType font hinting

4RH1T3CT0R — Mon, 06 Apr 2026 19:25:39 +0000

TrueType fonts have a hinting VM that grid-fits glyphs. It has a stack, storage area, conditionals, function calls, and it turns out it's Turing-complete. So I built a raycasting engine in the hinting bytecode.

The glyph "A" in the font has 16 vertical bar contours. The hinting program reads player coordinates from font variation axes via GETVARIATION, does DDA ray marching against a tile map in the storage area, and repositions bar heights with SCFS. It ends up looking like a crude Wolfenstein-style view.

Small visuzlization: https://github.com/4RH1T3CT0R7/ttf-doom/blob/main/docs/media...

About 6.5 KB of bytecode total - 13 functions, 795 storage slots, sin/cos lookup tables.

JS handles movement, enemies, and shooting, then passes the coordinates to the font through CSS font-variation-settings. The font is basically a weird GPU.

The weirdest parts: - TrueType MUL does (ab)/64, not ab. So 1*4=0. The DIV instruction is equally cursed. - No WHILE loops. Everything compiles to recursive FDEFs. FreeType limits call depth to ~64 frames. - SVTCA[0] is Y, SVTCA[1] is X. Of course.

There's a small compiler behind this - lexer, parser, codegen - that turns a C-like DSL into TT assembly.

Demo GIF: https://github.com/4RH1T3CT0R7/ttf-doom/blob/main/docs/media...

Live demo: https://4rh1t3ct0r7.github.io/ttf-doom/ (Chrome/Edge, WASD+arrows, Space to shoot, Tab for debug overlay)

This is a DOOM-style raycaster, not a port of the original engine - similar to DOOMQL and the Excel DOOM. The wall rendering does happen in the font's hinting VM though. Press Tab in the demo to watch the font variation axes change as you move.

Comments URL: https://news.ycombinator.com/item?id=47665685

Points: 66

# Comments: 12