GoldenEye 007 Has Been 100% Decompiled: Why It Matters

GoldenEye 007 has just reached a milestone that would have sounded extraordinary when Rare's Nintendo 64 shooter appeared in 1997: the game's community decompilation project has reached 100%. Every one of the 208 files tracked by the project has now been reconstructed, giving programmers a source-level representation of one of the most influential console shooters ever made rather than forcing them to understand the game solely through the machine code stored inside an N64 cartridge.

The significance is much larger than simply being able to read old code. A conventional emulator recreates enough of the Nintendo 64 to make the original ROM behave as it did on Nintendo's hardware, whereas a successful decompilation exposes the software itself in a form programmers can study, rebuild and ultimately adapt. GoldenEye's mission logic, artificial intelligence, weapons, multiplayer behaviour and many of the systems that made the game unusual can now be approached at source level, creating possibilities for native ports, substantially deeper modifications, bug fixes and preservation work that would be far more difficult if the original binary remained the only practical reference.

There is an important distinction, however, between saying GoldenEye has been “100% decompiled” and saying Rare's original source code has somehow leaked. It has not. The community has reverse-engineered the compiled Nintendo 64 program and reconstructed source capable of reproducing the game, but original programmer comments, the exact names Rare used internally and much of the human context surrounding the code are not magically restored by that process. The result is an extraordinary technical reconstruction, not a recovered copy of Rare's development server from 1997.

The milestone also does not suddenly turn GoldenEye into freeware. The decompilation repository deliberately excludes game assets required to build a complete ROM and requires users to provide an existing copy of the game from which those assets can be extracted. The code and the copyrighted content carried inside a commercial game are separate issues, and that distinction will remain important as native PC projects and increasingly ambitious modifications develop around the work.

What makes the timing particularly interesting is that PC work has already started. GoldenRecomp is an active recompilation project based around GoldenEye and N64Recomp technology, and its developer reports that the game is already stable and producing good audio. It is not finished: multiplayer UI, parts of GoldenEye's unusual rendering, weapon timing at 60 FPS and modern dual-analogue controls remain on the list. Those unfinished areas demonstrate exactly why decompilation matters, because turning a Nintendo 64 game into a modern PC application involves considerably more engineering than changing a resolution value and pressing compile.

---

GoldenEye 007 Decompilation At A Glance

Back To Menu

What Has Actually Happened?

The GoldenEye decompilation project has spent years taking apart the compiled Nintendo 64 program and rebuilding it as understandable source. In August 2026, the public project tracker reached 100.0%, with all 208 files it monitors recorded as complete. That is the milestone behind the current headlines, and it represents a very different achievement from merely discovering a way to launch the old ROM on a modern computer.

GoldenEye originally runs as MIPS machine code intended for the Nintendo 64's processor. Machine code is excellent for a CPU because it consists of the instructions the hardware can execute directly, but it is a poor representation of how humans originally designed a large software project. Functions, structures, loops and relationships that would have been comprehensible inside Rare's development environment are transformed during compilation into a form designed for execution rather than explanation.

Decompilation attempts to travel back in the opposite direction. Researchers analyse that binary, identify functions and data, determine what each section is doing and reconstruct higher-level source that behaves like the original. In a matching decompilation project, the goal becomes even more demanding because the reconstructed source needs to compile in a way that corresponds with the original game rather than merely producing something that looks approximately correct when played.

The GoldenEye repository now contains C source for the game alongside low-level assembly, build tooling, headers and the structures required to reproduce the original software. It also contains Rare-specific technology such as a modified version of Nintendo's libultra libraries and custom RSP graphics code, illustrating why this project has involved much more than mechanically translating one processor instruction at a time.

The repository's README still describes the project as WIP, which may look contradictory beside a 100% status tracker but actually reflects an important distinction. Completing the project's tracked decompilation target does not mean every possible task surrounding a reconstructed 1997 game has ended. Documentation can improve, naming can improve, additional understanding can be recorded, regional differences can be investigated and downstream projects can continue adapting the code long after the matching milestone has been reached.

View The GoldenEye Decompilation Status

View The GoldenEye 007 Decompilation Repository

Back To Menu

What Does 100% Decompiled Actually Mean?

The easiest misunderstanding is to imagine that decompilation recreates Rare's original source files exactly as they appeared on a programmer's workstation in 1997. Compilation destroys too much human information for that to be possible. A variable that originally had a descriptive name can become little more than a memory location or register operation, while comments explaining why a programmer chose a particular solution are not needed by the finished game and therefore do not survive inside the ROM.

What can be reconstructed is the structure and behaviour of the program. Researchers can identify functions, infer data types, reproduce control flow and build source that generates the required machine code. Names can then be assigned according to what a function appears to do, with accuracy improving as more of the surrounding system becomes understood. A function that initially looks like a mysterious block manipulating addresses may eventually become recognisable as part of guard behaviour, weapon handling, collision, objectives or menu logic once its relationships with the rest of the program are mapped.

This is why a mature decompilation becomes vastly more useful than raw disassembly. An assembly listing can tell an expert exactly which instructions are being executed, but well-structured C exposes the relationships between those instructions in a form that can be modified, compiled, tested and discussed far more easily. Instead of patching individual instructions in a binary and hoping that nothing else depends on their exact layout, a programmer can change source logic and rebuild the project.

The GoldenEye build system provides another important measure of success. With the correct dependencies and assets extracted from a user's existing ROM, the project can build the targeted GoldenEye ROMs and compare the resulting output against known hashes. The process currently supports the US, Japanese and PAL versions, which means the decompilation is also preserving differences between releases rather than treating GoldenEye as one universal binary.

