The perennial question “Can it run Doom?” has found a new, data-driven answer. Lukas Vogel has detailed his successful attempt to render the classic shooter using an SQL database, proving that even relational tables can handle the fires of Hell.
The Architecture of SQLDoom
While the project employs a small Python client to manage input, output, and timing, the core game logic resides within CedarDB. The engine is powered by approximately 1,300 lines of SQL queries spread across 89 common table expressions (CTEs), which generate 35 bitmap framebuffers per second.
SQLDoom marks a significant leap from Vogel’s previous effort, DoomQL, which was limited to grayscale ASCII graphics and 90-degree layouts. This new iteration produces full-color 640×480 frames that mirror the visual fidelity of the original 1993 executable.
Mapping Data to Gameplay
Converting Doom’s classic WAD files into a relational format was surprisingly straightforward due to the game’s original structure of vertices, lines, and sectors. Vogel utilized a sort_key to translate binary-space partition (BSP) trees into SQL. By using a standard ORDER BY statement, the database determines which wall segments to render or ignore for every frame, significantly optimizing performance.
Despite the overhead of constant database reads and writes, Vogel reported the game runs at roughly 60 fps on a Ryzen 7-powered laptop, dipping to 35 fps during complex scenes. The rendering of floors and ceilings remains a “hacky” implementation, as it cannot use the original game’s specific column-by-column mutation methods.
The Database Advantage
Vogel points out that using a database for a game engine isn't just a gimmick; it offers structural benefits for multiplayer environments. The inherent concurrency and access handling of SQL provide a steady “reference snapshot” of the game state. This ensures there are no partially applied updates or disputes over hit detection, as the database acts as the ultimate arbiter of truth.
