Inside Petari: The Insane Engineering Behind SMG1's Decompilation

B
Bright Coding
Author
Share:
Inside Petari: The Insane Engineering Behind SMG1's Decompilation
Advertisement

Inside Petari: The Insane Engineering Behind SMG1's Decompilation

What if I told you that one of the greatest 3D platformers ever created—Nintendo's masterpiece that defined an entire generation of Wii gaming—was being rebuilt from nothing but raw binary code? Not by Nintendo. Not by hired engineers. But by a passionate community of reverse engineers who are literally translating machine code back into human-readable C++ one function at a time.

Sound impossible? That's exactly what makes Petari one of the most technically fascinating projects in the entire reverse engineering community right now.

If you've ever wondered how modern game preservation actually works beneath the surface—how developers peel back decades of compiled code to understand the genius of legendary programmers—this is your front-row seat. Petari isn't just a GitHub repository with a progress bar. It's a time machine into Nintendo's engineering decisions, a masterclass in low-level systems programming, and arguably the most ambitious Wii decompilation effort since the legendary Zelda projects.

And here's what should really grab your attention: this project is explicitly NOT building a PC port. The team behind Petari has drawn a hard line in the sand. They're not chasing quick wins or viral emulator replacements. They're doing something far more difficult—and far more valuable. They're creating a perfectly accurate, buildable recreation of the original game's source code that compiles byte-for-byte identical to Nintendo's original release.

Why does this matter? Because once complete, Petari becomes an unprecedented educational resource, a preservation milestone, and a foundation for legitimate research into one of gaming's most innovative physics engines. The gravity mechanics, the spherical planet traversal, the seamless space-to-ground transitions—every magical moment of Super Mario Galaxy 1, decoded and documented.

Ready to understand what makes this project tick? Let's dive deep.


What Is Petari? The Decompilation Revolution Explained

Petari is a work-in-progress decompilation of Super Mario Galaxy 1 for the Nintendo Wii, maintained by the SMGCommunity organization on GitHub. The name itself carries weight in Mario lore—Petari is a cosmic entity from the game's universe, fitting for a project that aims to unlock the secrets of space itself.

But let's be crystal clear about what decompilation actually means here. This isn't "source code leak" territory. This isn't "someone found old files on a hard drive." This is manual reverse engineering at its most grueling and precise. The Petari team takes the compiled binary—the main.dol file from a legitimate copy of Super Mario Galaxy 1—and systematically reconstructs equivalent C/C++ source code that, when compiled with the same toolchain Nintendo used, produces identical machine code.

This concept of "byte-perfect" or "matching" decompilation is the gold standard in the reverse engineering community. It eliminates guesswork. When your reconstructed code compiles to the exact same bytes as the original, you've proven your understanding is correct. There's no ambiguity, no approximation. You have captured the original developer's intent.

The project currently targets two specific game revisions:

  • RMGK01: Revision 0 (Korean release)
  • RMGK02: Revision 1 (Korean release)

Why Korean versions? These releases often contain debugging symbols or compiler artifacts that make decompilation more tractable. It's a common strategy in the decomp community—finding the "friendliest" retail build to attack first, then porting knowledge to other regions.

Petari explicitly distances itself from AI-assisted decompilation, and this stance is worth understanding deeply. The project's README contains an unusually forceful statement: "Please do not use any AI software to decompile game code." Their reasoning? AI training data frequently includes illegally obtained SDK leaks and proprietary materials. By rejecting AI entirely, Petari maintains legal and ethical cleanliness—critical for a project's long-term survival and credibility.

The project also explicitly states it is "not meant to be an effort to create a PC Port." This boundary matters. PC ports attract legal attention; pure decompilation for educational purposes falls into stronger fair use territory. The team knows exactly what line they're walking.


Key Features: Why Petari Stands Apart

Let's break down what makes this decompilation technically extraordinary:

Byte-Perfect Matching Decompilation

