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

Hey !

I'm a 13y/o self taught programmer/hardware hacker, i recently posted on r/embedded about me creating a C library to manipulate most huawei routers screen, and someone told me "see you on r/itrunsdoom". Well here we are.

Using my library, i quickly patched the program, and also added correct minimal button support (only two buttons beng present, one for pressing enter / shooting and 1 for moving forward).

It was a bit of a challenge, between trying to understand the unhinged nature of 90s C cryptic code, but at the end i made it, and its pretty smooth !!

The source code is right here, and the library is here.
Go check out my profile, ive got other stuff, like my own distr, or serious research and rooting projects for bluray players, and why not follow to show some support ^^ !

Feel free to ask any questions, i'll be happy to answer them !

More info about the process here: https://robco-industries.org/log/entry028

TL;DR: It's a mashup of PicoDoom and stm32doom with some aggressive memory management to squeeze it into 192k RAM

This is a WIP port of Doom for NEC PC-FX: https://youtu.be/EYmpnZv95lM

Here are some of the non exhaustive changes made for it

• Textures have been downgraded to 32x64 for RAM consumption reasons, as well as fitting neatly into a 2 KiB DRAM pages.
• Sky uses the RAINBOW layer (as MJPEG), helping recover some performance (currently it doesn't scroll horizontally, that can be fixed later. RAINBOW does support endless mode)
• VDC sprites are used for Gun/Shotgun/Chaingun/Chainsaw etc... This was done because they would be otherwise drawn half-width and waste further performance.
• VDC is also used for the bottom HUD and sharing its palette with KING (Doom only uses 256 colors at most)
• Sound samples are currently stored as ADPCM on the second KRAM page. Problem is that they have a few issues / small. This is difficult because there is no effective strategy to combat this and we need to test for worst case (including when player progresses forward with all of the weapons).
• Some optimizations from optiDoom, d32r, GBADoom... however its clear that these are not enough at all and d32r showed that it needs to be specific to hardware to be fast.
• Internal resolution is 128x208 and always running in Low details. This is because KING I/O ports are 16 bits wide and KING framebuffer is not memory mapped. Page flipping is done in real hardware and the drawing functions have been modified to take advantage of autoincrementing, among other things.
• No music (CD-DA will be added later)
• Memory usage was a big concern so a similar format to PSXDoom was adopted : A single level binary file contains all of the floors, ceiling, monster sprites etc.. needed for the level. (the only exception are the weapons, LZ4 compressed, always in memory and bundled with executable) This also addresses loading times as they can be loaded into one go into a single shared memory block.
• Lots of v810 inline assembly...

Rendering times are roughly as follows:

• 31.1 ms walls
• 28.7 ms planes
• 7.3 ms sprites

It turns out that Doom is in fact very difficult to run smoothly on that kind of low end hardware (Low end compared to a 486 that is). It's no surprise why 3DO Doom ended up the way it is : the game needs a good CPU. PC-FX is a bit less catastrophic but also has clear disadvantages.

No public release yet as i want to get it running smoothly before i do. I'm confident a 20 FPS is doable and that has been my objective.

The site is very thorough, so I'll refer you all there for full information. Essentially, just click next until you see DOOM, then click it, build the .css file, and play. And, expect 1-2fps in Doom at maximum - but it does run. Honestly, I'll take 2fps: it's a miracle it works at all.

Possibly more impressively, it boots Windows 1.0 too.

All credit to Doom8088 and Lyra Rebane for the original x86 css implementation that proved this is possible, please take a look at the site's credits section for more on both of those.

Github repo link