That level of reconstruction is what makes source-level modification practical. It becomes possible to approach the game as software again instead of treating it solely as an immutable cartridge image.

Back To Menu

This Is Not A GoldenEye Source Code Leak

The distinction between decompilation and a source leak matters both historically and legally. If Rare's original 1997 source tree appeared online, it could contain internal filenames, comments, development utilities, unused material and potentially other proprietary information copied directly from the company. The community project did not obtain that material and then upload it to GitHub; it has reconstructed GoldenEye by analysing the released game.

That means the source we can now read represents a modern understanding of what the compiled program does. It may reproduce the same logic, but a function name chosen by the decompilation team is not automatically the name Steve Ellis, Mark Edmonds or another Rare programmer originally used. A clear comment explaining some obscure piece of AI behaviour today may have been written by a reverse engineer nearly thirty years later rather than preserved from Rare.

This does not make the reconstructed source less valuable. In some respects it makes the achievement more impressive because the relationships had to be rediscovered from the finished binary. It simply means the article, future ports and preservation discussions should describe the result accurately: GoldenEye's code has been decompiled and reconstructed, not recovered wholesale from Rare's original development archive.

The asset boundary is equally deliberate. The project's README states that it does not include everything necessary to compile a complete ROM and instructs users to provide an unmodified copy of GoldenEye so the required assets can be extracted locally. Models, textures, audio, level data and other game content remain part of the commercial work even when programmers have reconstructed the code responsible for using them.

Back To Menu

How Do You Rebuild An N64 Game From Machine Code?

GoldenEye's age makes it tempting to imagine the game as simple software, but the opposite becomes obvious when looking at its source structure. The Nintendo 64 asks the main CPU and Reality Signal Processor to cooperate around graphics, audio, memory and custom microcode while developers work within extremely limited RAM. Rare then modified parts of Nintendo's own supporting technology and introduced game-specific systems on top of it.

The decompilation project therefore has to understand not only high-level mission logic but also the assumptions made by a 1990s Nintendo 64 development environment. Its current build documentation uses an SGI IRIX 5.3 IDO compiler toolchain because reproducing the compiler behaviour used around the original software is important when generating matching output. Modern GCC or Clang may understand C perfectly well, but a different compiler can optimise the same source into completely different machine instructions.

GoldenEye's project structure gives a sense of the layers involved. The main src/game directory holds GoldenEye-specific C source, while other areas deal with decompression, Nintendo's libultra, Rare's modified libultrarare and custom RSP graphics code. The repository explicitly identifies custom GBI assembly including C0 and 4Tri commands, which becomes particularly relevant when modern graphics backends have to reproduce rendering behaviour that does not fit neatly inside standard assumptions about Nintendo 64 games.

Assets add another layer. Images, animation data, level geometry, briefing information, character data, weapon models, setup information and text all have to be extracted and rebuilt into the correct structures before the final ROM can be assembled. The build process then combines code and data into the correct layout before creating the final Nintendo 64 image and checking that output against the expected version.

This is why the finished project is more useful than a folder containing thousands of automatically generated functions. A practical decompilation needs enough understanding of the original architecture to rebuild the software as a coherent program.

Back To Menu

Why GoldenEye Is Worth This Much Effort

GoldenEye is a particularly valuable target because its historical importance extends well beyond being a successful licensed game. The Strong National Museum of Play records more than eight million copies sold worldwide and identifies it as the third-best-selling Nintendo 64 release, behind only Super Mario 64 and Mario Kart 64. In 2025 it entered the World Video Game Hall of Fame, with the museum highlighting both its success as a console first-person shooter and the influence of its four-player multiplayer.

The game also represents a transitional moment in first-person design. PC shooters had already established the genre commercially and technically, but translating that style of play onto a console was not simply a matter of replacing the mouse with an analogue stick. Rare had to rethink movement, aiming, mission structure and encounter design around a controller and television while still creating something recognisably descended from games the team admired.

GoldenEye then added systems that gave the campaign an identity beyond straightforward corridor shooting. Objectives change as difficulty rises, guards can be avoided or alerted, cameras and alarms matter, gadgets become mission tools and levels contain spaces that exist partly because they make the environment feel plausible rather than because every room serves an obvious combat purpose.

Its multiplayer had an equally large cultural effect because the Nintendo 64 already provided four controller ports. GoldenEye turned that hardware into a reason for groups of players to crowd around one television, choosing weapons, characters and rule sets before attempting to work out whether anybody could be trusted not to pick Oddjob. The technology and design have obviously been surpassed, but the social structure of local four-player FPS competition became one of the defining experiences associated with the console.

Decompiling GoldenEye therefore preserves more than a famous game. It exposes an important point in the development of console controls, mission-based FPS design, artificial intelligence, local multiplayer and Nintendo 64 programming.

Back To Menu

GoldenEye Was Designed Before Rare Fully Knew The N64

One of the strangest facts about GoldenEye is that Rare began planning the game while the hardware it would eventually run on was still taking shape. Martin Hollis has described beginning work without a finished Nintendo 64 specification, relying instead on expensive Silicon Graphics development hardware and informed guesses about what the eventual console would be capable of doing.

The situation created obvious risks. Artists could create environments only to discover later that the final machine could not process them efficiently, while programmers were building systems around assumptions that Nintendo's hardware might ultimately invalidate. Yet the uncertainty also encouraged the team to push rather than design conservatively around a fixed specification.