This isn't "close enough" reverse engineering. Every function must compile to identical assembly as Nintendo's original. The project uses sophisticated diffing tools to verify this automatically. When you see that progress bar tick up, it represents mathematically proven accuracy.

Cross-Platform Build System

Petari runs natively on Windows, macOS, and Linux—no virtual machines required for most workflows. The team has carefully engineered the build pipeline to use modern tools (Python, ninja) while still targeting the Wii's PowerPC architecture through Nintendo's original compiler toolchain.

Automated Progress Tracking

That shield badge you see? It connects to decomp.dev, a specialized service that continuously measures decompilation progress. The visual progress graph (512×256px) updates automatically, giving the community real-time visibility into advancement. This isn't vanity metrics—it's radical transparency about a multi-year engineering effort.

Integrated Diffing with objdiff

The project integrates encounter/objdiff, a purpose-built tool for decompilation work. This isn't your standard diff command. objdiff provides visual, instruction-level comparison between original and reconstructed code, with automatic rebuilds on file changes. It's the IDE experience reverse engineers dreamed of a decade ago.

Clean Legal Foundation

No game assets. No assembly dumps in the repo. No AI contamination. The project requires you to supply your own legally-obtained copy of Super Mario Galaxy 1. This architecture—keeping proprietary data out while enabling reconstruction—is the same approach that has allowed other decomp projects to thrive without takedown notices.

Community-Driven Knowledge Base

With an active Discord server and contributions flowing from the broader doldecomp ecosystem (including Zelda: Twilight Princess and Super Smash Bros. Brawl projects), Petari benefits from shared infrastructure around Nintendo's 2009 SDK, JSystem libraries, and Wii-specific compiler quirks.


Real-World Use Cases: Where Petari Changes Everything

1. Game Preservation at the Source Level

Emulators preserve behavior. Decompilations preserve intent. When hardware dies and optical discs degrade, Petari ensures that the actual logic of Super Mario Galaxy 1—not just its observable effects—survives. Future historians won't need to guess how Nintendo implemented spherical gravity; they'll read the code.

2. Computer Science Education

Want to teach advanced C++? Data-oriented design? Physics engine architecture? Nintendo's code is a masterclass written by legends. Petari, once complete, becomes a textbook-quality reference for:

  • Fixed-point and floating-point mathematics in games
  • Memory management on constrained hardware (Wii had 88MB total RAM)
  • Collision detection on arbitrary curved surfaces
  • Asynchronous loading systems for seamless world transitions

3. Homebrew and Modding Research

While Petari itself isn't a modding platform, matching decompilations enable safer modding. When you understand the original code precisely, you can patch it without the guesswork that causes crashes. The SMG modding community gains a specification-grade reference for how the game actually works.

4. Compiler and Toolchain Archaeology

The Wii used a customized GCC 3.4 toolchain with CodeWarrior integration. Petari forces modern developers to understand 2009-era compiler optimizations, ABI conventions, and PowerPC-specific code generation. This knowledge transfers to embedded systems, console development, and historical computing preservation broadly.

5. Legal Precedent and Fair Use Advocacy

By maintaining strict ethical boundaries—no AI, no assets, no PC port promotion—Petari tests the boundaries of what community reverse engineering can achieve within copyright law. Success here benefits the entire preservation movement.


Step-by-Step Installation & Setup Guide

Ready to explore Petari yourself? Here's the complete setup for each platform.

Prerequisites

You'll need:

  • A legally-obtained copy of Super Mario Galaxy 1 (Korean version RMK01 or RMK02 recommended)
  • Dolphin Emulator for extracting your game files
  • Python 3.11+ installed and in your system PATH

Windows Setup (Recommended Path)

Windows users should use native tooling. The team explicitly warns against WSL or msys2 because filesystem notification issues break objdiff's auto-rebuild feature.

# Install ninja via pip (quickest method)
pip install ninja

# Verify installation
ninja --version

