Show HN: Doom (1993) in a PDF

[vk6]

https://doompdf.pages.dev/doom.pdf

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.

[nmeta]

am I the only dummy missing an instruction? the game takes off w/o my input, moving and blasting away. surely I'm just OOTL w/ PDF gameplay, which I blame myself for

[ThomasRinsma]

Author of "PDF Tetris" here.

Great work! We had the same idea at the same time, here's my version of PDF Doom:

Source: https://github.com/thomasRinsma/pdfdoom

Playable here: https://th0mas.nl/downloads/doom.pdf

Yours is neater in many ways though!

[yoz]

This is amazing, but there are even wilder ways to run arbitrary code inside a PDF. How about stringing together several thousand segment commands in JBIG2 (one of the image codecs supported in PDF) to create a programmable virtual machine? https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

[pavo-etc]

> limited JS runtime of the PDF engine

humanity has gone too far

[hardwaresofton → pavo-etc]

That’s the only way we know how to go

[quotemstr → pavo-etc]

:-) 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 → quotemstr]

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.

[DiggyJohnson → llm_trw]

This is a very concise explanation, thanks for putting it so clearly. It’s not the features or requirements that are the focus of the scorn, per se, but how we got here. I still prefer and use PDF all the time, but between overly dynamic crap and the mainstream tooling, well… “hate” is a reasonable hyperbole.

[p_ing → quotemstr]

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 → p_ing]

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.

[lolinder → quotemstr]

The concern isn't that it was JS, the concern is that there's a scripting system inside of PDF at all. Why? What? Form validation is a lousy excuse because forms themselves were a bridge too far for the format. Why do we need to be able to validate them?

I knew PDFs could be dangerous, but I didn't realize it was because they're intentionally designed to allow embedded scripts.

[danieldk → lolinder]

I don't think forms are a bridge too far, it was very common that forms were provided as PDF and it is more convenient for the sender and receiver to fill the fields on a computer for readability, etc. before printing.

However, forms could be handled by a very simple DSL that would be easy to write a safe interpreter for.

[quotemstr → danieldk]

JavaScript is already a simple language. There's no requirement to have a JIT even. What makes you believe a custom language would be any safer or better in another way?

[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.

[1]: https://news.ycombinator.com/item?id=42674116

[khaledh]

Portable Doom Format

[takeda → khaledh]

As long as it is in Chrome

[Narishma → khaledh]

Not that portable since it only works on a single PDF engine.

[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

[experian21e]

Wow, I love how doom has become the run it everywhere possible game!

[anilakar]

Both Doom and Bad Apple in top four articles on the HN front page. This week is off to a good start.

[joelvalleroy]

Cool! Next up, PDF reader that runs in Doom.

[mdaniel → joelvalleroy]

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

[em3rgent0rdr → joelvalleroy]

PDF readers and Doom all the way down.

[cloudking → em3rgent0rdr]

We must go deeper.

[initramfs]

Doom, the PDF Movie.

In Theatres, Near You

[MarekKnapek]

As PDF supports DEFLATE compression, it should be possible to shrink the size of the PDF document considerably.

[LorenzoGood]

Biggest one up in history.

[RajT88]

You monster.

[remoquete]

Now, if only I could type IDDQD to print protected PDF files.

[peterburkimsher]

Is the WAD file open-source as a PDF attachment now?

[crtasm → peterburkimsher]

There's no WAD in the repo, I assume the linked PDF contains the shareware episode.

[armSixtyFour → crtasm]

The build wgets the wad from elsewhere.

[crtasm → armSixtyFour]

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.

[vk6 → armSixtyFour]

I just added this as a feature. You can launch the game with custom WADs at the site's landing page (https://doompdf.pages.dev/). It'll open a new PDF file as a blob URL (and you can even save and redistribute the PDF it generates).

A disclaimer though - I don't have any experience with Doom modding. I don't know if the behavior of this feature is correct. All it does is it loads the PWAD by passing the "-file" argument to the game's main function.