FastDoom achieves its speed primarily through optimizing data access patterns. The original Doom wastes cycles retrieving small pieces of data scattered throughout memory. FastDoom restructures data, grouping related elements together (like vertices for a single wall) for contiguous access. This significantly reduces cache misses, allowing the CPU to fetch the necessary information much faster. Further optimizations include precalculating commonly used values, eliminating redundant calculations, and streamlining inner loops, ultimately leading to a dramatic performance boost even on modern hardware.
This YouTube video demonstrates running a playable version of DOOM within a TypeScript type definition. By cleverly exploiting the TypeScript compiler's type system, particularly recursive types and conditional type inference, the creator encodes the game's logic and data, including map layout, enemy behavior, and rendering. The "game" runs entirely within the type checker, with output rendered as a string that visually represents the game state. This showcases the surprising computational power and complexity achievable within TypeScript's type system, though it's obviously not a practical way to develop games. Instead, it serves as a fascinating exploration of the boundaries of what can be accomplished with type-level programming.
HN users were generally impressed with the technical feat of running DOOM in a TypeScript type. Several pointed out the absurdity and impracticality of the project, with one user calling it "peak type abuse." Discussion touched on the Turing completeness of TypeScript's type system, its potential misuse, and the implications for performance. Some wondered about practical applications, while others simply appreciated it as a clever demonstration of the language's capabilities. A few users questioned the definition of "running" in this context, arguing that it was more of a simulation than actual execution. There was some debate about the video's explanation clarity and a call for a blog post with a more thorough breakdown.
Someone has rendered the entirety of the original Doom (1993) game, including all levels, enemies, items, and even the intermission screens, as individual images within a 460MB PDF file. This allows for a static, non-interactive experience of browsing through the game's visuals like a digital museum exhibit. The PDF acts as a unique form of archiving and presenting the game's assets, essentially turning the classic FPS into a flipbook.
Hacker News users generally expressed amusement and appreciation for the novelty of rendering Doom as a PDF. Several commenters questioned the practicality, but acknowledged the technical achievement. Some discussed the technical aspects, wondering how it was accomplished and speculating about the use of vector graphics and custom fonts. Others shared similar projects, like rendering Quake in HTML. A few users pointed out potential issues, such as the large file size and the lack of interactivity, while others jokingly suggested printing it out. Overall, the sentiment was positive, with commenters finding the project a fun and interesting hack.
Summary of Comments ( 43 )
https://news.ycombinator.com/item?id=43258709
The Hacker News comments discuss various technical aspects contributing to FastDoom's speed. Several users point to the simplicity of the original Doom rendering engine and its reliance on fixed-point arithmetic as key factors. Some highlight the minimal processing demands placed on the original hardware, comparing it favorably to the more complex graphics pipelines of modern games. Others delve into specific optimizations like precalculated lookup tables for trigonometry and the use of binary space partitioning (BSP) for efficient rendering. The small size of the game's assets and levels are also noted as contributing to its quick loading times and performance. One commenter mentions that Carmack's careful attention to performance, combined with his deep understanding of the hardware, resulted in a game that pushed the limits of what was possible at the time. Another user expresses appreciation for the clean and understandable nature of the original source code, making it a great learning resource for aspiring game developers.
The Hacker News post "Why FastDoom Is Fast" (https://news.ycombinator.com/item?id=43258709) has several comments discussing various aspects of the original article about optimizing Doom's performance.
Many commenters express appreciation for the deep dive into Doom's optimization techniques. They highlight the ingenuity of the original developers in pushing the limits of the hardware at the time. Some commenters share their own experiences working with older hardware and the challenges and satisfactions of squeezing performance out of limited resources.
A recurring theme is the contrast between modern game development and the approaches used in older titles like Doom. Commenters point out how modern game engines often prioritize features and ease of development over performance, sometimes leading to bloat and inefficiency. Doom's lean, hand-optimized code is seen as a refreshing counterpoint to this trend.
Several comments delve into specific optimization techniques mentioned in the article. These include discussions of fixed-point arithmetic, lookup tables for trigonometric functions, and clever use of the CPU's instruction set. Commenters explain the benefits of these techniques in the context of the limited processing power and memory available at the time.
Some comments focus on the broader implications of the article's findings. They discuss how understanding these older techniques can be valuable for modern developers, even though the hardware landscape has changed drastically. Learning from the past can inspire creative solutions to performance challenges in current projects.
A few commenters share anecdotes about playing Doom in its early days and the impact it had on the gaming industry. These comments add a historical context to the technical discussion, reminding readers of the game's legacy and influence.
There's also discussion about the interplay between performance and gameplay. Commenters note how Doom's fast pace and responsive controls were a direct result of its optimized code. This reinforces the idea that technical excellence can directly enhance the player experience.
Finally, some comments provide links to related resources, such as other articles about game optimization and historical accounts of Doom's development. This adds further depth to the conversation and allows readers to explore the topic further. Overall, the comment section offers a rich discussion of Doom's optimization, its historical context, and its relevance to modern game development.