Petari: matching Super Mario Galaxy from source, object by object

What a decompilation project actually is

Petari is described as a work in progress decompilation of Super Mario Galaxy, and the first line of the description is the crucial constraint. The repository does not contain any game assets or assembly whatsoever, and an existing copy of the game is required. The method is the standard one for a decompilation: the original game's compiled objects are the specification, and the project writes C++ source that compiles to the same bytes. The verification is objdiff, a tool that compares the two and shows where they differ, so a build is correct not when it runs but when it is identical. The progress badges in the README show the per-region completion percentage pulled from decomp.dev, and there are four of them, RMGJ01, RMGE01, RMGP01 and RMGK01, which are the game's region codes. So the state of the project is legible at a glance, which is unusual and useful.

What the project is not, and the boundary it draws around PC ports

The README is explicit that this project is not meant to be an effort to create a PC port, and it points people to the Discord server to learn about and ask about a separate work in progress PC port called AstroCore. That distinction matters because the two projects are easy to conflate and they have very different shapes. A decompilation reproduces the original, including its original platform assumptions, and its success criterion is a byte match. A PC port is a new program that runs the game somewhere else, and its success criterion is that it runs. Petari chose the first, which means its output is a faithful reconstruction rather than a playable build, and the project routes people who want the latter elsewhere. The licence is CC0-1.0, a public domain dedication, which is the standard choice for decompilation work where the contributors want the reconstructed source to be usable by anyone without restriction.

The AI policy, which is unusually explicit for a project of this kind

The Regarding AI Usage section addresses a real community concern head on. The README says a lot of discussion and accusations have been made claiming AI and LLMs were used to accelerate the decompilation, and states plainly that they were not. AI was allowed for tasks that did not directly affect progress, such as variable naming, code cleanup and documentation, but it never ended up playing a role, and the fast progress was attributed to new collaborators, motivation and community effort. The guidelines below are then stated as rules. AI may be used for code cleanup, formatting, documentation and naming assistance. AI-generated decompilation work is not allowed, and pull requests containing obvious AI-generated decompilation output or other AI slop will be rejected. Contributors should be able to explain and justify any decompilation work they submit, and this also applies to all tool-generated code. The invitation to read the source and form your own conclusions is a reasonable stance for a project whose output is meant to be auditable.

The build: Ninja, Python, and an extracted region from your own game

The building section is four steps. You clone the repository with git. You use Dolphin Emulator to extract your desired region of the game into orig/RMGX01/, where X is the region code, and the README says that to save space the only necessary file is sys/main.dol and any others can be deleted. You configure with python configure.py, and to use a version other than RMGK01, the Korea release, you specify it with a --version flag. And you build with ninja. The dependency list per platform is short. On Windows, native tooling is highly recommended and WSL or msys2 are not required, but under WSL objdiff cannot get filesystem notifications for automatic rebuilds, so you need Python added to your PATH, and ninja, which installs quickly with pip install ninja. On macOS, brew install ninja. On Linux, install ninja. And wibo, a minimal 32-bit Windows binary wrapper, is downloaded and used automatically.

git clone https://github.com/SMGCommunity/Petari.git

python configure.py

ninja

The diffing loop, which is how the work is actually done

The Diffing section explains the workflow that gives a decompilation project its pace. Once the initial build succeeds, an objdiff.json should exist in the project root. You download the latest release of objdiff from the encounter repository, set the project directory under project settings, and the configuration loads automatically. You select an object from the left sidebar to begin diffing, and changes to the project rebuild automatically, with the README listing what triggers a rebuild as changes to source files, headers, configure.py, splits.txt or symbols.txt. That last detail is the interesting one, because splits.txt and symbols.txt are the project's own bookkeeping, and the fact that editing them triggers a rebuild tells you the project treats the function layout of the original as a first class thing to manage rather than an emergent property of the source.

The repository layout and the upstream code it borrows from

The top level of the repository shows the structure of a decompilation project. There is src/ for the reconstructed source, include/ for headers, orig/ for the extracted original, libs/ for the library code, tools/ for the build tooling, config/ for the build configuration, and a configure.py at the root that drives the setup. There is a .clang-format file and a format_include.py script, so the formatting of the reconstructed code is enforced rather than left to whoever is writing it, along with a .flake8 for the Python tooling and a Doxyfile for the documentation. The Credits section names the upstream projects the code was sourced from, with big thanks to the doldecomp team for their efforts on bte, to tp for JSystem, and to ogws, where the repository sourced code and headers from. The community runs on Discord, and there is a build status badge pointing at a GitHub Actions workflow named build.yml.

Upkeep and what a reader should take from it

The last push to the repository was on 2026-10-14, the repository is not archived, the primary language is C++, and there are no GitHub releases, since the output is a source tree rather than a distributed artefact. The decomp.dev progress page is the live status of the four regions. What the project is worth to someone outside the community is a reference implementation of a shipped game in readable C++, and the reading is the point rather than the building, since the build needs a copy of the game you are meant to have bought. The most transferable thing in the README is the AI policy, which is a workable answer to a question more open source projects will have to answer, and the object-diff workflow, which is a clean example of a build system whose success criterion is identity rather than behaviour.

Editorial conclusion

Petari suits a reverse engineer or a learner who wants to study how a shipped game is built, and who is prepared to supply their own copy of the game and to read generated assembly. It is the wrong choice if you want to play the game on a modern PC, because the project states plainly that it is not a PC port effort, and a poor fit for a team that wants a working build without a matching original to diff against. Before you start, read the AI usage section, because the project has an explicit policy on generated decompilation output and on contributors being able to justify what they submit, and note that the build needs Ninja, a Python 3.11 install and a region extracted from your own copy of the game.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. README
4. SMGCommunity/Petari on GitHub