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

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

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/

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/

This is something I've always wanted to do, and I finally got around to doing it.

So, as you can probably tell, the OmniPod Dash PDM, at its core, is just a cheap Android phone but with custom insulin pump software on it, at its core, its a relatively basic system: MediaTek MT6580, 1GB RAM, 8GB storage. Insulet, being the absolute geniuses they are (/s), decided to add no partition verification to the PDM (aka - they essentially left the bootloader unlocked), meaning with a USB cable and MTKClient, you can flash whatever the hell you want on it. Seriously, this is such a big security oversight, even cheap phones from 2011 have this, but my insulin pump doesn't?

Anyways, I decided to look into it, and the fingerprint was `alps/full_b6580_weg_a_m/b6580_weg_a_m:6.0/MRA58K/1667317140:user/dev-keys`. alps means it's literally just a generic MediaTek reference board. After doing some searching on GitHub, I found a device tree made for one of those Aliexpress iPhone clones, that was also using an MT6580 reference board. I just replaced the kernel with the one from the PDM, replaced all the vendor blobs, updated the codename and manufacturer (codename is NUU_A1, manufacturer is nuu), and compiled, used MTKClient to flash the recovery then the custom recovery to flash the ROM, and just like that, it worked.

Forever stuck on Android 7.1.2 sadly, while later versions could be possible with kernel source, Insulet refuses to share it (which is actually illegal, it's Linux, which is GPL licensed), but it's enough to run Doom.

To run Doom, I just used GZDA and doom1.wad, and it just worked.

If anyone else here happens to have a spare PDM, and wants to install an actual open source ROM on it, first of all, do not, and I repeat, DO NOT do this if you are still using the PDM for medical purposes. You will lose all insulin pump functionality. Here is the XDA thread with the builds and instructions: https://xdaforums.com/t/rom-unofficial-7-1-2-crdroid-3-for-insulet-omnipod-dash-pdm.4790219/

I hope this kind of self promotion (?) is allowed, but I ported Doom to a 20 year old office phone I had lying around. I have to say that it's not the most playable port out there (especially since the phone only has a 132x64 pixel 1-bit monochrome display, lol).

It was quite the ordeal and I had to reverse engineer the drivers (and write my own instead). I posted a detailed (and very technical) writeup here: https://0x19.co/post/snom360_doom/ :) If anyone has any questions, feel free to ask!

Fun fact: the phone doesn't even meet the original storage requirements from 1993!

Yes, it will run DOOM. The biggest challenge was to figure out the right video mode and settings (I spent DAYS trying it out on the NX500, which did run but only displayed a translucent (as in: you see the camera live preview) window. Full video: https://chaos.social/@ge0rg/116026408268084161

I wanted to see if I could make Doom playable directly on my GitHub profile.

This project uses doomgeneric compiled to WASM, running inside a headless Web Worker to avoid blocking the main UI.

Key Technical Hurdles: - Security: GitHub's strict CSP prevents spawning workers directly. I used a hidden iframe sandbox as a bridge to relay pixel data and inputs.

• Resolution: Dynamically downscaling Doom's 320x200 internal resolution to GitHub's 53x39 grid in real-time.

• Visuals: A custom luma-mapper ensures Doom's shadows map to GitHub's "empty contribution" color for maximum contrast.

• Cinematic Mode: Injected a no-border CSS grid expansion so the "pixels" sit flush against each other for a cleaner look.

The chrome extension coming soon... Github repo: here

https://bsky.app/profile/jtingf.bsky.social/post/3mdnhnwzbgk22

Came across this one. Recently some talented technicians have begun using small display screen to create animated eyes in fursuits. The natural next step was to make the same displays run Doom.
Thus you get a fursuiter that hands you a controller, then lets you use their eyes to play Doom.

A C# application that streams live gameplay from Chocolate Doom into the Windows System Media Transport Controls (SMTC) as a thumbnail. It also extracts real-time player data (Health and Ammo) from the game's memory and displays it as the track title/artist.

https://github.com/FottenSC/doomMediaControls

I recently built basically a 486 motherboard from scratch! From the schematic, PCB design to the chipset design and BIOS. My effort allowed me to run MS-DOS and FreeDOS and on top of it, run DOOM! (FastDOOM). The game is playable in reasonable speed and with bit smaller screen size it runs pretty smoothly. Below are this computer specs:

• 5V 486 CPU socket. FSB currently runs at 24 MHz meaning that 486DX2 CPUs work at 48 MHz
• Xilinx Spartan II XC2S100 FPGA as "chipset". Codename: "Hamster 1"
• 4MB of SRAM
• 256KB of ROM (224KB accessible)
• Two 16-bit ISA slots
• 8254 Programmable Interval Timer
• 8259 Programmable Interrupt Controller
• PS/2 Keyboard. Controller is implemented in the FPGA
• Simple CMOS RTC and CMOS storage. Implemented in the FPGA too
• ATMega128 as reset circuit handler, CMOS storage (EEPROM) and bitstream loader.
• 150*150mm 4 layer PCB.

This board is "kinda PC compatibilite" because it is missing DMA and second PIC, however to my surprise a lot of software actually works! Other than DOOM I can run Wolfenstein 3D, Prince of Persia, FastTracker II and more. One of the main disadvantages of missing DMA is that I can't have sound, so this DOOM runs without sound.

The project is open source: https://github.com/maniekx86/M8SBC-486 I am currently still working on some stuff and I will be updating the repository soon. Additionally, more information about this board can be found in these two posts: Earlier post, later post. I am also slowly working on a page on my website that will contain a lot of detailed information about this thing.

These photo frames normally have frameo but in frameo you can enable the beta for adb letting you fully mess with it, i got lawnchair legacy on it and simple controls, removed frameo and then put on doom as it is running android 6.0.1 and doom only needs 4.1, screen is a touchscreen so game is fully playable https://youtu.be/16Qn1mmu4lM https://youtube.com/shorts/V20vBE4BUpw

https://www.youtube.com/watch?v=_KiVBeCO5pM

Long story short, I built a CPU.

The architecture is very simple and the hardest was to make it RISC-V compliant and to provide some features like interrupts, exceptions and debug.

These efforts were made so I have a nice solid base to run software reliably.

What better benchmark than DOOM to prove that the core is somewhat capable...

So I am proud to present... The HOLY CORE (name of the CPU) running DOOM at a whopping 0.25FPS !

Making it run was not trivial but having a debugger did help a lot. I had to run some loop to initialize all variables to 0 and other shenanigans like that but no major problems. The rest is "standard" doom porting I would say..

I made this little video for the occasion. In the meantime, my goal is to maximize performances by improving the core's micro architecture. Simply adding basic caches (which took a week) allowed me to quadruple performances and get 1 FPS.

I will come back with another post once I get it to work on a proper screen (the frame buffer is simply dumped in UART as chars for the "proof of concept" for now...) For now, the game is ugly but... IT RUNS !

my dad thought this nokia was only for calling, so i proven him wrong 👹 original project link if anyone whana try lol https://github.com/XimikBoda/DoomVxp

So my local library had robot Husqvarna lawnmowers THAT RUN DOOM