Just because you can render a Doom-like in SQL doesn't mean you should
- Reference: 1757569505
- News link: https://www.theregister.co.uk/2025/09/11/doom_for_sql/
- Source link:
The "pure SQL" part is important. There have been attempts to get Doom-like games up and running in the past. The excellent [1]DuckDB-DOOM , for example, appeared earlier this year and used SQL for the game logic (including 3D raycasting and rendering), but the author of [2]DOOMQL , Lukas Vogel, wanted to take things further and do everything in SQL.
Oh, and it had to be multiplayer too. After all, a database server is just like a traditional game server, right? How hard could it be?
[3]
To be clear from the outset, implementing a Doom-like game (and rendering it) in something like SQL is unlikely to produce visuals that rival the pixel prowess of the '90s original. In fact, its appearance made this writer nostalgic for 3D Monster Maze on the Sinclair ZX81, although DOOMQL, which Vogel reckons will run at 128 x 64 pixels at 30 frames per second, is a definite step up.
[4]
[5]
Vogel used CedarDB for database services, but said: "To be honest, the database nerd in me just wanted to turn all knobs up to 11 and see what breaks."
[6]30 years later, Doom returns to SNES with Raspberry Pi RP2350 muscle
[7]Fungus-inspired Linux hack gives Amiga a Doom-only brain
[8]The Doom-in-a-PDF dev is back – this time with Linux
[9]They've only gone and made Doom run in a PDF file
As it transpired, nothing does. It all appears to work splendidly, considering that this is SQL doing all the work (aside from a shell script that runs the file approximately 30 times a second and some Python to handle the inputs). "And multiplayer 'just worked' because the database system, which handles all the nasty concurrency, is the source of truth," Vogel said.
"I set out to see if I could push Patrick's demo [DuckDB-DOOM] to an extreme: doing the entire rendering pipeline in SQL. And while it works, I have to admit that it is a pretty… bad idea? Fast enough, but horrible to maintain and debug."
Vogel was quick to pile kudos on DuckDB-DOOM, and while we'd quibble a little with calling this (and its ilk) "Doom" – they are more "Doom-like" rather than a port of the original – the skill required to make SQL jump through the requisite hoops is undeniable.
[10]
If persuading SQL to do the entire rendering pipeline is a "bad idea," we cannot wait for a terrible one. ®
Get our [11]Tech Resources
[1] https://github.com/patricktrainer/duckdb-doom
[2] https://cedardb.com/blog/doomql/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aMKdtprfVMhPMUteye5FxQAAAEA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aMKdtprfVMhPMUteye5FxQAAAEA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aMKdtprfVMhPMUteye5FxQAAAEA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2025/08/29/30_years_snes_doom/
[7] https://www.theregister.com/2025/08/06/cordoomceps/
[8] https://www.theregister.com/2025/02/16/dev_linux_pdf/
[9] https://www.theregister.com/2025/01/14/doom_delivered_in_a_pdf/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aMKdtprfVMhPMUteye5FxQAAAEA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://whitepapers.theregister.com/
I have that terrible idea you were looking for....
So:
It was a long time ago. And I was a college student on a placement at Oracle.
We needed to spell out the amounts on cheques. So "150.31" would be "ONE HUNDRED AND FIFTY POUNDS AND THIRTY ONE PENCE".
I did it by:
1. Take your amount. Split it in whole pounds and pence.
2. Convert both of them to Julian dates (number of days since epoch)
3. Using the to_char function as Oracle to spell the julian date. So "150" is turned into "ONE HUNDRED AND FIFTY"
4. Glue pounds and pence together, and add a couple of DECODES for edge cases.
5. Profit!
And the whole thing was a single SQL expression...
Vogel used CedarDB for database services, but said: "To be honest, the database nerd in me just wanted to turn all knobs up to 11 and see what breaks."
A Virtual Pint for Herr Vogel