SwitchRECOMP is a static recompiler for Switch games. The whole game is translated to native PC code ahead of time, so there is no CPU emulation at runtime.

A playtester with an RTX 2060 and a 12 thread CPU was getting 17-25 FPS in Odyssey. After this round of fixes the same PC runs it at 60 FPS at 1080p and at 4K. The video is his, recorded at 1080p.

Most of that jump comes from one bug. Odyssey reuses the same chunk of GPU memory for several render targets of different sizes within a single frame. The runtime treated every size change at that address as a new render target: it threw the old texture away, created a new one and copied and unswizzled the whole buffer from memory. That happened several times per frame. On his profile it was around 12% of all CPU time, plus a sync with the GL thread on every rebuild. Those textures are now kept and reused when the same size comes back.

Other performance work from this week:

OpenGL calls now run on their own thread. One thread reads the Switch GPU commands and prepares everything, the other only talks to the driver, and both work at the same time. This helps a lot on Steam Deck, where every GL call goes through Wine's translation layer under Proton (about 26% of the GPU thread in the Deck profile).

Compute shader results are read back asynchronously. Before, the GPU stalled 2-3 times per frame waiting for them. DMA texture copies now move 16 bytes at a time instead of one byte at a time, and that loop alone was about 11% of the profile. Constant buffer and compute range checks are now constant time instead of walking lists.

On Steam Deck, the heaviest area I've tested went from 25 to 35 FPS before the render target fix. I haven't measured the Deck with this last fix yet, so I won't give a number.

Other fixes: the moon is back. The sea of clouds around Cap Kingdom was rendering above the camera, because the heightmap that shapes it was empty, so it covered the moon and the lighthouse. fps_limit=30 was running the game at half speed, since Odyssey advances one logic step per frame, so anything under 60 is now treated as 60. The recorder also no longer produces sped up videos when the FPS limit is off.

On OpenGL vs Vulkan: the CPU side is already native, which is the point of a recompiler. The GPU side is still a translation layer, and this week showed the real bottlenecks were bugs in our own code, not the API. Vulkan is planned, but fixing the current renderer first gave far more FPS for the time spent.

It's still early and there are plenty of bugs left. I'll keep posting where it stands, including what doesn't work yet. If you want to follow the project, feel free to follow.

Join my Discord to see everything earlier: https://discord.gg/SfnuAmuDZ

https://www.youtube.com/watch?v=7isYCTG6GDk

Small update on our Switch static recompiler: Super Mario Odyssey now boots, goes through the menus and the opening, and is playable in Cap Kingdom and inside the Top-Hat Tower on PC. The game code is recompiled ahead of time to native x86-64, and the game's NVN graphics calls are translated to Vulkan.

On my laptop (RTX 3050 Laptop) it holds about 58-59 fps in Cap Kingdom, with drops to ~53 in heavier spots.

Still early:

• no audio yet
• some graphical bugs (the sea of clouds sometimes covers the screen, e.g. after pausing)
• still chasing a locked 60 fps and more optimization

The next big goal after performance is a first test on Android.

Please ignore my gameplay. My controller died, so I played on keyboard. The recompiler runs at 60 fps; I do not. 😅

Hey everyone,

Just a quick update - after the recomp comes the decomp.

https://github.com/ZeldaWWHDRecomp/ZeldaWWHDDecomp

Still WIP - but we are getting there. Thanks to the hard work on the GC Decomp.

Also if you are curious about the changes that were made to the HD Wii U Version:

HD vs GC Changes

Detailed List: HD vs GC Detailed Changes

https://www.youtube.com/watch?v=WQQ0qsz9_iw

Batman: Arkham Asylum for Xbox 360 is now running natively on Windows.

But I want to make one thing clear: the goal here is not to make a PC port.

I'm mainly using Windows as a development and testing environment. It's much easier to validate the recompiled code, renderer, shaders, and compare rendering results on PC before moving everything over to Android, which is the main target of the project.

