zeldaret/botw: C++ source for one Switch build

Pinned to a single Switch build at v1.5.0

The repository reconstructs The Legend of Zelda: Breath of the Wild v1.5.0 as it runs on Nintendo Switch hardware, written in C++, and that single retail version is fixed in the project description rather than negotiated branch by branch. Topics filed against the project spell out the method: decompilation, reverse-engineering, nintendo-switch, clang and cpp. The README states the work is experimental and in progress, then gives three aims: understand game internals, aid glitch hunting, and write existing knowledge down in a permanent, unambiguous form that helps further reverse engineering. Those aims are what separate this from a port, because nothing here is arranged around shipping a playable copy. One boundary is stated without hedging too: the tree holds no game assets and no RomFS content, and cannot be used to play Breath of the Wild. Read that line first when sizing the repository, because it rules out the outcome most newcomers arrive expecting.

Two progress badges, one page, no printed figures

The README carries 2 badges that read like status and are not. One is labelled Decompilation Progress, the other Decompilation Progress (functions); both point at the same page, and each image is generated from a separate endpoint, so coverage by bytes and coverage by functions are 2 different numbers. The link definitions behind them are these:

https://botw.link/progress
https://img.shields.io/endpoint?url=https://botw.link/badges/progress.json
https://img.shields.io/endpoint?url=https://botw.link/badges/fn_progress.json

Open the page and you see two moving figures. Clone the repository and both badges render empty, because no completion value is stored in the tree. Measuring completeness happens entirely elsewhere, and that is a genuine limitation for anyone judging this project from its contents: the source shows what has already been recovered, never how much of the game is still missing, and nothing in the checkout can substitute for the number.

Seventeen root entries, three of them instructions

Based on the repository layout, the root holds seventeen entries, and only their names are visible here. `src/` sits beside `lib/`, `toolchain/`, `tools/`, `data/` and `docs/`, with `CMakeLists.txt` at the top level, while `.clang-format`, `.clang-tidy`, `.gitattributes` and `.gitignore` shape what can be contributed and how it is checked. The 3 instruction files deserve a closer look: `Contributing.md` is the human entry point, while `AGENTS.md` and `CLAUDE.md` are named after specific coding agents, which tells you the project expects machine-written patches to be reviewed against house rules. A repository that invites help from a model while pinning clang formatting is making a deliberate choice about who sets style. `.gitattributes` sits with those dotfiles to pin how Git treats line endings and binary blobs, which matters in a tree that mixes reconstructed code with the files under `data/`. No licence file appears among the seventeen entries, and the repository records no licence identifier, so nothing published in the tree settles reuse terms.

Submodules and a toolchain decide whether a build starts

A `.gitmodules` file at the root means dependencies arrive as git submodules rather than being vendored, and a `toolchain/` directory sits in the tree where a pinned compiler build would live. Those 2 entries together mean a fresh clone is not yet a buildable tree: something has to be fetched from outside before `CMakeLists.txt` can configure anything. That is normal for a decompilation, where the compiler version and flags decide whether recovered output matches the original, and it also means the repository is not self-contained. There are no install commands here, no configure invocation, and no statement of which clang build the project expects; the README sends readers to https://botw.link for more information and names `master` as the default branch. Anyone planning to build should treat that site as the setup document, and should inspect what each submodule resolves to before assuming a checkout is usable.

Formatting rules work against matching the binary

A decompilation earns its value only when the reconstructed code behaves like the original, and that objective sits awkwardly beside a strict formatter. `.clang-format` and `.clang-tidy` impose one house style across the tree, which keeps diffs readable and review tractable, and the clang topic tag says which tool drives both. The tension is concrete: a matching function has almost no freedom about spacing and naming, so every style rule is a decision to prefer readable source over byte-for-byte fidelity, or the other way round. What the repository never says is which side it chose for any given file, or whether the tidy checks are warnings or hard failures during a build. Nothing visible in the root listing points at a test harness either, so a green build would not by itself show that the output matches v1.5.0. Clang is named in the project topics rather than in a script you can read from the root, so the toolchain requirement is pinned somewhere outside the checkout.

Questions the README leaves unanswered about building

Name the gaps before committing time to this. The README does not document an install or build procedure, does not give a rollback path or a way to report a mismatched function, and prints neither progress figure. It says nothing about what lives in `data/` or `docs/`, so those 2 trees could hold anything from lookup tables to design notes. The repository is not archived, and the most recent push landed on 2026-09-27, which is the only freshness signal anywhere in the tree, and nothing in the listing promises another one on any schedule. For a project this size the silence is defensible, because the work is continuous and public, but the practical cost is that a reader has to join the Discord channel or read the website to learn the current state, and neither is reachable from a checkout.

Reconstruction is not the same as runtime patching

The usual alternative for a Switch game like this is a runtime framework: software that attaches to the running game, hooks functions in memory and changes behaviour while the game executes, shipping no source reconstruction at all. The README does not compare this project with any named tool, so treat the contrast as a category difference rather than a claim about competitors. The difference in approach is fundamental. Runtime patching produces a result in minutes but depends on one retail build staying loadable and keeps its knowledge in a binary; a decompilation produces readable source that can be reviewed line by line and survives any later build, at the cost of no playable output and no local measure of completeness. zeldaret/botw takes the second path for v1.5.0 specifically, which is why aiding glitch hunting appears in its stated aims: a recovered function can be read instead of inferred from watching the game misbehave. The trade is concrete, since a patcher lets you try a change without waiting for the surrounding code to be recovered, and this project accepts that wait each time it documents a function instead of patching memory.

Contributor graph and a server id in a badge

People, not versions, are what the 2 remaining badges track. One resolves to the GitHub contributors graph for zeldaret/botw, the other to a Discord server whose identifier, 688807550715560050, sits inside the badge image URL itself, which is more detail than most READMEs leave in plain text. Their targets are these:

https://github.com/zeldaret/botw/graphs/contributors
https://discord.zelda.deco.mp

The contributor total is drawn by the badge service at read time, so it is not written in the README either, and neither link states whether outside contributions are accepted or reviewed. `Contributing.md` would be where that lives, and its contents are not shown. For a repository of this size the absence matters: coordination happens in chat, while the source tree acts as the archive rather than the front door, which is why a first look at the code tells you less about the project than a look at the community does.

Editorial conclusion

Take zeldaret/botw if you want to read or extend a reconstruction of Breath of the Wild v1.5.0, or source you can diff while chasing a glitch; the C++ tree and its clang tooling are the reason it exists. Leave it alone if you need a playable or modifiable copy, because the tree carries no assets and cannot run the game. Before building anything, read `Contributing.md`, open `AGENTS.md` and `CLAUDE.md`, resolve the submodules declared in `.gitmodules`, and take every completion number from botw.link rather than from the repository.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. zeldaret/botw on GitHub