ssrecomp: Pokémon SoulSilver in Native C++, and Claude Wrote Nearly All of It
By Indie Kings | October 18, 2026
Updated October 18, 2026: ssrecomp is a native build of Pokémon SoulSilver that statically recompiles the game's ARM9 code to C++ on top of a patched melonDS core, and it hit GitHub only four days ago, on October 14, 2026. Per its own README, nearly all of the code, documentation and testing was done by Anthropic's Claude, and the author tells anyone reusing it to review the code first and to keep it out of pret entirely.
Image: Route 29 in widescreen. Credit: ClickingMaster/GitHub.
What ssrecomp actually is
Per the official repository README, ssrecomp is a native build of Pokémon SoulSilver for single-screen devices, and it works as a hybrid. The game's ARM9 code is statically recompiled to C++ from the build output of the pret/pokeheartgold decompilation, while the melonDS core, vendored at tag 1.1 with a few patches, provides the DS hardware underneath: graphics, sound, cartridge, save memory and the ARM7 CPU. So recompiled game logic runs against a DS hardware simulation instead of either being emulated or being ported wholesale.
Recompilation projects have become the community's preferred preservation path since the Nintendo 64 Zelda recomp wave showed that a statically recompiled game runs natively, needs no original console code and ports to devices that cannot emulate well. ssrecomp extends that pattern to the Nintendo DS, whose two CPUs made that an open question.
The scale is the giveaway that this is a real recomp of the game, not a wrapper. Per the README's build log example, one generation pass prints "121 sections, 25118 chunks, 1685104 instructions, 71 files", and the generated folder holds about 1.69 million recompiled instructions across 71 C++ files, each chunk function covering up to 256 instructions. Runtime code repeats the interpreter's per-instruction sequence of prefetch, execute and cycle accounting, so a recompiled run is bit-identical to an interpreted one, per the same file.
The repo is new and small by site traffic standards but moving fast: GitHub shows it created October 14, 2026, pushed October 18, 2026, with 76 stars at recheck time, under GPL-3.0-or-later, a license the README says is required by the melonDS core it builds on.
The AI wedge, stated in the README
The honesty flag is printed at the top of the README, not buried: "Made with heavy use of AI." Per the same file, nearly all of the code, documentation and testing was done by an AI coding assistant, Anthropic's Claude through Claude Code, directed and play-tested by the maintainer. The author asks readers to "expect bugs a person would not have made" and to review the code with that in mind before reusing any of it.
The warning has a hard edge aimed at one community: per the README, because the code is AI-written, no part of it may be submitted to pret, the decompilation project whose contribution rules do not accept such work. That matters in practice, because ssrecomp is built directly on pret's pokeheartgold output; a contributor tempted to upstream a fix found through ssrecomp has been told in advance not to.
Nothing in this article is a code audit. The claim outside the README, and it is ours, is that a project in which an AI agent wrote nearly everything, in four days, and then documented its own failure mode in the first paragraph of its README is a genuinely new kind of launch.
One screen, widescreen overworld, battle buttons
The README screenshots show Route 29 and Violet City drawn across a 16:9 screen, and a battle screen with the touch-screen command buttons laid out as a strip along the bottom, played entirely with a controller on one screen. That is the design problem the project exists to solve: a DS game is built for two 4-inch-class screens at 256x192 pixels each, and single-screen handhelds have one display.
Per the README's merged-view breakdown, the default view cuts the box result by situation. The overworld fills the whole widescreen picture instead of a 4:3 box and is drawn at high resolution, where a reworked 3D rasterizer, in the new melonDS file src/GPU3D_Wide.cpp, re-submits the frame's polygons with a widened clip so scenery left and right of the DS's own view gets drawn, perspective-correct, on worker threads. In battle, touch-screen commands are lifted off the bottom screen and laid out as buttons under the message's first line, with nothing of the scene covered; the game still receives them as touches.
Detail costs scale with ambition: per the README, the widescreen world at 720 lines costs about 5 ms per frame on a 6-core desktop CPU, 12 ms at 1080 and 18 ms at 1440. A 60 FPS mode is on by default even though the game updates its 3D scene 30 times a second, by pairing polygons between frames and drawing in-between positions during the same movement vote, with game speed unchanged. The older split layouts, hybrid, side, vertical, top and bottom, remain in the pause menu.
Platforms and the first build
Per the README, a setup program drives everything: choose your ROM, press Build, wait 20 to 40 minutes for the first build, then press Play. Even the Android APK is built on the PC from your own ROM, then copied to a 64-bit ARM device running Android 7.0 or later, and the README says plainly that the APK contains your copy of the game and must never be shared.
| Platform | Status per README | Notes |
|---|---|---|
| Linux x86_64 | Stable path | Setup binary plus AppImage packaging; run.sh path too |
| Linux ARM64 | Stable path | Raspberry Pi 4/5 with 64-bit OS and other arm64 boards; AppImage setup |
| Windows x86_64 | Shipped but untested | README marks Windows gameplay as untested |
| macOS | Experimental | Apple Silicon and Intel, macOS 11 Big Sur or later; Metal frontend, Retina support |
| Android | Experimental | 64-bit ARM, Android 7.0 or later; APK built on your PC from your ROM |
There is also a road into the project that never touches the decompilation: per the README, the recompiler can read the code straight from your own ROM dump, using a layout file named layouts/soulsilver-us.json that holds only addresses and checksums. Under that route the generated code is identical to the decompilation build's result. The full decompilation route is for people who want to change the game itself: build pret/pokeheartgold from source, verify the rebuilt ROM matches the retail cartridge SHA-1 published in the README, then regenerate. That path wants about 3 GB of disk, 16 GB of RAM, and takes 20 to 30 minutes of compilation on a 6-core CPU.
Testing discipline comes across in the tooling, again per the README. A lockstep mode runs an interpreter-only console and the recompiled one side by side and compares registers, flags, cycle counts and timestamps after every ARM9 instruction. Of 2,312 test screenshots, per the README, only 3 differ from the interpreter reference, each by one line during a battle transition.
The performance numbers
Per the README's performance section, the recompiled code is about 6 to 9 percent faster than the plain interpreter, measured over 1,800 frames of overworld from a save state, headless: about 9.0 to 9.9 seconds recompiled against 9.9 to 10.6 seconds interpreted. Around the recompiled code, core-level work, including 2D line caching, coarser scheduling slices and widescreen rasterization on worker threads, is credited with roughly 30 percent less time in the overworld and 20 percent in battles than v0.3.0. After all that, the recompiled ARM9 game code is about 60 percent of the main thread's time, per the same file.
| Metric per README | Figure |
|---|---|
| Recompiled vs interpreter, 1,800 overworld frames | 9.0 to 9.9 s vs 9.9 to 10.6 s, about 6 to 9 percent faster |
| Overworld time vs v0.3.0 | About 30 percent less |
| Battle time vs v0.3.0 | About 20 percent less |
| ARM9 game code share of main thread | About 60 percent |
| Overworld at 2560x1440, widescreen 720 lines | About 8 ms of the 16.7 ms frame on a 6-core CPU |
| Screenshot deltas vs interpreter, test suite | 3 of 2,312, by one line each |
Why it ships zero game data
Per the README, the repository contains no game code or data; it holds only the recompiler, the runtime and the frontend. The game-specific generated folder is produced on your machine from your own build of the pokeheartgold decompilation, which in turn needs your own copy of the game, and the README forbids committing generated code, ROMs, saves or save states. Its own quick start says you need your own copy of Pokémon SoulSilver (US) as a .nds file dumped from your cartridge, and that nothing of the game is in the repository or its releases.
Getting that copy is on you and it is where the legal line sits: buy the cartridge and dump it yourself, because legally obtained means your own game, not a download. Unofficial projects like this one run against Nintendo's terms, and the README handles its own exposure with a disclaimer: it is not affiliated with or endorsed by Nintendo, Game Freak, The Pokémon Company, pret or the melonDS project, and Pokémon is a trademark of its owners.
Our take: we think the DS was the console everyone quietly believed static recomp could not handle, and a dual-CPU system recompiled at the ARM9 with the ARM7 left emulated turns out to be a workable split. We also think the README's own warning is the most useful sentence here: four days from zero to a 1.69-million-instruction native port is a milestone for agent-built software, and the author telling reusers to review the code before trusting it is what makes sharing the milestone honest.
FAQ
Does ssrecomp need a SoulSilver ROM?
Yes. Per the README, you need your own copy of Pokémon SoulSilver (US) as a .nds file dumped from your cartridge, and nothing of the game is in the repository or its releases.
Who actually wrote ssrecomp?
Nearly all of the code, documentation and testing was done by Anthropic's Claude through Claude Code, directed and play-tested by the maintainer, per the README, which also warns that bugs a person would not have made should be expected.
Is it a port or an emulator?
Both, layered. The game's ARM9 logic is statically recompiled to native C++ at build time, then runs on a patched melonDS 1.1 core that supplies the DS hardware, including graphics, sound, cartridge, save memory and the ARM7.
What can I run it on?
Linux x86_64, Linux ARM64 including Raspberry Pi 4/5, and Windows x86_64 ship through the setup program, with experimental builds for macOS 11 or later and Android 7.0 or later, per the README.
Does it really run widescreen?
Yes. Per the README, the overworld fills a 16:9 display at high resolution through a reworked 3D rasterizer, battles stay 4:3 with touch buttons relaid along the bottom, and the README screenshots show Route 29 and Violet City in that view.
Can I use ssrecomp code in the pokeheartgold decompilation?
No. Per the README, because the code is AI-written, no part of it may be submitted to pret, whose contribution rules do not accept AI-written work. Review before reusing anywhere, the README says.
Bottom Line
ssrecomp, created October 14, 2026 and pushed October 18, 2026 with 76 stars, brings the static-recomp wave to the Nintendo DS: ARM9 SoulSilver logic recompiled to about 1.69 million instructions of C++ on a patched GPLv3 melonDS 1.1 core, running widescreen on single-screen devices. Nearly all of it was written by Claude over those four days, per the README, which warns about bugs and banishes the code from pret. The repo ships no game data at all, and the build starts from your own dumped copy of SoulSilver US.
Related: PlatinumSharp Is Not an Emulator: Pokémon Platinum's Own Code Runs as C# | pokeheartgold: The AI Decomp Fork pret Publicly Disowned | Wolverine Reaches Gameplay on KytyPS5 at Single-Digit FPS [2026]
Sources: per the official ssrecomp repository README at github.com/ClickingMaster/ssrecomp, fetched in full October 18, 2026; repository metadata (creation and push dates, star count, license) re-verified via the GitHub API on October 18, 2026; screenshot URLs hotlink-checked the same day.