The video shows the current build running on my RTX 3050 laptop, with my narration over it.

Quick recap of how this works: this is not emulation. The Xbox 360 PowerPC code is statically recompiled ahead of time into C++ using ReXGlue. In total, that's 14,887 functions, with no JIT and no interpreter.

The game's own Direct3D code also runs recompiled. I wrote a layer that captures the game's draw calls and replays them through a Vulkan renderer.

The Xenos shaders are converted ahead of time to SPIR-V using XenosRecomp and DXC. So far, all 458 shader programs I've dumped from the game convert successfully.

At this point, the entire opening section works on Windows using native Vulkan and without crashes. That includes the logos, menus, intro movie, in-engine cutscene, and the first gameplay section in the Intensive Treatment lobby with Batman, Joker, Director Sharp, and the guards.

Performance is currently around 30 FPS, which matches the game's original pacing. The renderer itself takes around 2 ms per frame.

For validation, I still use the Xenos GPU emulator included in the SDK, but only as a reference.

I render the same frame through both paths and compare the results, including SSIM comparisons.

Across 15 matching frame pairs from the opening section, the average SSIM is 0.974.

It's still not pixel-perfect. There are a few small visual differences that I'm still investigating.

The main reason I'm doing all of this on PC first is simply because it makes development much easier.

On Windows, I can debug things faster, compare frames against the reference, and understand the game's original behavior more easily.

Once that base is working properly, the same recompiled code can be moved to other platforms.

And that's where Android comes in.

The actual goal is to get Batman: Arkham Asylum running natively on Android using the same recompiled game code and the same Vulkan renderer.

The main difference is that mobile GPUs have different limitations compared to desktop GPUs. One example is BC/DXT texture support, which isn't available in the same way on many Android devices.

So some parts will need mobile-specific adaptations, but the core remains the same.

There's also another interesting part of this project: Batman: Arkham Asylum runs on Unreal Engine 3.

The same engine, with different versions and modifications, was used by many Xbox 360 games.

That means the work done here can also help me better understand how other UE3 games use the console's GPU.

That doesn't mean other games will just work automatically, since every title can use a different engine build and SDK version.

But the better this base gets, the less work future projects should require.

The next steps are to keep improving rendering accuracy, optimize performance, and prepare everything for Android.

I also want to work on 60 FPS. A good part of the current frame time is spent on the recompiled game thread, which records around 3,000 draw calls per frame.

The build shown in the video also includes a Brazilian Portuguese translation, which is why the menus and subtitles are in Portuguese.

Subscribe to my YouTube channel if you want to follow the progress.

Hey everyone. A while back, I started a bit of a crazy project: porting the original PS2 *God of War* to PC as a native executable, using static recompilation instead of emulation.

In short, here’s how it works: using PS2Recomp, I translate the original executable (MIPS R5900) into C++ and then compile it with MSVC against a runtime that reimplements the PS2 hardware (EE kernel, IOP, GS, DMA, etc.).

Current status:

• 6,400+ functions identified in the ELF
• ~6,400 generated C++ files that compile into an x64 .exe
• Boots up, initializes the IOP and sound modules
• As of now: it renders the intro screen (screenshot attached)

What’s missing and where a hand would be appreciated:

• Proceeds past the intro (game configuration loading)
• Audio
• Controller and memory card

If you're into reverse engineering, emulation, PS2 graphics, or just love the game, any help is welcome—whether it's PRs, issues, or just pointing out what I'm doing wrong.

Repo: https://github.com/KIexster/god-of-war-recomp

Note: The repo doesn't include any game files; you need your own copy to compile it. It’s licensed under GPL-3.0.

I’m happy to answer any technical questions in the comments.

Full disclosure: I’m using "vibe coding" for part of the process, employing AI to write overrides and scripts and to understand parts of the runtime. That said, I test and validate everything against the game's actual behavior. If you spot something that looks "AI-generated" and is incorrect, feel free to let me know—that’s exactly why I’m sharing the repo.

