# Sonic 3 A.I.R.: a fan remaster built as a reusable C++ engine

> The Eukaryot/sonic3air repository ships the source for Sonic 3 Angel Island Revisited together with the Oxygen Engine, the librmx libraries and the lemonscript language runtime behind it. It is written for people who want to build, port or study the game, not for players looking for a release.

**Eukaryot/sonic3air** — Source and data to build Sonic 3 A.I.R. (Angel Island Revisited) and the Oxygen Engine

- Repository: https://github.com/Eukaryot/sonic3air
- Stars: 665 · Forks: 171
- Language: C++
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/eukaryot-sonic3air

## A remaster that is really an engine with a game attached

Sonic 3 A.I.R., short as S3AIR, is a non-profit fan remake of Sonic 3 and Sonic & Knuckles, built by Eukaryot. The repository description makes the scope explicit: it holds the source and data to build the game and the Oxygen Engine that powers it.

That distinction matters if you are an engineer rather than a player. The game content lives in one directory, Oxygen/sonic3air, and everything else is infrastructure: a game framework, a script language, and hardware emulation. The project documentation notes that Oxygen can be built as its own application, OxygenApp, without the S3AIR C++ code. So the repository is really two products sharing a build: a fan game, and a general purpose 2D engine with a script layer and an emulated Sega Genesis environment.

The legal frame is part of the project's definition rather than a footnote. It is not affiliated with SEGA or Sonic Team, Sonic the Hedgehog remains a SEGA trademark, no financial gain is made from the project, and any commercial use without SEGA's explicit consent is prohibited. That constrains what a fork can become even though the code itself is open.

## Four layers sit under the repository root

The repository overview splits the code into several projects, and the top-level entries show where each one lives: framework, librmx, Oxygen and the root README.

The framework directory holds the larger external dependencies, namely SDL2, Ogg/Vorbis and zlib, as copies of the respective open source projects with a few custom changes applied where needed. Each carries its own how-to-build.txt file describing those changes, which matters because a patched copy is not interchangeable with the upstream release.

The librmx libraries are described as the foundation for the author's own projects, S3AIR and private work. They consist mainly of rmxbase, a collection of helper and utility classes, and rmxmedia, a basic game framework built on top of SDL2 and OpenGL. LemonScript is the third piece: a language library with a compiler and a runtime environment for script execution.

The fourth layer is Oxygen Engine itself, the backbone that handles input, graphics, audio and the rest of the application, plus the simulation environment. S3AIR specific C++, scripts and data live in Oxygen/sonic3air, as the project puts it, yes, that is what it is named.

## Genesis hardware behaviour is emulated through script

The most interesting design decision in the stack is that the simulation of Sega Genesis hardware is not confined to C++. Oxygen Engine includes a simulation environment built around LemonScript that, as far as needed for the purposes of S3AIR, emulates aspects of the Sega Genesis hardware.

That means the emulated part of the machine is expressed in a language with its own compiler and runtime, sitting under the game code. Scripts and data for the game live alongside the C++ in Oxygen/sonic3air, so a change to game logic can, in principle, be made without touching the engine.

The emulation is explicitly scoped. The phrase as far as needed for the purposes of S3AIR limits the claim, so this is not a cycle accurate Genesis emulator with full hardware coverage. Sound chip emulation related code comes from GenesisPlus GX and sits in Oxygen/oxygenengine/source/oxygen/simulation/sound. The Discord Game SDK is vendored for integrations at Oxygen/sonic3air/source/external/discord_game_sdk.

Two upscaler shader sets are included twice, xBRZ in Oxygen/oxygenengine/data/shader and again in Oxygen/sonic3air/data/shader, and Hqx in the same two locations, so the engine and the game each carry the shader code and data.

## Building means picking one of six platform directories

There is no single build command in the project documentation. The instructions point you to readme files in the respective subdirectories of Oxygen/sonic3air/build, one per platform: _vstudio for Windows, _xcode for Mac, _cmake for Linux, _android for Android, _emscripten for the web, and _make for the Switch.

That is the tutorial, and it is worth stating plainly: the README does not give a copy and paste build recipe. Each platform has its own build guide inside the build tree, and the framework dependencies ship their own how-to-build.txt files describing the custom changes applied to the vendored SDL2, Ogg/Vorbis and zlib copies. Read the guide for your platform first, and read the framework notes before you assume a dependency behaves like the upstream release.

One platform has its own home. The Switch entry is labelled _make and marked unmaintained. For PlayStation Vita, the documentation points at a separate repository, https://github.com/v-atamanenko/sonic3air, rather than at anything inside this tree.

Expect a large checkout. The project vendors a substantial amount of third-party code, so the size of the repository is not a sign of the size of the game.

## Pull requests are declined, forks are the contribution route

The contribution policy is unusual enough to state early. The project notes that this repository is not meant for direct distribution and asks that anyone with changes to share create a fork of the repository instead of making pull requests. The stated reason is to avoid the overhead of managing and reviewing code changes from others.