The development group was exceptionally small by modern standards and included several people with little or no previous commercial game-development experience. Karl Hilton later characterised the team as university graduates carrying considerably more enthusiasm and ambition than practical experience, while David Doak has similarly described the unusually intense amount of time they were able to spend working on the project.

That should not be converted into a simple argument that inexperienced developers working extreme hours are somehow a superior production model. Accounts from the team also describe intense pressure and burnout, and the industry's long history of celebrating heroic development schedules can hide the personal cost behind successful games. GoldenEye's achievement is interesting because this small group learned extraordinarily quickly under unusual conditions, not because exhaustion should be treated as a prerequisite for creative work.

The controller presented another challenge because GoldenEye's design began before the team had a final control scheme around which to build. The N64 analogue stick eventually became central to the game, but Rare was effectively developing a new type of console first-person control at the same time players were learning how an analogue stick could work inside a 3D environment.

The resulting controls can feel unusual beside modern twin-stick shooters, yet they were a major step in demonstrating that complex first-person movement and aiming could succeed on a home console. GoldenEye did not invent console FPS controls, but its commercial success made it much harder to argue that serious first-person shooters belonged exclusively on PC.

Read More About Developing GoldenEye Before The N64 Was Finished

Back To Menu

From Virtua Cop To A Free-Roaming FPS

GoldenEye's final form was not obvious when development began. Martin Hollis and other team members have repeatedly identified Sega's Virtua Cop as a major early inspiration, with the original concept much closer to an on-rails shooting game than the free-roaming missions eventually released. The attraction makes sense because Virtua Cop offered immediate action, limited ammunition, reload management and highly readable enemy animation without requiring players to navigate complicated 3D spaces at the same time.

Rare gradually became more ambitious as its technology developed. The possibility of moving freely through levels transformed everything because a space designed for an on-rails shooter only needs to support the viewpoints the game intends to show, whereas GoldenEye's eventual player can approach guards, doors and objectives from different directions. Level geometry consequently stopped being scenery arranged around a camera path and became an environment players needed to understand.

Ideas from Virtua Cop remained embedded in the finished game. Ammunition magazines and reloading create moments when the player cannot fire, while enemy hit reactions and elaborate animation provide immediate visual feedback. GoldenEye's guards can react differently depending on where they are hit, and their physical responses give firefights a weight that distinguished the game from shooters whose enemies simply absorbed damage until an animation triggered.

Super Mario 64 provided another influence once it appeared during development. Hollis has specifically credited Mario's objective structure with inspiring the idea of multiple goals within GoldenEye's levels. Rare then adapted that concept into a completely different genre, producing missions in which Bond might photograph equipment, plant explosives, retrieve an object, protect somebody or escape after completing several interdependent tasks.

This combination is one reason GoldenEye was able to feel both familiar and unusual. The shooting retained the immediacy of arcade inspiration, while free movement and objectives gave the player reasons to understand each level as a place rather than merely a sequence of targets.

Watch Martin Hollis Discuss The Making Of GoldenEye 007

Back To Menu

Objectives Made GoldenEye Feel Like A Spy Game

One of GoldenEye's most effective ideas is so familiar to anybody who played it that its importance can be overlooked: changing the difficulty setting changes what Bond is actually required to accomplish. Agent, Secret Agent and 00 Agent are not merely the same missions with enemies given progressively larger health pools. Higher settings introduce additional objectives, meaning the player needs to understand more of the level and interact with more of its systems.

This provides difficulty through knowledge as well as combat. A player who can survive Facility on Agent has not necessarily learned where every objective is located, which equipment must be used or which sequence of actions is required on 00 Agent. Replaying a stage therefore reveals more of the underlying mission rather than simply asking the player to repeat exactly the same route against harder opponents.

The objective structure also helps GoldenEye feel like a Bond game. Shooting remains central, but the fiction repeatedly gives Bond another reason for entering the environment. The player may be gathering intelligence, destroying a particular installation or making contact with somebody rather than being sent into a level solely because several dozen enemies need eliminating.

Rare's unusual method of building levels reinforced this feeling. Martin Hollis has explained that environment artists sometimes created spaces without a tightly predetermined gameplay route before designers later populated those spaces with objectives and enemies. That sounds inefficient, and in production terms often was, but it generated rooms, alternate routes and architectural details that did not exist purely to guide the player towards the next scripted encounter.

The result resembles a location being used for a mission rather than a mission corridor disguised as a location. The distinction is subtle, but it contributed heavily to GoldenEye's sense of infiltration and became another reason its single-player campaign mattered alongside the famous multiplayer.

Back To Menu

Why GoldenEye's AI Felt Smarter Than It Really Was

GoldenEye's guards created another important illusion. Players remember enemies hearing gunfire, reacting to nearby events, running towards alarms, patrolling corridors, surrendering in particular situations and changing posture while fighting. On Nintendo 64 hardware with extremely limited memory and processing time, that could make the characters appear remarkably intelligent.

David Doak's later discussion of the system reveals something more interesting than an unexpectedly powerful artificial intelligence algorithm. Mark Edmonds developed a scripting system that allowed designers to combine behaviours and create context-specific reactions, while Doak and other developers continued extending those scripts as the missions evolved. The apparent intelligence was therefore produced by careful combinations of relatively understandable behaviours rather than one universal AI system reasoning about the entire map.

Guards can detect the player through sight and sound, react to gunfire and enter different alert states, but they do not possess a modern global understanding of every other character around them. Some situations that appear intelligent are actually bespoke scripts created for a particular level. Protecting Natalya, managing scientists or creating special behaviour around Silo and Train required designers to handle the exact circumstances they expected players to encounter.

