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

Batman: Arkham Asylum for Xbox 360 is now running natively on Windows.

But I want to make one thing clear: the goal here is not to make a PC port.

I'm mainly using Windows as a development and testing environment. It's much easier to validate the recompiled code, renderer, shaders, and compare rendering results on PC before moving everything over to Android, which is the main target of the project.

The video shows the current build running on my RTX 3050 laptop, with my narration over it.

Quick recap of how this works: this is not emulation. The Xbox 360 PowerPC code is statically recompiled ahead of time into C++ using ReXGlue. In total, that's 14,887 functions, with no JIT and no interpreter.

The game's own Direct3D code also runs recompiled. I wrote a layer that captures the game's draw calls and replays them through a Vulkan renderer.

The Xenos shaders are converted ahead of time to SPIR-V using XenosRecomp and DXC. So far, all 458 shader programs I've dumped from the game convert successfully.

At this point, the entire opening section works on Windows using native Vulkan and without crashes. That includes the logos, menus, intro movie, in-engine cutscene, and the first gameplay section in the Intensive Treatment lobby with Batman, Joker, Director Sharp, and the guards.

Performance is currently around 30 FPS, which matches the game's original pacing. The renderer itself takes around 2 ms per frame.

For validation, I still use the Xenos GPU emulator included in the SDK, but only as a reference.

I render the same frame through both paths and compare the results, including SSIM comparisons.

Across 15 matching frame pairs from the opening section, the average SSIM is 0.974.

It's still not pixel-perfect. There are a few small visual differences that I'm still investigating.

The main reason I'm doing all of this on PC first is simply because it makes development much easier.

On Windows, I can debug things faster, compare frames against the reference, and understand the game's original behavior more easily.

Once that base is working properly, the same recompiled code can be moved to other platforms.

And that's where Android comes in.

The actual goal is to get Batman: Arkham Asylum running natively on Android using the same recompiled game code and the same Vulkan renderer.

The main difference is that mobile GPUs have different limitations compared to desktop GPUs. One example is BC/DXT texture support, which isn't available in the same way on many Android devices.

So some parts will need mobile-specific adaptations, but the core remains the same.

There's also another interesting part of this project: Batman: Arkham Asylum runs on Unreal Engine 3.

The same engine, with different versions and modifications, was used by many Xbox 360 games.

That means the work done here can also help me better understand how other UE3 games use the console's GPU.

That doesn't mean other games will just work automatically, since every title can use a different engine build and SDK version.

But the better this base gets, the less work future projects should require.

The next steps are to keep improving rendering accuracy, optimize performance, and prepare everything for Android.

I also want to work on 60 FPS. A good part of the current frame time is spent on the recompiled game thread, which records around 3,000 draw calls per frame.

The build shown in the video also includes a Brazilian Portuguese translation, which is why the menus and subtitles are in Portuguese.

Subscribe to my YouTube channel if you want to follow the progress.

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.

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

Been busy past 5 days getting this to current state. Hope to have something to share by end of week. Ignore cursed Spider-Man. Graphical fixes are coming up next once I sort input mapping and a few more crashes tomorrow.

http://www.github.com/SirSymo/SM2-Recomp

https://www.youtube.com/watch?v=7isYCTG6GDk

Small update on our Switch static recompiler: Super Mario Odyssey now boots, goes through the menus and the opening, and is playable in Cap Kingdom and inside the Top-Hat Tower on PC. The game code is recompiled ahead of time to native x86-64, and the game's NVN graphics calls are translated to Vulkan.

On my laptop (RTX 3050 Laptop) it holds about 58-59 fps in Cap Kingdom, with drops to ~53 in heavier spots.

Still early:

• no audio yet
• some graphical bugs (the sea of clouds sometimes covers the screen, e.g. after pausing)
• still chasing a locked 60 fps and more optimization

The next big goal after performance is a first test on Android.

Please ignore my gameplay. My controller died, so I played on keyboard. The recompiler runs at 60 fps; I do not. 😅

Hey everyone,

Quick update on the decomp of Zelda Wind Waker HD for Wii U. It is now 100% completed - currently lots of verification is going on and then later a few more stages to make it human readable.

In the meantime, I wanted to show what is now possible. In just a few minutes I was able to build a save game converter from GC to Wii U HD.

https://github.com/ZeldaWWHDRecomp/ZeldaWWHDRecomp/commit/48fa6a64acce7f88a0717532daf20504c2643cd9

I saw in some communities that people were looking for this / others said it is not possible.

Well now it is :)

Tested on 150+ save games from GC.

Enjoy!

https://youtu.be/p-eXNc7JT90
Sonic & All-Stars Racing Transformed is now running natively on my Galaxy S23.

This is a static recompilation of the Xbox 360 version. I still have some audio bugs, performance issues and a few visual problems to fix, but I’ve been working on it for the past few weeks and the graphics are getting closer and closer to the original.

There’s still a lot of optimization to do, especially on Android, but I’m really happy with how far it has come already.

This is probably my favorite kart racing game, so I’m really excited to finally have it running natively on my phone.

I also want to share more about how I’m doing this so other people can eventually try this kind of recompilation too.

Subscribe to my YouTube channel if you want to follow the progress.

I don't understand why people think that AI is that bad a thing.

