Doom as an art gallery, as a CAPTCHA, banned by corporations, running on lawnmowers, on Lego bricks, teletext, even inside itself. Technical reasons are set aside, and the only valid answer is "because we can." So what's next? For years, users have injected all kinds of elements (some quite malicious) into PDF documents, but GitHub user "adding2210" created a port that brings the Doomguy into Google Chrome's PDF system.
When we think of PDF documents, we automatically imagine a rigid format, with content difficult to alter without external help. However, not everyone knows that PDF supports JavaScript. The only program to fully implement it was Adobe Acrobat, with features like 3D rendering and HTTP requests. On the other hand, the support we find in browsers like Chrome and Firefox is much more limited (citing security issues)… but that is not enough to stop "adding2210" on GitHub. What did he do? Run Doom in a PDF.
DoomPDF: 'Rip and tear' in a PDF document
"adding2210" explains that C code can be compiled to work inside a PDF using an old version of Emscripten that targets asm.js instead of WebAssembly. The rest is a matter of developing a way to register input commands, and a framebuffer for output. The inputs are simple, as Chromium's PDF engine supports text fields and buttons. The framebuffer is a very different story, but "adding2210" managed to present an output of six monochrome tones in pure ASCII, and each frame has an average latency of 80 milliseconds.
In short, it looks bad, but it doesn't matter. The only way to run DoomPDF correctly is using some flavor of Chromium, and to control the Doomguy you have to 'type' in a small section of the document. Obviously, framerate issues make it almost impossible to play, however, I imagine more than one daring person in the past accepted similar performance to 'enjoy' it on a 386.
