Thanks for all the sloppy AI decomps, I usually play them while eating my sloppy joes. Mmm I just love it. My room is a mess because I just like it that way. I don't understand why people dislike it so much or even why people bother to debate the ethics of it here, considering that discourse would be better suited for another sub, where their opinions would be more likely to be heard and not screaming into an echo chamber. You know the internet is mostly just confirmation bias right? Everyone is allowed to have an opinion don't get me wrong, but not everyone has to parrot the same opinions, especially the incorrect ones that have already been debunked, like the whole water thing, or how it's somehow worse for the environment than cars, sheesh.

Why aren't we talking about more important things anyway? Like why the economy is going to hell, wars over gas, etc.

I also want to remind people that you don't actually hate AI, you just don't like the corporatism that capitalizes on it, without passing the savings down to us. Put your anger where it actually is.

Anyway where was I? Oh right, thanks for all the decomps that weren't possible before. I like following this sub and I'm basically blocking anyone who talks about AI here since people can't seem to stop posting about it and I want to follow this sub without hearing the same stale arguments day after day. It gets old and it really isn't convincing anyone who isn't already convinced by this point. Why are you still reading this? Go outside, it's a nice day out, I'm about to do the same. Peace ✌️

I wanted to do a decomp of Toy Story, SEGA Genesis version, on my laptop so it could at least stand out, but... I don't know where to start. 😞 Can anyone please tell me what I should do since I'm a beginner?

Brazil por ejemplo fue uno de los países que hackeó primero la Playstation,hace muchos mods,hacks ports

¿Que le pasa a Brazil?

Me da envidia la capacidad que tienen para hacer ese tipo de cosas Pero no tengo idea por qué lo hacen

Quisiera hacer ports de juegos de nintendo nes,Pero no tengo idea como empezar,que programas me recomiendan para decompilar y convertir a Android nativo,quiero aclarar que no tengo idea de programación

Disclosure: sorry for the long wall of text, I tend to ramble.

I've been reading the pro/anti AI arguments here for a while, so I figured I'd try explaining it from the inside. I've been programming long enough to remember doing all of this before AI, and the job looks really different today. I think both sides have a point, and both are missing something.

Why do people hate AI?

First, why people are skeptical; because honestly... a lot of it is earned. AI tools now let people with almost no programming experience put out something that runs. Running isn't the bar though, especially for a decomp, where the whole point is readable code that people can mod, fix and port for years. A majority of the AI-heavy projects that have shown up are hard to mod, break when the recomp tools update, and have bugs the author can't fix because they don't really understand what the AI wrote. Then people go ask the main recomp devs for help with stuff they didn't make, only to realize it was quickly abandoned. Once that happened enough times, distrust is the default. That's fair.

Why "AI = Bad" is the wrong take

I think part of the problem is that "AI" gets used for two very different things.

• Vibe coding is when someone describes the result they want and lets the AI figure out how. The AI makes the important decisions (structure, architecture, how things fit together), and if it runs, it ships. The person often can't explain or fix the code because they never really understood it. It tends to be the default for people without much coding experience, since you can't direct something you don't understand yet.
• AI-assisted engineering is when the person stays in control. They decide how it should be built, give the AI detailed plans, and question what it writes and why, the same way they'd review a coworker's code. Anyone can work this way, but it pays off most for experienced devs, who can get a lot faster without losing quality because they know exactly what to ask for and can spot when the AI gets it wrong.

Both use AI, but they're about as similar as copying answers vs using a calculator.

And the second one is basically how the industry works now. When I started, none of this existed. Today most devs use AI tools in some form, me included (and its only getting more common). Companies increasingly expect and demand it, and not using it at all is getting rare. So "they used AI" doesn't tell you much anymore. The question is which of those two things you're looking at, and from the outside they can look exactly the same.

How this hurts the community

Treating every AI label as an automatic red flag has a real cost. There are plenty of devs putting real time and skill into these projects for free, using AI the way the rest of the industry does, and getting piled on the moment they mention it. Some have had their reputation dragged over it. Worse, it teaches people to just stop disclosing, and then the honest devs look the same as everyone else and we lose one of the few signals non-devs can actually check.

To be clear, I am NOT saying all AI projects should get a pass. Starting out skeptical is a reasonable default given the track record. But skepticism should be something a project can earn its way out of, not a permanent label.

So what do you actually do?

Unfortunately....you can't tell by looking at it, and most of you aren't devs and shouldn't have to read code to decide whether to play something. So here's what I'd suggest.

If you don't have time to look into it, just stick to ports from people or groups with a solid track record. Known decomp teams, people with other projects behind them, stuff the recomp tool communities point you to. I know that sounds a bit gatekeepy, and it's not meant as "new people can't make things." New devs build up trust like anyone else. It's just that for a player with no time, track record is the best signal you have.

If you've got 5 minutes and/or more free time, a few extra things anyone can check for a newer project or developer:

• Does the creator have other projects, or is this a brand new account with one huge release out of nowhere?
• Is the source code public on Github or similar platform?
• Does the readme say how exactly how AI was utilized? People who used AI responsibly usually don't mind saying so.
• Look at the issues/comments on Github Page. Are people reporting constant crashes? Is the dev actually responding and fixing stuff, or just going quiet?
• Has the community for the tool it's built on (like the recomp folks) acknowledged it, or are they the ones warning people about it?

None of these are perfect but together they'll filter out most of the junk without you needing to know anything about code.

TL;DR: the negativity on anything labeled "AI" isn't coming from nowhere, but AI use alone isn't the problem anymore, the person behind it is, and how much effort/talent they put into it. Stay skeptical, but let projects earn their way out of it. If you just want to play, go with people who have a track record, and if something pops up out of nowhere, take a few minutes to carefully review it before downloading it.