This is a useful reminder that believable game AI and academically sophisticated AI are not the same thing. What matters to the player is whether the world appears to react consistently to their actions. A guard who hears an unsilenced weapon and runs towards an alarm provides meaningful feedback because the player can understand the cause of the reaction and alter their behaviour next time.

GoldenEye's stealth therefore emerges from the relationship between level geometry, sensors, alarms, patrols and scripts. The player learns that firing a loud weapon has consequences and that a camera or alarm can change the state of an encounter, allowing a relatively modest collection of behaviours to create tactical possibilities that felt far richer than the underlying hardware should have allowed.

A completed decompilation makes systems like these particularly valuable to researchers because the actual structures can be inspected rather than inferred solely from observing the finished game. The source can show where general AI ends and level-specific scripting begins, providing a much clearer picture of how Rare produced the illusion.

Read The Detailed Analysis Of GoldenEye 007's AI

Back To Menu

The Multiplayer Mode That Nearly Did Not Exist

GoldenEye's multiplayer became one of the defining features of the Nintendo 64, yet the mode was not the centre of the project from the beginning. Martin Hollis and programmer Steve Ellis have described multiplayer development beginning extremely late, around March or April 1997 when the commercial game was already approaching the end of its long development.

Ellis implemented the core multiplayer system in roughly a month, and the work was initially carried out without Rare or Nintendo management formally approving it. That does not mean the entire polished multiplayer experience materialised in exactly four weeks because optimisation, balancing, character selection, rule variations and extensive playtesting still followed, but the basic mode arrived remarkably late for a feature that would become inseparable from GoldenEye's reputation.

The Nintendo 64's hardware helped make the idea unusually practical. Four controller ports were built directly into the console, allowing four people to play without buying an adapter, while split-screen rendering allowed one machine and one television to become a small multiplayer network. That accessibility was fundamentally different from contemporary PC deathmatch, where networking multiple computers required far more equipment and technical preparation.

GoldenEye then gave those players enough options to turn a match into a social rule system. Weapon sets could be changed, characters could be selected and modes such as Licence to Kill or You Only Live Twice altered the meaning of the same maps. Arguments over Oddjob's height became part of the culture precisely because players were repeatedly sharing the same physical room and television.

From a decompilation perspective, this is another area with enormous potential. Multiplayer rules no longer need to be treated solely as fixed behaviour locked inside a ROM. Source-level modification can ultimately make it easier to experiment with player counts, modes, weapon rules, map logic and networking, although implementing something like proper internet multiplayer would still require substantial new engineering around a game designed for four controllers connected to one console.

Read How GoldenEye's Multiplayer Was Added Late In Development

Back To Menu

GoldenEye's Frame Rate Was A Deliberate Compromise

GoldenEye is famous for pushing the Nintendo 64 and equally famous for slowing down when too much begins happening at once. Large numbers of guards, smoke, explosions, detailed rooms and split-screen multiplayer can cause substantial drops from the game's nominal refresh target, and the effect is particularly obvious when viewed beside modern shooters running at a locked 60 or 120 frames per second.

Martin Hollis has described this as a conscious trade rather than an unexpected final bug. The team could have reduced scene complexity more aggressively to maintain a higher minimum frame rate, but doing so would have meant sacrificing enemies, effects and environmental detail that contributed to the experience. In busy situations the game could fall dramatically below its normal target, yet Rare preferred a richer world that occasionally struggled rather than designing every encounter around the worst possible performance case.

The regional versions complicate the subject further. NTSC versions target the approximately 29.97 Hz television standard, while PAL operates around 25 Hz. Real gameplay often runs lower than either figure because those values are not guarantees that every frame will be completed in time.

This historical compromise is one of the most obvious reasons a PC version is attractive. Modern processors and graphics hardware have performance reserves that would have been unimaginable to the original team, potentially allowing GoldenEye to render smoothly at resolutions and frame rates far beyond the cartridge release.

The decompilation also reveals why simply forcing the number upwards can be dangerous. Old games frequently connect simulation behaviour to assumptions about update rate, and GoldenEye is no exception. GoldenRecomp's current documentation already reports that certain guns fire too quickly when the game runs natively at 60 FPS all the time. A higher frame rate therefore requires identifying and correcting systems whose timing was built around the original update behaviour rather than merely asking the renderer to produce twice as many frames.

Back To Menu

What Can The Decompiled Code Now Unlock?

The most exciting possibilities fall into several categories, but none should be presented as automatic features that appeared the moment the tracker reached 100%. Decompilation provides the foundation; programmers still have to build the modern software on top of it.

Native PC Versions

Instead of recreating an entire Nintendo 64 around the original cartridge, developers can adapt or recompile GoldenEye's game logic for modern systems and connect it to contemporary graphics, audio, input and operating-system layers. This can reduce the amount of legacy hardware behaviour that needs to exist between the game and the player, although accurate emulation remains extremely valuable for reference and historical authenticity.

Modern Resolutions & Widescreen

A port can render at desktop resolutions far beyond the Nintendo 64's output and potentially support arbitrary aspect ratios, but widening the field of view can expose geometry the original camera was never supposed to reveal. GoldenRecomp already has an open issue concerning large fields of view allowing players to see through geometry, demonstrating how a seemingly simple visual improvement can expose assumptions built into old maps.

Higher Frame Rates

