Most laypeople who encounter SQL think of it purely as a tool for managing large datasets. While that is certainly what it was designed for, SQL is still a programming language at its core. It includes many of the features found in general-purpose languages like C or Python, and although it wasn’t built for general-purpose work, it can handle a surprising range of tasks that programmers might not expect to use it for. To demonstrate its capabilities, and perhaps to show off their skills with SQL, a group at CedarDB ported the original DOOM to this language.
The project stores the WAD data (essentially everything except the engine) in a series of tables, which was fairly straightforward compared to the rest of the project. Where it gets more complicated is managing the timing that ties the game to 35 fps, and of course rendering the images. Their rendering process takes up 1300 lines of SQL across 89 common table expressions (CTEs) which is certainly advanced for this language. The rest of the project is another 4000 lines of SQL, with a bit of Python to handle the keyboard inputs, timing, and display of the generated bitmap.
Perhaps counterintuitively, DOOM might be the perfect game to run on SQL. It was built in an era before dedicated graphics cards and isn’t truly 3D, meaning that the programmers had to do a lot of tricks to get it to look as if it is 3D. This results in a lot of data transformations uniquely suited to SQL. It’s almost like DOOM‘s original renderer was built by someone with extensive SQL knowledge in the first place. For those looking to try this out, the source code for the project is available on a GitHub page, and for some other unique implementations of DOOM there’s also this version built in regular expressions and this one in Microsoft Word.
Applications that are really a database with some kind of GUI rendering the frontend are quite common, btw.
I’ve also worked with not just dynamic loading, but SQL auto-generated, ie, within SQL itself there would be pre-processors deciding the branch of logic, etc. In very real sense bunch of SQLs would act as app business layer, NOT generated outside the SQL, inside SQL statements themselves, so it is decidedly doable. As far as reasoning goes, it is down to where does one keep the app states, in the code variables (ie outside the SQL), or in the database behind it, and sometimes it is easier (and faster) to go with the database.
I am speculating the real reason for the slowness is the database engine SQL execution plans that are not optimized for this particular kind of “programming”. Yet. While those things (calculating execution plans) are usually written by geniuses, they, too, are not super-geniuses knowing each and every use case scenario. Also, some of the limitations of the execution plan calculations are rooted in pretty mundane things, cache sizes, indexes/recalculations.
Depending on how thin you want to stretch the definition, almost all applications are just a database, some logic, and a GUI.
So it is finally a Python/SQL mix. So it is like “The glorious flying car” and on the end on the article is statement “… was loaded in Hercules”.
I don’t think that’s fair, given that SQL is designed as a backend database language, with the assumption that something else will provide front-end. So of course it requires something else to provide realtime input and graphic display capabilities.. which is exactly (and only) what the python part does.
To use another tortured airplane metaphor, if someone told me they had a Cessna 150 that could land on water, I wouldn’t be upset to discover they’d put floats on it rather than using the stock wheels.
A stock Cessna 150 can land on water, without any floats or other modification, it just can’t take off from water afterwards.
It should be noted that any aeroplane can land on water, however briefly.
I concede your and [irox]’s point :)
Although… the bar is pretty low for what constitutes a “landing”, but it’s not zero. If the airframe inevitably explodes or disintegrates on contact with water, I’m not sure it would count, even if the pilot was attempting a landing.
Which is why people don’t make airframes out of metallic sodium. Clearly.
In an alternative reality, Myst, Commander Keen or Blockout would be candidates for such ports, maybe. And society would be thriving there.
How many discs was Riven? That would be one epic dataset.
Riven, of course! It’s such a classic! 🩶
Btw, that reminds me I was somewhat focused on early 90s
that I totally forgot there’s also “realMyst” now, a 3D version of the original.
So maybe one of those two would been good candidates for ports.
Let’s imagine a world where people would not be trying to get bloody Doom on as many platforms,
but any of these episodes of Myst instead. 🥹
It would be fun to see Mario 64 ported to run in MySQL.
The amount of knowledge needed to make this hack, amazing!