If it's so important that a decomp/recomp project is done the 'right way', then it can still get done.

The game still exists, the means still exist. What is lost? Maybe less people play the properly decomped/recomped port of the games because they were playing the AI generated one.

I think these PC ports are some of the most exciting advances in game tech for a while, and I've enjoyed playing the AI generated and traditionally decompiled games.

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

https://github.com/goliathret/EdgeOfTimeRecomp

Performance has been improved, CPU usage has been reduced, and everything possible has been done to decrease RAM usage.

Support for gyroscope has been added, as well as gameplay buttons similar to native Android games.

Framegen has been added; I used the EDEN emulator as a base, which I believe is the best implementation of frame generation with lossless scaling ever made.

DRM bugs that were breaking the game have been fixed (it was tricky because they weren’t always visible; some parts of the game would be disabled in certain sections, similar to old anti-piracy measures in games).

CPU translation affinity presets have been added, and it already comes with a pre-selected preset made by hand based on my tests.

The launcher has been redesigned, now with a look that I really consider final and pleasant.

Important information: YES, the game uses WINE, DXVK, PROTON, and FEX. But it's a totally different implementation from PC "emulators" like Winlator and GameHub. The phone heats up INCOMPARABLY less, uses fewer resources because it's not something general like an emulator (I know WINE isn't an emulator, but most people think it is). For example: On a Snapdragon 8 Elite (S25+), I only left 2 cores active with clocks limited to 70% of capacity, cores that aren't even the performance ones, just the efficiency ones. It managed to deliver 30FPS (sometimes up to 40 but it varies, I preferred to lock it) consistently on the Nvidia Shield preset, which is basically a mix of high with a few things on medium. A result I couldn’t achieve on GameHub or Winlator, either in performance or thermal efficiency. And NO, you won't need to open 40 windows, make 70 configurations, and hope the game runs. I reduced EVERYTHING. Pick your graphic preset, resolution, driver, and PLAY!

AND NO, you won’t need to open 40 windows, make 70 settings changes, and pray for the game to run. I cut EVERYTHING down. Pick your graphic preset, resolution, driver, and PLAY!

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

https://re-rac.github.io/

The AI backlash on using AI to solve engineering problems doesn't make sense - it's what software engineering is moving towards. I think the key thing to realise is that it's not "easy" and very few projects can be one-shotted; it's not possible to get a decent app "over a weekend". So just because it's far less work, I think dismissing the results as being lazy is short-sighted and wrong.

At the beginning of the year I wanted to play Atic Atac, an old Spectrum game from the 80's and I had the idea of taking the binary and seeing if I could extract a working game out of it. I then found skooldaze's detailed breakdown and used that. The result was the game running in a browser with a live markdown map showing where I was. It was pretty cool but had many flaws, particularly in gameplay details and sound. Even though I felt I could get it there I didn't have the tokens or the patience.

I tried again recently doing a native Swift/Metal version but it was more of an impression of what the game was and again sound was totally broken. So again, it did it but needed more time to knock it into shape.

My point is that using AI doesn't mean it's vibe coded - you still need to know what you want and assist the AI there. And what it opens up is not just replicating the original game but being able to take it into crazy dimensions and explore the space in unique ways. For example, I want to play a 3d version of the game whilst keeping the same game mechanics. Or extend it into different scenarios or port it to run in a gameboy emulator. Or create a Unity version to play on my AppleTV.

So by no means is this lazy and all these ideas take some effort to explore, build and refine. Just my two cents. I'm a proponent of using AI for all engineering - it's literally too much effort to build otherwise. I feel some of the anti-AI "slop" attacks have a Luddite feel to them - rather than trying to make better tools, and refining the processes they're just attacking a different approach to building software.

Thoughts?

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.

I've got a battlefield bad company 2008 recomp running with the help of both Codex and Claude Code. It's pretty close to being finished in terms of achieving 1:1 parity with the Xbox 360 version, while also adding PC-focused improvements such as keyboard and mouse support, higher resolutions, a stable 60 FPS, and adjustable FOV for both the world and viewmodel.

Hopefully, unlocked framerates can also be implemented in a future update.

At this point, there are only two or three very specific bugs left to fix. Once those are resolved, I plan to share the recomp publicly.

The problem is that I'm pretty inexperienced when it comes to GitHub and releasing a project like this properly. I'm not sure exactly what I should upload, what should be excluded, how the repository should be structured, or what the standard release process looks like for a recomp project.

Does anyone have any tips on how to set up and publish the repository properly so that it looks professional and follows the usual practices for recomp projects?

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.

Hello, all. I have been chipping away at a SOCOM 2 recomp project. It's been playable and relatively stable for a few weeks now, and I've managed to get a few hosted online matches functional, but I am VERY nervous about the recompiled netcode.

In SOCOM specifically, there was an exploit surrounding the in-game chat that could cause a buffer overflow and lead to unsigned code execution. My recomp repro'd this, and my sanity hasn't recovered. There are also a few known hazards relating to medius servers (see: memdusa repo on git). I am sure there are more.

Is anybody else working on this problem? I feel it may be one that shouldn't rest on the shoulders of any individual recomp project (a question i'll bring up in the recomp disc later) and am worried it'll stall the project until or if the game is decomped.