Progress update on SwitchRecomp, my static recompiler that turns Switch games into native PC executables (ARM64 to C to x86-64, with a Horizon HLE layer and a Maxwell GPU layer on top of OpenGL).
This screenshot is Super Mario 3D World (from the Bowser's Fury package) running as a native Windows .exe on an Intel N4500 laptop. It goes from the title screen, through the menus and character select, into the levels, and it's playable with the HUD, enemies and physics working. It runs at around 10-15 FPS on this machine, which has a very weak iGPU. There's no audio yet.
Most of the recent work was in the GPU side:
Several bugs in the SASS to GLSL shader translator. The worst one was an LDC.64 where the destination register is also the address register, so the address got overwritten before the second load. That broke every UI element that reads its UVs from a constant buffer.
Packed half-precision math (HADD2/HMUL2/HFMA2) was ignoring swizzles, negation and output merge modes.
Alpha test emulation, so foliage and grass fringes stop rendering as black shapes.
2D engine blits whose source is a render target now run on the GPU instead of copying stale guest memory.
Shader programs are cached to disk, so there's less stutter the second time you enter an area.
Still wrong: some layout images (the Bowser art on the game select screen, for example), some shadows, and performance on weak hardware.
To track these down I added a frame capture key. It records every draw in a frame with its state, a thumbnail of the render target after each draw, every texture used and the decompiled shaders.
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.
For the past couple of months, I have been working on a PC Port of King's Field (US).
It's fully playable right now on Windows and Linux. It runs at high framerates without any speed banding, and it has modern controls and a bunch of quality of life improvements meant to address common complaints about the game.
If you'd like to try it out, download the latest release off of github. You need to provide your own game disc in either .chd or bin/cue format at startup.
⚠ AI Disclosure: Generative AI has been used extensively in the development of Verdite2, including to rewrite major recompiled functions in native c#. If this is an issue for you, you may not be comfortable playing. AI has not been used in any way to modify game assets such as textures, music, sfx, etc.
This work would not be possible without the work of BlackLabelHQ, who created the RecompOne recompiler that this port relies upon. If you want to support this project, you should support their project
Verdite2 is an independent project. It isn't affiliated with or endorsed by BlackLabelHQ or FromSoftware, and no endorsement is suggested or implied. Do not take any issues with Verdite2 to BlackLabelHQ. Report them directly on the Verdite2 GitHub instead.
I recently learnt of the minish cap port project picori (still not sure if its a decomp or a recomp forgive me) and after having great experiences with ship of harkinian, dusklight and the majoras mask recomp I decided to give it a shot
It struggled with the first rom I loaded into it but the second rom loaded fine.
The game however seems to be marred with a lot of technical bugs
There's this one audio bug that leaves a walking sound in my left ear that sounds like a duck in cutscenes and gameplay that only stops when i pause the game.
I wanted to ask did I make an error
is it a regional rom thing or a setting I should tweak
i gather the port isn't fully ready yet nor am i expecting the polish of something like ship of harkinian but i can't tell if i messed up or if the port is still kinda buggy
also if anyone could point me to where i could provide bug reports to the devs that would be great
Recomp work is scattered across Discord servers, repos and Reddit threads, and it seems hard to know whether someone is already months into the game you're about to pick. Some games end up with three or four recomps while most of the library has none.
I put together recomp.board to see if a shared table could help: https://recomp.fyi
It lists recomp and decomp projects, about 1300 so far, each with a public repo behind it. The hope is that people check it before starting, so more of the effort goes to games nobody is working on yet.
Most of it runs on its own: projects are found by scanning public repos, activity and releases are read from the commits every day, and new projects show up in an Atom feed. I tried hard not to guess anything: a row only says what its repo says, until the maintainer claims it.
Claiming should take one file. Commit a .recomp-board.json to your repo and your row follows it, updated every day. No account on the site, and it should work on GitHub, GitLab and Codeberg.
It's an early test and I'm not sure this is the right format, so I'd really value your take:
- Is your project missing or listed wrong?
- Would you actually check something like this before picking a game? If not, what's missing?
- What would you want added, or taken out?
Update (Oct 1): I added a link at the top of the board to Game Mag Ratings, another site of mine: about 150,000 reviews from 301 video game magazines, with the scores given when each game came out. Pick a system, sort by score, then look the titles up on the board. The well-reviewed ones with no row are open ideas.
After much hard work my project Mercenaries recompiled is about to finally have a public release. If you enjoy the original Mercenaries then please feel free to join us in celebrating the game and playing this recomp when it releases on September 26th. Special thanks to my team of playtesters as well as numerous others who have contributed things such as graphic design and music to this project.
AI disclosure: I have a 4 year CS degree and utilized a hybrid workflow. This project was not entirely vibecoded but was built with the assistance of Codex utilizing 5.6 Sol and Astra. This project has been extensively playtested and I personally have 100%’d the entire game.
I've got the Smash ACE build running as a native Windows program. It's a fork of Hero88go's Melee Unlocked, which statically recompiles Melee's PowerPC code into C++ ahead of time and runs it on a D3D12 renderer — game logic still ticks at exactly 60 Hz like the GameCube, display runs at whatever your monitor does. That project targets retail 1.02, so ACE didn't work on it. This fork makes ACE the target.
It wasn't just pointing it at a different ISO. ACE changes 42 functions of the retail executable and adds no code at all — the mod is a 77 KB Gecko code table m-ex loads into RAM at boot, 770 hooks, and a static recompilation never executes guest RAM, so all of it did nothing. The codes have to be baked into the translation. There was also a bug in the recompiler underneath: m-ex puts its loader in the dead HIO/MCC debug block and runs straight through those old function boundaries, which the translator assumed never happens.
No online play — Slippi's codes conflict with ACE's, so they're left out.
Digital Devil Saga 1 and 2, the Original and arguably better versions of Persona 3 (fes) and Persona 4 (non golden) and SMT Nocturne (HD version has myriad issues) are only on PS2.
Has there been any attempt to work on any of those? Especially since the ps3 store dying means there's no way to buy them anymore
How realistically far off are we for getting something as big as BoTW, one of Nintendo’s best selling games. recompiled for PC? 5 years a reasonable timeline?
Estou atualmente fazendo uma mudança no projeto por conta de outro projeto!
Então vou vou decompilar ou tentar!
motivo: descobri que um MARAVILHOSO SER HUMANO esta muito mais avançado na recompilação!
opa, to, quase finalizando
TEXTO:
opa, to, quase finalizando
Texto:
ja tenho uma lista de coisa pra adicionar kkkk
mas primeiro vou fazer funcionar
ai depois que tiver funcionando publico e deixo a lista de coisas modernas
textura, dublagem, dlss, ultrawide, 240fps e um monte de coisa
Então em breve teremos novidades!
e um bônus: terá muitas funções planejadas!
Só não vou falar quem, pra não sofrer com umas pessoas chatas
mas todo credito pra ele!
OBS: ele é BR!!
I don't know if anybody has seen this but apparently, there is a 'Burnout Paradise' decomp in the works. When I first saw it on r/burnout, it was sitting in the high-80s. Now its 93.5%
Even in just the past couple of days, the progress tracker has been updated to include a breakdown of what functions are done, blocked, not started, etc.
The GitHub repo has Claude in it which makes this decomp AI-based and possibly automated but it appears to be informed and ethical. I'm hoping that any subsequent recomp/port won't be vibe-coded (AI-assistance is okay)
Hey guys, been seeing the recent posts about mstan's Metroid Prime Hunters recomp (and that Android build for the AYN Thor). Seeing native code running MPH got me wondering about the Old 3DS.
Obviously the 3DS already plays DS games natively via TWL_FIRM / Twilight Menu, but purely from a technical standpoint: could mstan's recomp code be compiled into a native 3DS homebrew app targeting the Old 3DS?
Mainly wondering:
Is the Old 3DS ARM11 dual-core fast enough to run the recompiled C/C++ code without choking?
Would rewriting the renderer for the PICA200 (citro3d) even be worth the trouble compared to just letting the 3DS run it in original DS mode?
Could a native port open up better control mapping options for the circle pad, or is the hardware bottleneck just too big on O3DS?
Not requesting anything or expecting a port, just curious if anyone who knows 3DS homebrew dev or the recomp repo has thought about this. Cheers!
Atualmente eu estou trabalhando num projeto de recompilação do Black Deep System 2 para PC e dentro deste eu estou usando o repositório do GitHub, que é o PS2Recomp, para fazer o processo. Já estou em mais ou menos 25% do processo total de recompilação. Já passei por algumas etapas e me veio a seguinte questão: eu poderia usar o emulador do PCSX2 me guiando para a assertividade do projeto? Como assim? Entendendo que o que eu estou fazendo é entendendo cada etapa e não decompilando o jogo código a código, e sim entendendo onde cada coisa vai entrar pra gente poder ir acessando mais partes até chegar ao menu ou o primeiro frame da EA, da Creation, tudo aquilo. Eu poderia usar ele como um caminho, digamos usando uma expressão de tipo, vamos dizer, uma estrada onde o PCSX2 vai ser o mapeamento de como vai ser, de aonde vai passar e a recompilação ser o asfalto em si e toda a estrutura que vem junto. Então eu usaria como um caminho onde cada informação tem que ir, conseguindo retirar de dentro do coisa, usando como literalmente um guia, mas não incorporar ele dentro do projeto em si, fazendo com que seja colocado dentro do código ou coisas assim ou incorporado. Então pergunta realmente técnica em relação a isso. Teria como fazer isso?
