Why Doom Belongs in Paint (And Other Places It “Shouldn’t”)
Creative coding hacks that run games inside everyday software—like Doom in Paint—are experiments where developers repurpose familiar tools as unexpected displays, using system-level tricks and nostalgia to turn mundane utilities into playful, technically revealing playgrounds for classic game engines and demos. This is more than a goofy meme. It is a statement about how flexible software architecture can be when curious people push it past its intended use. When a drawing program becomes a game screen, or a system monitor turns into a toy, we see how much power hides behind interfaces we treat as boring utilities. That subversive spirit is the real story: developers are not content to accept “what this app is for” and instead treat everything on their desktop as raw material.
DoomPaint: Turning Microsoft Paint Into a Game Monitor
DoomPaint is the purest example of this mindset: it runs the original shareware version of Doom while using Microsoft Paint only as its monitor. The compute happens in ViZDoom, a ZDoom-based platform designed primarily for AI research, which renders the game headlessly and feeds frames to Paint. Every rendered frame is placed on the Windows clipboard as a bitmap and pasted into the canvas as a genuine document edit, powered by an OLE clipboard hack that can keep the game near Doom’s native 35 fps tic rate. In other words, Paint “renders the game but does not compute it”—it displays pixels while the engine lives elsewhere. Performance depends on your PC and resolution between 320×200 and 640×480, and Russinovich notes it can drop to “spreadsheet-tier” when Paint struggles to composite images in time. It is gloriously impractical, and that is the point.
The Clipboard Trick: Exploiting Architecture for Play
What makes DoomPaint more than a visual gag is how cleanly it exploits Windows’ own architecture. An early version kept overwriting the clipboard before Paint finished reading frames, creating a race condition. The fix was decidedly clever: DoomPaint publishes a single OLE data object and updates the image bytes it supplies, letting Paint’s reads act as signals for when the next frame can be made available. A low-level keyboard hook captures movement, strafing, shooting, and door-opening while Paint remains the active window so the drawing app itself stays untouched. Every frame is a real edit, which means Ctrl+Z can walk backward through time and File > Save gives you instant PNG screenshots. This is creative coding in its pure form—using clipboard internals, input hooks, and document history not as dry APIs, but as building blocks for unconventional software uses like a fully playable FPS inside a paint program.
Nostalgia, System‑Level Curiosity, and the Doom-on-Anything Phenomenon
DoomPaint slots neatly into a long tradition: people have made Doom run on gut bacteria, a pregnancy test, and even a Commodore 64 port that gives the already primitive-looking shooter an even more pixelated look. These projects are not about playing the “best” version of the game. They are about nostalgia and curiosity colliding with low-level engineering. ViZDoom itself was built for AI experiments, yet here it powers a joke that exposes how clipboard rendering, threads, and tic rates actually behave. When developers turn classic games into software easter eggs hiding in Paint, task managers, or firmware screens, they are quietly teaching us that no tool is single-purpose. For people who care about systems—AI researchers, engine tinkerers, or hobbyists following instructions on GitHub to run DoomPaint themselves—these hacks are a reminder that the boundary between “serious” utilities and playful experimentation is mostly cultural, not technical.
What These Hacks Tell Us About the Future of Everyday Software
The takeaway from DoomPaint and its cousins is simple: our everyday software is far more flexible than its menus suggest. When a paint app becomes a game renderer and a classic FPS rides the clipboard at 35 fps, the message is that APIs, data objects, and threads are open territory for experimentation—not sacred implementation details. We should expect more creative coding hacks that reimagine task managers, editors, or note apps as playful platforms, not just static tools. That does not mean everything needs a game crammed into it, but it does mean developers should feel licensed to bend interfaces in unexpected directions. In the long run, the same curiosity that makes Doom run in Paint will lead to debugging views that are more visual, system monitors that tell clearer stories, and utilities that reveal their internals not as dry status windows, but as interactive spaces we can explore.
