# NocturneRecomp recompiles PowerPC into native code, so the game becomes moddable

> A static recompilation of the Xbox 360 version of Symphony of the Night for Windows and Linux, built on a pinned ReXGlue SDK. The PowerPC executable is translated to x86_64 at build time and wrapped in a small host runtime, and no copyrighted asset ships in the repository.

**birabittoh/NocturneRecomp** — Static recompilation of Castlevania: Symphony of the Night (XBLA) for Windows and Linux, built on the ReXGlue SDK.

- Repository: https://github.com/birabittoh/NocturneRecomp
- Website: https://goopie.xyz/#/library/nocturnerecomp
- Stars: 359 · Forks: 21
- Language: C++
- License: MIT
- Published: 2026-09-18 · Updated: 2026-09-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/birabittoh-nocturnerecomp

## Recompilation, not emulation, is what makes mods possible

The mechanism is stated in one sentence and it is the whole project. The Xbox 360 PowerPC `default.xex` is converted into native x86_64 code at build time, then wrapped with a small host runtime providing logging, overlays and hooks. The result runs natively and can be modded like a PC port.

The difference matters. An emulator interprets the original PowerPC instruction stream at runtime, so the program exists only inside the emulator's address space and a mod has to be injected through the emulator's own mechanisms. A recompilation produces an ordinary native binary, so the game is a program with a heap, a symbol table and a normal build pipeline, and a mod is just something that links against it.

That is why the host runtime carries overlays and hooks rather than translation services. Those features exist because there is a real process to attach them to.

## The licence covers the host side and nothing else

The legal boundary is drawn precisely, and it is worth reading the licence line rather than assuming. What is MIT licensed is the host side source in `src/`, the build scripts, and the CI configuration. That is the entire licensed surface.

The project states plainly that you must own the game, and that it ships no copyrighted code, data or assets. You provide your own legally dumped copy. So there is no ambiguity about what you are downloading from the repository: the runtime that hosts the game, the scripts that build it, and the automation, but none of Symphony of the Night itself.

This is why the SDK sits outside the licence statement. It is fetched from a separate repository during the build rather than vendored here, which keeps the toolchain and the game content clearly separated in both the tree and the terms.

## The SDK is downloaded and pinned, from a fork

The build does not assume you already have the ReXGlue SDK. Step two fetches it:

```bash
python scripts/download-sdk.py --pinned
```

The `--pinned` flag is the important part, and the repository root carries a `.sdk-version` file, so the SDK revision is recorded rather than taken from whatever the upstream default branch happens to be today. That is what makes a from source build reproducible, at the cost of needing network access during the build.

There is a detail in the credits worth noticing. The download points at an SDK repository under the same account as this project, while the credits link to the upstream ReXGlue SDK under a different owner. So you are building against a maintained fork rather than the original, which is normal for a tool like this and also means the pin is protecting you from upstream changes the project has not vetted.

## One build script, two variants, three config files

The build is a single script with a flag rather than two separate build systems:

```bash
# Vanilla
python scripts/build.py

# Title Update
python scripts/build.py --tu /path/to/TU_*
```

Passing a Title Update package produces a different build of the same game, and the repository reflects that split in its configuration. There are three TOML files at the root: `nocturnerecomp_config.toml`, `nocturnerecomp_manifest.toml` and `nocturnerecomp_tu_config.toml`, with the third being the Title Update counterpart.

Underneath, the build is CMake driven, with both `CMakeLists.txt` and `CMakePresets.json` at the root and Ninja named as the generator on both platforms.

So a Title Update build is a configuration change rather than a fork, which means a bug fixed in one is usually a configuration fix rather than a code fix.

## The dependency lines differ more than the README suggests

Step zero installs dependencies, and the two lines are not equivalent translations of each other.

On Arch and CachyOS:

```bash
paru -S clang20 cmake ninja vulkan-headers
```

On Windows:

```powershell
scoop install llvm cmake ninja
```

The Linux line names Clang 20 specifically, which is a deliberate pin of the compiler major version. The Windows line installs a package called `llvm` with no version constraint, so you get whatever the bucket currently serves. Both add `vulkan-headers` or nothing respectively, since the Vulkan headers are listed only on the Linux side.

If you are chasing a build difference between platforms, that asymmetry is a better first suspect than anything in the source, because it means the two platforms are not being compiled by the same compiler version.

## You must extract the game before codegen will run

