A retro video gaming devotee has showcased Lara Croft adventuring in and among ancient tombs on a humble ESP32-P4 microcontroller. This highly affordable device (available as a sub-$25 dev board) packs a pair of 32-bit 400 MHz RISC cores and delivers a slick, playable 1,024 x 600 pixel experience for TheAlexKid777, yet consumes roughly 1 watt at peak. It is good to see someone having video-gaming fun with cheap, power-sipping new tech in 2026.

When it launched in the mid-90s, Tomb Raider quickly became a classic by successfully capturing the add-a-third-dimension-to-all-games-and-IPs trend while delivering an eminently enjoyable adventure game. Not all games were better because they were in 3D rather than 2D. Far from it. Now the compute power required to run a title like OpenLara doesn’t require an expensive and power-hungry game console - a cheap dev board that typically consumes milliwatts is capable enough today.

But the high-efficiency low-wattage gaming feat described above is just half the story. The other phenomenon demonstrated here is the beefing up of commonly available microcontrollers. Developers no longer need to be extremely resource thrifty when coding for these humble devices. They now pack plenty of horsepower to spare.

In the case of Espressif’s ESP32-P4, there is “a dual-core RISC-V CPU featuring AI instruction extensions, an advanced memory subsystem, and integrated high-speed peripherals,” the maker highlights. There’s also up to 64MB PSRAM, 768KB SRAM, an FPU, DSP, ISP, 55 programmable GPIOs, and more. It sounds almost like an original Tomb Raider era dream.

In TheAlexKid777’s demo, this hardware is attached to the back of what looks like a 7- or 8-inch LCD. It runs OpenLara at 320 x 240 pixels, which is PPA hardware scaled to 1,024 x 600 pixels. The game also features stereo audio pumped through the dev board’s ES8311 codec, and it's controlled via a connected USB keyboard.

We’ve previously reported on various ESP32 family microcontrollers being used to: power a retro Mac emulator, host a tiny ad-blocking dongle, and even run a 28.9 million parameter LLM. Some of these projects use far cheaper ESP32 microcontrollers, too, starting at $5.

Late last week, Google announced that scientists had, for the first time, “mapped the complete brain and central nervous system of an adult male fruit fly.” On Monday, software engineers were already demonstrating the full MaleCNS v1.0 fruit fly connectome being trained to play Doom, as well as Super Mario 64. In light of these developments, perhaps it is time to amend Arthur C. Clarke’s Third Law. We suggest something similar to ‘Any sufficiently advanced new technology will immediately be forced to play Doom.’

Let’s look at this story in its natural chronological order. Scientists have been using fruit flies for research for over a century. The winged insects have a strong history in the avenues of genetic research. The humble fruit fly is still relevant in the 2020s in genetics, neuroscience, and more.

Now, for the first time, the complete brain and central nervous system of an adult male fruit fly have been fully mapped. Google Research scientists worked alongside HHMI Janelia Research Campus and the scientific community to achieve this milestone. In the social media post outlining the achievement, Google claimed that AI was used “to combine millions of 2D images into 3D neural shapes, reconstructing a record-breaking 166,000+ neurons.” That’s somewhat below the estimated 86 billion neurons in the human brain. AI data centers are going to need more RAM, folks.

This scientific breakthrough is going to “accelerate our understanding of the brain, and is a major milestone in neuroscience,” noted Google last Thursday. By Tuesday, it was already being trained to play classic video games.

We’ve seen software engineer Alex Wormuth and ‘C++ ragebaiteur’ Jessica Paquette already demonstrate fly-brain video game training. Their fly-brain tinkering focuses on Doom and Mario 64, respectively.

Of their Doom training efforts, Wormuth says that “Each Doom frame stimulates sensory neurons. Neural activity is mapped to game controls. Damage triggers a stimulus to two PPL101 dopamine cells as reinforcement.” The dev closes their tweet with the question “Will the fly learn to survive?” The code is fully open source, and you can also watch the training progress of the 166,700 neurons live.

Paquette’s short video clip shows Mario repeatedly taking off and bumping into a wall. If it were bumping into a window, it would be exhibiting the pinnacle of fly-brain intelligence. We also have the code to this fly-brain video gaming project, which was “literally 100% vibe coded with GPT Astra… just for fun.” Hopefully non-coders/tinkerers will get updates on the success of this training via Paquette’s socials.

Solo developer Grow Now! Games has put a playable browser build of its walkable ASCII cyberpunk city online, running on a 283KB Rust WebAssembly engine feeding a WebGL renderer. The build went live this week alongside a second YouTube video, ASCII City Update: Interiors, Elevation & Skyscrapers, following the original video, which has passed a million views and 9,000 comments.

The page fetches ascii-city-engine_bg-DqjAhqbp.wasm, a 283KB module that reserves 1,152KB of linear memory at startup and reports an engine version of 0.1.0 when instantiated outside the browser. Its exports include initialise_native_game, step_native_game, and generate_native_local_map. Debug paths left in the binary name the Rust source modules behind those calls: city.rs, world.rs, population.rs, interiors.rs, and rendering.rs. World generation runs in Rust, which hands JavaScript base64-packed byte arrays covering building heights, tile kinds, surfaces, hues, saturations, window styles, lit flags, and floor plan IDs.

The renderer requests a WebGL context and compiles a vertex and fragment shader pair, the fragment stage consisting of a single texture2D lookup. Characters are drawn once each into an atlas canvas with fillText, cached per character-and-color combination, uploaded to the GPU with one texImage2D call, and then drawn as textured quads with six vertices apiece.

