DOOM, simulated and rendered inside the Firebird SQL database using WASM

A WASM build of Firebird SQL runs a playable DOOM engine entirely inside the database: every game tic is implemented as a PSQL procedure call and each frame is produced by SELECTs; JavaScript only reads input and maps returned texels to the canvas. WAD lumps are imported into SQL tables (VERTEXES, LINEDEFS, SECTORS, THINGS, etc.), map initialization walks the BSP and builds blockmaps in recursive CTEs, and game logic (movement, collisions, hitscan, pickups, monster AI, movers, line specials, lights) is ported to stored procedures. Rendering is expressed in SQL as FRAME_WALLS / FRAME_SPRITES and there are two renderers - a BSP front-to-back walk using a string-based solidsegs coverage trick, and a brute-force projector that tests every linedef - both producing exact texture columns and vertical openings for compositing.

Practical findings emphasize SQL/WASM performance tradeoffs: the BSP renderer is about 3× faster on Freedoom’s 36 maps and matches brute-force outputs in CI; PSQL loops run around 0.2 µs per statement in WASM; derived tables get inlined so deep projection chains were reworked into generator procedures, and join ordering had dramatic effects (an inner join took 65 s versus 0.2 s after pinning the join direction). Tooling includes npm scripts to fetch WADs, run headless tests, render screenshots and serve locally; simplifications include no sound, limited weapons, flat projectiles and per-slice floor/ceiling draws. The code is MIT-licensed, credits Firebird-WASM and Freedoom, and is inspired by earlier SQL DOOM efforts.