Aurora is a GameCube and Wii compatibility layer written for decompilation

A compatibility layer, not an emulator

Aurora is described as a source-level GameCube and Wii compatibility layer intended for use with game decompilation projects. That framing is the whole thing and it is worth being precise about, because the name invites a wrong assumption. An emulator takes retail game binaries and reproduces the original hardware well enough to run them. A compatibility layer does something else: it re-implements the platform's API surface so that game code recompiled from source can build and run natively. Aurora was originally developed for Metaforce, a Metroid Prime reverse engineering project, and it now powers several completed source ports, with Dusklight named. The practical consequence is that Aurora is aimed at people who already have decompiled source, not at people who want to run a dumped ISO. The repository structure reflects that audience, with `include/` holding the public headers, `lib/` and `platforms/` holding the implementation, `extern/` for third-party code, and `examples/` with a `simple.c` file.

The GX layer sits on WebGPU and Dawn

The graphics side is the most substantial part of the project. The GX compatibility layer is built on top of WebGPU, a cross-platform graphics API abstraction layer, and the implementation used is Chromium's Dawn. The stated reason is that WebGPU allows targeting all major platforms simultaneously with minimal overhead, and the feature list names D3D12, Vulkan and Metal as the graphics APIs supported. What that buys a decompilation project is a single implementation of the GX API, which was Nintendo's immediate-mode-ish graphics interface for GameCube and Wii, written against a modern abstraction rather than against the original hardware's fixed-function pipeline. The feature list also calls the implementation highly accurate and performant, and describes a pipeline cache system with transferable cache support for releases, plus support for Dolphin-compatible texture packs, which matters because it means an existing texture pack made for the Dolphin emulator carries over. There is widescreen and resolution scaling support, and custom APIs for offscreen rendering.

PAD, DVD and CARD cover the rest of the platform

The other three compatibility layers fill in the rest of what a game expects. The PAD layer handles controllers, using `SDL_Gamepad` for wide controller support including GameCube controller adapters, with a layered input routing system for advanced input handling and remapping, and it automatically saves and loads controller bindings and port mappings. Gyro, keyboard and mouse input are supported as well, which is what makes a port playable without original hardware. The DVD layer uses nod, a project from the same organisation, to support all GameCube and Wii disc image types including RVZ, the compressed format that Dolphin users know. The CARD layer gives full compatibility with Dolphin's `.gci` and `.raw` save formats. Two UI toolkits are built in: Dear ImGui for simple debug interfaces, and RmlUi for full HTML and CSS-based user interfaces, which is the heavier option a port would use for its own menus. Between them, the layers cover graphics, input, disc access and saves, which is close to the complete surface a retail game touches.

The application layer decides where the port runs

Above the platform layers sits an application layer built on SDL3, and this is the layer that determines the platforms a port can ship on. The listed targets are Windows, Linux, macOS, iOS, tvOS and Android, which is a notably wider set than the original hardware. The reason SDL3 is a good fit here is that it is the same library the PAD layer already uses for controllers, so a single dependency covers both the windowing and input side. The repository layout backs up the picture of a modular library rather than an application: there is a `CMakeLists.txt` at the root, a `cmake/` directory, a `platforms/` directory for the per-platform backends, `tests/`, and `examples/` with its own `CMakeLists.txt` and a `simple.c` entry point. The `docs/` directory holds the build documentation, and there is a `.clang-format` file, which suggests a fairly uniform code style expectation across contributors.

Building it, and where the documentation stops

The README's build section is a pointer rather than a guide: see `docs/building.md` for build instructions, CMake integration and configuration options. There is no command sequence in the README itself, so the concrete build steps live in that document and the honest thing to do is read it there rather than guess at flags. The same applies to the `examples/` directory, which carries its own `CMakeLists.txt` and a `simple.c` file, so a consumer integrating Aurora into an existing CMake project has a worked example of that integration to copy. Two other things are worth knowing from the top-level layout. The `extern/` directory indicates third-party code is vendored rather than fetched at build time, which makes the build more hermetic but means updates to those dependencies arrive through the project rather than a package manager. And the presence of a `tests/` directory tells you there is a test suite, which for a compatibility layer is where most of the real confidence lives, since the layer's job is to behave exactly like hardware that no longer exists to compare against.

Why the project is driven by decompilation rather than by coverage

The most useful thing about Aurora is what its shape implies. It was built for one project, Metaforce, and it grew to power several completed source ports, which means the layer is being pulled by real demand rather than by an attempt to be complete. That has an upside and a downside. The upside is that the parts of the API that decompilation projects actually hit are the parts that got implemented properly, and the ports that exist are ports that ran. The downside is that coverage is uneven, because a layer built for Metroid Prime does not necessarily implement every GX call or every PAD edge case that a different game needs, and the feature list is written in the language of the projects that asked for it. There is no compatibility list in the README, no matrix of implemented versus missing functions, and no statement of which games are known to work. If you are evaluating this for a decompilation effort, the practical check is whether the ports already built on it exercise the APIs your project needs, and the repository, not the README, is where you would look for that.

Editorial conclusion

Adopt Aurora if you are working on a GameCube or Wii decompilation and need the platform's GX, PAD, CARD and DVD APIs re-implemented on a modern graphics stack. Skip it if you want to play GameCube or Wii games, since Aurora is a compatibility layer for recompiled source, not an emulator of retail binaries. Before you commit, read docs/building.md for the build options and CMake integration, and check that the ports you care about are among the completed ones, since the layer is driven by the needs of decompilation projects rather than by full platform coverage.

Frequently asked questions

Official sources

1. encounter/aurora on GitHub
2. Issues
3. License: MIT
4. README