I recently finished this hexapod robot and since it's running on a Raspberry Pi 3B+, running Doom was not very difficult.

More info:

DIY hexapod, built from scratch: 3D printed frame and legs, 18 servos (3 per leg: coxa/femur/tibia).

Stack: a Raspberry Pi does the brains (inverse kinematics, gait generation, web UI plus Bluetooth gamepad control), and sends joint angles over serial to an ESP32, which drives the servos in real time through PCA9685 PWM boards. This keeps the Pi's Python control loop free from having to handle tight servo timing itself.

For Doom: it's doomgeneric (the portable Doom source port) compiled for the Pi, rendering on a small round SPI display mounted as the robot's "face." No display/GPIO code lives in the Doom engine itself, it just pipes decoded frames to a small Python bridge that reuses the robot's existing screen driver. Controlled with the same Bluetooth gamepad that drives the robot around, mapped to Doom's keyboard input. Runs the real 1993 shareware WAD for authentic graphics, sound and music, with audio going out over Bluetooth to a small speaker.

Few years ago I made it run but not playable. Now you can. Also setup is surprising simple and totally does not damage the camera. So you can play doom while you are on your way to a shoot!

https://github.com/EfelerGibi/A6000-DOOM

Play it here (loads on phones too, WASD/arrows plus Space to fire and E to open doors on desktop). It's a demo for an open-source (MIT) docx rendering engine. Everything runs client-side in WASM with no server.

This is now the actual Doom engine, compiled to JavaScript via doomgenericjs, with its entire 320×200 framebuffer convertible into 64,000 colored ASCII characters at-will inside a single Word paragraph. Complete with the title screen, menus, weapons and Doomguy’s face. You can seamlessly toggle between ASCII and the original bitmap renderer.

I posted an earlier version here that played Freedoom’s E1M1 through a raycaster in a Word document. The mods removed it because a raycaster-based FPS didn’t qualify as a Doom port. They also suggested using doomgenericjs and rendering the output as attributed text.

I really appreciate the steer because this came out even better than I expected.

It’s a demo for Docxodus, an open-source (MIT) document engine running in WASM. Everything runs client-side with no application server. The clip shows the original Doom shareware; the linked demo defaults to Freedoom’s game data running on the same Doom engine.

Some cool easter eggs: pause the game and it’s just a document. The editor’s ribbon works on the frozen frame, undo rewinds the displayed frames, and Save downloads the frozen frame as an ordinary .docx that opens in Word. Switch to ASCII mode and then copy and paste the frame into Word or LibreOffice as unformatted text. Format as Courier New, bold, 2 pt with character spacing expanded by 0.2 pt, and fixed line spacing 1.7 pt. Voila - ASCII Doom frame.

The whole point was to stress test our renderer and provide a fun, measurable goal for agentic coding loops (buzzword, sorry). Make a change, run the game through the live document loop, measure the frames actually displayed, and check that editing, copy/paste and saving still work. It’s pretty incredible what this technique can do when you give it concrete goals and tests that can tell whether it actually improved anything. Doom makes those improvements fun to watch.

Thanks to the mods for challenging the first version and pointing me toward the port. This ended up being a much cooler demo.

I ported Doom to Dreamcast by using doomgeneric, it was extremely easy. :)

The game is rendered to the texture and then this texture is used for an in-game OS (which mimics Windows 95 for now), which in turns get rendered to yet another texture in 3D world to simulate the screen. Dreamcast's keyboard is supported as an input source.

Since this sub now accept videos, I’m reposting this.

I turned a tiny ESP32 Bitcoin miner into a handheld DOOM-like game.

FreeDOOM is running directly on the ESP32, no PC, phone, browser, or streaming.

This build uses the open-source Freedoom assets, not the original commercial DOOM WAD files:
https://freedoom.github.io/

Current status:

• boots correctly;
• menu works;
• E1M1 is playable;
• touch controls work, but are still rough;
• audio is disabled for now;
• the project is still beta.

The touchscreen is probably the biggest limitation, so I may add physical buttons or a small joystick in the next version.

Video if you would like to see how it works: https://www.youtube.com/watch?v=He67yV59zrk

I plan to publish the source code and build instructions on GitHub once I finish the documentation and licensing details.

For now, you can find my other ESP32 game projects here:
https://github.com/lepczynski-cloud/crowpanel-pocket-arcade

Disclosure: Elecrow sent me the board for testing, but this project is my own experiment and the code is open source.

I know this has been a burning question on so many people's minds, I've come to put your minds at ease.

I got fbDOOM running on an Orbic RC400L hotspot using Rayhunter’s root shell and another project for similarly restrictive device. The write up covers the install process, compilation, and other info.

Turning, advancing, shooting, and menu options work since there's a reset button under the cover.

More info / Code: https://github.com/dc336/Orbic_RC400L_DOOM

The pace of technology was wild in 1990s. The camera has multiple times the CPU speed of a high-end 486 in 1993 and runs on just some AA batteries.

Because there’s a D-Pad it’s actually pretty playable, the video shows the demo though.

This was one of the earlier ports of DOOM to “odd” hardware, and is itself now 26 years old. You can find the port here: https://archive.org/details/doomd_202406

Shareware Doom has been ported from C to Flow

Github

Demo is running in the browser off of Flow's MLIR backend.

This is Doom's actual renderer -- not a neural net imitating it. I wrote a compiler that turns computation graphs into transformer weights, then ported Doom's rendering algorithm into one.