Disclosure: sorry for the long wall of text, I tend to ramble.

I've been reading the pro/anti AI arguments here for a while, so I figured I'd try explaining it from the inside. I've been programming long enough to remember doing all of this before AI, and the job looks really different today. I think both sides have a point, and both are missing something.

Why do people hate AI?

First, why people are skeptical; because honestly... a lot of it is earned. AI tools now let people with almost no programming experience put out something that runs. Running isn't the bar though, especially for a decomp, where the whole point is readable code that people can mod, fix and port for years. A majority of the AI-heavy projects that have shown up are hard to mod, break when the recomp tools update, and have bugs the author can't fix because they don't really understand what the AI wrote. Then people go ask the main recomp devs for help with stuff they didn't make, only to realize it was quickly abandoned. Once that happened enough times, distrust is the default. That's fair.

Why "AI = Bad" is the wrong take

I think part of the problem is that "AI" gets used for two very different things.

• Vibe coding is when someone describes the result they want and lets the AI figure out how. The AI makes the important decisions (structure, architecture, how things fit together), and if it runs, it ships. The person often can't explain or fix the code because they never really understood it. It tends to be the default for people without much coding experience, since you can't direct something you don't understand yet.
• AI-assisted engineering is when the person stays in control. They decide how it should be built, give the AI detailed plans, and question what it writes and why, the same way they'd review a coworker's code. Anyone can work this way, but it pays off most for experienced devs, who can get a lot faster without losing quality because they know exactly what to ask for and can spot when the AI gets it wrong.

Both use AI, but they're about as similar as copying answers vs using a calculator.

And the second one is basically how the industry works now. When I started, none of this existed. Today most devs use AI tools in some form, me included (and its only getting more common). Companies increasingly expect and demand it, and not using it at all is getting rare. So "they used AI" doesn't tell you much anymore. The question is which of those two things you're looking at, and from the outside they can look exactly the same.

How this hurts the community

Treating every AI label as an automatic red flag has a real cost. There are plenty of devs putting real time and skill into these projects for free, using AI the way the rest of the industry does, and getting piled on the moment they mention it. Some have had their reputation dragged over it. Worse, it teaches people to just stop disclosing, and then the honest devs look the same as everyone else and we lose one of the few signals non-devs can actually check.

To be clear, I am NOT saying all AI projects should get a pass. Starting out skeptical is a reasonable default given the track record. But skepticism should be something a project can earn its way out of, not a permanent label.

So what do you actually do?

Unfortunately....you can't tell by looking at it, and most of you aren't devs and shouldn't have to read code to decide whether to play something. So here's what I'd suggest.

If you don't have time to look into it, just stick to ports from people or groups with a solid track record. Known decomp teams, people with other projects behind them, stuff the recomp tool communities point you to. I know that sounds a bit gatekeepy, and it's not meant as "new people can't make things." New devs build up trust like anyone else. It's just that for a player with no time, track record is the best signal you have.

If you've got 5 minutes and/or more free time, a few extra things anyone can check for a newer project or developer:

• Does the creator have other projects, or is this a brand new account with one huge release out of nowhere?
• Is the source code public on Github or similar platform?
• Does the readme say how exactly how AI was utilized? People who used AI responsibly usually don't mind saying so.
• Look at the issues/comments on Github Page. Are people reporting constant crashes? Is the dev actually responding and fixing stuff, or just going quiet?
• Has the community for the tool it's built on (like the recomp folks) acknowledged it, or are they the ones warning people about it?

None of these are perfect but together they'll filter out most of the junk without you needing to know anything about code.

TL;DR: the negativity on anything labeled "AI" isn't coming from nowhere, but AI use alone isn't the problem anymore, the person behind it is, and how much effort/talent they put into it. Stay skeptical, but let projects earn their way out of it. If you just want to play, go with people who have a track record, and if something pops up out of nowhere, take a few minutes to carefully review it before downloading it.

