“RenderingDoomin a database is obviously a bad idea,” Lukas Vogel writes ina lengthy blog postexplaining how exactly he managed to renderDoomusing an SQL database.
OK, that’s not entirely accurate. TheSQLDoom projectuses a small Python client to handle input and output, drive the game’s timing, and display each frame to the screen. Behind that, a series of CedarDB tables tracks the game geometry and state, while about 1,300 lines of SQL queries spread across 89common table expressionsimplement the game logic and generate 35 bitmap framebuffers per second.
In this, SQLDoom is a major improvement overVogel’s previous DoomQL project, which last year set out to build “a multiplayer Doom-like shooter entirely in SQL.” Unfortunately, that effort ended up with raycasting-based, grayscale ASCII graphics that were more akin to the simplistic 90-degree-angled maps ofWolfenstein 3D. The newer SQLDoom, on the other hand, generates full-color 640×480 frames that look like they could have come from the originalDoomexecutable.
It’s all just data, man
ConvertingDoom‘s classic WAD files to a relational database was relatively simple and straightforward, Vogel writes, because of the way the original game broke levels down into vertices, lines, sectors, and so on. EvenDoom‘s famousbinary-space partition treescan be broken down into SQL using a sort_key for objects that’s pre-computed for each position at load time. With this set in your table, a simple “ORDER BY” statement can determine every frame which parts of walls to display and which to ignore, vastly improving performance.
