MarathonRecomp: a static recompilation port of Sonic the Hedgehog (2006)

The port ships code, not the game

Marathon Recompiled is described in the README as an unofficial PC port of the Xbox 360 version of Sonic the Hedgehog (2006), created through the process of static recompilation, with Windows, Linux and macOS support. The licensing boundary is stated plainly: the project does not include any game assets, and you must provide files from your own legally acquired copy to install or build it.

That makes the project a translation effort rather than a re-release. What you download is tooling and generated code; what you supply is the retail content. The README also marks the effort as unfinished, with a caution that the recompilation is still under active development, is not meant for public use, and will not receive support until an official release. There is no official website, and the README asks that people link to the repository rather than to any other address.

Two recompilers split the work between code and shaders

The pipeline divides into two tools with different jobs. XenonRecomp converts the original PowerPC game code into C++, and XenosRecomp converts the Xenos shaders into HLSL. The README credits both as the main recompilers used for the port, and describes their development as directly inspired by N64: Recompiled, the project behind Zelda 64: Recompiled.

The repository layout backs that up. The root holds a CMakeLists.txt, a CMakePresets.json, a toolchains directory, a thirdparty directory and a vcpkg.json dependency manifest, alongside the MarathonRecomp and MarathonRecompLib source directories and a MarathonRecompResources submodule reference in the form of a .gitmodules entry. An update_submodules.bat script and a flatpak directory sit next to them. Based on that layout, the build is driven by CMake with vcpkg-managed dependencies, and the native toolchain is checked into the tree rather than assumed to be installed system wide.

The installer rejects anything it did not come from a disc

Installation is the part with the sharpest edges. The README links a How to Install section and then spends most of the FAQ on the installer error message about invalid files, which points at several distinct causes.

Compressed archives are the first. Files such as .zip, .7z or .rar will not work, so the game content must be extracted before the installer sees it. The Add Folder option is the second trap: it expects a directory whose contents are already extracted, with entries like .xex, .ar.00 and .arl, and it explicitly does not scan the folder for compatible content. The third is region. Discs and title updates from different regions cannot be combined, and mixing them fails at the patch generation step. The last is modification: the installer only accepts original and unmodified files.

There is a way to re-run the installer later, for example after accidentally altering game files:

While it's unlikely you'll need to do this unless you've modified your game files by accident, you can force the installer to run again by using the launch argument: `--install`.

Save data and config.toml live in per-platform directories

Save data and configuration are written to platform specific locations:

- Windows: `%APPDATA%\MarathonRecomp\`
- Linux: `~/.config/MarathonRecomp/`
- macOS: `~/Library/Application Support/MarathonRecomp/`

Save data sits under the save folder, and the configuration file is named config.toml. If you would rather keep everything beside the executable, an empty portable.txt file in the installation directory makes the game ignore the default paths and write into the installation folder instead. The README is direct about the consequence of that choice: you become directly responsible for the safekeeping of your save data and configuration.

Keyboard bindings live in the same config.toml, and the README points to an enum template in the source for the list of valid key values. A controller is described as highly recommended until Action Remapping is added in a future update.

Updates copy files over the installation and keep your save

Updating is not a reinstall. The README explains that you can copy the files from a release on top of an existing installation, and that save data and configuration will not be lost, because the game files themselves stay the same across versions of Marathon Recompiled.

Two installation details round this out. The Flatpak version has its own data location, described separately in the README. And on Linux the video driver can be forced, which matters on systems where the default session type is not what you expect:

- X11: `--sdl-video-driver x11`
- Wayland: `--sdl-video-driver wayland`

The second argument is passed straight to SDL as a hint for initialising the game with the preferred option. The same launch argument style as --install is used here, so the port has a small, consistent command line surface.

Original game bugs are preserved on purpose

The most surprising policy for a new user is that original game bugs are deliberately kept. The README states that bugs present on the original hardware are intentionally preserved and will not be fixed, apart from a few minor exceptions tracked in a specific issue. Bug reports for behaviour that also happens on the Xbox 360 will be rejected. Reports of bugs unique to the port must be accompanied by footage captured on original Xbox 360 hardware showing the bug does not occur there.

That is a defensible choice for a preservation project, since it keeps the recompiled build faithful to the retail release instead of quietly becoming a remaster. It also moves work onto the reporter. The same policy extends to the known issues list, which the README asks you to consult before reporting anything, with the issue tracker as the place to check first.

Steam Deck Game Mode blocks the file picker

On Steam Deck, running in Game Mode, the file picker used to supply the game files may not appear. The README attributes this to restrictions in how the desktop environment behaves in Game Mode, and the workaround is to boot into Desktop Mode at least once. After that, the Deck allows the file picker to be used when returning to Game Mode. The README suggests completing the whole installation in Desktop Mode to avoid having to browse through Game Mode at all.

This is the kind of detail that decides whether the port is usable on a given device, and it is only present because the project documents it. The repository itself shows no GitHub releases so far, and the README instructs that builds should only be downloaded from the Releases page, stating that they will never be distributed on other websites, through Discord servers or via third-party update tools. The project is distributed under GPL-3.0, with the COPYING file at the repository root.

For toolchain work, XenosRecomp alone may be the entry point

If your interest is the technique rather than the game, the split between the two recompilers is the useful part. A project that only needs shader translation does not need XenonRecomp, and a project that needs code translation without touching shaders does not need XenosRecomp. Marathon Recompiled needs both because the Xbox 360 release combines PowerPC code with Xenos shaders, and the README credits each tool to the part it handles.

The lineage the README names is N64: Recompiled, used to create Zelda 64: Recompiled, and it describes that work as the direct inspiration for the two recompilers here. The practical distinction between MarathonRecomp and a conventional emulator is not something the README spells out, so treat any claim about runtime translation as unverified. What can be traced is narrower and still concrete: two published tools, one for PowerPC to C++ and one for Xenos shaders to HLSL, and a CMake-driven build that uses them together.

Editorial conclusion

MarathonRecomp suits a player who already owns the Xbox 360 disc and wants the 2006 release running natively on Windows, Linux or macOS, and a developer curious about how the XenonRecomp and XenosRecomp toolchain works on a full title. It is not a distribution channel: the README states the project is not meant for public use, ships no assets, and the repository has no GitHub releases. Verify first that your disc is original and unmodified, that all disc and title update files come from the same region, and that the installer accepts your files before planning around it.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. sonicnext-dev/MarathonRecomp on GitHub