# The Wind Waker decompilation rebuilds a GameCube game from your own disc > The zeldaret/tww project is a work in progress decompilation of The Legend of Zelda: The Wind Waker for GameCube, and it contains no game assets at all, so an existing copy of the game is required to build it. Progress is measured as a percentage against the original code with objdiff, and the project runs a shared Ghidra server so contributors can read the compiled functions without owning the hardware. **zeldaret/tww** — Decompilation of The Legend of Zelda: The Wind Waker - Repository: https://github.com/zeldaret/tww - Website: https://zeldaret.github.io/tww - Stars: 1,119 · Forks: 174 - Language: C++ - License: CC0-1.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/zeldaret-tww ## A decompilation measured against the original binary The Legend of Zelda: The Wind Waker project is a work-in-progress decompilation of the GameCube game, and the progress badges in the readme are the clearest statement of what it is. There are three of them, from the decomp.dev site. The first is overall code progress. The second is DOL progress, which is the main program, and the third is RELs progress, which is the modules. Each one is a percentage, so the project reports its own state in the one unit that matters for a decompilation, which is how much of the original code has been matched. The implementation language is C++, the licence is CC0-1.0, and the site is zeldaret.github.io/tww. The last push was on 2026-10-14, and there are no GitHub releases, since the output is a build rather than a download. The licence is worth a second look, because it is unusual for this kind of project. CC0-1.0 is a public domain dedication, which means the decompiled source that the contributors write is placed in the public domain rather than being copyleft. That is a deliberate choice for reverse engineering work, and it is what lets the result be used by anyone. ## No assets, and every GameCube revision supported The second line of the readme is the condition of the whole project, and it is stated in bold. This repository does not contain any game assets or assembly whatsoever, and an existing copy of the game is required. Everything the project ships is code, and everything the game contains is read from the disc you supply. That is the arrangement that makes a decompilation project publishable, and it is why the readme is explicit about the supported versions. All GameCube versions are supported. GZLE01 is Rev 0 for the USA and Rev 48 for Korea, GZLP01 is Rev 0 for PAL, GZLJ01 is Rev 0 for Japan, and there is a kiosk demo, D44J01, from Japan. The kiosk demo is the interesting one, because kiosk builds are built from the same code as the retail game with a small amount of extra material, so it is a version of the binary that the project can diff against when a function is not behaving as expected. The repository also has an orig/ directory, which is where you put your disc image, and the readme notes that after the initial build the disc image can be deleted to save space. ## Building it: clone, copy the disc, configure, ninja The build is four steps, and the toolchain is the interesting part of it. First you clone the repository, and then you copy your game's disc image to orig/GZLE01. The supported formats are ISO in the GCM form, RVZ, WIA, WBFS, CISO, NFS, GCZ and TGC, and after the first build the image can be deleted. Then you configure, and the configuration step is a Python script. ```bash python configure.py ``` To use a version other than GZLE01 for the USA, you specify --version GZLJ01 for Japan or --version GZLP01 for PAL. And then you build with ninja. ```bash ninja ``` The build tool is Ninja on all three platforms, which is unusual and it is what makes the incremental rebuild fast enough to be usable while decompiling. On Windows the readme says it is highly recommended to use native tooling, because WSL or msys2 are not required and because under WSL objdiff is unable to get filesystem notifications for automatic rebuilds. The Windows prerequisites are Python and ninja on the PATH, and the macOS and Linux ones are ninja, installed with brew on macOS. There is one extra piece on macOS and Linux, wibo, a minimal 32-bit Windows binary wrapper that is downloaded and used automatically. ## Diffing is how the work is judged The Diffing section is the part that makes a decompilation project a decompilation project rather than a rewrite. Once the initial build succeeds, an objdiff.json file should exist in the project root. You download the latest release from the encounter/objdiff repository, set the project directory under project settings, and the configuration loads automatically. Selecting an object from the left sidebar begins the diffing, and changes to the project rebuild automatically, with the readme naming the triggers as changes to source files, headers, configure.py, splits.txt or symbols.txt. So the workflow is a loop. You change the C++, you rebuild, objdiff compares your object against the original one, and the number that goes down is the number that goes up on the progress badge. That is a much stronger form of correctness than a test suite, because the reference is the thing the original console shipped. A function that matches byte for byte cannot be subtly wrong in a way a reviewer would miss, and a function that does not match has a diff that says exactly where it diverges. The two files in the rebuild triggers, splits.txt and symbols.txt, are the decompilation bookkeeping, and they are named in the same list as the source files, which tells you that reorganising the symbol or split layout is as much a part of the work as writing the code. ## The shared Ghidra server, and why you copy the file locally Setting up Ghidra is a long section, and the readme is unusually open about the limits of the tool and the sharp edges of the setup. Ghidra is a tool that automatically decompiles code, and although its output is not accurate enough to be directly copy-pasted into this decompilation project, it can still be helpful for understanding functions and decompiling them faster. The project runs a shared Ghidra server for Wind Waker, and you get access by linking your Discord account, creating a Ghidra account, and requesting Read access to the WindWaker server, after which an admin approves it. The local setup needs a JDK, with OpenJDK 17 linked from Adoptium, and the RootCubed Ghidra build, launched with ghidraRun. You then create a new project with the server name ghidra.decomp.dev and the port 13100, open the main file, and make a local copy of it by right clicking, copying and pasting. The reasons for the local copy are given and they are both practical. You do not have write access to change main itself, so the copy is where your decompiled changes live, and separately there is a Ghidra bug that makes the remote version of main extremely slow to use if you only have read access. There is also a tip about the Twilight Princess server, and the reason is the interesting part. A significant amount of engine code is shared between the two games, and the debug version of Twilight Princess is easier to work with because inline functions are not inlined in that version. ## Machine-generated contributions are rejected The Contributing section ends with a policy that is unusual and worth reading carefully. Anyone can open a pull request, but the project does not accept contributions that are primarily AI-generated or directly copy-pasted from Ghidra, and a pull request will be closed if it contains obvious signs of machine-generated code. The rest of the paragraph explains the reasoning. It is your responsibility to check the code that you are submitting and make sure it is readable and feels like something a human programmer would write, and the coding guidelines page is linked. That policy is worth understanding as a technical statement rather than a rule about tooling. A decompilation is only useful if the resulting C++ is something a person can read and change, because the whole point of the project is to produce a maintainable representation of the original code. A Ghidra dump that compiles and matches byte for byte is worth less than nothing, since nobody can work on it, and the diffing loop is not a substitute for the code being legible. The same logic explains why the project tells you to read the decompiling guide first, and why the shared Ghidra server is a reading tool rather than a source. ## The repository layout follows the decompilation workflow The top level listing shows the structure of a project with a build step that produces a binary from a mix of your own code and the original one. There is include/ and src/ for the decompiled C++, config/ for the build configuration, orig/ where the disc image goes, tools/ for the supporting scripts, and docs/ for the contribution guides, including the decompiling guide and the coding guidelines that the contributing section points at. Then there is configure.py, which is the step that reads your disc image and writes the build configuration, and the .clang-format file, which matters more here than in most projects, because the project compares your code byte for byte against the original and a formatting difference is a difference. The .clangd file is a configuration for the clangd language server, and .vscode/ holds the editor settings for the same reason, so that a contributor working in an editor sees the same parsing behaviour as the build. The build itself is driven by the Ninja files that configure.py generates, and the GitHub Actions workflow behind the build status badge is what runs the compile on every change, so a contributor finds out whether their change still matches the original without having to set up the local toolchain first. ## Conclusion Adopt this project if you want to study how a GameCube game was written, or you want to contribute to a decompilation effort where the result is checked against the original binary. Do not expect a finished game, since the readme calls it a work in progress, and do not expect to build it without your own copy of the game, because the repository contains no assets. Verify first that your disc image format is one of the supported ones, that you can supply the original copy, and that the contribution rules about machine-generated code are ones you can work within. ## FAQ ### What is the tww repository? It is a work in progress decompilation of The Legend of Zelda: The Wind Waker for GameCube, written in C++. The project measures its own progress as a percentage of the original code matched, in the main program and in the modules, and publishes those figures as badges. ### Do I need to own the game to build it? Yes. The repository does not contain any game assets or assembly whatsoever and an existing copy of the game is required. You copy the disc image into the orig directory, and after the first build you can delete it again. ### How do I build the Wind Waker decompilation? Clone the repository, copy your disc image to orig/GZLE01, run python configure.py, optionally with --version for a Japanese or PAL copy, and then run ninja. The build tool is Ninja on Windows, macOS and Linux. ### How does objdiff fit into the workflow? After the first build an objdiff.json file exists in the project root, and the objdiff tool compares your compiled objects against the original ones. Changes to source files, headers, configure.py, splits.txt or symbols.txt trigger an automatic rebuild. ### Can I use Ghidra output directly in the decompilation? No. The readme says Ghidra's output is not accurate enough to be directly copy-pasted into the project, although it helps with understanding functions faster. The project also rejects pull requests that are primarily AI-generated or copied from Ghidra. ### What licence does the Wind Waker decompilation use? CC0-1.0, a public domain dedication, which places the contributed decompiled source in the public domain rather than imposing copyleft on it. ## Sources - [Issues](https://github.com/zeldaret/tww/issues) - [License: CC0-1.0](https://github.com/zeldaret/tww/blob/main/LICENSE) - [Project website](https://zeldaret.github.io/tww) - [README](https://github.com/zeldaret/tww/blob/main/README.md) - [zeldaret/tww on GitHub](https://github.com/zeldaret/tww) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zeldaret-tww