zeldaret/tww

If you own a supported GameCube disc image and want to rebuild The Wind Waker from matching C++ source, this project is aiming for exactly that. It is a work in progress, not a finished, drop-in source release, so treat it as a contribution project rather than a convenient game port.

The problem

You want to study or modify Wind Waker at the source level, but the game ships only as PowerPC code inside a GameCube image. ROM hacking tools let you patch bytes, yet they do not give you named functions, structured files or a source tree you can compile back into the original binary. Decompilation changes the workflow: instead of guessing at an address in a hex editor, you match a function in C++ and verify that the compiler produces the same machine code.

The repository does not include game assets or assembly, so an existing copy of the game remains part of the setup. The build uses that image to produce the matching binary; the disc image can be deleted after the initial build, according to the README project instructions.

What's different

The interesting mechanism is the matching workflow. After a first successful build, an objdiff.json is generated, and you open it with objdiff to compare the assembly generated from your C++ against the original object diffing instructions. That gives contributors a concrete target: a function is either matching or it is not, and changes trigger automatic rebuilds. Progress is tracked separately for the main executable and the relocatable modules, so it is possible to see how much of each area is covered progress site.

The shared Ghidra setup is the other practical piece. Contributors can request remote access and work against a prepared project, then make a local copy for their own edits; the project even suggests consulting the Twilight Princess decompilation because engine code is shared and its debug build is easier to read Ghidra setup. The trade-off is that this is not a one-command conversion: Ghidra output is explicitly described as not accurate enough to paste directly into the project, so the human part is understanding and rewriting functions. The project also states it will not accept pull requests that are primarily AI-generated or directly copy-pasted from a decompiler, which raises the bar for contributors who hoped to automate progress.

Who should try it

A good fit is someone with reverse-engineering curiosity and patience for matching compiler output, especially a developer who has a legal copy of one of the listed GameCube versions and wants to contribute to a long-running preservation effort. The project supports USA, PAL, Japanese, Korean and the Japanese kiosk demo image, so owners of several regional versions can choose their own build target version instructions.

A poor fit is a player looking for a playable PC port, a modder who wants a stable asset pipeline, or a beginner expecting a ready-made source tree to compile without comparing assembly. Contributors who mainly want to submit generated code are also a mismatch, since the contribution rules explicitly reject that style of change.

Requirements and limitations

The setup is platform-aware but not trivial. On Windows, the README recommends native tooling rather than WSL or msys2, because objdiff cannot get filesystem notifications for automatic rebuilds under WSL; you need Python and ninja on %PATH%. On macOS and Linux, ninja is the main package, and wibo is downloaded automatically to run the Windows-oriented toolchain platform setup. You also need a disc image for one of the supported versions and enough disk space to copy it into orig/ for the initial build.

Ongoing work is the real constraint. Matched code is only useful if it stays readable and builds cleanly, and the coding guidelines matter as much as matching output contribution guide. There is no evidence in the supplied material about how complete the decompilation is, so the progress badges are the place to check before assuming a particular part of the game is already covered.

HotRepo's take

HotRepo observed the project on the monthly C++ board on 2026-10-25 at #16 with +155 stars for that month monthly board. That is one dated observation and no comparable daily history, so persistence cannot yet be judged from these signals. Before investing time, check the current progress breakdown by executable and module, because the useful question is not whether the project exists but whether the area you care about already has matching, readable source.