Native port
GoldenEye on Metal
GoldenEye 007 ported to macOS, iOS and Apple TV on a native Metal renderer. Open source, releasing on GitHub.
GoldenEye 007 running natively on Apple silicon — macOS, iOS and Apple TV — on a Metal renderer rather than an emulator.
Releasing open source on GitHub.
Why a port and not an emulator
An emulator reproduces a console: the CPU, the graphics coprocessor, the timing quirks, the bugs. It works, and it costs you a whole simulated machine's worth of overhead to draw a frame that the host could have drawn directly.
A port throws the console away. The game's own logic is recovered and recompiled to run natively, and the rendering is rewritten against the platform's real graphics API. The result runs at the display's refresh rather than the cartridge's, scales to whatever panel it is on, and takes input from a modern controller as a first-class citizen rather than through a mapping layer.
It is considerably more work and it is the difference between "it runs" and "it belongs here".
The graphics problem
The original renderer targets fixed-function hardware with assumptions that no longer exist anywhere — a microcode display list, its own matrix stack, combiner modes with no modern equivalent, and a framebuffer format built around a 1996 television.
Metal is an explicit, modern API: you build pipeline state up front, manage your own buffers and encode command buffers yourself. Bridging those two worlds is most of the project. Every combiner mode has to be reproduced as a shader that produces the same pixels, because "close enough" on a game people have known for thirty years is instantly visible — the wrong blend on a muzzle flash reads as broken to anybody who has played it.
Three platforms, one codebase
macOS, iOS and tvOS share Metal and diverge on everything that matters: input, lifecycle, memory ceilings, and what a user is allowed to touch. Apple TV in particular has no keyboard, a strict memory budget, and a remote as the assumed controller.
Handling that as one codebase with narrow platform boundaries — rather than three forks that drift — is the difference between a project that ships and a project that is maintained once.
Open source
It goes up on GitHub. Preservation work that lives on one person's drive is not preservation.