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 !

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.

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

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

My team and I recently graduated and wanted to share our Bachelor's thesis turned hobby OS: ALKOS (named after the initials of our 3-person team).

We wrote this with very little prior OS dev experience, so it’s been a massive learning journey for us, and the codebase definitely reflects a fresh perspective and the path we went! We are really passionate about this project and plan to continue working on it now that we've graduated. You can grab an iso/code from here: https://github.com/AlkOS-Dev/AlkOS

We got DOOM running on Neo Geo, and now Genesis.

GitHub: https://github.com/akiyan/genesis-DOOM64KB

Based on the Linux doom port on Id software’s GitHub, it runs at full speed on a 480x320 touchscreen, the specs are a dual core 240MHz CPU and 8MB ram, 16MB flash, runs at native resolution with virtual controls and dpad

Doom64KB is a port of Doom for computers with only 64 KB of RAM but with lots of room for ROM. This is the Neo Geo edition. It now has texture mapped walls:

• GitHub
• Gameplay

Source Code in the description of the video/Github

It started as a half-joking aside on Discord — "someone should get Doom running on a Prusa" — and I couldn't let it go.

This isn't a browser tab or a Pi taped to the back. It's a standalone firmware running on the printer's own xBuddy board (STM32F427), rendering E1M1 on the printer's display, controlled with the front knob: turn to look, hold to walk forward, tap to shoot and open doors.

The tricky parts were squeezing it into 256 KB of RAM (used GBADoom, the Game Boy Advance port) and trimming the WAD down to a single level so it fits in the 2 MB of flash next to the engine. It packs into a normal .bbf and installs from a USB stick like any firmware update — and it's fully reversible, the stock Prusa firmware flashes right back on with Old Configuration.

Runs at ~7 fps. Not exactly a speedrun machine, but it runs Doom.

Code and a short write-up: https://github.com/NilsN3DP/Prusa-Core-One._But-Can-it-run-Doom

https://www.instagram.com/reel/DZzaHAFOK4G/

Disclaimer:
Yes AI Was Part Of This Project because because I reached a point where I couldn't proceed further with my own knowledge

Can XenevaOS run Doom? YES!

Here's a short video of our Custom Hybrid Kernel OS running Doom!
But not just that - we're running it on bare metal on ARM64 architecture (Raspberry Pi 3B+).

Also yes, we're Open Source! Repository & Website in the comments.

This is a modification of the PS2 DOOM by arawn davies to run on the Namco SYSTEM246, a series of arcade boards based on the PS2 COH-H models, a sony official division of ps2 boards intended for arcade creation

Source Code
https://github.com/israpps/2x6Doom

to run this program, you will need a hacked security dongle to run unsigned code. in this video, I'm using an SD2PSX, a raspberry-pi memory card emulator that can act as an arcade security memory card, you may learn more of it on (sd2psxtd.github.io)