Lukas Vogel details the process of rendering Doom within a database system, explaining the technical approach in a recent blog post.
The SQLDoom project employs a lightweight Python client to manage input and output, drive game timing, and display each frame. Behind the interface, CedarDB tables track game geometry and state, supported by approximately 1,300 SQL queries across 89 common table expressions that implement game logic and generate 35 bitmap framebuffers per second.
SQLDoom represents a significant advancement over Vogel’s earlier DoomQL project, which aimed to create a multiplayer Doom-like shooter entirely in SQL. That prior effort resulted in raycasting-based, grayscale ASCII graphics reminiscent of Wolfenstein 3D’s simplistic 90-degree maps, whereas the new SQLDoom produces full-color 640×480 frames consistent with the original Doom experience.
It’s all just data, man
Converting Doom’s classic WAD files into a relational database proved straightforward due to the game’s modular level structure of vertices, lines, and sectors. Even the renowned binary-space partition trees translate to SQL effectively through a pre-computed sort_key for each position at load time, allowing a simple “ORDER BY” clause to determine which wall segments to render each frame, dramatically improving performance.