Someone got Doom in an SQL database

Summary

Doom has been rendered in an SQL database using approximately 1,300 lines of SQL queries and 89 common table expressions. This project, SQLDoom, improves upon a previous iteration by generating full-color 640x480 frames at up to 35 frames per second. The creator highlights potential benefits for multiplayer servers due to the database's inherent state management.

Key Takeaways

1. 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.
2. 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.
3. Despite the substantial additional overhead of reading and writing to SQL tables for everything, Vogel said he was able to get DoomSQL running at about 60 fps on a Ryzen 7-powered laptop, with occasional dips down to 35 fps for busy scenes.

Statement Breakdown

• Claimed Facts: 70% of statements the article presents as facts
• Opinions: 20% of statements classified as editorial or subjective
• Claims: 10% of statements surfaced for additional reader evaluation

Credibility & Bias Reasoning

Credibility assessment: The article presents a technical achievement with clear explanations and details about the implementation. It cites the creator's own blog post and acknowledges potential limitations and overheads, indicating a balanced approach to reporting.

Bias assessment: Enthusiastic Tech Reporting. The article focuses on the technical novelty and achievement of running Doom in an SQL database. While objective in its reporting of facts, there's an underlying tone of fascination and appreciation for the ingenuity involved.

Note: This article details a technical experiment. While factual, the novelty of the achievement may overshadow practical applications.

Credibility flag: Technical Novelty

Claimed Facts (7)

• This is a factual statement describing the technical components of the project.
• This provides specific, quantifiable details about the implementation and performance metrics.
• This is a comparative statement of fact, referencing a previous project and its stated goal.
• This is a descriptive statement of the visual output of the project.
• This states a process and the reason behind its perceived simplicity, attributed to the original game's design.
• This provides performance data and context regarding the hardware used.
• This statement outlines specific technical advantages of using a database for game state management, attributed to the creator.

Opinions (2)

• This is a direct quote expressing a subjective opinion from the creator about the nature of his own project.
• The term 'pretty hacky' is a subjective assessment of the technical approach used.

Claims (2)

• The description of the previous project's graphics as 'simplistic' and 'more akin to Wolfenstein 3D' is a subjective comparison and potentially dismissive.
• The statement about 'pretty poor performance' is subjective and lacks specific metrics for the online demo.

Key Sources

• Lukas Vogel — Creator of SQLDoom
• Kyle Orland — Author