Someone Got Doom In an SQL Database

An anonymous reader quotes a report from Ars Technica: Rendering Doom in a database is obviously a bad idea," Lukas Vogel writes in a lengthy blog post explaining how exactly he managed to render Doom using an SQL database. OK, that's not entirely accurate. The SQLDoom project uses 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 89 common table expressions implement the game logic and generate 35 bitmap framebuffers per second.

In this, SQLDoom is a major improvement over Vogel'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 of Wolfenstein 3D. The newer SQLDoom, on the other hand, generates full-color 640x480 frames that look like they could have come from the original Doom executable. [...] If you want to run a Doomtabase on your own local machine, you can do so simply with the GitHub code, a copy of CedarDB, and a Doom WAD file. Or you can jump into a free online hosted demo match to test it out without all the setup [...].

So?

[gweihir]

These stunts are getting boring.

Re:

[Krishnoid]

You're just jaded [sqlite.org]. And better that people perform stunts involving this kind of CTE, than the other kind [nih.gov].

Re:

[irreverant]

I kind of like this stuff. Makes your brain think about the how. You know, I got lucky enough to be told I'm a brilliant genius. I'll take it as I'm surrounded by good company. Truth is it's nice finding out that the way it works is exactly the way you thought it would work. Humbling experience. Have a good day.

As a DOOM fan and a DBA

[jfdavis668]

This horrifies me. Talk about a complex way to implement a rather simple solution.

Re:

[Cajun Hell]

Fine, show us all your simple way to port Doom to SQL.

Re:

[Baron_Yam]

Maybe I'm missing something, but I don't believe SQL includes client data rendering. At least not any SQL implementation I've ever worked with. There's always a client that has to interpret SQL data and convert it into a rendered frame as well as send user input back to SQL as a query.

That would seem to be enough of a limitation to 'Doom on SQL' to make the total project... doomed from the start. It remains an interesting exercise in getting SQL to do the rest of it. As long as the code to do so is elega

Re:

[WaffleMonster]

Maybe I'm missing something, but I don't believe SQL includes client data rendering. At least not any SQL implementation I've ever worked with. There's always a client that has to interpret SQL data and convert it into a rendered frame as well as send user input back to SQL as a query.

Here the database outputs a fully rendered bitmap containing the frame to display. Client script driving everything is just taking that bitmap and pushing it out to the display.

Re:

[Vomitgod]

This horrifies me. Talk about a complex way to implement a rather simple solution.

lets be professionally offendeded by things.

Not really a "DOOM on a ..." story

[93 Escort Wagon]

It's always fun to read about people implementing DOOM on various unlikely devices... however this is not one of those stories. This is just porting DOOM to a different language, but still running on a standard computer. And the heavy lifting is being done with python rather than SQL - so it's not even a new language, in terms of DOOM ports.

It does sound like it was an interesting and likely fun project for the coder(s), in any case.

Is this a sponsored post?

[ByTor-2112]

Paid for by CedarDB?

For burning time off social media

[fahrbot-bot]

DoomSQLing :-)

Well I got Adventure in SQL

[greytree]

For me, SQL will always be "twisty little passages".