Stable 60 FPS and beyond should become increasingly practical, but timing-dependent code has to be separated from rendering frequency where necessary. GoldenRecomp's current weapon-rate problem provides a real example of why the work cannot be reduced to removing an artificial frame cap.

Modern Controls

Mouse aiming, conventional dual-stick input, configurable sensitivity, gyro controls and improved controller mapping become much easier to implement at source level. Again, the goal is not simply making the game more modern; a good port can offer modern options while preserving the original N64 behaviour for players who want it.

Bug Fixes

Bugs that once required ROM patches or carefully targeted binary modifications can be fixed at the level where the underlying behaviour actually exists. Developers can understand the cause, change the relevant code and rebuild rather than merely altering machine instructions around the symptom.

Much Deeper Mods

Custom missions, AI behaviours, weapons, rules and multiplayer systems can ultimately be altered at a level far beyond replacing textures or editing known data structures. GoldenEye already has an established ROM-hacking community, so exposing more of the game's architecture gives experienced modders a considerably larger surface on which to work.

Back To Menu

GoldenRecomp: The Current PC Project

The phrase “GoldenEye PC port” is already appearing in coverage of the decompilation milestone, but the current situation deserves more precision. One of the most important active projects is GoldenRecomp, maintained by KholdFuzion, and it uses recompilation technology rather than being a straightforward conventional source port.

The project's README says the game currently works and is perfectly stable with good sound, which means this is considerably further along than a theoretical proof that somebody might eventually get GoldenEye running. At the same time, its documented problems show how much platform-specific work remains between “the game executes” and “here is the polished modern release everybody imagined after reading the headline.”

GoldenEye's original use of the Nintendo 64 Translation Lookaside Buffer presents one complication because N64Recomp does not currently support the game's TLB arrangement directly. GoldenRecomp therefore uses a special modified branch of the decompilation that removes that requirement and stores the ROM in decompressed form. The resulting modified N64 build needs 8 MB of RAM if used on real hardware, meaning an Expansion Pak is required instead of the standard console memory configuration.

Recompilation itself has also needed GoldenEye-specific changes. The project documents unusual jump tables that required KholdFuzion to modify N64Recomp, illustrating again that Nintendo 64 games cannot always be pushed through a generic conversion pipeline without understanding their original implementation.

Rendering provides another problem. GoldenEye uses custom graphics commands for effects including the Dam skybox and the Frigate's sky and water, and GoldenRecomp notes that RT64 does not currently support those commands directly. Those pieces therefore have to be recreated or otherwise handled by the modern renderer rather than emerging automatically from the recompilation.

Then there are the player-facing issues. Multiplayer still needs UI work, modern dual-analogue controls remain on the list and certain guns fire too quickly at the current native 60 FPS update rate. None of these problems makes the project unsuccessful. They are exactly the sort of problems that become solvable once developers have sufficiently deep access to the program.

View The GoldenRecomp Project

What Happened To MGB64?

A separate project called MGB64, or Man with the Golden Build, took the more traditional source-port route and reimplemented GoldenEye in portable C with a modern application layer. It could build for macOS, Windows and Linux while requiring users to provide their own ROM for copyrighted assets, providing an important demonstration that the reconstructed code could support a genuinely native source-port architecture.

However, MGB64 should not now be described as the active GoldenEye PC project. Its repository was archived by its owner on 18 August 2026 and explicitly states that development, maintenance and support have ended. Existing builds remain historically interesting, but the project's own notice directs users towards other community work that has since surpassed it.

The two projects nevertheless demonstrate different routes opened by GoldenEye reverse engineering. One can adapt reconstructed source directly into a portable application, while another can statically recompile Nintendo 64 code and patch the platform-specific boundaries around it. The eventual GoldenEye ecosystem does not have to choose only one method.

View The Archived MGB64 Project

Back To Menu

Decompilation Vs Recompilation Vs Emulation

These terms are increasingly used together in retro-gaming news even though they describe fundamentally different approaches, and GoldenEye now provides a useful example of all three.

Emulation

An N64 emulator recreates the environment expected by Nintendo 64 software. GoldenEye's original ROM remains essentially the game, and the emulator provides equivalents for the CPU, graphics, audio, memory and other hardware behaviour needed to execute it. This is enormously valuable because one emulator can support a large library and can aim to preserve original hardware behaviour extremely closely.

Decompilation

Decompilation works on the software itself. Researchers analyse the compiled program and reconstruct higher-level source that reproduces its behaviour. The resulting source becomes readable and modifiable in ways the original machine code is not, although it remains heavily informed by the architecture and compiler that created the original executable.

Static Recompilation

A static recompiler instead converts compiled instructions from the original system into code that can execute on a modern host, usually while providing replacement layers for the old console's hardware interfaces. It can achieve excellent performance without requiring every function to be manually reconstructed into conventional source first, although game-specific quirks may still need patches and specialised support.

Source Port

A source port begins with sufficiently useful source and adapts the application around a new platform. Old graphics APIs can be replaced, operating-system assumptions can be removed and input, audio and filesystem code can be rewritten for modern machines. This provides enormous flexibility but can require substantial work because the original game was never designed around those modern abstractions.

None of these methods makes the others obsolete. Emulation remains one of the best ways to study the authentic console behaviour against which new ports should be compared, while decompilation exposes the game at a deeper level and recompilation can provide another fast route to modern hardware. Preservation is stronger when several independent ways of understanding and running the software exist.

Back To Menu

Why 60 FPS & Widescreen Are Not Simple Switches

