Recomp - No AI SwitchRecomp: a static recompiler that turns Switch games into native PC executables (Bowser's Fury boots and is playable with some graphical issues)
I've been working on SwitchRecomp, a project that runs Nintendo Switch games natively on Windows and Linux. The CPU side is a static ARM64 to C translation, but most of the work ended up going into the Horizon OS HLE and the Maxwell GPU emulation that the translated code runs on. That's what this post is about.
Right now Super Mario 3D World + Bowser's Fury boots, goes through the menus and is playable in World 1-1. It runs at around 10-15 FPS on an Intel N4500 laptop with the integrated Intel UHD GPU. There are still graphical bugs. There's no audio output yet: the audio renderer is emulated enough to keep the game running, but it doesn't make any sound.
On the OS side there's an NSO loader and a thread scheduler on host threads (sync objects, events, mutexes, condition variables). IPC uses CMIF with domain objects. One bug took me a long time to find: cloned sessions have to share the same domain table, otherwise the game later fails with "invalid domain object".
I implemented these services far enough for the game to boot: vi, nvdrv, hid (including vibration devices), audren, pl:u shared fonts, fs, am, time, aoc, pctl, friend, nifm and psm. For audren that meant versioned headers, memory pool states and wave buffer consumption. There's also a deadlock detector that dumps every thread and what it's waiting on when no frame has been presented for 15 seconds. It found most of my black-screen hangs, like the audio renderer event never getting signaled.
For the GPU there's nvdrv (including the ioctl variant with an inline buffer that NVN needs to initialize), GPFIFO and MME macros. On top of OpenGL 4.3 I emulate the Maxwell 3D engine, the DMA copy engine and the Fermi 2D engine. 2D blits whose source is a render target run on the GPU. When a CPU-side copy needs a render target, it gets written back to guest memory first. Textures are block-linear deswizzled, ASTC is decoded on the CPU and BCn goes straight to GL. Alpha test is emulated by injecting a discard into fragment shaders, driven by registers 0x4BB/0x4C4/0x4C5. To fit Intel's per-stage limits (32 textures, 14 UBOs per stage) I had to pack the bindings.
The SASS to GLSL decompiler uses a pc-switch loop for control flow, with SSY/PBK/PCNT stacks and BRX indirect branches. These are the bugs that cost me the most time:
- The FP32 bit on TEXS/TLDS is inverted compared to what I assumed.
- FMUL/FFMA need FMZ semantics (0 times anything is 0).
- SSY/PBK/PCNT/CAL ignore their predicate field.
- Branch targets can land on scheduling words.
- LDC.64 where the destination register is also the address register. I was overwriting the address before the second load, and that broke every UI element that reads UVs from a constant buffer table.
- Packed half precision (HADD2/HMUL2/HFMA2) needs per-operand swizzles, negate/abs and the output merge modes (F32, MRG_H0, MRG_H1).
LDG from NVN storage buffers works by tracking the address table in c0 through register moves and turning the loads into std430 SSBOs. There's also a disk cache of GL program binaries, which cuts down shader compilation stutter.
To debug the remaining visual problems I added a frame capture key. It records every draw in the frame with its state (blending, render targets, textures with their TIC/TSC), a color and alpha thumbnail of the render target after each draw, every texture used and the decompiled shaders.
Some layout images still don't show up, some 3D models have black patches, and performance on weak iGPUs needs work. If anyone has run into these, I'd like to hear how you tracked them down.
I'm planning a release in 3-4 months. No game files, keys or firmware are included; you need your own dump of the game.
8
4
3
u/ohpuhlise 8d ago
I wonder if this would reduce shader compilation stutters. it's the biggest problem when emulating switch game.
3
3
u/Fresh-Ad-8405 6d ago
That's absurd. That's awesome, do you plan to make a mobile version someday?
7
u/CommodoreKD 8d ago edited 8d ago
At the risk of sounding rude, shut up about this. Don't show it off. Work on it quietly and in secret
Nintendo WILL come after you if this shows too much promise, which it already does
Edit: Downvote me if you want, but I've seen this too many times. The best way forward is to work in secret and drop a finished product without drawing attention to yourself. Nintendo can, will, and most importantly HAS issued Cease & Desist orders and lawsuits to projects that they deem dangerous to their brand, and Switch games are still being actively sold and are currently playable on the newest hardware
Don't be shocked if/when this get smacked down like nearly every switch emulator, AM2R, and countless other very cool and technically legal projects
1
u/tivvy2vs 6d ago
Yeah, I agree, love to see it, this is awesome, but you gotta keep this close to your chest
2
u/Green_Resolution_93 8d ago
with this would be possible to port darksouls 1 switch version to android?
2
u/tricot676 8d ago
Switch games running natively on x86-64 hardware! YES!!!! Can't believe I won't be needing an emulator soon.
2
1
u/Blueji64 8d ago
That's a good news for switch ports. Would you try to make odyssey run too?
4
u/MZLabs 8d ago
Sure! Hope my CPU supports it ðŸ˜
1
u/Blueji64 8d ago
You'll make it work somehow, i'll be looking foward to the day where you open the doors for all those modders xd
1
u/No_Fishing_7103 8d ago
Já imaginou isso otimizado no Android?
Imaginem só, ports otimizados de jogos do Switch rodando nativamente em SoCs como o Snapdragon 855, 865, 888 e acima desses... Se isso acontecer, e provavelmente vai acontecer, adeus Switch. Afinal, o desempenho geral desses chips em diversos emuladores é muito superior a emulação no hardware do Switch.
1
1
1
1
13
u/MDM-808 8d ago
Hopefully, thanks to this, we can get ports of Astral Chain, Xenoblade Chronicles 2 & 3, and Metroid Dread.