Atlas cells measure 11 pixels tall by the monospace advance width plus two. Every visible cell goes into one buffer upload, and one drawArrays call per frame. Two fallbacks sit beneath this, a Canvas 2D drawImage path when WebGL is unavailable, and a per-cell fillText path reachable through a ?direct URL parameter.

Desktop sessions render 180 columns by 80 rows, or 14,400 character cells, in 10px Consolas at nine pixels per row. Touch devices drop to 48 rows and between 96 and 168 columns, and the Rust engine uses a separate 160 by 112 profile. The vertex buffer preallocates 2.76MB and doubles when a frame overruns it.

Grow Now! Games described the original demo to PC Gamer as having "no Unity, there's no Unreal, there's no 3D models, textures, or shaders." A first-person Backrooms game for the 1994 Sega 32X runs on a raycasting engine written from scratch in C and SH-2 assembly. A multiplayer Doom tribute implements raycasting and sprite projection as a stack of SQL views, reaching roughly 30 FPS at 128 x 64. Thunder Lizard, an ASCII roguelike, has had its character grid redrawn by image models into full-motion visuals at around 10 FPS.

Champion coder Yusuke Endoh has been flexing their esoteric programming muscles on social media. Their latest confection is a Piet Quine – a GIF image that prints itself. In other words, the GIF is both the code and the precise result after running the code.

If you haven’t quite grasped the enormity of this feat from the title, it is worth breaking down the respective definitions of both Piet and Quine in a computer programming context. Piet is an esoteric programming language in which programs look like complex, colorful, tiled artwork. Inventor David Morgan-Mar named it after Piet Mondrian, the famous founder of the neoplasticism artistic movement. Such artwork is immediately recognizable with its bold squares and rectangles bordered by heavy black lines. Smaller Piet GIFs look a bit more Mondrian-y to me, but also look more like colorful QR codes than paintings.

Endoh has created a Quine, graphically. In computer coding, a Quine is a program that produces a copy of its own source code without any external input. This can be quite a tricky feat, even when confined to the world of ASCII text. A requirement of this coding art is that the output is a character-for-character identical representation of the input. It must not simply read its own file to do the duplication task.

When merging the two ideas above, together, things get a whole lot more complicated. However, the top-linked blog and the embedded video shine a light on the task at hand and how Endoh succeeded. Specifically, the video shows Piet Quine running. The Piet interpreter scans the source GIF image in a ‘load data’ phase, followed by a read of the GIF file header and palette info. The challenge here, raising the task above text Quines, is that the GIF folds in binary data, compression, and an awkward flow – they must all be handled deliberately to end up with the desired result.

A key thing to understand about the source image is that it includes a separately interpreted data part, compressed with an adaptive run-length encoding, and a code part. Endoh says that they managed to actually first achieve this way back in 2009, but the GIF was very tall, so not ideal for visual appreciation. The developer decided to ask Claude Code to analyze and reconstruct the original script and build a ‘landscape’ Piet Quine. Even with AI's help, it wasn’t easy to refine the design to the compact finished GIF seen in this article and video. Only after much work on shrinking the visuals and coaching Claude was the GIF shoehorned into the finished 4:3 landscape image (252 x 189 pixels).

Finally, Endoh reveals that a driving force behind their Piet Quine development efforts was the wish to raise awareness of the 2026 Obfuscated Programming Language Design Contest, which is running right now. If you can, please design an esoteric programming language and submit it! Endoh is one of the judges, and you have until October 1 to make your submission(s).

Running the 1992 Doom on the most random piece of hardware around has become probably the most common unofficial programming challenge. We've seen the game running on anything from toasters to an Anker charger, and even a pregnancy test. Enterprising coders also get it running on the weirdest software possible, and just recently Artem Lytkin got it running in regular expressions.

Developers in the audience are probably recoiling in horror, as that sentence is definitely cursed. You see, regular expressions (regexes) are a utility language used in programs for finding and replacing text. They're incredibly powerful, but the syntax is often said to be write-only, as it looks just like gibberish. For example, /.*(\d{4}).*/g would find the "2026" in "Tom's Hardware 2026 articles." They can be exceedingly complicated, as they include conditional statements, elaborate character-jumping, and substitution rules. However, this also means they fulfill all the technical requirements to be a programming language.

Leveraging those capabilities, Lytkin created a 96 MB plain-text string that contains sections for the virtual CPU's registers, some RAM, a video output (framebuffer), the game's WAD data, plus I/O and other bits and bobs. Once it's all started, the regex will start text-matching and substituting characters in the string to pretend they're the numbers in each processor's register, then accessing and writing to the "memory," so on and so forth.

As you can imagine, this is spectacularly slow, and Lytkin says that it takes around 180 seconds to produce a single frame of game output. Each of those needs nearly 14 million substitutions, though (a) it actually works and (b) Lytkin claims it's byte-identical to the actual Doom output running. You can even control the game with the keys, but as the daring coder poignantly illustrates, playing it "is closer to correspondence chess with a shotgun than to a twitch shooter."

Particularly nerdy devs will be happy to know how Lytkin wrote the memory access part: essentially a binary tree, by jumping from "branch" to branch using standard regex character-jump instructions. This avoids having to scan the entire 96 MB of text repeatedly just to find the "#M" marker bookending it. Lytkin notes the challenge was not about whether it could be done, but whether the game would run "before the heat death of the universe," as the engine fires up 80,000 text substitutions per second.

The doom-regex repository is here, and you can download a demo to run it on your own computer. The project's website demonstrates how the regex machine runs in both visual and text format, and it's mesmerizing to watch. It's quite reminiscent of the time we spent watching defragging utilities do their thing when we were young'uns.