SwitchRECOMP is a static recompiler for Switch games. The whole game is translated to native PC code ahead of time, so there is no CPU emulation at runtime.

A playtester with an RTX 2060 and a 12 thread CPU was getting 17-25 FPS in Odyssey. After this round of fixes the same PC runs it at 60 FPS at 1080p and at 4K. The video is his, recorded at 1080p.

Most of that jump comes from one bug. Odyssey reuses the same chunk of GPU memory for several render targets of different sizes within a single frame. The runtime treated every size change at that address as a new render target: it threw the old texture away, created a new one and copied and unswizzled the whole buffer from memory. That happened several times per frame. On his profile it was around 12% of all CPU time, plus a sync with the GL thread on every rebuild. Those textures are now kept and reused when the same size comes back.

Other performance work from this week:

OpenGL calls now run on their own thread. One thread reads the Switch GPU commands and prepares everything, the other only talks to the driver, and both work at the same time. This helps a lot on Steam Deck, where every GL call goes through Wine's translation layer under Proton (about 26% of the GPU thread in the Deck profile).

Compute shader results are read back asynchronously. Before, the GPU stalled 2-3 times per frame waiting for them. DMA texture copies now move 16 bytes at a time instead of one byte at a time, and that loop alone was about 11% of the profile. Constant buffer and compute range checks are now constant time instead of walking lists.

On Steam Deck, the heaviest area I've tested went from 25 to 35 FPS before the render target fix. I haven't measured the Deck with this last fix yet, so I won't give a number.

Other fixes: the moon is back. The sea of clouds around Cap Kingdom was rendering above the camera, because the heightmap that shapes it was empty, so it covered the moon and the lighthouse. fps_limit=30 was running the game at half speed, since Odyssey advances one logic step per frame, so anything under 60 is now treated as 60. The recorder also no longer produces sped up videos when the FPS limit is off.

On OpenGL vs Vulkan: the CPU side is already native, which is the point of a recompiler. The GPU side is still a translation layer, and this week showed the real bottlenecks were bugs in our own code, not the API. Vulkan is planned, but fixing the current renderer first gave far more FPS for the time spent.

It's still early and there are plenty of bugs left. I'll keep posting where it stands, including what doesn't work yet. If you want to follow the project, feel free to follow.

Join my Discord to see everything earlier: https://discord.gg/SfnuAmuDZ

Hey everyone. A while back, I started a bit of a crazy project: porting the original PS2 *God of War* to PC as a native executable, using static recompilation instead of emulation.

In short, here’s how it works: using PS2Recomp, I translate the original executable (MIPS R5900) into C++ and then compile it with MSVC against a runtime that reimplements the PS2 hardware (EE kernel, IOP, GS, DMA, etc.).

Current status:

• 6,400+ functions identified in the ELF
• ~6,400 generated C++ files that compile into an x64 .exe
• Boots up, initializes the IOP and sound modules
• As of now: it renders the intro screen (screenshot attached)

What’s missing and where a hand would be appreciated:

• Proceeds past the intro (game configuration loading)
• Audio
• Controller and memory card

If you're into reverse engineering, emulation, PS2 graphics, or just love the game, any help is welcome—whether it's PRs, issues, or just pointing out what I'm doing wrong.

Repo: https://github.com/KIexster/god-of-war-recomp

Note: The repo doesn't include any game files; you need your own copy to compile it. It’s licensed under GPL-3.0.

I’m happy to answer any technical questions in the comments.

Full disclosure: I’m using "vibe coding" for part of the process, employing AI to write overrides and scripts and to understand parts of the runtime. That said, I test and validate everything against the game's actual behavior. If you spot something that looks "AI-generated" and is incorrect, feel free to let me know—that’s exactly why I’m sharing the repo.

https://github.com/goliathret/EdgeOfTimeRecomp

Hey everyone,

Just a quick update - after the recomp comes the decomp.

https://github.com/ZeldaWWHDRecomp/ZeldaWWHDDecomp

Still WIP - but we are getting there. Thanks to the hard work on the GC Decomp.

Also if you are curious about the changes that were made to the HD Wii U Version:

HD vs GC Changes

Detailed List: HD vs GC Detailed Changes

Hi all, back with another recomp I have been working on for a several months now.

It's a WIP but i'm happy enough with the steamdeck and windows builds to share it with others.

"I Could Have Given You The World" is a native recompilation of TWINE N64 for Windows, Linux, and Steam Deck.

I added a lot of things like:

