Coder runs Doom with regex at 80k subs per second

What happens when you combine the deeply complex world of programming with sheer, glorious randomness? You get an experiment that redefines what “playable” really means. Enter Artem Lytkin, a coder who has taken on arguably the most bizarre unofficial challenge in computer history: running the 1992 classic Doom game on the most improbable piece of hardware imaginable.

Forget powerful GPUs and sleek modern CPUs. Lytkin’s method involves using anything from toasters to Anker chargers, or even a pregnancy test, as the foundation for this virtual machine. This isn’t just about pushing hardware limits; it’s about proving that the architecture of a game can be simulated through sheer linguistic ingenuity.

The real magic, however, lies in leveraging a tool often dismissed as gibberish: regular expressions (regex). Regexes are powerful utility languages for text searching and substitution. While their syntax can look like a cryptic code, they possess the full technical capabilities required to be considered a programming language, complete with conditional statements and complex substitution rules.

Lytkin used these powerful capabilities, combined with the principles of the Turing machine and the Markov algorithm, to build a virtual CPU in text. He created a 96 MB plain-text string that served as the entire operational state of the system—containing sections for processor registers, memory (RAM), video output, and even the game’s WAD data.

By employing regex matching, Lytkin made the text substitute for actual binary instructions. The regular expression acted as a text-matching engine, finding patterns in the string to mimic the numbers inside each processor register, allowing the system to access and write to the simulated memory. It is an astonishing feat of conceptual engineering.

The resulting performance was, shall we say, slower than a leisurely Sunday stroll. Producing a single frame of game output required roughly 180 seconds, involving nearly 14 million substitutions. Yet, despite the slow processing speed, Lytkin demonstrated that this textual simulation was byte-identical to the actual Doom output. The system managed to run the game under extreme duress.

This experimental approach revealed a fascinating dichotomy: while the execution felt agonizingly slow, playing the game itself took on a unique quality. Lytkin noted that the experience was less like a frantic twitch shooter and more akin to “correspondence chess with a shotgun.” It turns a purely visual, action-packed experience into a profound exercise in algorithmic patience.

For developers and curious minds alike, this project offers an incredible look at how abstract logic can translate into tangible results. The entire system architecture—including the ingenious way Lytkin managed memory access using regex character jumps rather than repetitive scanning—is documented in the doom-regex repository, which features a mesmerizing visual demonstration of the regex machine in action.