Nicheloom

Market intelligence for builders — see what's gaining traction before it's crowded.

KiDoom

Running DOOM on PCB Traces

Details

External ID
46051449
Source
HN
Company
—
Product
KiDoom
Website domain
mikeayles.com
Launched
Nov. 25, 2025
Cohort
—
Upvotes
362
Upvotes percentile
0.9759825327510917
Tags
—
Fetched at
Sept. 7, 2026, 9:25 p.m.
Updated at
Sept. 7, 2026, 9:25 p.m.

Description

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: ScopeDoomAfter 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/#kidoomScopeDoom GitHub: https://github.com/MichaelAyles/ScopeDoom, writeup: https://www.mikeayles.com/#scopedoom

Enrichment

Theme
lightweight and on-device AI runtimes
Vertical
Horizontal
Function
Hardware & robotics
Audience
B2C
AI stance
Not AI
Project type
Hobby / open-source project
Normalized one-liner
doom running on pcb traces
Manually corrected
False

Could you build this?

No Translating the Doom engine's framebuffers into dynamically updated KiCad PCB tracks and component footprints in real time requires deep domain expertise in game engine internals and EDA data formats.

What it would actually take: This requires modifying the Doom source code (like Chocolate Doom) to intercept frame rendering and replace rasterization with a vectorizer that converts polygons and BSP output into KiCad PCB_TRACK segments and SMD footprints. The pipeline must interact with KiCad's pcbnew Python bindings or manipulate KiCad's s-expression layout files at high update rates. It requires specialized graphics hacking and EDA software development skills.

Discussion

20 comments analyzed.

Competitors mentioned: ZMachine games, FreeDoom, vector displays

Concerns raised: Occlusion logic needs improvement for display clarity, Cheap oscilloscopes may not distinguish between rendering intensity levels, PCB fab minimum order quantities (MOQ of 5) make it expensive per second of gameplay, High cost per second of gameplay (~80-100 Euro per second)

Feature requests: Native Teensy 4.1 implementation with WAD on SD card and direct input, Dynamic sprite simplification for smoother rendering, Map generation from chip design CAD files, Better occlusion rendering logic, Support for faster DAC or multi-kHz arbitrary waveform generator

Competitors

Other products that read as similar to this one — 78 launches clear the similarity bar, closest 8 shown.

Attention rank: #8 of 79 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).

Launched 27 days after the earliest competitor.

Other launches for this product

Same idea, different domain

Nobody's really built a hardware & robotics tool for Fintech yet.