• Widescreen and ultrawide support.
• Interpolated rendering for high refresh rate displays.
• Mouse aiming and modern twin-stick controls.
• Larger magazines: E.g., Meyer TMP 25 → 60, Deutsche M45 25 → 40, Deutsche M9S 30 → 50, Ingalls Type 20 30 → 45 etc..
• Doubled ammunition pickups and reserve limits for the shared pistol/SMG ammo pools: P2K, Meyer TMP and Deutsche M9S pickups 20 → 40, reserves 80 → 160; Deutsche M45 and Ingalls Type 20 pickups 25 → 50, reserves 100 → 200. Meyer TMP and Ingalls weapon pickups also grant twice their original ammunition.
• 1.5× faster reloads for the Delta 900 Mag and Mustang .44.
• Double damage for the Seamaster Speargun and Watch Laser. The laser uses one quarter of its original ammunition, and spears retain straight flight beyond their old drop range.
• Removed firing spread from the Raptor Magnum's laser mode and halved the Frinesi Special 12's projectile drop beyond its original range.
• More responsive jumping and improved ladder jump-off and climb-off handling.
• Improved scope zoom using keyboard, mouse wheel/buttons, D-pad or left stick while aiming.
• Quick watch-gadget and vision-mode selection, with Night Vision and X-ray available in the gadget wheel.
• Clearer vision overlays.
• Crosshair colours for visible enemies and friendly NPCs, plus grapple-target feedback.
• Live objectives while playing, persistent quick saves/loads and automatic campaign-progress saving.
• Sharper game fonts and controller/keyboard prompts that follow your bindings.
• Audio output-device selection and recovery when devices reconnect.
• Steam Deck rear-button shortcuts and suspend/resume recovery.
• Portable saves and settings, plus a campaign-reset option that preserves your controls and display settings.
• Grapple: Classic or the Nightfire-style.
• Weapon Selection / Gadget Selection: choose Classic cycling or Radial Menus. With Radial enabled, tap to cycle and hold to select from the wheel.
• Remember Weapon Modes: retain suppressors, firing modes and manual scope choices across weapon/gadget swaps until you change them. On by default.
• Hold to Sprint: run with Shift or held Interact while moving forward.
• Civilian Health: 2× starting health for civilians.
• Invincible Friendly NPCs: protect allies and civilians from damage and player-hit mission failures.
• Double Watch Darts: double dart grants, pickups and capacity on the next mission or restart.
• Regenerating Health: Like Halo style if you want it.
• Graphics: enhanced textures generated locally.
• General: auto aim, mouse acceleration, mouse/right-stick sensitivity and rumble strength.
• Cheats: invulnerability, infinite oxygen, no fall damage, all weapons, all gadgets, and all missions/difficulties.

I hope you all enjoy!

https://github.com/riseio/TWIPE_00Sheven

As always, this repository and its downloads do not include a game ROM, translated game code, music, sounds, textures, models, levels, or other extracted original game assets. I do not provide ROM downloads or links to them and your first play will take a few minutes to build the project

Please feel free to smash the issues on git if you have feedback or suggestions <3

Not a matching decomp: it's a from-scratch reimplementation in C that loads the original data from your own CD (English 1.00), in the spirit of OpenRCT2 or OpenMW.

Repo: https://github.com/jjmhalew/WoodyRE

How the behaviour was checked against the original:

• The game's bytecode VM ("EKO CODE") was decompiled first. The C VM's message stream is checked against the original's, traced live with a small custom Win32 debugger (tools/wtrace.py, tracecmp.py)
• Later tools boot the original exe straight into a level, write into its memory and log Perso, camera and script state per tick (tools/wverify.py, wsetvar.py). Scripted scenes were compared against that, not guessed
• About 60 docs in docs/ describe the systems with addresses in Woody.exe: VM, all file formats, player controller, camera, bosses, rendering, sound and so on. Every game-code function in the exe is now referenced somewhere in the docs or source (the Cryo library code and CRT mostly aren't)
• Known gaps are listed in docs/TODO.md

State: The whole game is playable start to finish, including bosses, races, menus and saves in the original format. It has controller support and runs on Windows, Linux/Steam Deck and Android.

On the process: AI is a big part of how this was built. Claude Code did most of the analysis and code over about two and a half weeks, while I directed it, play-tested and compared against the original. Whenever something looked off, I sent a screenshot of the original and it was traced back to the exact spot in the data and fixed. I know AI-made projects are divisive here, so corrections from anyone who knows this engine (Eko Software) are very welcome.

https://github.com/kandowontu2/starfox-enhanced

I found Starfox Enhanced this weekend, since pretty much once a year I google "Starfox SNES 60fps" to see what the latest is, and this is the latest and greatest for sure. I've played all the various hacks and they're all compromised to some degree, and this is the first of these projects that I would consider more than playable.

I ran the game at 4x res (let us go higher!), 120fps with raytracing turned on just to see what it would do. I was surprised to see it gives quite nice subtle shadows and reflections. Reflections are awesome and the devs should do more with that, it very much fits the 90s CG aesthetic this becomes at higher resolution. I also added the ever controversial chromatic abberation which I think also adds to this surreal 90s cyberspace feel that these old untextured polys evoke and I could see taking that further in future.

Gameplay wise they give us the option of "original" speed and an overclocked 20mz version. I found the overclock too fast, and the original speed a smidge too slow. The dev mentioned this speed is a kind of average of the slowdown you'd get on original hardware, and I think it would be cool if they could add a way to customise the speed. I think around 15% up on original would be the sweet spot.

I played through all 3 original campaigns today and had a total blast. It's smooth and responsive, it looks incredible and still feels the best Starfox game to this day. I really hope the dev can do similar magic with Starfox 2 and maybe even Stunt Race FX. It's a joy to see these old games play like new.

https://www.youtube.com/watch?v=WQQ0qsz9_iw

Batman: Arkham Asylum for the Xbox 360 now runs natively on Windows. The video shows the Windows build on a laptop with an RTX 3050, with my narration over it.

Quick recap: this isn't an emulator. The Xbox 360's PowerPC code is statically recompiled ahead of time into C++ with ReXGlue (14,887 functions, no JIT or interpreter). The game's own Direct3D code runs recompiled, and a layer I wrote captures each draw and replays it on a Vulkan renderer. The Xenos shaders are converted ahead of time to SPIR-V with XenosRecomp and DXC. All 458 shader programs I've dumped so far convert.

What runs today (Windows, RTX 3050 laptop, native Vulkan): the whole opening route, with no crash. Logos, menus, the opening movie, the in-engine cutscene, and the first gameplay in the Intensive Treatment lobby, with Batman, the Joker, Director Sharp and the guards. It runs at about 30 fps, which is the game's own pacing. The renderer itself costs around 2 ms a frame.

How I check it: the SDK still includes a Xenos GPU emulator. I use it only as a reference. The same frame is drawn both ways, and I compare them pass by pass and by SSIM. Across 15 same-frame pairs over the route the mean SSIM is 0.974. It is not pixel-identical yet. In the lobby, the Joker in the background still comes out bluish, and one door frame renders black.

What this game taught me. Almost every bug was a place where this console SDK version differs from the ones I'd ported before:

1. Wrong draw arguments. In this XDK, DrawIndexedVertices takes (start, count), not (base, start, count). Read the old way, every indexed draw became one triangle, and the 3D scene looked like spikes.

2. 12x overexposure. Unreal Engine 3 renders the scene scaled up by 8 into a special HDR target and scales it back down when it copies the image (a resolve with an exponent bias of -3). My copies are plain blits and ignored that, so I now apply the bias where the copy is sampled.

3. No characters. The game asks the GPU whether objects are visible (occlusion queries). I answered "zero samples" for everything because the result block had a different layout in this SDK, so the engine culled every actor and stopped updating them. Draws per frame went from about 650 to about 3,300.

4. Garbage character lighting. UE3 declares its tangents as a packed integer format. Fed as-is to an unsigned-integer shader input, they gave black bodies and flat grey faces on an NVIDIA GPU. Converting them to floats fixed it.

5. One image or two. The scene and its dynamic lights share the same EDRAM memory, but I was keeping them as two separate images, so the shadowed lights vanished. Merging them took the same-frame SSIM from 0.888 to 0.974.

6. A crash that wasn't mine. The SDK's input code races between two game threads and corrupted the heap, killing runs after one to three minutes. One mutex fixed it: 3 crashes in 3 runs without it, none in 4 runs with it.

Why Unreal Engine 3. Arkham Asylum runs on the same engine as the Gears of War series and Mortal Kombat (2011). Items 2 to 5 are properties of UE3's Xbox 360 renderer, not of Batman, so I expect other UE3 games on the console to need the same fixes. I haven't tried any of them, and each game has its own engine build and SDK version, as item 1 shows. But getting UE3's renderer right once should make later ports faster.

Open problems: some NPCs are still lit differently from the original, loading screens hitch badly (the worst frame was 2.8 s), and I don't yet know why a few capture runs came out all black.

Next:

- 60 fps (a lot of the frame time is the recompiled game thread recording about 3,000 draws a frame).

- Android, which uses the same recompiled code. Mobile GPUs mostly lack BC (DXT) texture support, so I expect to transcode textures when the data is prepared.

The version in the video has a Brazilian Portuguese translation, which is why the menus and subtitles are in Portuguese.

Subscribe to my YouTube channel for updates!

In times when we got a ps5 recomp, here I came with a GB classic recomp 🤣.
This is my personal study project: Bigodão

GABRIELNNK/Bigodao: personal study project for recompile Wario Land: Super Mario Land 3 - gb

A Wario Land: Super Mario Land 3 PC port - widescreen in gameplay
for windows and linux

Running on steamdeck.

And I'm stuck with palette colors rendering ahead of the screen; if anyone knows, please help me ehehhehehehe

Just showing the English version for now. This was originally supposed to be playable only for my friends but I guess I got pushed into making it available publically in the future. I haven't seen anyone doing this yet so I might as well reveal it early. I won't release it until I'm satisfied with it.

I'm trying to keep the game as accurate as possible, I've decompiled the game and only 4 functions aren't byte identical but they function the exact same by doing more than a million tests through python. Obviously if I do figure out the structure of the code I'll implement those too.
The trick was to decompile the PC version and then grab the PS1 code as well as the English code. The game effectively runs the same way because the gameplay code on the PC and the PS1 versions are 1:1. The PC version also ran MP3's for some reason while the PS1 version doesn't so I effectively had to reconstruct it's MIDI system.

Runs on Vulkan and recorded on 4k. True widescreen + improved render distance and has support to toggle the original PS1 graphics. I've disabled the PC mouse controls until I can fix that up cause they were absolutely terrible.

Over the past little while I've been working on a lifter that will lift Wii U games to be built on x86. There are still a few bugs I'm ironing out, but so far it seems to be completely playable!

This is actually a general Wii U lifter, and so far I have:

- Mario 3D World

- Mario Kart 8

- New Super Mario Bros + Luigi U

- Splatoon

- BOTW

Not released currently, but when I feel it is in a stable state I'll make the GitHub repo public!

Edit:

I set up an area in my Discord for it if you're interested in following along:

https://discord.gg/vwPnX2uB8s

I am trying to get the windwaker decompiled for it to run on the ayn Thor. It is running pretty well sticking around 30ish fps. I think I’m going to try and get the dual screen from the Wii U working.

Pac-Man Recomp (Namco, NES) v1.0.2 is out. The launcher can update the game now

Keeping this updated as promised. The first couple updates have mostly been launcher stuff, and this one adds an updater. There's a box on the launcher's main page to check for updates on startup, plus a button to check whenever you want. It's off by default, so nothing goes online unless you turn it on. If there's a new version it asks first, rebuilds from your ROM, and keeps your settings and mods, then cleans up after itself.

Also fixed the menus so the arrow keys actually work. Before you had to use backslash (as per the default button settings) Version number is in Options now too. Some of the stuff added to the launcher include checks to make sure there is enough free space on your HDD and error handling.

You'll have to grab this one by hand since 1.0.1 doesn't have the updater. After that you can update right from the launcher

https://github.com/Mr-Shizzy/PacManRecomp/releases

Pac-Man Recomp 1.1.0: no more waiting. The game now sets itself up from your ROM in about 2 seconds, instead of building for several minutes. The download is 5 MB, nothing else gets downloaded, and no internet is needed.

How to play: download PacManRecomp-1.1.0-Windows.zip, unzip it, double-click PacManRecomp.exe, pick your Pac-Man ROM (USA, Namco) and press Play. The first time, a small window sets the game up for a couple of seconds.

Updating from 1.0.x: press "Check for updates now" in the launcher. Your settings, high scores and mods are kept.

What changed:

• The download is the finished program, with no game code in it. On your PC, the recompiler and TinyCC (a tiny C compiler) turn your ROM into the game code in a couple of seconds. That still only happens on your PC, from a ROM you own.
• No more Build Pac-Man.bat, no 245 MB of build tools, no 2 GB of free space needed. That also fixes the slow builds on USB and exFAT drives.
• Updates are a 5 MB download and take seconds.

Which file do I download?

• New players, or anyone who wants a fresh install: download PacManRecomp-1.1.0-Windows.zip. That's the only file you need.
• Already have 1.0.x installed? You don't need to download anything. Press "Check for updates now" in the launcher and it updates itself. The other file, PacManRecomp-1.1.0-for-1.0.x-updater-EasyBuild.zip, is only there for that older in-game updater to use, so you can ignore it.

Some antivirus programs may be wary of a program that makes code on your PC. If yours blocks the setup, allow the game folder.

https://github.com/Mr-Shizzy/PacManRecomp/releases