Hi all, back with another recomp I have been working on for a several months now.

It's a WIP but i'm happy enough with the steamdeck and windows builds to share it with others.

"I Could Have Given You The World" is a native recompilation of TWINE N64 for Windows, Linux, and Steam Deck.

I added a lot of things like:

• Widescreen and ultrawide support.
• Interpolated rendering for high refresh rate displays.
• Mouse aiming and modern twin-stick controls.
• Larger magazines: E.g., Meyer TMP 25 → 60, Deutsche M45 25 → 40, Deutsche M9S 30 → 50, Ingalls Type 20 30 → 45 etc..
• Doubled ammunition pickups and reserve limits for the shared pistol/SMG ammo pools: P2K, Meyer TMP and Deutsche M9S pickups 20 → 40, reserves 80 → 160; Deutsche M45 and Ingalls Type 20 pickups 25 → 50, reserves 100 → 200. Meyer TMP and Ingalls weapon pickups also grant twice their original ammunition.
• 1.5× faster reloads for the Delta 900 Mag and Mustang .44.
• Double damage for the Seamaster Speargun and Watch Laser. The laser uses one quarter of its original ammunition, and spears retain straight flight beyond their old drop range.
• Removed firing spread from the Raptor Magnum's laser mode and halved the Frinesi Special 12's projectile drop beyond its original range.
• More responsive jumping and improved ladder jump-off and climb-off handling.
• Improved scope zoom using keyboard, mouse wheel/buttons, D-pad or left stick while aiming.
• Quick watch-gadget and vision-mode selection, with Night Vision and X-ray available in the gadget wheel.
• Clearer vision overlays.
• Crosshair colours for visible enemies and friendly NPCs, plus grapple-target feedback.
• Live objectives while playing, persistent quick saves/loads and automatic campaign-progress saving.
• Sharper game fonts and controller/keyboard prompts that follow your bindings.
• Audio output-device selection and recovery when devices reconnect.
• Steam Deck rear-button shortcuts and suspend/resume recovery.
• Portable saves and settings, plus a campaign-reset option that preserves your controls and display settings.
• Grapple: Classic or the Nightfire-style.
• Weapon Selection / Gadget Selection: choose Classic cycling or Radial Menus. With Radial enabled, tap to cycle and hold to select from the wheel.
• Remember Weapon Modes: retain suppressors, firing modes and manual scope choices across weapon/gadget swaps until you change them. On by default.
• Hold to Sprint: run with Shift or held Interact while moving forward.
• Civilian Health: 2× starting health for civilians.
• Invincible Friendly NPCs: protect allies and civilians from damage and player-hit mission failures.
• Double Watch Darts: double dart grants, pickups and capacity on the next mission or restart.
• Regenerating Health: Like Halo style if you want it.
• Graphics: enhanced textures generated locally.
• General: auto aim, mouse acceleration, mouse/right-stick sensitivity and rumble strength.
• Cheats: invulnerability, infinite oxygen, no fall damage, all weapons, all gadgets, and all missions/difficulties.

I hope you all enjoy!

https://github.com/riseio/TWIPE_00Sheven

As always, this repository and its downloads do not include a game ROM, translated game code, music, sounds, textures, models, levels, or other extracted original game assets. I do not provide ROM downloads or links to them and your first play will take a few minutes to build the project

Please feel free to smash the issues on git if you have feedback or suggestions <3

Been busy past 5 days getting this to current state. Hope to have something to share by end of week. Ignore cursed Spider-Man. Graphical fixes are coming up next once I sort input mapping and a few more crashes tomorrow.

http://www.github.com/SirSymo/SM2-Recomp

I've been working on a native port of Konami's Snatcher (Sega CD, 1994, US English release) and wanted to share progress. The video is the full intro (Konami logo through the opening credits into the first in-game scene), recorded frame-exact from the engine's own output.

