People have ported Doom to everything from calculators to McDonald's cash registers. Recently, there has been a push to run the software on platforms that don't have the actual processing power, with PDF and Word documents being the latest examples. Of course, these methods are very slow, but incredibly, the game can even be executed on non-computer platforms.
People have ported Doom to everything from calculators to McDonald's cash registers. Recently, there has been a push to run the software on platforms that don't have the actual processing power, with PDF and Word documents being the latest examples. Of course, these methods are very slow, but incredibly, the game can even be executed on non-computer platforms.
Software engineer Dmitri Mitropoulos took the work of porting Doom to non-computer platforms to a whole new level. This programmer succeeded in making Doom run within TypeScript's type system, which was so complex that it took him a full year to complete this feat.
TypeScript is a language developed by Microsoft that adds static type checking capabilities to JavaScript to catch coding errors before execution. Think of it as a spelling or grammar checker for your code, ensuring that functions and variables are entered correctly. Developers often use it to build large JavaScript applications.
Running games within TypeScript's type system is considered "impossible". Mitropoulos even noted that he started the project to "quickly" prove why it couldn't be done. However, as he delved deeper into his research, he became obsessed with making it work. In the end, even experienced TS developers were impressed by him and had nothing to say.
Mitropoulos' version of Doom ran 3.5 trillion rows of types and consumed a staggering 177TB. It takes 12 days to compile one frame, resulting in an incredibly slow 0.0000009645 frames per second. The TypeScript type tracker must process 20 million type instances per second to produce output, resulting in extremely slow frame rates.
Despite the expense, Mitropoulos believes performance improvements are possible. In the Michigan TypeScript Discord channel he suggested that with further optimizations, compile times could be reduced to "1 to 12 hours." He has identified areas where he can improve his speed.
To make this happen, he built a virtual machine entirely using TypeScript types, including the logical implementation of all 116 WebAssembly instructions needed to run Doom. Every element of a functioning computer - memory, disk space, even the L1 CPU cache - must be painstakingly recreated in the type system. Since TypeScript only allows iteration of strings from the left side, he has to type the binary algorithm in reverse.
Running the program requires a custom WebAssembly runtime that handles everything in the TypeScript editor. Additionally, the TypeScript compiler had to be modified to handle the sheer scale of the project, as the type tracker alone consumed over 90GB of RAM during execution.
Mitropoulos described the work as a daunting challenge. He wrote 12,364 handwritten tests, learned multiple programming languages, and initially estimated that the project would require 1.25PB before optimization. At one point, compiling a framework required continuous instantiation for three months. He said artificial intelligence can't help.
"Oh, the AI can't do anything about any of that stuff," Mitropoulos said in his brief seven-minute video explanation. "It's so low-level, there are no arrays or objects or strings or booleans inside the engine, just binary numbers, and Doom only uses 64-bit and 32-bit integers, that's it. Oh, and those integers are neither signed nor unsigned. It took me all day to figure that out."
This arduous task took a full year, working 18 hours a day, to complete. Other TS developers have had a lot of questions about the project, so Mitropoulos plans to release two more videos explaining the highly technical details and his motivations. Now, we have yet another piece of evidence that Doom can run on anything - including things that can't run the game at all.