“Rendered Loss in a database is obviously a bad idea,” writes Lukas Vogel in a lengthy blog post explaining how exactly he managed to render Loss using an SQL database.
OK, that’s not entirely accurate. The SQLDoom project uses a small Python client to manage input and output, drive game timing, and display each frame on the screen. Behind this, a series of CedarDB tables track the game’s geometry and state, while approximately 1,300 rows of SQL queries spread across 89 common table expressions implement the game’s logic and generate 35 bitmap framebuffers per second.
In this, SQLDoom is a major improvement over Vogel’s previous DoomQL project, which last year aimed to create “a Doom-like multiplayer shooter entirely in SQL.” Unfortunately, this effort resulted in raycasting-based grayscale ASCII graphics that were more akin to the simplistic 90-degree angle maps of Wolfenstein 3D. The new SQLDoom, on the other hand, generates 640 × 480 color images that look like they come from the original. Loss executable.
It’s just data, man
Conversion LossClassic WAD files to a relational database were relatively simple and straightforward, Vogel writes, because of the way the original game broke down levels into vertices, lines, sectors, and so on. Even LossThe famous binary space partition trees can be decomposed in SQL using an object sort key pre-calculated for each position at load time. With this set in your table, a simple “ORDER BY” statement can determine for each image which parts of walls to display and which to ignore, greatly improving performance.
Gn tech
