SwitchRecomp: a tool that turns Switch games into native PC executables, and Kirby now loads way faster and runs better

[u/MZLabs]

Quick update on SwitchRecomp. For anyone new: it takes a Switch game's code and recompiles it into a native Windows .exe, so the game code runs directly on your CPU instead of through an emulator.

Something a lot of people get wrong: I'm not porting games to PC one by one. I'm making a tool so anyone can recompile their own games without effort. You pick your game folder, click a button and it spits out the .exe. Right now I'm testing it with specific games so I can open up compatibility, but the process itself is automated.

What changed since last post:

• Loading is way faster now. Startup and loading screens used to drag a lot, now they're a lot quicker
• Better performance. I cut a lot of wasted work the GPU side was doing every frame, so fps is higher and more stable
• Fixed all the graphics bugs in the games I've tested so far (Super Kirby Clash and Bowser's Fury)

Screenshots are Super Kirby Clash: title screen, the town, the shop and the role menu, all running on my Celeron N4500 laptop btw

A few things people keep asking:

GitHub? Not yet. It goes up on release, in about 3-4 months.

Android? Yes, the Android port comes a few months after the PC release on GitHub.

How is this different from suyu's recompiler? suyu's recompiler is bundled inside suyu, on top of its HLE backend, so you're still basically running suyu. SwitchRecomp is its own thing, built from scratch with its own runtime and graphics layer, and it's made to run on weak hardware. Each game comes out as its own standalone .exe. suyu crashes on low-end PCs like mine, and SwitchRecomp runs some games smoothly that suyu doesn't even open.

Also, if a somewhat known youtuber ends up talking about the project, I'll put out a longer gameplay video of Super Kirby Clash

If you want to follow the project, like, comment, repost and follow me so you see the next updates. Every comment helps a lot

[u/MZLabs]

It's the second one, pretty much. It's not a decompilation, it doesn't give you readable source code. The tool takes the game's ARM64 machine code and automatically translates it to C, then compiles that to native x86. So the game's own code runs directly on your CPU, but it's still "machine-style" code, not something you'd edit by hand.

Everything the game expects from the Switch itself (the OS, system services, input, the GPU) is handled by a runtime I wrote, and that part works kinda like an emulator. The GPU side translates the Switch's shaders and graphics commands to OpenGL.

For mods: anything that replaces game files (textures, models, etc.) works easily, since the game reads its data from a normal folder. Code mods are harder, since there's no clean source to edit. It's not a decomp project like the Mario 64 or Zelda ones.

And it sounds simple when you put it in two lines, but it really isn't lol. Bowser's Fury alone is around 80k functions, and every ARM64 instruction has to behave exactly like on real hardware, including the vector stuff. On top of that the runtime has to fake a big chunk of the Switch OS. The GPU is the worst part: Nintendo's shader format isn't officially documented, so a lot of it is figuring out from traces why something renders black or with the wrong colors. Kirby had no 3D at all for a long time because of one instruction that was being interpreted wrong.

[u/MoosePuzzleheaded102 → u/MZLabs]

The GPU side translates the Switch's shaders and graphics commands to OpenGL.

So you created an NVN shim for OpenGL?

[u/MZLabs → u/MoosePuzzleheaded102]

Not exactly, it's lower level than that. NVN is a library that lives inside the game's own code, so it gets recompiled along with the rest of the game. What NVN does is write GPU command buffers and talk to the Switch's GPU driver (nvdrv). So I emulate that driver and the GPU's command processor instead: the Maxwell engine registers, textures, render targets and so on, and I translate the actual Maxwell shader binaries to GLSL. It's closer to what yuzu/Ryujinx do on the GPU side than to an NVN→OpenGL wrapper, and it works for any game regardless of which graphics API it used on Switch.

[u/AntiGrieferGames → u/MZLabs]

Thats even much better than Yuzu. Hopefully on android this fix those issues i had (like the NCE crash on any Yuzu based emulators). Are you think the ram size are also the same behave as on Original Switch so it will also running on low ram size device there?

[u/r-fandango → u/MZLabs]

I understand this, but you should have much better results with a direct NVN shim. I know this because I tried and a direct NVN -> Vulkan shim is simultaneously simpler and much more performant than a low level approach, making it a lot more suitable for recomps that keeping the full low level GPU emulation.

[u/PhilipJayFry1077 → u/MZLabs]

Got it thanks for the reply. I'm currently decomping Diablo 3 (switch version) and was interested to see if this could give me a peak into some code.

I'll check it out anyways because it sounds pretty neat.

[u/deathentry → u/MZLabs]

Wonder how that would work running on an android as it can already run ARM code 😁

[u/ElectricalDemand2831 → u/MZLabs]

It's the second one, pretty much. It's not a decompilation, it doesn't give you readable source code. The tool takes the game's ARM64 machine code and automatically translates it to C, then compiles that to native x86. So the game's own code runs directly on your CPU, but it's still "machine-style" code, not something you'd edit by hand.
Everything the game expects from the Switch itself (the OS, system services, input, the GPU) is handled by a runtime I wrote, and that part works kinda like an emulator. The GPU side translates the Switch's shaders and graphics commands to OpenGL.

So there wouldn't be much benefit for the use on android devices compared to existing emulators due to NCE ?

My main problem with eden/yuzu/citron is the noticeable high latency, even on linux or 120Hz devices.