You are (or I suspect your LLM is) not correct about Doom using a raycasting engine. Wolfenstein fits that description, yes. Doom rather famously introduced BSP for level data and it draws sorted polygons front-to-back without ray-marching.
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
Ok the MUL workaround got me. MUL does (ab)/64 so you have to DIV first to get a64, 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?
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
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
This is how fixed-point arithmetic works. For multiplication of Q26.6 numbers you clear the squared scaling factors (2^6) by dividing/shifting one of them away.
12 comments
Pretty cool though!
The enemies did scale up and shrink as I got closer, and the minimap worked.
Tried with Brave on Linux, and Google Chrome on macOS.
> TrueType MUL does (ab)/64, not ab
This is how fixed-point arithmetic works. For multiplication of Q26.6 numbers you clear the squared scaling factors (2^6) by dividing/shifting one of them away.