Although generally described as a document format, PDFs have ballooned from a Postscript-lite format into a mutant featuring XML and JavaScript support, basically turning what once was a fairly simple format into an interactive page. Naturally, this has to be used for good, and that is why we have the Doom PDF project, as well as [Game of Tobi] using that project as the inspiration for a Super Mario 64 port based on the decompiled source code.
The nice thing about the Super Mario 64 version is that it’s stand-alone, running from a 23.5 MB PDF, unlike the Doom PDF which runs the game in DOSBox. The compromise is that Super Mario 64 PDF runs at just a few FPS, with the output in glorious ASCII.
What enables this feat is to open the PDF in a viewer that supports JavaScript, with the PDF.js that comes with most browsers generally allowing for integrated JS in the PDF to be executed. Unfortunately [Game of Tobi] hasn’t released source code for this project, but we hope that this is forthcoming.
While one can argue about the practicality of this whole demonstration from a gaming perspective, it definitely shows that PDF as a format has gotten way out of hand now that it’s even overrun with hellspawn and Italian plumbers.
” unlike the Doom PDF which runs the game in DOSBox.”
No, it doesn’t.
Technical Implementation
Utilizes embedded JavaScript within PDF files
Runs modified DOSBox for DOOM execution
Leverages PDF.js capabilities in Mozilla Firefox
Implements innovative memory management solution
The DOOM PDF github linked in TFA is an AI slop ad for a website rehosting the file. https://github.com/ading2210/doompdf
Is the one that got most the press attention a few months back and is a pretty straightforward emscripten asm.js port of the DOOM source code.
Well, this remembers me a Sun conference in the 80’s (yeah, I’m pretty old now) where the idea was to use pdf as a mean to write on the screen (i.e. the graphic controller was a pdf interpreter, the screen being the page). The demo was interesting, but never materialized at the customer level… X-windows took the relay.
This was the logic for the PostScript displays. They were made and sold, but I believe at the time the cost was bigger than a normal display, thus the product was discontinued
Yes, PDF can serve as a small GUI and supports scripting.
I’ve also programmed just that – PDF entry form, naive/simple error checking, etc in the 2000s; in the long run the project was deemed too naive (won’t do proper error checking and data processing) and cancelled due to security concerns.
IMHO, SVG with scripting can accomplish about the same minus the heavy PDF bloat, and still have vector graphics, etc. I don’t think there are any wins, with PDF you’d still need the PDF Reader – in addition to the JS run engine wherever that is, whereas with SVG you need just the rendering engine alone.
1- DoomPDF does not use dosbox. It uses a modified version of the doom generic source port.
2- The GitHub repo URL for DoomPDF is wrong, it’s https://github.com/ading2210/DoomPDF.
The URL is correct, there’s more than one GitHub repo in the world.
There’s a lot of things wrong with this article.
First of all the original DoomPDF never used DOSBox or any kind of DOS emulation. It was a port of the original Doom source code. The previous Hackaday article about this topic has the proper details: https://hackaday.com/2025/01/15/nice-pdf-but-can-it-run-doom-yup/
Also, the article links to a spam site for DoomPDF. The article links to https://github.com/doom-pdf which was made by a spammer to bring clicks to their ad-filled site. The correct link is https://github.com/ading2210/doompdf.
Arrrr … Things that cause nightmares.
Why?
My boss threw an absolute fit when she saw the flight simulator in Excel 95. This is similar and signals the end of PDF as a sensible format.