You Can Now Play DOOM In Microsoft Word, But You Probably Shouldn’t

January 20, 2025 by Lewin Day 21 Comments

DOOM used to primarily run on x86 PCs. It later got ported to a bunch of consoles with middling success, and then everything under the sun, from random embedded systems to PDFs. Now, thanks to [Wojciech Graj], you can even play it in Microsoft Word.

To run DOOM inside Microsoft Word, you must enable VBA macros, and ignore security warnings, to boot. You’ll need a modern version of Word, and it will only work on Windows on an x64 CPU. As you might imagine, too, the *.DOCM file is not exactly lightweight. It comes in at 6.6 MB, no surprise given it contains an entire FPS. It carries inside it a library called doomgeneric_docm.dll and the whole doom1.wad data file. Once the file is opened, a macro then extracts all the game data and executes it.

If you think that Microsoft Word doesn’t really have a way of displaying live game graphics, you’d be correct. Instead, that DLL is creating a bitmap image of the game state for every frame, which is then displayed inside Word itself. It uses the GetAsyncKeyState function to grab inputs from the arrow keys, number keys, and CTRL and space so the player can move around. It certainly sounds convoluted, but it actually runs pretty smoothly given all the fuss.

While this obviously works, you shouldn’t get in the habit of executing random code in your word processor. It’s just not proper, you see, like elbows on the dinner table! And, you know. It’s insecure. So don’t do that.

Continue reading “You Can Now Play DOOM In Microsoft Word, But You Probably Shouldn’t” →

Nice PDF, But Can It Run DOOM? Yup!

January 15, 2025 by Donald Papp 12 Comments

DOOM is a classic game to implement on a variety of platforms, but doompdf by [ading2210] is one we didn’t see coming. It runs a bit slow and controls are a little awkward but it does run. Entirely within a PDF file, at that.

How is this possible? PDFs are technically capable of much more than just displaying static content, and support JavaScript with their own library of functions. Adobe Acrobat implements the full spec, but modern web browsers implement at least a subset of the functionality in a sandboxed JavaScript runtime environment. Input and output are limited to things one might expect from a fancy PDF form (text input boxes, clickable buttons, things of that nature) but computation-wise, just about anything goes.

Continue reading “Nice PDF, But Can It Run DOOM? Yup!” →

Hackaday Links: January 5, 2025

January 5, 2025 by Dan Maloney 4 Comments

Good news this week from the Sun’s far side as the Parker Solar Probe checked in after its speedrun through our star’s corona. Parker became the fastest human-made object ever — aside from the manhole cover, of course — as it fell into the Sun’s gravity well on Christmas Eve to pass within 6.1 million kilometers of the surface, in an attempt to study the extremely dynamic environment of the solar atmosphere. Similar to how manned spacecraft returning to Earth are blacked out from radio communications, the plasma soup Parker flew through meant everything it would do during the pass had to be autonomous, and we wouldn’t know how it went until the probe cleared the high-energy zone. The probe pinged Earth with a quick “I’m OK” message on December 26, and checked in with the Deep Space Network as scheduled on January 1, dumping telemetry data that indicated the spacecraft not only survived its brush with the corona but that every instrument performed as expected during the pass. The scientific data from the instruments won’t be downloaded until the probe is in a little better position, and then Parker will get to do the whole thing again twice more in 2025. Continue reading “Hackaday Links: January 5, 2025” →

Protect Your Site With A DOOM Captcha

January 1, 2025 by Jenny List 25 Comments

We all know that “Can it run DOOM?” is the first question of a hardware hacker. The 1993 first person shooter from id Software defined an entire genre of games, and has since been made open source, appearing on almost everything. Everything, that is, except a Captcha, those annoying “Are you a human” tests where we’re all expected to do a search giant’s image classification for them. So here’s [Guillermo Rauch] with a DOOM captcha, in which you must gun down three bad guys to proceed.

As a way to prove you’re a human we can’t imagine a more fitting test than indiscriminate slaughter, and it’s interesting to read a little about what goes on behind the scenes. It’s a WebAssembly application as you might have guessed, and while it’s difficult to shake that idea from the early ’90s that you needed a powerful computer to run the game, in reality it shows just how powerful WebAssembly is, as well as how far we’ve come in three decades.

We’d prefer a few different entry points instead of always playing the same level, and we were always more handy with the mouse than the keyboard back in the day, but it’s certainly a bit of fun. It’s worth noting that simply playing the game isn’t enough to verify your humanity — if you’re killed in the game before vanquishing the required three foes, you’ll have to start over. As the game is running at “Nightmare” difficulty, proving your worth might be a tad harder than you’d expect…