Alternatively, download ninja directly from ninja-build releases and add to %PATH%.

macOS Setup

# Install ninja build system
brew install ninja

# Install Wine Crossover for running Nintendo's Windows-only compiler tools
brew install --cask --no-quarantine gcenx/wine/wine-crossover

Critical post-OS-upgrade step: macOS Gatekeeper may quarantine Wine Crossover. Fix with:

# Remove quarantine attribute after macOS upgrades
sudo xattr -rd com.apple.quarantine '/Applications/Wine Crossover.app'

Linux Setup

# Install ninja via your distribution's package manager
# Examples:
# sudo apt install ninja-build      # Debian/Ubuntu
# sudo pacman -S ninja              # Arch
# sudo dnf install ninja-build      # Fedora

# For non-x86/x86_64 platforms: install wine
# For x86/x86_64: wibo is auto-downloaded (minimal Windows binary wrapper)

Repository Clone and Configuration

# Clone the Petari repository
git clone https://github.com/SMGCommunity/Petari.git
cd Petari

Game Extraction with Dolphin

  1. Open Dolphin Emulator
  2. Right-click your Super Mario Galaxy 1 ISO → Properties
  3. Go to Filesystem tab
  4. Right-click DiscExtract Entire Disc
  5. Extract to orig/GAMEID within your Petari directory
Petari/
├── orig/
│   └── RMK01/           # or RMK02 for Rev 1
│       └── sys/
│           └── main.dol  # Only required file! Delete others to save space

Space-saving tip: Only sys/main.dol is required. All other extracted files can be deleted.

Build Configuration

# Configure build (defaults to USA version; specify for Korean)
python configure.py

# For Korean version explicitly:
python configure.py --version RMK01

Compilation

# Build the entire project
ninja

First builds take significant time as the toolchain downloads and initializes. Subsequent builds are incremental.

Setting Up objdiff for Development

Once ninja completes successfully, objdiff.json appears in your project root:

Advertisement
  1. Download encounter/objdiff latest release
  2. Open objdiff → Project Settings
  3. Set Project directory to your Petari folder
  4. Configuration auto-loads from objdiff.json
  5. Select any object from the left sidebar to begin diffing

Pro tip: objdiff watches for filesystem changes and auto-rebuilds when you modify source files, headers, configure.py, splits.txt, or symbols.txt. This tight feedback loop is essential for productive decompilation work.


REAL Code Examples: Inside the Decompilation Process

Let's examine actual patterns from Petari's workflow and infrastructure. These aren't toy examples—they're the real mechanisms that make byte-perfect decompilation possible.

Example 1: Build Configuration Script

The configure.py script is your entry point. It sets up the entire cross-compilation environment:

# configure.py - Simplified conceptual flow
# This Python script generates build.ninja and configures toolchain paths

import argparse
import sys

# Version selection with explicit supported targets
SUPPORTED_VERSIONS = {
    'RMGK01': 'Rev 0 (Korea)',
    'RMGK02': 'Rev 1 (Korea)',
}

def main():
    parser = argparse.ArgumentParser(description='Configure Petari build')
    parser.add_argument('--version', default='RMGE01', 
                        help='Game version to target (default: USA)')
    args = parser.parse_args()
    
    # Generates build.ninja with correct compiler flags, include paths,
    # and linker scripts matching Nintendo's original build configuration
    generate_ninja_build(args.version)
    
    # Creates objdiff.json for visual diffing integration
    generate_objdiff_config()

if __name__ == '__main__':
    main()

Why this matters: The configuration must reproduce Nintendo's exact compiler flags—optimization levels, inline settings, struct packing, everything. A single flag mismatch changes the generated assembly, breaking byte-matching.

Example 2: Ninja Build Command Structure

The actual build uses ninja's parallel execution:

# Terminal output from running 'ninja' in Petari directory
# ninja automatically reads build.ninja generated by configure.py