The most predictable response to any N64 decompilation is a wishlist containing 4K, widescreen, 60 FPS and modern controls. Those are sensible goals, but GoldenEye provides an excellent demonstration of why old software cannot always accept them without further modification.

Frame rate is the clearest example. If a weapon's firing logic assumes a particular update frequency, doubling that frequency can cause the weapon to process its firing state twice as often. GoldenRecomp currently reports exactly this behaviour for certain guns at native 60 FPS. The correct solution is not to abandon 60 FPS but to identify every system making timing assumptions and separate game simulation from presentation where necessary.

Widescreen creates a different class of problem. GoldenEye's designers built and tested each environment against the field of view available on the Nintendo 64. Geometry hidden outside that view might never have needed to be watertight from every possible angle. Increase the field of view far enough and the camera can suddenly see through surfaces or reveal objects before the designers expected them to become visible.

Rendering effects can be even more specific. GoldenEye's custom Nintendo 64 graphics commands are part of the reason areas such as Dam and Frigate need special attention in GoldenRecomp. A modern renderer cannot display an effect it does not understand simply because the CPU-side game logic has been successfully converted.

The strongest future port will therefore be one that understands the original assumptions rather than simply removing every technical limit. Higher resolution, modern input and smoother animation can coexist with GoldenEye's original gameplay, but preserving the timing and encounter design requires deliberate engineering.

Back To Menu

What This Means For GoldenEye Modding

GoldenEye already has an unusually dedicated modification community, with ROM hackers having spent years learning the game's level formats, setup data and internal structures. Those achievements are especially impressive because much of the work was accomplished while the commercial ROM remained the primary object being modified.

A completed decompilation changes the scale of what can be approached comfortably. If a behaviour exists in readable source, a modder can follow the relationships between functions instead of locating a few bytes inside a binary and determining how far they can be altered without disturbing surrounding code. Systems that previously looked like fixed rules become potential design material.

Mission logic is an obvious example. GoldenEye's objective system, guards, alarms, cameras and scripted characters could support missions whose rules differ considerably from those Rare built. Multiplayer can be extended at a deeper level, while weapons can gain behaviour that would be awkward to implement through traditional binary patching.

Source access also allows tooling to improve. Editors can eventually target documented data structures instead of reverse-engineered offsets, diagnostic information can be added and the game can be instrumented while a developer is testing a map. That reduces the gap between creating content for a 1997 commercial engine and working inside something resembling a modern modding environment.

The likely long-term result is not simply “GoldenEye with better graphics.” It is GoldenEye becoming a platform from which people can build increasingly different experiences while retaining the movement, combat, objectives and AI that make the original engine recognisable.

Back To Menu

What This Means For Preservation

The preservation argument is less immediately exciting than seeing GoldenEye running at high resolution, but it may ultimately be more important. A commercial ROM is an extraordinarily compact historical artefact, yet understanding one requires either the original hardware or sufficiently accurate knowledge of that hardware to recreate its environment.

A source reconstruction adds another form of evidence. Future programmers can inspect how the game works, rebuild it and adapt the underlying logic when today's operating systems, processors and graphics APIs have themselves become obsolete. That does not replace the cartridge; it preserves a different layer of information about the software.

The decompilation also documents a development culture that is disappearing. Rare's modified Nintendo libraries, its custom graphics code and the way a small British team structured a major N64 game can now be studied directly. Researchers no longer need to infer every technical decision from screenshots, interviews and runtime behaviour.

Multiple regional versions add further value. PAL, Japanese and North American GoldenEye are not completely identical, and a buildable project provides a framework for identifying exactly where those releases differ. Even apparently small changes such as fixes, timing differences or altered text become easier to document when the relevant code can be compared directly.

Emulation remains essential throughout this process because it provides a reference for what the original binary actually does. A source port that accidentally changes AI timing or weapon behaviour may run beautifully but still fail as an accurate representation of GoldenEye. Preservation works best when the original ROM, accurate emulation, hardware testing and reconstructed source can be compared against one another.

Back To Menu

What The Decompilation Does Not Give You

The current excitement makes it worth defining the boundaries clearly because otherwise “100% decompiled” can quickly become “GoldenEye is now open source,” which is not the same statement.

The project does not make GoldenEye's commercial assets freely redistributable. The repository explicitly requires a pre-existing copy of the game because assets must be extracted from the user's ROM. A future port can distribute new open-source platform code while still requiring the user to supply GoldenEye data, an arrangement already familiar from source ports of other commercial games.

The decompilation also does not restore all of Rare's development history. Original comments, unused source that never reached the final ROM, external tools and abandoned experiments cannot be reconstructed merely because they once existed somewhere during production. If a compiler removed something completely from the released binary, there may be no information left from which to recover it.

Nor does completion automatically produce a flawless PC edition. Native graphics, audio, controls, input latency, multiplayer, save handling, timing and platform integration all require engineering. GoldenRecomp's current issues are useful evidence of the remaining work rather than weaknesses in the decompilation itself.

Finally, 100% should be understood in relation to the project's own tracked goal. The tracker reports all 208 files complete, while the repository can still legitimately call itself a work in progress because researchers continue refining everything surrounding those files. Software archaeology rarely reaches a point where nobody can learn anything else.

Back To Menu

What About The Official 2023 Release?

GoldenEye already returned officially in January 2023, which raises an obvious question: if Rare, Xbox and Nintendo have already made the game playable on modern consoles, why does a community decompilation matter?

The Xbox release addressed many of the accessibility problems associated with returning to the original N64 cartridge. Rare's version supports modern control options including dual analogue sticks, native 16:9 presentation, resolutions up to 4K, a more consistent refresh rate, achievements and the original four-player local split-screen multiplayer. It gave Xbox players a legitimate and convenient way to experience the 1997 game without configuring an emulator or original console.

