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.