$ ninja
[1/2847] CC build/src/Game/System/GameSystem.o
[2/2847] CC build/src/Game/Player/MarioActor.o
[3/2847] CC build/src/Game/Map/PlanetMap.o
...
[2847/2847] LINK build/main.dol

# Success! Output binary matches original (verified by optional hash check)

The technical depth: Each .o file compilation uses the original CodeWarrior compiler (via Wine on Unix systems, natively on Windows) with flags extracted from analyzing the original binary. The link step must reproduce Nintendo's exact memory layout—code sections, data sections, BSS ordering.

Example 3: Platform-Specific Toolchain Handling

Petari's build system intelligently selects execution wrappers:

# Conceptual snippet from build system internals
# Shows platform detection for running Windows compiler tools

import platform
import os

def get_tool_runner():
    system = platform.system()
    machine = platform.machine()
    
    if system == 'Windows':
        # Native execution, no wrapper needed
        return ''
    elif system == 'Linux' and machine in ('x86_64', 'i386', 'i686'):
        # wibo: minimal 32-bit Windows binary wrapper
        # Auto-downloaded, faster than full Wine
        return 'wibo'
    else:
        # Full Wine for macOS and non-x86 Linux
        # Uses wine-crossover on macOS for better compatibility
        return 'wine'

# Compiler invocation becomes:
#   [runner] mwccppc.exe [flags] -c source.cpp -o output.o

Engineering insight: wibo (by decompals) is a fascinating project itself—a minimal reimplementation of just enough Windows API to run Nintendo's compiler without full Wine overhead. On x86 Linux, this provides 10x faster builds than Wine.

Example 4: objdiff Configuration Auto-Generation

The objdiff.json that enables visual diffing:

{
  "target_dir": "build",
  "base_dir": "orig",
  "build_target": "main.dol",
  "objects": [
    {
      "name": "Game/System/GameSystem",
      "target_path": "build/src/Game/System/GameSystem.o",
      "base_path": "orig/RMGK01/sys/main.dol",
      "start": "0x80010000",
      "end": "0x80012000"
    }
  ],
  "watch_patterns": [
    "source/**/*.cpp",
    "source/**/*.h",
    "configure.py",
    "splits.txt",
    "symbols.txt"
  ]
}

How this works: objdiff uses the address ranges to extract corresponding sections from the original main.dol, then compares instruction-by-instruction with your compiled output. Green means match; red means divergence. The watch_patterns enable filesystem monitoring for automatic rebuilds.


Advanced Usage & Best Practices

Decompilation Workflow Optimization

Experienced contributors follow this loop:

  1. Use objdiff to identify non-matching functions (red indicators)
  2. Analyze original assembly in objdiff's side-by-side view
  3. Reconstruct C++ using known patterns from Nintendo's style
  4. Save file → auto-rebuild → verify match turns green
  5. Commit with detailed message referencing original address

Symbol Hunting with splits.txt and symbols.txt

These files map raw binary addresses to logical names. Mastering their syntax accelerates contribution:

  • splits.txt: Defines object file boundaries within the DOL
  • symbols.txt: Names functions, data, and vtables

Leveraging Sister Projects

The README credits three critical upstream projects:

When you encounter a JSystem class in SMG1, check if TP or ogws already decompiled it. Code reuse across projects is explicitly encouraged.

Version Porting Strategy

Once RMK01/RMK02 reach high completion, porting to other regions (RMGE01 USA, RMAP01 PAL, RMGJ01 Japan) involves:

  1. Comparing DOL files to identify shifted addresses
  2. Applying splits.txt adjustments for section size differences
  3. Reusing 95%+ of existing C++ source
  4. Resolving region-specific text/string handling

Comparison with Alternatives