Nintendo's Switch Online release takes a different approach by presenting GoldenEye through the Nintendo 64 catalogue and adding online functionality around the original multiplayer experience. That made it possible for players in different locations to participate in multiplayer that had originally required everybody to sit around the same television.

These releases are important, but they remain finished products controlled by the platform holders. Players can use the options provided to them, but they cannot inspect the game architecture, rewrite guard behaviour, build a new renderer or design a radically different mission system.

Decompilation therefore solves a different problem. The official release preserves access to a curated GoldenEye experience, while reconstructed source preserves the possibility of understanding and extending the technology underneath it. The two approaches complement rather than replace one another.

There is also something fitting about the timing. GoldenEye entered the World Video Game Hall of Fame in 2025, received renewed official accessibility in 2023 and has now reached a major community preservation milestone in 2026. A game whose long-term reputation once depended heavily on ageing cartridges and memories of four-player matches is becoming unusually well documented from several different directions.

Read Rare's Official GoldenEye Modern Release Announcement

Read Nintendo's GoldenEye Switch Announcement

Back To Menu

What Happens Next?

The 100% milestone changes where effort can be spent. Matching the remaining assembly is no longer the central objective of the status tracker, allowing more attention to move towards documentation, tooling, recompilation, native platform work and modifications built on top of the reconstructed game.

GoldenRecomp is the project to watch immediately because it has already moved beyond theory. The game runs, major systems are functional and the remaining list contains the sort of specific engineering problems expected when converting unusual N64 behaviour into a modern desktop environment. Solving those issues could produce an increasingly polished PC experience while simultaneously improving the tools available to other Nintendo 64 recompilation projects.

A conventional source port may also re-emerge. MGB64 demonstrated that portable C builds for modern desktop systems are possible even though that particular project is now archived, and completion of the main decompilation makes the underlying source a stronger foundation for anybody pursuing another port architecture.

Modding is likely to expand alongside those projects. Once a stable modern runtime and mature decompiled source exist together, the barrier to experimenting with GoldenEye drops substantially. Rather than asking whether a binary patch can squeeze another behaviour into the original ROM, developers can begin asking what they want the game to do.

The most important outcome may therefore take several years to become visible. Super Mario 64's decompilation did not matter only because somebody produced a PC executable; it created an ecosystem of ports, enhancements, technical research and increasingly ambitious modifications. GoldenEye now has the foundations required for a similar transition, although its licensed Bond content and unusually customised N64 technology make its path distinct.

What happened in August 2026 is not the arrival of the definitive GoldenEye PC edition. It is the point at which one of the largest technical barriers standing between GoldenEye and that future has been removed.

Back To Menu

The Bottom Line

GoldenEye 007 reaching 100% decompilation matters because the Nintendo 64 classic is no longer understandable only as a black box whose behaviour must be observed from the outside. Years of reverse engineering have reconstructed its tracked code into source that can be built, inspected and modified, exposing systems created by one of the most influential small development teams of the 1990s.

That matters for players because native PC work, modern controls, smoother frame rates, widescreen support and much deeper mods become substantially more achievable. It matters for programmers because GoldenEye's AI, objectives, multiplayer, rendering and platform code become educational material rather than mysteries hidden inside MIPS instructions. It matters for historians because the implementation provides another form of evidence for understanding how Rare managed to produce such an ambitious game on difficult hardware.

The achievement should not be exaggerated. GoldenEye is not suddenly public domain, Rare's original source archive has not appeared online and a perfect 4K 120 FPS PC version does not automatically emerge from the reconstructed C. The assets remain copyrighted, platform work remains necessary and modernising timing or rendering can expose assumptions embedded deeply in the 1997 game.

Those limitations are precisely why the milestone is important. The difficult questions have shifted. Instead of asking whether GoldenEye's code can ever be reconstructed completely enough to work with, developers can increasingly ask what they want to build from it.

For a game built by a small team before the final Nintendo 64 hardware was even completely understood, surviving long enough to have its entire program reconstructed by another generation of developers feels particularly appropriate. GoldenEye helped prove that a first-person shooter could thrive on a console in 1997; in 2026, its community has ensured that the technology behind that achievement can continue being understood long after the hardware that defined it has become retro history.

Back To Menu

TL;DR: Why The GoldenEye Decompilation Matters

If you only want the short version, GoldenEye's public decompilation tracker has now reached 100.0%, with all 208 tracked files complete. That gives developers a source-level reconstruction of the original Nintendo 64 game and removes one of the largest technical barriers to deeper ports, modifications and preservation work.

GoldenEye Decompilation In A Few Minutes

