A work-in-progress matching decompilation of Mario Strikers Charged for Nintendo Wii, developed by Next Level Games and published by Nintendo.

This repository does not contain game assets or assembly. You must provide your own legally obtained copy of the game.

Dates are the original regional Wii releases, sorted chronologically. Separate release dates for the EU disc revisions have not been verified; both EU rows show the regional launch date. The linked Nintendo release information and Nintendo Korea announcement provide the date sources.

R4QE01 remains the default. USA and both EU revisions link entirely from reconstructed source. Japan and Korea reuse verified source units; unresolved regional differences still use extracted objects. Each version has its own symbols, splits, progress report and retail DOL hash. The revision numbers above are the revision bytes recorded in the disc headers.

The former R4QP01 configuration is now named R4QP01_rev2. For an existing checkout, move the local files from orig/R4QP01 into orig/R4QP01_rev2 and configure again. Revision 1 needs its own disc image; the two EU revisions are not interchangeable.

Decompilation is the process of reverse-engineering compiled machine code back into human-readable source code. Unlike disassembly, which produces assembly language, decompilation aims to reconstruct high-level code (like C or C++) that closely matches what the original developers wrote. This process involves analyzing the binary executable, understanding its structure and behavior, and translating it back into source code that compiles to produce identical machine code. In this project, the goal is not just a close match, but a 100% match—the decompiled source code must compile to produce byte-for-byte identical machine code to the original. This is why diffing (see the Diffing section below) is an essential piece of the process, as it allows us to verify that our decompiled code produces exactly the same binary output as the original game. Decompilation projects like this one enable deeper understanding of game mechanics, facilitate modding and preservation, and serve as valuable learning resources for understanding how games were built.

Track the project decompilation progress and explore the interactive graph on decomp.dev.

• Python 3
• Ninja

The build downloads pinned versions of decomp-toolkit, the compiler, binutils, objdiff-cli, and wibo when needed.

Place a supported disc image in orig/<version>: orig/R4QE01 for USA, orig/R4QP01_rev1 for EU revision 1, orig/R4QP01_rev2 for EU revision 2, orig/R4QJ01 for Japan, or orig/R4QK01 for Korea. ISO, RVZ, WIA, WBFS, CISO, NFS, GCZ, and TGC images are supported. Use the disc revision listed above.

Then configure and build:

python3 configure.py
ninja

To select another version:

python3 configure.py --version R4QP01_rev1
ninja

python3 configure.py --version R4QP01_rev2
ninja

python3 configure.py --version R4QJ01
ninja

python3 configure.py --version R4QK01
ninja

Running python3 configure.py without --version selects USA again. Build outputs are kept separately in build/<version>; build.ninja and objdiff.json describe the currently selected version.

On the first build, decomp-toolkit extracts sys/main.dol from the disc image and performs the initial analysis. Once extraction succeeds, the disc image can be removed from orig/<version> to save space.

For USA, Europe and Japan, Ninja also generates the disc-message image include from that version's main.dol. The generated DiscMessageImages.inc stays in the build directory and is ignored by Git, including when using --build-dir. Korea has a different disc-message implementation, which currently uses extracted objects.

The reconstructed config/<version>/symbols.txt and config/<version>/splits.txt are checked into the repository. Disc images, extracted game files, split objects and build outputs must remain untracked. A successful USA build ends with:

build/R4QE01/main.dol: OK

Each version checks its own build/<version>/main.dol in the same way. The build prints code matching and source-linking percentages and writes build/<version>/report.json. A verified DOL can still contain extracted objects; the linking percentage counts only code linked from source.

To generate a linker map for the reconstructed ELF, configure with --map:

python3 configure.py --map
ninja

The result is written to build/<version>/main.elf.MAP. It describes the reconstructed link rather than an original development map and is intentionally ignored by Git.

After configuration, open the project directory in objdiff. It reads the generated objdiff.json automatically and rebuilds changed objects with Ninja.

Some retained template definitions are provided by another compiled source object. objdiff_weak_providers lists those sources for a unit. Ninja creates its comparison object in build/<version>/compare/, preserving the local object's definitions and adding missing weak definitions from the providers. The ordinary compiled objects remain the linker inputs. This accounts for shared method matches; source-linking a TU still requires matching its layout.

Contributions are welcome. Read CONTRIBUTING.md before starting work so that changes follow the repository's matching, style, and asset-handling rules.

smstrikers-decomp is the sibling decompilation project for Super Mario Strikers, the Nintendo GameCube predecessor first released in November 2005.

This project is based on encounter/dtk-template and uses decomp-toolkit. Thanks to the GameCube/Wii decompilation community for the tools and documentation that make projects like this possible.

The repository's original source contributions are dedicated to the public domain under CC0 1.0. Third-party source retains its own terms; see LICENSES. Game assets and other copyrighted material are not covered and must not be committed.