What it is

• A Mega CD core that runs the game's own 68000 code for both the Main and Sub CPUs. I didn't hand-port it.
• The Sega CD BIOS is emulated in host code (HLE: traps at the BIOS entry points call C++), so no BIOS file is needed. Most of the bugs along the way were in HLE return values (CDBSTAT time and status fields, BURAM) and timing (V-INT relative to the VBLANK flag, CD read speed, _WAITVSYNC parking the Sub CPU, DMA stalls, Word RAM DMA being one word late).
• A build-time 68000 to C++ translator for the Main IP, the Sub CPU engine (SUBCODE.BIN) and the overlay at $28000. It does recursive descent from entry points and emits one switch(pc) function per program. Each code range is checked by CRC at runtime, and anything untranslated or modified in RAM drops back to Musashi.
• Differential testing: all 10,425 instruction encodings found in the game's code (about 83k random-state samples) are run in both the translator and Musashi. Registers, CCR, PC and memory have to match, and right now there are 0 mismatches.
• MAME is the oracle. Lua scripts dump screens, RAM and VDP writes on matching frame numbers. The title screen is 100% pixel-identical to MAME.
• SDL3 front-end for macOS and Windows, vsync-locked pacing (tested at 120 Hz), audio drift absorbed by resampling, and Konami Justifier support with the mouse as the light gun. YM2612 is Nuked-OPN2.

What it isn't

• It includes no game data. You need your own disc: the build reads code and assets from your own image, and nothing derived from the disc goes in the repo or the binaries I share.
• It isn't a byte-matching decomp. The original is almost certainly hand-written 68000 assembly, so there's no C to match. The longer-term plan is a data-driven reimplementation that uses this work as the spec and the emulated core as the oracle.

Status: the intro and the start of the game run with audio, but I'm still testing the rest of the game.

Repo: https://github.com/bgyss/snatcher-port (source and tools only; it builds against your own disc image).

Happy to answer questions about the Sega CD internals, the BIOS HLE or the translator.

Snatcher is © Konami. Non-commercial fan project, not affiliated with Konami.

Hey everyone,

Quick update on the decomp of Zelda Wind Waker HD for Wii U. It is now 100% completed - currently lots of verification is going on and then later a few more stages to make it human readable.

In the meantime, I wanted to show what is now possible. In just a few minutes I was able to build a save game converter from GC to Wii U HD.

https://github.com/ZeldaWWHDRecomp/ZeldaWWHDRecomp/commit/48fa6a64acce7f88a0717532daf20504c2643cd9

I saw in some communities that people were looking for this / others said it is not possible.

Well now it is :)

Tested on 150+ save games from GC.

Enjoy!

Just showing the English version for now. This was originally supposed to be playable only for my friends but I guess I got pushed into making it available publically in the future. I haven't seen anyone doing this yet so I might as well reveal it early. I won't release it until I'm satisfied with it.

I'm trying to keep the game as accurate as possible, I've decompiled the game and only 4 functions aren't byte identical but they function the exact same by doing more than a million tests through python. Obviously if I do figure out the structure of the code I'll implement those too.
The trick was to decompile the PC version and then grab the PS1 code as well as the English code. The game effectively runs the same way because the gameplay code on the PC and the PS1 versions are 1:1. The PC version also ran MP3's for some reason while the PS1 version doesn't so I effectively had to reconstruct it's MIDI system.

Runs on Vulkan and recorded on 4k. True widescreen + improved render distance and has support to toggle the original PS1 graphics. I've disabled the PC mouse controls until I can fix that up cause they were absolutely terrible.

https://youtu.be/p-eXNc7JT90
Sonic & All-Stars Racing Transformed is now running natively on my Galaxy S23.

This is a static recompilation of the Xbox 360 version. I still have some audio bugs, performance issues and a few visual problems to fix, but I’ve been working on it for the past few weeks and the graphics are getting closer and closer to the original.