• GoldenEye 007's tracked decompilation has reached 100.0%, covering all 208 files listed by the project.
• This is not Rare's original leaked source code. The code has been reconstructed by reverse engineering the released Nintendo 64 program.
• Original comments and exact internal names are not automatically recovered because compilation does not preserve all of that human information.
• The project can rebuild US, Japanese and PAL GoldenEye ROMs using the appropriate build environment.
• Copyrighted game assets are not simply included with the decompilation. Users need an existing ROM from which required assets are extracted.
• GoldenEye uses Rare-specific Nintendo 64 technology, including a modified libultra implementation and custom RSP graphics commands.
• Native PC and recompilation work is already happening.
• GoldenRecomp currently runs stably with good sound but is still a work in progress.
• GoldenRecomp still needs multiplayer UI and modern dual-analogue controls.
• Dam and Frigate contain rendering that needs special handling because GoldenEye uses custom graphics commands not currently supported directly by RT64.
• Some weapons currently fire too quickly at native 60 FPS, demonstrating that higher frame rates require timing fixes rather than simply removing a cap.
• MGB64 demonstrated a portable native source-port approach but was discontinued and archived on 18 August 2026.
• Decompilation, recompilation, source ports and emulation are different techniques and can all contribute to preserving GoldenEye.
• The game's AI relied heavily on scripting and carefully designed reactions rather than one magically intelligent universal system.
• GoldenEye's changing mission objectives were a major part of its single-player design, with harder difficulties adding objectives rather than merely increasing enemy strength.
• The famous multiplayer arrived extremely late in development, with Steve Ellis implementing its core in roughly a month before further optimisation and testing.
• Rare knowingly accepted substantial frame-rate drops in exchange for richer scenes, enemies and effects on limited N64 hardware.
• The game sold more than eight million copies and became the third-best-selling Nintendo 64 game.
• GoldenEye entered the World Video Game Hall of Fame in 2025.
• The official 2023 Xbox and Switch releases remain valuable, but they provide modern access rather than source-level freedom to study and alter the game.
• The biggest story begins now. Reaching 100% gives programmers a much stronger foundation for whatever GoldenEye's next thirty years look like.

The Short Version

GoldenEye has not suddenly become open-source freeware, and a finished native PC edition did not appear the moment the decompilation tracker reached 100%. What has changed is more fundamental: programmers now have a completed source-level reconstruction of the game's tracked code rather than being forced to work principally against an opaque Nintendo 64 binary.

That makes accurate bug fixes, modern platform work, deeper modifications and long-term preservation substantially easier. GoldenRecomp is already showing both the possibilities and the remaining challenges, from stable PC execution to custom rendering and frame-rate-dependent weapon behaviour. The decompilation therefore represents the end of one enormous reverse-engineering project and the beginning of a much broader period of GoldenEye development.

Back To Menu

Research Sources & Further Reading

Research for this article prioritised the GoldenEye decompilation and recompilation repositories, current project documentation, first-hand developer retrospectives, official Rare, Xbox and Nintendo material and institutional game-history sources. Particular care has been taken to distinguish decompilation from source-code recovery, source ports from static recompilation and community projects from the official commercial releases.

• GoldenEye 007 Decompilation Project – GitHub Mirror
  Primary project repository containing the reconstructed game source, build system, regional ROM targets and documentation explaining the requirement for user-supplied game assets.
• GoldenEye 007 Decompilation Status
  Public project tracker recording the progress of the GoldenEye reverse-engineering effort.
• GoldenRecomp
  Active GoldenEye recompilation project documenting its current playable state, TLB changes, N64Recomp modifications, rendering issues, frame-rate problems and remaining control work.
• MGB64 – Man With The Golden Build
  Archived native source-port project demonstrating a portable C approach for Windows, Linux and macOS. The repository was archived on 18 August 2026 and is no longer maintained.
• Tom's Hardware – GoldenEye 007 Reaches 100% Decompilation
  Contemporary August 2026 reporting on the completion milestone and implications for future modifications and ports.
• ComputerBase – GoldenEye 007 Fully Decompiled
  August 2026 reporting confirming the 100.0% status and completion of all 208 tracked files.
• Game Developer – The Making Of GoldenEye 007
  Martin Hollis' GoldenEye postmortem covering the game's Virtua Cop origins, development process and evolution into a free-roaming console shooter.
• Game Developer – Developing GoldenEye 007 When The Technology Didn't Exist
  Developer recollections about creating GoldenEye before the Nintendo 64 hardware and its practical limitations were fully established.
• Game Developer – The AI Of GoldenEye 007
  Detailed examination of GoldenEye's guard scripting, sensory systems, navigation and bespoke mission behaviours based on discussion with David Doak.
• Game Developer – How GoldenEye's Multiplayer Was Added At The Last Minute
  Coverage of Martin Hollis' GDC postmortem and the extremely late development of the four-player multiplayer system.
• Game Developer – Martin Hollis Interview
  Long-form interview discussing GoldenEye's Virtua Cop influence, the unfinished Nintendo 64 hardware and the influence of Super Mario 64's objective structure.
• GoldenEye Depot – GoldenEye Regional Versions
  Detailed comparison of NTSC-U, Japanese and PAL GoldenEye, including compile information, PAL differences and the 7 November 1997 PAL release.
• Rare – GoldenEye 007 Returns
  Official information on the modern Xbox version, including dual-analogue controls, 16:9 output, resolutions up to 4K, consistent refresh rate and local split-screen multiplayer.
• Xbox Wire – GoldenEye 007 On Xbox Game Pass
  Official launch information covering objective-based campaign design and the modern Xbox features.
• Nintendo – GoldenEye 007 On Nintendo Switch Online
  Official information on GoldenEye's return through the Nintendo 64 library on Nintendo Switch.
• The Strong National Museum Of Play – GoldenEye 007
  Historical overview covering GoldenEye's sales, console-FPS influence, multiplayer legacy and 2025 World Video Game Hall of Fame induction.
• Wikimedia Commons – GoldenEye Logo
  GoldenEye logo classified as a public-domain text/logo for copyright purposes, with separate trademark considerations.
• Wikimedia Commons – Nintendo 64 & Controller
  Public-domain Nintendo 64 hardware photograph by Evan-Amos.

Back To Menu

Back To Menu