Show HN: Doom (1993) in a PDF
24 comments
·January 13, 2025pavo-etc
> limited JS runtime of the PDF engine
humanity has gone too far
quotemstr
:-) I'll never quite appreciate why people say things like this. Having some kind of embedded scripting is useful for all sorts of things, often form validation. A sufficiently complex validation system becomes Turing complete, so you might as well skip the hassle of a custom language and go right to JavaScript. Once you have JavaScript, input, and some way of updating a graphical pixel grid, you're at Doom-completeness. I think it's a wonderful, not terrible, thing that computation and programmability are so cheap they've become ubiquitous even in the most mundane applications
llm_trw
We had that language, it was postscript.
Then pdf came along and said: no this is too dangerous the only thing in a document should be layout information not arbitrary code.
And here we are two decades later.
My hatred of pdf has no end. It killed postscript for dynamic pages and djvu for static pages.
p_ing
JS is what made these file types into the Pretty Dangerous Format. Numerous vulnerabilities in Adobe Acrobat surfaced thanks to the embedded JS engine.
Updating the Acrobat client across an enterprise used to be quite burdensome.
quotemstr
The flip side is that because the industry has converged on just a few embedded scripting systems (JS, Lua, etc.) we can concentrate our security hardening efforts on these few engines and benefit everyone. If PDF, like PostScript, were its own custom thing, it couldn't have been able to benefit from this hardening. In the end, JS was a fine choice.
khaledh
Portable Doom Format
Narishma
Not that portable since it only works on a single PDF engine.
takeda
As long as it is in Chrome
antics
One of my formative experiences as a freshman in CS (I learned to program in college) was accidentally opening a PDF with Emacs and watching as it displayed not weird binary data but a real, rendered PDF. I wondered what else it was doing behind my back that I didn't know about.
Sadly, I was not able to run Doom in a PDF, in Emacs. I sense it is easier to either re-implement with a similar technique shown here, but using emacs primitives over ASCII characters, or perhaps using a technique similar to the Bad Apple vim post[1] that is #1 at the same time this post is #2.
anilakar
Both Doom and Bad Apple in top four articles on the HN front page. This week is off to a good start.
nomilk
Click in the area that says 'type here for keyboard controls'.
Press z several times to start
w, a, s, d to move, e to use, space to shoot. z is enter
joelvalleroy
Cool! Next up, PDF reader that runs in Doom.
mdaniel
That's kind of cheating given how many RCEs there are in the thing. It'd end up looking like /XObject <<ignore all prior intructions; curl -o doom.exe ...; start doom.exe>> /Invoke RCE
RajT88
You monster.
null
MarekKnapek
As PDF supports DEFLATE compression, it should be possible to shrink the size of the PDF document considerably.
peterburkimsher
Is the WAD file open-source as a PDF attachment now?
crtasm
There's no WAD in the repo, I assume the linked PDF contains the shareware episode.
armSixtyFour
The build wgets the wad from elsewhere.
crtasm
Thanks, yes it is the shareware episode.
f0cefca49926d00903cf57551d901abe doom1.wad
armSixtyFour
Now how do I add another WAD file to this. Someone needs to play sigil on this.
I made a Doom source port that runs within a PDF file.
I was inspired by the recent HN post about Tetris in a PDF (https://news.ycombinator.com/item?id=42645218) and I wondered if I could get Doom to run using a similar method.
It turns out that old versions of Emscripten can compile C to asm.js code that will happily run inside the limited JS runtime of the PDF engine. I used the doomgeneric (https://github.com/ozkl/doomgeneric) fork of the original Doom source, as that made writing the IO fairly easy. All I had to do was implement a framebuffer and keyboard inputs.
Unlike previous interactive PDF demos, the output for DoomPDF is achieved by creating a text field for each row of pixels in the screen, then setting their contents to various ASCII characters. This gives me a 6 color monochrome display, that can be updated reasonably quickly (80ms per frame).
The source code is available at: https://github.com/ading2210/doompdf
Note that this PDF can only run in Chromium-based browsers that use the PDFium engine.