The game handoff is three steps and the ordering is a hard constraint. Clone the repository, drop your legally dumped XBLA package, which is the `LIVE` or STFS file, into `game/`, then extract it:

```bash
python scripts/extract_game.py
```

The condition is stated explicitly: `assets/default.xex` must exist before codegen runs. So the extraction script is a prerequisite step, not a convenience, and if you skip it the build fails at a point where the error will not obviously point back to the missing extraction.

The same handoff exists on the prebuilt route, with one difference in ergonomics. If you take a release build you do not run the extraction script. You extract the archive, run the executable, and it prompts you to extract the game. The prompt is the equivalent of step three, pushed into the binary so that a user who only downloaded a release never has to think about Python scripts at all.

## Prebuilt releases and nightly artifacts cover different needs

There are two distribution channels and they are chosen differently on purpose.

Stable builds come from the repository's releases page, with the latest being the one to grab. Nightly builds come from CI artifacts instead, through a nightly.link style link into the CI workflow on the main branch. So a nightly is not a tagged release; it is whatever the build produced on that run, which means it can be broken without warning and carries no version number you can rely on.

The release cadence in the tag history suggests a busy patch line rather than occasional milestones: v1.4.3, v1.4.4 and v1.4.5 landed within ten days of each other in August 2026. That is consistent with a project where the recompiler is chasing compatibility fixes for a specific game rather than building a general tool.

There is also a distribution front end: the project is listed on Goopie, which is where the game itself can be obtained alongside the build.

## Conclusion

Use NocturneRecomp if you own the Xbox Live Arcade release of Symphony of the Night and want it running as a native x86_64 program on Windows or Linux, with a host runtime that has overlays and hooks and therefore supports mods, rather than sitting behind an emulator. The prebuilt route is three steps and needs no compiler at all. Four things to know before you start. That you must supply your own legally dumped package, because nothing copyrighted ships here and the prebuilt executable prompts you for the game on first run. That the MIT licence covers only the host side source, build scripts and CI config, not the game content or the SDK. That the SDK is fetched at build time with a pinned version, so a from source build needs network access. And that the Linux dependency line pins Clang 20 by name while the Windows one installs an unpinned LLVM, so the two platforms are not built against identical toolchains. Releases v1.4.3, v1.4.4 and v1.4.5 all landed in August 2026, and the last push to main is dated 27 August 2026.

## FAQ

### How does recompilation work?

In NocturneRecomp the Xbox 360 PowerPC default.xex is translated into native x86_64 code at build time rather than interpreted at runtime, then wrapped in a small host runtime that provides logging, overlays and hooks. Because the output is an ordinary native binary, the game can be modded the way a PC port can.

### Is there a PC port of Castlevania: Symphony of the Night?

NocturneRecomp targets the Xbox Live Arcade release of Symphony of the Night, recompiled to native x86_64 for Windows and Linux. You must own the game and supply your own legally dumped package, because the project ships no copyrighted code, data or assets.

### What does the MIT license on NocturneRecomp actually cover?

Only the host side source in src/, the build scripts, and the CI configuration. The game content and the ReXGlue SDK sit outside that grant, since the SDK is downloaded from a separate repository during the build and the game comes from your own dump.

### How do I build NocturneRecomp from source?

Install dependencies, which are clang20 plus cmake, ninja and vulkan-headers on Arch or CachyOS and llvm, cmake and ninja on Windows. Then clone, run python scripts/download-sdk.py --pinned, put your dumped LIVE or STFS file into game/ and run python scripts/extract_game.py, and finally run python scripts/build.py, or python scripts/build.py --tu /path/to/TU_* for a Title Update build.

### Can I play NocturneRecomp without a compiler?

Yes. Take the latest stable build from the releases page, extract the archive and run the executable. It will prompt you to extract the game. Nightly builds are also published as CI artifacts on the main branch, but those are untagged and can break without notice.

## Sources

- [birabittoh/NocturneRecomp on GitHub](https://github.com/birabittoh/NocturneRecomp)
- [License: MIT](https://github.com/birabittoh/NocturneRecomp/blob/main/LICENSE)
- [Project website](https://goopie.xyz/#/library/nocturnerecomp)
- [README](https://github.com/birabittoh/NocturneRecomp/blob/main/README.md)
- [Releases](https://github.com/birabittoh/NocturneRecomp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/birabittoh-nocturnerecomp