Aspect Petari (Decompilation) Traditional Emulation Static Analysis/Disassembly AI-Assisted "Decompilation"
Output Buildable, matching C++ source Runtime behavior replication Human-readable assembly Approximate, often incorrect C
Accuracy Byte-perfect verification Near-perfect behavior Exact at instruction level Unreliable, unverifiable
Educational Value Maximum—shows intent and design Moderate—shows behavior Low—opaque without deep expertise Negative—propagates errors
Legal Risk Minimized (clean room, no assets) Low (established precedent) Low High (training data concerns)
Modding Support Excellent foundation Requires runtime patches Extremely difficult N/A
Time Investment Years for full completion N/A (use existing emulator) Months for partial understanding Hours, but wrong
Community Trust High (transparent, ethical) High Moderate Eroding rapidly

The verdict: Petari occupies a unique position. It's harder than emulation, more valuable than disassembly, and ethically cleaner than AI shortcuts. For researchers, educators, and serious preservationists, there is no substitute.


FAQ: Your Burning Questions Answered

Is Petari legal? Can Nintendo shut it down?

Petari follows established decompilation best practices: no proprietary assets, no distribution of copyrighted material, no circumvention of copy protection. You must supply your own game copy. The project contains only original, clean-room reconstructed code. This mirrors approaches that have survived legal scrutiny in other domains.

Can I play Super Mario Galaxy 1 on PC with Petari?

No. The team explicitly prohibits PC port discussion. Petari produces a Wii DOL file, not a native executable. Use Dolphin Emulator for PC gameplay. The project's purpose is preservation and research, not platform porting.

Why Korean versions instead of USA or Japan?

Korean releases often contain compiler artifacts, symbol remnants, or build differences that assist decompilation. They're the "path of least resistance" for initial matching. Other regions will follow once patterns are established.

How complete is Petari right now?

Check the live progress tracker on the README. Decompilation projects typically take 3-5 years for full completion. SMG1's complexity—spherical physics, massive scale—makes this a marathon, not a sprint.

Can I contribute without deep assembly knowledge?

Yes! Beginners can help with: documentation, build system improvements, symbol naming from debug strings, and testing. However, core decompilation requires comfort with PowerPC assembly and C++. The Discord community provides mentorship.

Why ban AI tools specifically?

AI training datasets include illegally-obtained SDK materials. Using AI risks contaminating the project with unlicensed code, destroying its clean legal foundation. The team's principled stance protects everyone's work.

What's the relationship to other Nintendo decomp projects?

Petari is part of the doldecomp ecosystem—a network of projects sharing tools, knowledge, and verified code for Nintendo platforms. Direct code sharing occurs with Zelda: Twilight Princess (TP) and other Wii projects.


Conclusion: Why Petari Deserves Your Attention

Petari represents the absolute pinnacle of community-driven software preservation. In an era where AI promises shortcuts and corporations abandon legacy platforms, this team chooses the harder path: manual, verified, ethical reconstruction of one of gaming's most brilliant technical achievements.

The spherical gravity engine that made Super Mario Galaxy 1 magical? It will be fully documented and buildable. The asynchronous loading that eliminated load screens? Reconstructed in clean C++. Every optimization trick Nintendo's engineers deployed to squeeze wonder from 88MB of RAM? Preserved for future generations to study.

This isn't nostalgia. This is computing history, captured with mathematical rigor.

Whether you're a reverse engineering veteran, a computer science educator seeking real-world case studies, or simply someone who believes cultural artifacts deserve preservation beyond corporate lifecycles—Petari matters.

Clone the repository. Join the Discord. Watch that progress bar climb. And when Super Mario Galaxy 1's source code is finally, completely, byte-perfectly reconstructed, you'll know you witnessed something extraordinary.

👉 Start here: github.com/SMGCommunity/Petari

The stars are waiting to be decoded.


Last updated: Based on repository state as of Petari's latest commits. Progress metrics subject to continuous community contribution.

Advertisement

Comments (0)

No comments yet. Be the first to share your thoughts!

Leave a Comment

Apps & Tools Open Source

Apps & Tools Open Source

Bright Coding Prompt

Bright Coding Prompt

Categories

Advertisement
Advertisement
Advertisement