[HN Gopher] Show HN: TTF-DOOM - A raycaster running inside TrueT...
       ___________________________________________________________________
        
       Show HN: TTF-DOOM - A raycaster running inside TrueType font
       hinting
        
       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 (a _b) /64, not a_b. 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.
        
       Author : 4RH1T3CT0R
       Score  : 12 points
       Date   : 2026-04-06 19:25 UTC (3 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | emanuele-em wrote:
       | Ok the MUL workaround got me. MUL does (a _b) /64 so you have to
       | DIV first to get a_64, then MUL finally gives you a*b. And
       | recursive FDEFs because there's no WHILE? All in 6.5KB? What kind
       | of frame rate do you actually get out of this?
        
         | 4RH1T3CT0R wrote:
         | 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
        
       ___________________________________________________________________
       (page generated 2026-04-06 23:00 UTC)