The second reason given is about ownership and licences. Using the librmx, LemonScript and Oxygen Engine code elsewhere under a different licence than GPL is much easier if there is no large group of contributors to ask. The author mentions plans for possible future projects using this code as a foundation, perhaps even commercial ones, where GPL could complicate matters.

For an engineer evaluating adoption, this is a hard constraint rather than a preference. The repository is licensed GPL-3.0, the source file LICENSE is at the root, and the maintainer's stated intent is to keep a different licence possible for future reuse. Anyone planning to embed the engine in a codebase with a different licence needs to plan for that conversation early.

## Third-party code is vendored, patched and copied in two places

Dependency handling is the main maintenance cost in this repository, because the code is in the tree rather than fetched by a package manager. The documented external libraries include SDL2 in framework/external/sdl, libogg and libvorbis in framework/external/ogg-vorbis, zlib including minizip in framework/external/zlib, libcurl in framework/external/curl, Dear ImGui in framework/external/imgui, jsoncpp in librmx/source/rmxbase/jsoncpp and GLEW in librmx/source/rmxmedia/glew.

Two things follow. First, you inherit the licences of all of those projects, and the tree mixes GPL-3.0 project code with libraries published under their own terms. Second, since some copies carry custom changes, updating a dependency is not a version bump. It is a merge.

The alternative approach to this kind of fan remake is worth naming, because it produces a very different kind of artifact. A disassembly approach, such as the Sonic 3 and Sonic & Knuckles Disassembly the project credits as a valuable source of information, rebuilds the original game logic directly from the disassembly rather than writing a new engine with an emulated hardware layer. The disassembly route gives closer fidelity to the original code and less new source, but it yields a game, not a reusable engine, and it does not give you LemonScript, the script runtime or the rmxmedia framework to build other projects on.

## Releases, platforms and who does what

The repository is not archived and the last push was on 2026-10-18, so work is ongoing. Recent releases follow a dated scheme with platform notes in the tag names: v26.08.15.0-test and v26.07.12.1-test are described as test builds for Windows only, while v26.03.28.0-stable is a stable update. That split suggests the stable line and the faster test line do not move at the same pace, and that test builds have been scoped to one platform.

The build support list is what a porter actually cares about: Windows, Mac, Linux, Android, web through Emscripten, plus a Switch directory that is marked unmaintained and a Vita fork maintained elsewhere.

The credit list is long and split by role: source code contributions, a remastered soundtrack, and game scripts and other contributions, plus thanks to the contributors of the Sonic 3 and Sonic & Knuckles Disassembly. With GPL-3.0 and that many contributors, and a policy of forks rather than pull requests, the copyright situation for any downstream fork depends on tracking who holds what, which is exactly the overhead the maintainer is trying to avoid.

## Conclusion

Adopt this repository if you want to compile the remaster yourself, port it to a platform the project does not maintain, or reuse the Oxygen Engine and librmx for your own game work under GPL terms. Skip it if you expected a single binary, if you need to contribute through pull requests, since the project asks for forks, or if a non-GPL licence is a requirement for the engine code you want to reuse. Before building, check the how-to-build.txt file in the build directory for your platform and confirm that the third-party copies under framework/external still match your toolchain.

## FAQ

### What is Sonic 3 A.I.R. and what does the Eukaryot/sonic3air repository contain?

It is the source and data for Sonic 3 Angel Island Revisited, a non-profit fan remaster of Sonic 3 and Sonic & Knuckles, together with the Oxygen Engine that powers it. The tree also bundles the librmx libraries, the LemonScript language library and vendored copies of third-party dependencies.

### How do I build Sonic 3 A.I.R. on Linux or Windows?

The project documentation points to per-platform readme files in the subdirectories of Oxygen/sonic3air/build: _vstudio for Windows, _xcode for Mac, _cmake for Linux, _android for Android, _emscripten for the web and _make for the Switch. There is no single top-level build command, and the vendored dependencies carry their own how-to-build.txt notes about custom changes.

### Can I use the Oxygen Engine and librmx in a project with a non-GPL licence?

The repository is licensed GPL-3.0, and the maintainer explains that keeping the contributor group small keeps the option of relicensing the librmx, LemonScript and Oxygen Engine code open. The repository also asks contributors to fork rather than send pull requests, so you would need to reach the maintainer separately about any relicensing.

### Is the Nintendo Switch version of Sonic 3 A.I.R. still supported?

The build directory list marks the Switch entry, _make, as unmaintained. PlayStation Vita is handled by a separate repository at https://github.com/v-atamanenko/sonic3air.

## Sources

- [Eukaryot/sonic3air on GitHub](https://github.com/Eukaryot/sonic3air)
- [Issues](https://github.com/Eukaryot/sonic3air/issues)
- [License: GPL-3.0](https://github.com/Eukaryot/sonic3air/blob/main/LICENSE)
- [README](https://github.com/Eukaryot/sonic3air/blob/main/README.md)
- [Releases](https://github.com/Eukaryot/sonic3air/releases)

---

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