Alejandro Villegas Alonso’s public project ports OpenLara to Espressif’s ESP32-P4-Function-EV-Board. It combines software rendering, audio, and USB HID keyboard input to run the classic Tomb Raider 1 engine. That is impressive work on a dual-core RISC-V microcontroller platform, particularly because the implementation does not lean on a conventional desktop GPU pipeline. Yet the technical details also put useful limits around the most eye-catching parts of the story: roughly 1 W, 400 MHz, and a 1024×600 display.
This is an OpenLara port, not a tiny console emulator
The first clarification is architectural. The project is based on the MS-DOS flavor of OpenLara and uses its software renderer rather than the GL renderer. OpenLara is an engine implementation capable of working with Tomb Raider game data; this is not evidence that the ESP32-P4 is emulating original PlayStation hardware.
That difference is significant. Emulation recreates the behavior of an original machine and its graphics pipeline, usually adding substantial processing overhead. A native or purpose-built engine port can instead make choices suited to the target platform, including a lower internal resolution, software rasterization, and use of available display-processing hardware. Neither approach is inherently “better,” but they make very different demands of the processor.
The accomplishment here is therefore not that a small chip has somehow become a PlayStation replacement. It is that a developer has adapted an engine and rendering route to a microcontroller-class system with tight compute, memory, and I/O constraints. For anyone interested in retro-game preservation, engine reimplementations, or low-power computing, that may be more instructive than the headline itself.
The game renders at 320×240, not 1024×600
The project’s published configuration uses an RGB565 software renderer at 320×240. The image is then hardware-scaled to a 1024×600 display through the board’s Pixel Processing Accelerator (PPA).
This is an important technical distinction because a 1024×600 output panel can make a demo appear to be rendering at that resolution even when the rendering workload is much lower. A 320×240 frame contains 76,800 pixels. A 1024×600 frame contains 614,400 pixels—eight times as many. Rendering at the smaller resolution and scaling for display is a sensible embedded design choice, but it should not be represented as native 1024×600 software-rendered gameplay.
The approach also makes practical sense for Tomb Raider 1. Its original-era visual design can remain readable at a modest internal resolution, while hardware-assisted scaling gives the connected screen a more usable image. The port also lists 44.1 kHz stereo audio over I2S using an ES8311 codec, so the project is tackling more than graphics alone.
For Windows gamers accustomed to judging a PC game by its monitor resolution, this is a helpful reminder that “display resolution” and “render resolution” are separate measurements. The same principle applies to PC technologies such as resolution scaling: outputting a high-resolution image does not necessarily mean every scene was rendered at that panel’s full pixel count.
What the setup actually includes
“Runs on a chip” is convenient shorthand, but it leaves out much of the system needed for the published configuration. The stated hardware arrangement includes an ESP32-P4 board with 16 MB of flash and 32 MB of PSRAM, a 1024×600 display, MicroSD storage, and a USB HID keyboard. The project also requires users to provide their own Tomb Raider 1 data files.
Those details matter for both reproducibility and legal expectations. The source port does not supply the commercial game’s assets. A person trying it must have access to the needed data files, as well as the specified peripherals and storage. The keyboard requirement also means the demonstrated experience is not, as published, a self-contained handheld or controller-driven appliance.
The screen deserves special attention in the power discussion. Espressif’s board documentation describes an optional 7-inch, 1024×600 capacitive-touch display and recommends powering its LCD adapter board through a USB connection. That does not reveal the actual consumption of the panel during Tomb Raider gameplay, but it illustrates why chip-level and whole-system power figures cannot be used interchangeably.
A complete playable station includes power conversion, display electronics and backlight, external storage activity, audio hardware, keyboard connectivity, and the development board around the microcontroller. Each can affect a measured result. The measurement boundary must therefore be stated: a USB meter measures power at the USB supply or input point where it is connected, while a claim about power drawn from the wall requires a separate AC-side measurement.
Why the “1 W” claim needs qualification
Secondary coverage describes the setup as consuming roughly 1 W at peak. That is a striking number, and it may be directionally useful as a claim about an efficient embedded demonstration. But the accessible material does not establish how the figure was measured, which supply rail was tested, or whether it covers the complete assembled system.
More specifically, neither the project README nor the cited secondary report documents the meter, measurement boundary, voltage, test duration, accuracy, or which peripherals were included. The linked video is titled as a power test, but its methodology could not be independently verified from the accessible material. Those omissions do not show the reported figure is wrong; they mean roughly 1 W cannot be treated as a verified total-power specification for the demonstrated gaming setup.
The ESP32-P4 datasheet offers a different type of information. It characterizes the family as a dual-core, 32-bit RISC-V MCU with a high-performance CPU rated up to 400 MHz. Its 400 MHz active-mode figures span 23 mA to 150 mA typical depending on workload and enabled peripheral clocks. The datasheet also cautions that active current can be higher when the chip accesses flash or PSRAM.
These values are useful for understanding that the processor can operate within an embedded power envelope. They do not convert directly into “Tomb Raider uses one watt.” Current alone is not power without a defined voltage, and controlled chip active-mode readings are not the same as total energy at a board input. More importantly, the game’s workload involves memory, display output, audio, storage, and USB activity—the very conditions where a narrowly framed chip-current table is least suited to characterizing a finished system.
There is a reasonable counterpoint: even if the measurement boundary is unclear, the port still demonstrates that classic 3D game content can be made playable on unusually modest hardware. That remains true. The problem arises only when a rough, unqualified power figure becomes the principal claim. “About 1 W” is an interesting secondary-reported observation, not a sufficiently documented system specification.
The 400 MHz label is not fully settled for this demo
The ESP32-P4 family can be described as supporting a CPU frequency up to 400 MHz. However, applying that exact speed to the showcased Tomb Raider build requires caution.
The README labels the SoC as dual-core at 400 MHz while also specifying “chip rev < 3.0.” Espressif’s revision information says the earlier v1.3 revision was stable at 360 MHz, while the newer v3.2 revision increased CPU frequency from 360 MHz to 400 MHz. The repository and accessible demonstration metadata do not identify the exact stepping or active clock of the showcased unit.
That creates a real ambiguity. It may be appropriate to say that the port targets the ESP32-P4 platform, whose current family documentation lists speeds up to 400 MHz. It is not justified to state as settled fact that this specific recorded run used a 400 MHz v3.2 chip. Likewise, the repository’s 30 FPS description is the author’s advertised result, not an independently documented benchmark with scene definitions, frame-time data, and repeatable test conditions.
This is not a minor editorial technicality. In embedded projects, silicon stepping, memory behavior, clock configuration, thermal conditions, and peripheral activity can materially affect results. A reliable performance claim should identify the board revision, chip revision, firmware configuration, and gameplay scenario. Until then, “advertised at 30 FPS” is more precise than “proven to run at 30 FPS.”
Why software rendering makes the result notable
The port is still noteworthy precisely because it takes the software-rendering route. The ESP32-P4 is not being presented here as a conventional graphics-accelerated PC platform. It is handling a 320×240 RGB565 rendering workload in software, then using dedicated pixel processing to scale the completed image for the 1024×600 panel.
That division of work is a practical embedded pattern. Keep the game engine’s render target small enough to be feasible, then use specialized display hardware for a task such as scaling that would otherwise consume processor time or bandwidth. It does not mean the PPA is rendering Tomb Raider’s 3D world; based on the published project description, its listed role is scaling the rendered image.
The design also underlines why the demo should not be compared directly with a Windows PC playing Tomb Raider at modern resolutions. A desktop system may be driving a vastly higher pixel count, operating system services, high-refresh displays, controller stacks, and a different rendition of the game. The meaningful comparison is not absolute graphical capability. It is the level of focused engineering needed to make an early 3D game engine, game data, input, audio, and display output operate on a compact MCU platform.
What enthusiasts should take from the project
For makers, this is a useful case study in adapting software to hardware limits rather than brute-forcing a desktop workload onto a small device. The project demonstrates several deliberate choices: a software-based engine path, a restrained internal render resolution, hardware scaling, PSRAM-backed board hardware, external storage, audio codec support, and USB keyboard input.
It also offers a reality check for anyone tempted by simplified headlines. Reproducing it is not equivalent to flashing a bare inexpensive chip and receiving a pocket Tomb Raider console. The published setup calls for a particular development board configuration, display hardware, MicroSD storage, a keyboard, and separately obtained game data. Buyers should also avoid assuming that an advertised board price includes all of those parts, or that any resulting system will consume exactly one watt.
For the broader technology industry, the lesson is more interesting than a dubious superlative. Efficient hardware and software adaptation can keep older game experiences accessible on hardware far below conventional PC specifications. But accurate reporting should preserve the boundaries: 320×240 is the renderer’s workload, 1024×600 is the scaled display output, 30 FPS is the repository author’s advertised result rather than an independent benchmark, and roughly 1 W is secondary reporting without sufficient measurement context to define whole-system consumption.
That framing does not diminish the achievement. It makes it clearer. A classic game engine operating with software rendering, audio, keyboard input, removable storage, and a scaled display on an ESP32-P4 development platform is compelling embedded engineering. It simply deserves to be celebrated for what has been demonstrated, rather than for power and clock claims the accessible evidence does not yet fully verify.