Show HN: KiDoom – Running DOOM on PCB Traces

mikeayles.com

209 points by mikeayles 10 hours ago

I got DOOM running in KiCad by rendering it with PCB traces and footprints instead of pixels.

Walls are rendered as PCB_TRACK traces, and entities (enemies, items, player) are actual component footprints - SOT-23 for small items, SOIC-8 for decorations, QFP-64 for enemies and the player.

How I did it:

Started by patching DOOM's source code to extract vector data directly from the engine. Instead of trying to render 64,000 pixels (which would be impossibly slow), I grab the geometry DOOM already calculates internally - the drawsegs[] array for walls and vissprites[] for entities.

Added a field to the vissprite_t structure to capture entity types (MT_SHOTGUY, MT_PLAYER, etc.) during R_ProjectSprite(). This lets me map 150+ entity types to appropriate footprint categories.

The DOOM engine sends this vector data over a Unix socket to a Python plugin running in KiCad. The plugin pre-allocates pools of traces and footprints at startup, then just updates their positions each frame instead of creating/destroying objects. Calls pcbnew.Refresh() to update the display.

Runs at 10-25 FPS depending on hardware. The bottleneck is KiCad's refresh, not DOOM or the data transfer.

Also renders to an SDL window (for actual gameplay) and a Python wireframe window (for debugging), so you get three views running simultaneously.

Follow-up: ScopeDoom

After getting the wireframe renderer working, I wanted to push it somewhere more physical. Oscilloscopes in X-Y mode are vector displays - feed X coordinates to one channel, Y to the other. I didn't have a function generator, so I used my MacBook's headphone jack instead.

The sound card is just a dual-channel DAC at 44.1kHz. Wired 3.5mm jack → 1kΩ resistors → scope CH1 (X) and CH2 (Y). Reused the same vector extraction from KiDoom, but the Python script converts coordinates to ±1V range and streams them as audio samples.

Each wall becomes a wireframe box, the scope traces along each line. With ~7,000 points per frame at 44.1kHz, refresh rate is about 6 Hz - slow enough to be a slideshow, but level geometry is clearly recognizable. A 96kHz audio interface or analog scope would improve it significantly (digital scopes do sample-and-hold instead of continuous beam tracing).

Links:

KiDoom GitHub: https://github.com/MichaelAyles/KiDoom, writeup: https://www.mikeayles.com/#kidoom

ScopeDoom GitHub: https://github.com/MichaelAyles/ScopeDoom, writeup: https://www.mikeayles.com/#scopedoom

actinium226 5 hours ago

Lol, I jsut started learning KiCAD last week, and I work in at a game dev coworking space, so this is a perfect combination of the two! Nice!

  • aqid1 30 minutes ago

    [dead]

mlhpdx 6 hours ago

I don’t care how this makes the world a better place, because it just does.

sho_hn 6 hours ago

Love ScopeDoom!

KiDoom I don't fully get. The website says "All components connected to a shared net; the PCB could be sent to a fab house (it just wouldn't do anything useful)" but I don't see any of the component pins hooked up in the demo video.

  • hbnjjgff 3 hours ago

    What don't you get? The pins are not hooked up, so the PCB wouldn't do anything useful

    • sho_hn 3 hours ago

      It means they're not actually "all connected to a shared net", no?

      Something that actually connects the components and routes the traces in a way that makes it somehow still recognizable as the 3D environment would've been cool, otherwise this is kind of just like piping draw commands into a <canvas> from a hook in the Doom renderer. KiCAD just happens to be a complicated line drawing app.

      Don't get me wrong, still a fun little hack. But some more PCB-ness would make it even cooler.

      It might be that the website undersells it and there's more PCB-ness than I can detect in the visuals. Is it using layers and vias between them for the z-sorting or so? Both the website and the commits have a distinct AI slop feel to them and are somehow not very detailed on this part.

      • mikeayles an hour ago

        So the reason everything is on one net is so kicad doesn't need to calculate a ratsnest/air wires.

        As for the drawing, we pulled the vectors as a list from the C, and used a painters algo and drew back to front using the distance from the player in the python code.

        We then treated them as polygons to allow us to work out occlusion to hide things behind walls, but the data pipes to kicad/the headphone jack is just the vector/wireframes/outlines, filtered by what's left after the occlusion test.

        So yep, using footprints as sprites was my (clunky) nod to electronics, as I didn't like the idea of drawing polygons. Kicad can definitely handle them, but they're less fun.

        Now, if I'm really bored over Christmas, I may port it to fusion360, which will have a 3d engine.

        I 100% abused Claude code to get here, and i tend to get it to write the bones of a write up, which I then populated with my own thoughts, else I can't get started. We are worryingly becoming more aligned.

Lerc 7 hours ago

One of my to-do-one-day projects is an audio jack display system out of a Microcontroller.

Was never quite sure if I should raw XY it or soft modem so I could decode on a web page on a handy device.

  • retrac 7 hours ago

    > raw XY it or soft modem

    How about analog raster scan? a.k.a. slow-scan TV? [0] Like how they returned the live television images from the Apollo missions. (They only had 1 MHz of bandwidth for everything - voice, computer up and downlink, telemetry, and TV. Standard analog broadcast TV was 6 MHz. So they reduced the scan rate to 10 frames per second instead of 60, and halved the horizontal line resolution -- that could fit in 500 kHz.)

    Most modern SSTV standards are super-narrowband, designed to fit into just a few hundred Hertz for amateur radio. But what if you had the full 20 kHz of bandwidth of a nice audio channel? With 100 horizontal lines per frame, and 1 frame per second -- that is about 200 cycles per horizontal line, or enough to resolve, in theory, 100 vertical lines on each horizontal line. I.e., 100 x 100 pixels (ish) at 1 fps.

    [0] https://en.wikipedia.org/wiki/Slow-scan_television

jacquesm 2 hours ago

Inception version: make it so shooting components degrades the machine it runs on.

  • p0w3n3d 2 hours ago

    You remind me about Atari XL/XE game "Inside", which was fighting some dust balls or what? inside the Atari. If a circuit was broken you had to fly there and fix it, but when for example Pokey was broken the music was distorted, Antic - the screen was distorted etc

robbru 7 hours ago

Of course I love this. DOOM forever.

GaryBluto 4 hours ago

Awesome project, but why is the page a semi-transparent overlay on another page?

TOR22 33 minutes ago

[dead]

aqid1 28 minutes ago

[dead]

djmips 6 hours ago

This is just a meme now. Doom running on X. I don't get it but congratulations on your very whimsical accomplishment!

  • sethaurus 6 hours ago

    This is a little different from most "Doom on X" projects, because the accomplishment is less about the hardware (it's just a normal computer) and more about turning a circuit-board designer into a real-time game display.

  • nurettin 5 hours ago

    I wish doom ran on X.

    • sho_hn 5 hours ago

      Sorry, only Wayland allowed.