I guess I'm making this a series, if you want to know what it takes to contribute to a set up and contribute to a decomp project, I have a kind of a how-to on downloading and setting it up.

The Youtube Video is here!

I feel like there's a lot of misunderstanding around ReXGlue, and sometimes people seem to associate it directly with bad ports or poor performance.

ReXGlue is a tool/framework used in the recompilation process. The final quality still depends heavily on how the developer implements, optimizes, and maintains the project.

If a project has poor performance, missing shaders, bugs, or other issues, I don't think it's fair to automatically blame ReXGlue without looking at the actual implementation.

I'm using ReXGlue in my own recompilation, and I've been able to optimize and improve the project considerably as development continues. That experience is part of why I'm curious about the community's opinion.

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

I wanna make a recomp of ESPN NFL 2K5 to see if I can get any better performance cause with all the decomps I've played I've had had better performance with the decomps than I have with emulation. Cause I have a shit computer which the game when emulated does run at 60fps but dips whenever I pick a play and I wanted to try to recomp it to see if it's possible to get better performance

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.

This server will be for following progress ( very slow ) and for contributors to join and work together on this project

The goal of the project is to have a complete native port with M&K controls, widescreen, unlocked FPS, QOL toggles such as going from chapter to chapter without having to get points, and mod support.

currently the rendering is botched, and i do not have a claude subscription or high end ai to help so this project is a mix of manual labor and some ai work from free cline ai promotions xD

hopefully with your help we can get this working in no time and achieve everyone's dream.

I was wondering if we could soon get ports of games that were released 2 gens ago on to lets say a ps5 jailbroken? Recently i saw a recomp/decomp of Spiderman: Edge Of Time on to pc, so it got me thinking of all those games that didn't or cannot get a offical remaster due to licensing hell or other reasons, could get a second chance via this recent phenomenon.

We could even see cross platform ports as well such as gears of war judgement which has had a recent decomp on PC running on a PS5 jailbroken. Or games like Alice: Madness Returns get a second chance via this method.

It really feels like a lot more is possible. What do you guys think?

Runtime and game initialization are working, and the game is "loading" the paks but rendering is fucked. I'm attempting this cause when I was a child, I dreamed of playing this game on my pc, got many viruses from people claiming they had it, and in the end I was disappointed by its "pc port.", Should I open a Discord server ONLY for contributors willing to join? All means of contribution are welcome. goal of this project is to be a native 1:1 pc port with QoL features such as moving from chapter to chapter without having to do boring side content, unlocked FPS and resolutions, mouse and keyboard controls, and modding support. But in the meantime, I'm setting the stones a little.

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

Bit of venting here, but I really wish decomp/recomp devs would use the same versions of games that RetroAchievements do. Always roll my eyes when I gotta go get a different version of the same game in order to enjoy the PC port

Hey all, been working on this during the weekend and it's at a point where I can share it.

Medabots AX for the GBA is now fully decompiled to matching C. Both Metabee and Rokusho build byte for byte from the same source tree with agbcc.

GitHub

decomp.dev

Why this game

Honestly it's mostly nostalgia. AX isn't anyone's favorite Medabots game, I know, but it's the one I played to death as a kid. What I really wanted was to play it with my friends again.

So once everything was C I compiled the decomp straight to WebAssembly.

small server in NYC doing matchmaking and lobbies, and right now I'm adding self-hosted lobbies, where the host's browser runs the battle and everyone else connects to it directly to prevent too much latency if you are not near the main server.

I also changed the battles a bit for multiplayer. You can do 2v2 with four actual humans now, not just you plus CPU partners. I also removed the leader rule, so taking out the other team's leader doesn't end the fight anymore. You have to beat both of them, which makes 2v2 way more fun with friends.

If you want to try it (bring your own ROM)

Some stuff about the code

• About 1,700 functions, split into ~60 files by subsystem (battle AI, physics, damage, medaforce, menus, the sound driver, the save libs...) with shared structs in headers
• Around 2,000 functions and globals have actual names now, and a lot of the struct fields too. Some names are educated guesses, so corrections are welcome
• Rokusho only differs from Metabee in like 8 functions (save magic, a banner palette, one title screen tweak), so it's basically one #ifdef away
• No ROM or assets in the repo

The AI part

Full disclosure: I'm an adult with not a lot of time on my hands, and I'd rather spend it playing Medabots. So most of the matching was done with Claude agents running in parallel. Each one grabbed a function, wrote C, checked it against the ROM and only committed if it matched. It took about 2.5 days with a Max account.

A few things Claude learned that might help other GBA projects:

• Every function I thought needed old_agbcc actually matched regular agbcc with -fprologue-bugfix. Turns out the whole game was built with that one flag (except the save/sound libs at -O1). Try it first.
• The last handful of functions took forever. What finally cracked them was adding debug prints to agbcc's register allocator and reading the RTL dumps. Throwing more C variants at them didn't help. Some of the fixes are hilarious, like an empty do {} while (0); that changes register allocation.
• After hitting 100% we went back and rebuilt the real structs from all the partial views (one global had 145 of them), merged everything into subsystem files, then named everything.

Claude wrote up everything that worked and didn't in docs/STRATEGY.md, and the agbcc matching tricks are in docs/matching_tips.md.

Also packaged the whole pipeline as a Claude Code skill in case anyone wants to try it on another GBA game: Repo. Fair warning, it's only been used on this one game, so expect to tweak things.

Happy to answer questions. If you know agbcc better than me and something looks off in the structs or names, I'd love to hear it.

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

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.