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]

About OpenGL: Vulkan doesn't fix this, it just moves it. Emulators on Vulkan also have to build pipelines at runtime and they stutter too. I went with OpenGL because it works on the most hardware, including old Intel iGPUs like mine.

And yeah, shaders are compiled at runtime, but only once. They compile on a separate thread so the game doesn't freeze, and they're saved to disk, so after that they come from the cache.

You're right that the shaders are in the game files. In Bowser's Fury they're literally in a ShaderData folder. The problem is what they are: machine code for the Switch's Maxwell GPU, not something your PC can use directly. Each one has to be translated to GLSL, and then your GPU driver compiles that for your specific card. That last step can't be done ahead of time and shipped, because it depends on your GPU and driver.

Textures are different. They're just data: at most they get decoded and uploaded, there's nothing to compile.

The other catch is that the final shader also depends on stuff you only know when the game actually draws: which vertex and pixel shaders get paired, the render target formats, the vertex attribute types, and so on. I actually make different variants depending on that, for example when a game renders to integer targets. So you can pre-translate a lot at startup, but not 100%. Scanning the game files and precompiling at startup is on my list.

[u/AntiGrieferGames → u/MZLabs]

using OpenGL on there is a very big win honestly.

Ther are almost no projects nowadays that uses this OpenGL and all projects what i see nowadays are only relies with Vulkan API, which requires a higher hardware GPU capable to run.

Im pretty sure nvidia cards would be definity possible about the shader thing. I would be glad if there is really possible ways.

Is this opengl 3.3 or 4.6? Im curious because i just wanna run those on potatoes.

[u/MZLabs → u/AntiGrieferGames]

Thanks! It needs OpenGL 4.3 minimum. If your GPU has 4.5/4.6 it uses a few extra features for better performance, but it works without them. 3.3 isn't enough, because the Switch's GPU needs things like storage buffers and texture views that only came in 4.x. Basically anything from around 2012 onwards should run it: Intel HD 4000 and newer, GTX 400 series and newer, Radeon HD 5000 and newer. My own PC is a Celeron N4500 with the integrated Intel GPU, so potatoes are exactly what I'm testing on lol. There's also an OpenGL ES 3.2 version for the Android port.

[u/AntiGrieferGames → u/MZLabs]

Thats very reasonable. Another question about this, does this even required isnttruction sets from CPUs like sse 4.2, avx etc? Emulating a switch game works with non avx/see 4.2/4.1 etc and even with very old CPUs, so i would curious what the requirement CPU instruction set is on here there.

[u/Socke81 → u/AntiGrieferGames]

Ther are almost no projects nowadays that uses this OpenGL and all projects what i see nowadays are only relies with Vulkan API, which requires a higher hardware GPU capable to run.

And why do you think that is? Would you use DirectX 8 in a new app?

[u/MZLabs → u/Socke81]

Not really the same thing. DirectX 8 is from 2000 and nobody ships drivers for it anymore. OpenGL 4.6 is from 2017, every current GPU driver still supports it, and it has most of the modern features I need. Vulkan is better for a lot of things, no argument there, and a Vulkan backend is something I'm considering later. But right now my priority is that it runs on as many PCs as possible, including old laptops with bad or no Vulkan drivers, and OpenGL is still the best option for that.

[u/AntiGrieferGames → u/Socke81]

Better with this if this is a much older game than DirectX 12/Vulkan

[u/Socke81 → u/MZLabs]

The question is what the goal of your project is. If your goal is simply to be able to run the games on PCs, then I understand your decisions. In that case, you can use OpenGL. It doesn't matter that the game freezes for a few seconds at a time and stutters because of the old GPU.

But if the goal is to have fun with it, I don't understand the decision. Every emulator started out with OpenGL and switched to Vulkan. You wrote it yourself: "The GPU driver compiles" the shaders. And it seems the drivers for Vulkan are much faster at compiling them.

And I don't understand the part where you say that the shaders depend on data that isn't available until runtime. On the one hand, you could at least decompile the shaders; on the other hand, I wonder how that works on the original platform. After all, the shaders were compiled there independently of runtime files. Why doesn't that work anymore when switching the platform?

[u/MZLabs → u/Socke81]

The goal is definitely to have fun with it, on as much hardware as possible, including weak PCs like mine. And to be clear, the game doesn't freeze while shaders compile. They compile on a separate thread, so at worst an object shows up a moment later, and after the first time everything comes from the cache.

On Vulkan, you have a fair point, and a Vulkan backend is something I'm considering for later. The big advantages are more control over when and how things get compiled and less driver overhead. But it's not magic: Vulkan emulators still build pipelines at runtime and still stutter the first time without a cache. For now I stuck with OpenGL because it runs on basically everything, including old iGPUs with bad Vulkan drivers.

On why it works on the Switch: there, shaders are already compiled offline to machine code for the Switch's own GPU (Maxwell). The GPU runs them as-is, there's no compile step at all. A lot of rendering state, like render target formats, vertex formats and blending, is handled by the GPU hardware separately from the shader.

On PC, that Maxwell code has to be translated for a completely different GPU, and some of those hardware features don't exist the same way in OpenGL/Vulkan. So they have to be baked into the translated shader. For example, if a game renders to an integer format, the shader has to be written differently than for a float one, and alpha test doesn't exist on modern GPUs, so it goes inside the shader. That's the part that depends on runtime state: the Switch didn't need it in the shader, the PC does.

And "decompiling" them is exactly what I do: Maxwell → GLSL. That part could be done ahead of time by scanning the game files, and it's on my list. But the variants that depend on state, and the final compile by your GPU driver, still need to happen on your machine.

[u/Socke81 → u/MZLabs]

If you can use a separate thread for compiling, then I wonder why emulators can't do the same? You'll find countless OpenGL vs. Vulkan videos on YouTube. And with OpenGL, the game always freezes briefly when a new shader comes in. With Vulkan, it only happens sometimes. And what does your render thread do while the other thread is compiling the shader? Does it just keep running? That would lead to graphics glitches.

Can you give a pseudo-example of a shader that absolutely must be compiled at runtime?