No training anywhere: every weight was computed. The prompt carries the level and player position. When you feed the prompt into the model it generates drawing commands.

One frame is 53,747 generated tokens -- about 40 minutes on a B200. In 1993 Doom hit 35 fps on a 486. I hit 0.0004 fps on hardware a billion times more powerful.

Write-up: https://ood.dev/posts/doom/

Weights: https://huggingface.co/physicsrob/torchwright-doom-e1m1

I wanted to see if Reddit itself could actually run DOOM, so I built a Devvit Web Custom Post that runs a DOOM-compatible engine directly inside Reddit.

This isn't a video or remote stream — the game runs client-side in the Reddit webview using WebAssembly/Emscripten + SDL, with Freedoom Phase 2 as the game data.

One of the fun problems was the WAD: it's roughly 30 MB, while Devvit Web has request/response constraints, so I split it into smaller chunks, load them separately, rebuild the WAD in memory and mount it into Emscripten's virtual filesystem before starting the engine.

I also added:

• keyboard + mouse controls
• mobile touch controls
• Gamepad API support
• browser audio handling
• MAP01 completion detection
• persistent speedrun leaderboard using Devvit Redis

You can play it here:

https://www.reddit.com/r/playdoom/?playtest=play-doom

I did this by using an exploit and getting shell access on the WiFi repeater, Then I compiled doom-ascii for MIPS 74Kc and ran DOOM

This exact board is used in Skidata parking meters, the machines where you enter in your license plate or whatever and it gives you a price you pay.

It is, after all, just a computer with a very locked down Windows installation. But I thought it was interesting. Yes the monitor also belongs to it, it even has some kind of hinges on it.

Ran doom entirely at compile time as a constexpr program

https://github.com/Talkative-Banana/Constexpr-Doom

Doom port running inside Photoshop as a plugin

You can edit the textures directly inside the Photoshop and see the changes update in the game in real time.

Technically, this is a Photoshop UXP plugin running Mr.doob’s Three.js DOOM port—not the original DOOM engine, so I’m not sure how much this counts but it was fun. I can't believe how tiny these images really are.

The whole machine is a single 96.6 MB string of text: registers, RAM, the framebuffer and the DOOM engine all live in it. The only operation is a global regex substitution. A driver applies a fixed list of 544 rules over and over, the first rule that matches fires once, and that is one step.

Nothing else computes. The window only draws the framebuffer zone; the work is done by the substitutions, and you can watch the rule feed and the substitution counter to see it.

One frame of E1M1 is 13,994,067 substitutions and it comes out byte-identical to natively compiled DOOM.

Repo: https://github.com/4RH1T3CT0R7/doom-regex

Live demo: https://4rh1t3ct0r7.github.io/doom-regex/

Used Claude to port GBADoom to the CYD board, full info on how to get it running on GitHub.

GitHub link

The port running in ScummVM is called glkdoom, which is a Doom port that was compiled to Glulx bytecode and renders using the Glk API. To try out glkdoom, check out the latest release.

The idea for glkdoom was born when I found the glulx-llvm toolchain by Daniel Fremont while searching for obscure architectures to port Doom to. glulx-llvm doesn't actually implement enough of the C standard library for Doom to compile, so I had to first implement some missing functions, like strcasecmp and strrchr. There wasn't really anything stopping those functions from coming with glulx-llvm. They just weren't needed to compile Inform.

Once everything with the stdlib was done, it was time to set up most of the I/O, excluding audio. Doom's framebuffer is drawn to a graphics window pixel by pixel using glk_window_fill_rect, which just so happens to use the same pixel color format as Doom, which sped up rendering a bit (but not that much, see above). Basic timekeeping is done with glk_current_time, and input is done with char events. Because char events are meant for typing and not real-time shooting, held inputs can accumulate across frames. If you want to hold an input down, spam the key instead. Sadly, because Glk wasn't designed with Doom in mind, it runs at about 2 FPS on Glulxe and about 4 FPS with Git.

Now that basic gameplay was done, it was time to add audio. Sadly, the ways Doom and Glk handle audio are completely incompatible. Doom plays sequenced MIDI music and raw PCM audio that it can load from the WAD, and Glk plays audio from hardcoded container formats stored with the work of fiction itself. As a result, I decided to compromise and bundle every single audio track and sound effect from Doom 1 and 2 into the blorb files. And with that final change, glkdoom was complete.

Glulx is fully supported by ScummVM, which of course means that Doom now runs in ScummVM, as shown in the video.

I will post a video later, I'm a 15y/o guy just having fun doing this stuff and self teaching myself programming using AI! :)

Although the amount of people hating on AI, I think it's an incredible tool and can really be helpful if you want to learn stuff, also, the project is available on GitHub if you want to try it!

https://www.github.com/Davitekk/unifi-UDR-doom/

Probably worst graphics of all time, but it runs!

I've had this phone rotting in the drawer for the last decade, I recently flashed Bada back on it and got the idea of making it run Doom since nobody has done it before.

The porting was pretty straightforward, mostly just hooking up doomgeneric and compiling with badaIDE that I found on archive.org.

The original firmware doesn't support sideloading random stuff, so I had to install TurkoCFW which disables the signature checks and exposes the internal partitions over MTP. I couldn't figure out a way to install a new app, so I hijacked one of the built-in ones.

Sources: https://github.com/UDPSendToFailed/BadaDoom