Need more DOOM? How about seeing it on hardware nobody would have believed in 1993?

The Business Card Of DOOM

December 28, 2024 by Dan Maloney 11 Comments

This account of running DOOM on a PCB business card isn’t really about serving the “Will it DOOM?” meme of getting the classic game to run on improbable hardware. Rather, this project has more to do with getting it done right and leveraging work that’s already been done.

We’ll explain. You may recall [rsheldiii]’s previous DOOM keycap build, which was quite an accomplishment for someone who doesn’t fancy himself a hardware hacker. But he made a fair number of compromises to pull that build off, and rather than letting those mistakes propagate, he decided to build a more general platform to serve as a jumping-off point for the DOOM building community. The card is centered on the RP2040, which keeps things pretty simple. The card has a tiny LCD screen along with USB jacks for power and a keyboard, so you can actually play the game. It also has GPIO lines brought out to pads on the edge of the board, in case you want to do something other than play the game, which is shown in the brief video below.

Pretty standard stuff, right? Perhaps, but where this project stands out for us is that it stresses the importance of relying on reference circuits. We’ve all seen projects that have been derided for pulling the example circuit from the datasheet, but as [rsheldiii] points out, that seems a little wrongheaded. Component manufacturers put a lot of effort into those circuits, and they don’t do it out of the goodness of their hearts. Yes, they want to make it easier for engineers to choose their parts, but in doing so they’ve done a lot of the work for you. Capitalizing on that work wherever possible only makes sense, and in this case the results were perfect for the task at hand.

Continue reading “The Business Card Of DOOM“ →

Quake In 276 KB Of RAM

October 5, 2024 by Bryan Cockfield 20 Comments

Porting the original DOOM to various pieces of esoteric hardware is a rite of passage in some software circles. But in the modern world, we can get better performance than the 386 processor required to run the 1993 shooter for the cost of a dinner at a nice restaurant — with plenty of other embedded systems blowing these original minimum system requirements out of the water.

For a much tougher challenge, a group from Silicon Labs decided to port DOOM‘s successor, Quake, to the Arduino Nano Matter Board platform instead even though this platform has some pretty significant limitations for a game as advanced as Quake.

To begin work on the memory problem, the group began with a port of Quake originally designed for Windows, allowing them to use a modern Windows machine to whittle down the memory usage before moving over to hardware. They do have a flash memory module available as well, but there’s a speed penalty with this type of memory. To improve speed they did what any true gamer would do with their system: overclock the processor. This got them to around 10 frames per second, which is playable, but not particularly enjoyable. The further optimizations to improve the FPS required a much deeper dive which included generating lookup tables instead of relying on computation, optimizing some of the original C programming, coding some functions in assembly, and only refreshing certain sections of the screen when needed.

On a technical level, Quake was a dramatic improvement over DOOM, allowing for things like real-time 3D rendering, polygonal models instead of sprites, and much more intricate level design. As a result, ports of this game tend to rely on much more powerful processors than DOOM ports and this team shows real mastery of their hardware to pull off a build with a system with these limitations. Other Quake ports we’ve seen like this one running on an iPod Classic require a similar level of knowledge of the code and the ability to use assembly language to make optimizations.

Thanks to [Nicola] for the tip!

DOOM On A Volumetric Display

September 9, 2024 by Dave Rowntree 15 Comments

There’s something magical about volumetric displays. They really need to be perceived in person, and no amount of static or video photography will ever do them justice. [AncientJames] has built a few, and we’re reporting on his progress, mostly because he got it to run a playable port of DOOM.

Base view of an earlier version showing the motor drive and PSU

As we’ve seen before, DOOM is very much a 3D game viewed on a 2D display using all manner of clever tricks and optimizations. The background visual gives a 3D effect, but the game’s sprites are definitely very solidly in 2D land. As we’ll see, that wasn’t good enough for [James].

The basic concept relies on a pair of 128 x 64 LED display matrix modules sitting atop a rotating platform. The 3D printed platform holds the displays vertically, with the LEDs lined up with the diameter, meaning the electronics hang off the back, creating some imbalance.

Lead, in the form of the type used for traditional window leading, was used as a counterbalance. A Raspberry Pi 4 with a modified version of this LED driver HAT is rotating with the displays. The Pi and both displays are fed power from individual Mini560 buck modules, taking their input from a 12 V 100 W Mean-Well power supply via a car alternator slip ring setup. (Part numbers ABH6004S and ASL9009 for those interested.) Finally, to synchronise the setup, a simple IR photo interrupter signals the Pi via an interrupt.

Continue reading “DOOM On A Volumetric Display” →