-
Notifications
You must be signed in to change notification settings - Fork 150
Important
This project's goal is to reconstruct byte-matching C source for the US 1.02 GameCube version of Super Smash Bros. Melee. It is a research and archival project. It is not a PC-port, netplay addition, modding toolkit, or Slippi-replacement project, and completing it would not automatically create any of those things.
These questions come up often, and they are welcome. This page attempts to explain some commonly-asked questions and assumes no programming or reverse-engineering experience.
A decompilation aims at turning a compiled program back into readable source code as closely as possible.
HAL originally wrote source code and used a compiler to turn it into PowerPC machine code, which is the low-level instructions understood directly by the GameCube's CPU. The retail disc contains those instructions, but none of the original source. This project works in the other direction: contributors write C, compile it with the same kind of compiler HAL used, and compare the result with the machine code shipped in the original game.
The goal is to create a C project that rebuilds the US 1.02 version of Melee as accurately as possible, down to matching the original program's code and data. People work on it for research, archival value, and the interest of understanding how the game was made.
The project is not organized around any particular follow-up product. It is not promising a PC port, static recompiler, modding platform, new online mode, or replacement for Slippi. Other people may use the research in future projects, but those projects would have their own goals, teams, and engineering work.
Not necessarily. It is newly reconstructed source that is designed to produce the same compiled game.
Compilation removes comments and most variable names, and it can erase clues about types, macros, file organization, and how an expression was originally written. Different pieces of C code can also compile to the same instructions. Some original details can be inferred from strings, data, behavior, and common coding patterns, but byte matching cannot prove that every line looks exactly as it did in HAL's files.
Exact matching gives the project an objective way to check its work. Code that looks equivalent to a person may behave differently in a rare situation, use a different data layout, or rely on a mistaken assumption. When the compiler produces the same instructions and data as the retail game, there is much less room for those hidden differences.
This standard also serves the project's research and archival goal. A later mod or port may intentionally change the program, but this project first tries to preserve a verified reference.
Creating a fully working port for other hardware requires a lot of different work than what we are focused on in this project. The matching work being done in this repository will not automatically make porting to other systems/platforms easy to do. A lot of extra effort will be required to make the output compatible with other platforms, and that work is not the goal of this project.
The normal build produces main.dol, which is a GameCube executable. Completed project files are compiled from the reconstructed C. For files that are not yet complete, the build uses the corresponding machine code extracted from the user's original US 1.02 executable. This lets the project build and verify the whole program while work continues file by file.
The result is still a GameCube program/game and still needs the other files from the user's own game disc. It can be used with GameCube-compatible hardware or software such as Dolphin, but it is not a native Windows, macOS, or Linux app.
What is the difference between emulation, static recompilation, cross-compilation, and a native port?
They are different ways of getting a game to run:
- Emulation runs the original GameCube program while software (like Dolphin) imitates the console hardware.
- Static recompilation translates the already-compiled GameCube instructions into another form so it can be ran on other platforms/architectures. It does not require recovered C, although it can help people understand and modify the result of the recompilation. It also needs supporting software for the console/hardware the game expects.
- Cross-compilation asks a compiler to turn source code into instructions for a different CPU or operating system. This only works correctly when the source and its supporting libraries are portable to that target.
- A native port deliberately adapts the game to a new platform. It replaces or rewrites platform-specific pieces and tests that the adapted game still behaves as intended.
A future project could combine these approaches. Finishing this decompilation would provide useful, verified source, but it would not choose an approach or actually perform the porting work.
Because having C source does not automatically make that source portable. Melee expects a PowerPC CPU and GameCube-specific graphics, audio, input, storage, memory, timing, and operating-system libraries/services. Its code and data also make assumptions about details like how multi-byte values are arranged in memory, number data-type sizes, and floating-point behavior.
A native port would need replacements for those console interfaces, conversions for affected data, and extensive testing. A modern compiler may also interpret old or platform-dependent C differently. Running the recovered source through a compiler targeting a desktop platform is the first step in that process, not the whole process.
They describe matching progress, not how ready the project is for a PC release, or anything related to porting:
- A fuzzy match is code that resembles the target & produces assembly that partially matches the original but is not yet an exact match.
- A full/perfect match is a function whose compiled instructions match, but whose containing project file is not ready to replace the original extracted file.
- A fully linked file has all of the necessary code and data matched and is built from the project's source as part of the final executable.
A file can contain many perfectly matched functions and still not be able to be fully linked because another function in the file, a data object, or the exact ordering of its contents remains unfinished.
It would mean that the US 1.02 program has met this project's code, data, and linking goals, so the target GameCube executable can be rebuilt from the project sources instead of relying on extracted original code for unfinished files.
It would not include the rest of the game disc's assets, any other regional or revision differences, a native port, netplay, new features, or a modding tool.
No. Matching answers “what instructions and data does this produce?” It does not always answer "what does this function do" or “why did the original developers write it?”
Exhaustive documentation of the fully matched C code is the natural extension of the project as functions are completed.
Some functions and fields still have address-based or placeholder names because their purpose is uncertain. Names, comments, types, and higher-level explanations can continue improving after the compiled bytes match.
We don't know. This is a volunteer project, and the remaining work isn't uniform in difficulty. Some code can be matched easily, while a single small code or data-layout difference can take a long time to resolve.
The percentage therefore should not be read as a linear schedule. Use the live progress dashboard to follow current status rather than relying on a prediction from the contributors/maintainers.
Yes, in principle. A separate porting project could begin with the source that is already available, write its own replacements for missing code, or connect reconstructed and translated code in stages. A 100% match is valuable because it provides a more complete and objectively checked reference, but it is not explicitly required.
Doing so would not change this repository's project's priorities. The matching project would continue pursuing its own research and archival goal.
Possibly, but “only versus mode” still depends on a large part of the game. A prototype would need shared fighter logic, physics, collision, animation, stage code, rendering, input, audio, memory management, and resource loading. It might skip many menus and single-player features, but it would not be a small or automatic conversion.
That scope decision belongs to a separate porting project. This project matches the whole target program rather than prioritizing features by what an early port would need.
No, not by itself. The point of a matching decompilation is to reproduce the original program, including its existing performance and timing.
A derivative project could optimize code or target newer hardware, but that requires additional design, engineering, and testing. Melee's gameplay, scripts, and animations are built around a 60-updates-per-second simulation. A later project might draw extra frames between those updates, while changing the simulation rate itself can change gameplay. Neither comes automatically from finishing the decompilation.
No. Completing the decompilation would not modify Slippi in any way or render it useless.
A replacement or alternative would need its own networking, a game simulation that stays exactly in sync between players, matchmaking or connection services, replays, testing, security, maintenance, and player base. A future port could coexist or interoperate with other tools, but that would depend on the people building those project, not this projects' decompilation percentage.
Possibly in a purpose-built project, but the decompilation alone does not provide crossplay. Every participant would need compatible networking code and a shared protocol—the rules and message format used to communicate. The different versions would also have to keep the game simulation in sync closely enough to avoid desynchronization.
That would be a substantial feature with its own hardware, performance, testing, and distribution constraints. It is not the goal of this project.
It can make some kinds of modding easier because readable C is usually simpler to understand, change, review, and maintain than hand-written assembly patches. The project can also reveal game structures and relationships that are useful to tool and mod authors.
It does not make every mod straightforward. Melee still has fixed data formats, memory and engine limits, platform-specific systems, and a large collection of disc assets. User-friendly editors, packaging, compatibility rules, and mod distribution would be separate work. This repository is not a modding SDK and does not attempt to provide tooling to make modding easier.
No. The repository contains the reconstruction work and build tooling, not a playable copy of Melee or its art, music, movies, stages, and other disc files. Building and running the GameCube executable requires files from the user's own legally-obtained US 1.02 copy of the game.
No. Publishing reconstructed source does not grant permission to use Nintendo or HAL's characters, trademarks, art, audio, or other protected material. Replacing names and artwork also does not by itself answer whether a derivative release is lawful.
This FAQ is not legal advice. Anyone planning to distribute a port, clone, mod, or collection of game data should obtain advice appropriate to that project and jurisdiction.
You can follow the repository's build instructions to build a GameCube executable using data from your own US 1.02 copy. The result runs as GameCube software; it is not a desktop installer or a double-clickable native PC version.
If your goal is to contribute, building the project is useful because it lets you compile changes and compare them with the retail game. It is not a separate way to obtain Melee.
The project already benefits from automated tools and AI-assisted workflows, but they produce candidates rather than verified answers. A tool can generate C that looks plausible yet has the wrong types, hides a misunderstood structure, or matches through awkward, unrealistic code that needs to be cleaned up before being put up for review.
Every result still needs to be compiled, compared with the target, checked in the context of its surrounding file, reviewed for reasonable source, and integrated without breaking other work. Automation helps contributors do that work faster; it does not remove the verification and judgment that make the result useful.
Start with the getting-started guide and the contribution guide. The wiki's Translation Units page shows project files that still need work.
If you match a function on decomp.me but are not comfortable/familiar with creating a pull request, the contribution guide explains how to submit the scratch in a GitHub issue so a maintainer can integrate it. Questions are also welcome in the #smash-bros-melee channel on the community Discord.
Yes, although most core matching work involves C and assembly. Useful supporting work can include improving beginner documentation, testing setup instructions, reporting reproducible documentation or tooling problems, and organizing verified project knowledge. After learning the documented workflow, helping newcomers find the right guide can also reduce repeated support work.
Ask maintainers before beginning a large non-code project. That confirms the work is wanted, avoids duplicating an existing effort, and identifies the right place and format for it.
- Follow current matching status on the progress dashboard.
- Browse code, changes, issues, and build instructions in the project repository.
- Read project working notes and file status on the GitHub wiki.
- If your question isn't answered here, or you want more details, you can find us in
#smash-bros-meleeon the community Discord.