# RSDKv4-Decompilation rebuilds the Retro Engine from source, and needs your own game assets > The RSDKModding repository is a complete decompilation of the Retro Engine v4 plus the menus from Sonic 1 and 2 (2013), and the one rule it states first is that you must own an official release, because the assets are not in the repository. It builds with CMake on Windows, Linux, macOS, Android and UWP, with a set of RETRO_ flags that configure the build. **RSDKModding/RSDKv4-Decompilation** — A complete decompilation of Sonic 1 & Sonic 2 (2013) & Retro Engine (v4) - Repository: https://github.com/RSDKModding/RSDKv4-Decompilation - Stars: 1,152 · Forks: 263 - Language: C++ - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/rsdkmodding-rsdkv4-decompilation ## What a decompilation project actually is The repository description is a complete decompilation of Sonic 1 and Sonic 2 (2013) and the Retro Engine v4, and the readme narrows it to a complete decompilation of Retro Engine v4 and the menus from Sonic 1 and 2 (2013). That narrowing is the important part. The engine is the code, and the menus are the screens, and the gameplay and the assets are not included. The project is a from-scratch implementation of the engine, written in C++, that behaves like the original when you give it the original's data files. That kind of project is worth having for a few reasons. It makes the engine readable and modifiable in a way a shipped binary never is, it lets a community build on top of it, and in the case of an engine that was never released as source, it is the only way to understand it properly. The implementation language is C++, the licence is a custom one that GitHub cannot classify, with the text in the LICENSE.md file, and the last push was on 2026-09-06. The recent releases are 1.3.3 from 2025-11-02, 1.3.2 from 2023-09-18 and 1.3.1 from 2023-03-19, so the project is still being worked on and the release line is moving slowly. ## The rule that comes first: buy the game The readme's first heading is a call to support the official release of Sonic 1 and 2, and the sub-point under it is the whole condition of use. Without assets from the official releases, this decompilation will not run. The rest of the section tells you where to get an official release, and it is thorough about it. The Windows version is available through Steam and the Epic Games Store, both as part of Sonic Origins. The Nintendo Switch version is on the eShop, and there are iOS and Android versions through the App Store and Google Play or Amazon, with a note that the mobile releases have been delisted but that if you downloaded one in the past you can redownload it from your purchase history. The explicit instruction is that even if your platform is not supported by the official releases, you must buy or officially download it for the assets, and that you do not need to run the official release, you just need the game assets. A guide on the project site explains how to find the required assets from your legally obtained copies. So the boundary is clear and it is the right one. The code is open, the data is not, and the project needs you to have bought the thing. There is also a practical detail for people moving from the mobile versions, since the save file is at a path inside the Android data directory and is named SGame.bin in the decompilation folder as SData.bin. ## What has been added on top of the original engine The Additional Tweaks section is where the project becomes more than a faithful reconstruction, and it is worth reading because it shows where the community has pushed the engine. The script compiler from RSDKv5U has been added, and with it a built in mod loader and API, allowing mods with features such as save file redirection, custom achievements and XML GameConfig data. There is a custom menu and networking system for Sonic 2 multiplayer, so that anyone can host and join servers and play 2P VS. Several things have been ported in from Sonic Mania. The F12 pause, and the F11 step over and fast forward debug features, are enabled if devMenu is on. The idle screen dimming feature from Sonic Mania Plus is there, with the option to disable it or set how long it takes. And the Egg Gauntlet Zone is playable in the Time Attack menu in Sonic 2 if your version includes it. The dev menu has been extended with its own set of keys. F1 loads the first scene in the presentation stage list, usually the title screen. F2 and F3 load the previous and next scene in the current stage list. F5 reloads the current scene along with its assets and scripts. F8 and F9 visualise the touch screen and the object hitboxes. And F10 activates a palette overlay that shows the game's eight internal palettes in real time, which is the kind of feature you only add if you are interested in how the renderer works. There is also a settings.ini file that the game uses to load all its settings, similar to Sonic Mania, and the dev menu can be reached from anywhere with the ESC key if it is enabled in the config. ## Build with CMake, and clone the submodules properly The build section is short and the instruction that matters is a warning. The project uses CMake, a building system that supports many different compilers and platforms, and the readme asks you to make sure to enable the feature to add CMake to the system PATH during installation. Then the source code, with a rule that is stated in capitals. Do not download the source code ZIP archive from GitHub, as they do not include the submodules required to build the decompilation. Instead, clone the repository using Git, recursively. ```git git clone --recursive https://github.com/RSDKModding/RSDKv4-Decompilation ``` And for a repository you already have, the command to bring the submodules up to date. ```git git submodule update --init --recursive ``` That is a common and reasonable rule, and following it saves an afternoon. A ZIP archive of a repository with submodules gives you an empty directory where the dependencies should be, and the build fails with a missing directory rather than a missing file, which is harder to read. The compile itself is two commands in the root of the repository. ``` cmake -B build cmake --build build --config release ``` And the result is somewhere in build/ depending on your system. ## Dependencies, four package managers and one vcpkg The dependency section is per platform, and the set is the same everywhere: OpenGL, GLFW, SDL2, and the Ogg and Vorbis audio libraries. On Windows you install Visual Studio Community with the Desktop development with C++ package, and vcpkg, following only the first setup step of the vcpkg guide. Then you install the libraries with the vcpkg command, and the readme spells out that you replace the triplet for a 32-bit build. ``` [vcpkg root]\vcpkg.exe install glew sdl2 libogg libvorbis --triplet=x64-windows-static ``` The CMake configure then needs three extra arguments, the toolchain file, the target triplet and the prefix path pointing at the installed directory, and the readme repeats the instruction to replace each instance of the vcpkg root path. On Linux the same libraries come from the system package manager, and the readme lists the command for four of them. For pacman on Arch it is the base-devel group with cmake, glew, sdl2, libogg and libvorbis. For apt on Debian and Ubuntu it is build-essential, cmake and the development packages. For dnf on Fedora it is the same set with the glfw and zlib development packages added. And for apk on Alpine and PostmarketOS it is build-base with the same libraries. Then there is a line inviting contributions, which tells you the list is expected to grow. Android has its own instructions in the dependencies/android directory, and there is a flatpak/ directory at the top of the repository for a packaged build. ## The build flags are the configuration surface After the compile commands, the readme lists the CMake arguments, and they are worth reading as a description of what the engine can be told to do. RETRO_REVISION takes an integer and defaults to 3, which is the Origins revision, so the default build targets the most recent game release. RETRO_DISABLE_PLUS takes a boolean and decides whether the Plus DLC is disabled, and the readme says to build with it on when compiling for distribution, because the Plus content is not licensed for redistribution. RETRO_FORCE_CASE_INSENSITIVE forces case insensitivity when loading files and defaults to off, which is the flag you want if you are running on a case sensitive filesystem and the original assumed otherwise. RETRO_MOD_LOADER enables or disables the mod loader and defaults to on, and RETRO_NETWORKING enables or disables the networking features used for Sonic 2's 2P VS mode and defaults to on. RETRO_USE_HW_RENDER enables the hardware renderer. So the flags fall into three groups. The first is which game revision you are targeting. The second is which content you are allowed to include, which is the legal question again, expressed as a build option. And the third is which subsystems are compiled in at all, which is a size and behaviour question. That last group is the one people miss. A build with the mod loader and the networking off is a different program from the default, and for anyone shipping a binary, the flags are how the shipping decision gets made. ## The repository carries a build for every platform in the list The top level listing shows the scale of the porting work, which is the other thing that distinguishes this project. There are solution and project files for Visual Studio, a RSDKv4.sln and a RSDKv4.UWP.sln, and separate Sonic1Decomp.UWP/ and Sonic2Decomp.UWP/ directories for the Universal Windows Platform versions. There is an Xcode project for macOS, RSDKv4.xcodeproj/, and another one for iOS, RSDKv4 ios.xcodeproj/. There is an Android.mk, which is the Android native build makefile, and an android/ directory with the platform specific build instructions, plus a flatpak/ directory for a Linux package. The engine itself is in RSDKv4/, and the platforms/ directory holds the platform abstraction. The Server/ directory is the multiplayer server component, which matches the custom networking system the readme describes. There is a dependencies/ directory for the third party libraries, props/ for the shared build properties, and an FAQ.md alongside the README. There is also a .clang-format file, so the code style is enforced by a tool rather than by review, and a .gitmodules entry, which is the reminder that the recursive clone is not optional. The practical summary is that a single source tree is maintained across six or seven build systems, which is a maintenance burden that a project with a single maintainer and a slow release cadence takes on because the community wants the game to run everywhere. ## Conclusion Adopt this repository if you want to read or modify the Retro Engine v4 code and can supply the assets from a legally obtained copy of the game. Do not treat it as a way to obtain the game, because the project requires you to buy it and provides a guide for extracting the assets from your own copy. Verify first that you have the assets and know where to put them, that your toolchain has the listed dependencies for your platform, and that the RETRO_ flags match the revision of the game you are aiming at, since the default revision is the Origins one. ## FAQ ### What is the RSDKv4-Decompilation repository? It is a complete decompilation of Retro Engine v4 and the menus from Sonic 1 and 2 (2013), written in C++. The engine and the menu code are reconstructed in source form, and the game assets are not included. ### Do I need to own Sonic 1 and 2 to use the decompilation? Yes. Without assets from the official releases the decompilation will not run, so you must buy or officially download the game for its assets, even on a platform where the official release is not supported. A guide on the project site explains how to find the assets from your legally obtained copy. ### How do I get the source code for the decompilation? Clone it recursively with git clone --recursive, because the ZIP archive from GitHub does not include the submodules needed to build. For a repository you already have, run git submodule update --init --recursive inside it. ### How do I build it? With CMake, using cmake -B build followed by cmake --build build --config release. On Windows you need Visual Studio with the Desktop development with C++ package and vcpkg, and on Linux the OpenGL, GLFW, SDL2, Ogg and Vorbis packages from your distribution. ### What are the RETRO_ build flags for? RETRO_REVISION selects which game revision to compile for and defaults to 3, the Origins one. RETRO_DISABLE_PLUS excludes the Plus DLC and should be on for a distributed build, RETRO_MOD_LOADER and RETRO_NETWORKING toggle the mod loader and the Sonic 2 multiplayer features, and RETRO_FORCE_CASE_INSENSITIVE changes how files are loaded. ### What has been added to the engine beyond the original? The script compiler from RSDKv5U, a built in mod loader and API with save file redirection, custom achievements and XML GameConfig data, a custom menu and networking system for Sonic 2 multiplayer, a settings.ini, and a set of dev menu features ported from Sonic Mania including the F12 pause, fast forward and a palette overlay. ## Sources - [Issues](https://github.com/RSDKModding/RSDKv4-Decompilation/issues) - [README](https://github.com/RSDKModding/RSDKv4-Decompilation/blob/main/README.md) - [Releases](https://github.com/RSDKModding/RSDKv4-Decompilation/releases) - [RSDKModding/RSDKv4-Decompilation on GitHub](https://github.com/RSDKModding/RSDKv4-Decompilation) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rsdkmodding-rsdkv4-decompilation