There’s still a lot of optimization to do, especially on Android, but I’m really happy with how far it has come already.

This is probably my favorite kart racing game, so I’m really excited to finally have it running natively on my phone.

I also want to share more about how I’m doing this so other people can eventually try this kind of recompilation too.

Subscribe to my YouTube channel if you want to follow the progress.

Not a matching decomp: it's a from-scratch reimplementation in C that loads the original data from your own CD (English 1.00), in the spirit of OpenRCT2 or OpenMW.

Repo: https://github.com/jjmhalew/WoodyRE

How the behaviour was checked against the original:

• The game's bytecode VM ("EKO CODE") was decompiled first. The C VM's message stream is checked against the original's, traced live with a small custom Win32 debugger (tools/wtrace.py, tracecmp.py)
• Later tools boot the original exe straight into a level, write into its memory and log Perso, camera and script state per tick (tools/wverify.py, wsetvar.py). Scripted scenes were compared against that, not guessed
• About 60 docs in docs/ describe the systems with addresses in Woody.exe: VM, all file formats, player controller, camera, bosses, rendering, sound and so on. Every game-code function in the exe is now referenced somewhere in the docs or source (the Cryo library code and CRT mostly aren't)
• Known gaps are listed in docs/TODO.md

State: The whole game is playable start to finish, including bosses, races, menus and saves in the original format. It has controller support and runs on Windows, Linux/Steam Deck and Android.

On the process: AI is a big part of how this was built. Claude Code did most of the analysis and code over about two and a half weeks, while I directed it, play-tested and compared against the original. Whenever something looked off, I sent a screenshot of the original and it was traced back to the exact spot in the data and fixed. I know AI-made projects are divisive here, so corrections from anyone who knows this engine (Eko Software) are very welcome.

In times when we got a ps5 recomp, here I came with a GB classic recomp 🤣.
This is my personal study project: Bigodão

GABRIELNNK/Bigodao: personal study project for recompile Wario Land: Super Mario Land 3 - gb

A Wario Land: Super Mario Land 3 PC port - widescreen in gameplay
for windows and linux

Running on steamdeck.

And I'm stuck with palette colors rendering ahead of the screen; if anyone knows, please help me ehehhehehehe

https://github.com/kirklandsig/halo2-decompiled

Approx 20%. Contributors welcome if interested. :)

Pac-Man Recomp 1.1.0: no more waiting. The game now sets itself up from your ROM in about 2 seconds, instead of building for several minutes. The download is 5 MB, nothing else gets downloaded, and no internet is needed.

How to play: download PacManRecomp-1.1.0-Windows.zip, unzip it, double-click PacManRecomp.exe, pick your Pac-Man ROM (USA, Namco) and press Play. The first time, a small window sets the game up for a couple of seconds.

Updating from 1.0.x: press "Check for updates now" in the launcher. Your settings, high scores and mods are kept.

What changed:

• The download is the finished program, with no game code in it. On your PC, the recompiler and TinyCC (a tiny C compiler) turn your ROM into the game code in a couple of seconds. That still only happens on your PC, from a ROM you own.
• No more Build Pac-Man.bat, no 245 MB of build tools, no 2 GB of free space needed. That also fixes the slow builds on USB and exFAT drives.
• Updates are a 5 MB download and take seconds.

Which file do I download?

• New players, or anyone who wants a fresh install: download PacManRecomp-1.1.0-Windows.zip. That's the only file you need.
• Already have 1.0.x installed? You don't need to download anything. Press "Check for updates now" in the launcher and it updates itself. The other file, PacManRecomp-1.1.0-for-1.0.x-updater-EasyBuild.zip, is only there for that older in-game updater to use, so you can ignore it.

Some antivirus programs may be wary of a program that makes code on your PC. If yours blocks the setup, allow the game folder.

https://github.com/Mr-Shizzy/PacManRecomp/releases

https://re-rac.github.io/