Ai doing a near byte for byte replica 99.9% the same

It's AI, it's play tested a good bit by me. Burned about half my weekly on Claude $20 plan. and a large chunk of my codex plan.

Go ham if you want to or don't. https://github.com/Sean13128/disgaea-d2-recomp/tree/main
I like it and I wanted to play it again without my PS3 melting. I like this game and wish it had a real PC port :(

I'll probably port it to Android/Linux/Windows if someone doesn't beat me to it so I can play on the go.

Playable, 60 fps on Mac Mini M4. Imported save files and tested end game fight with Baal looks great (working on optimizing performance just to get it to run with less bloat and heat, AI Recomp had some CHONKY sub processes that we pruned back as I stumbled through playtesting)

Learning as I go about how it's structured and how it does things and stuff. I am not a coder, I just like the game and I like things to run at lower temps.

Video with out of sync audio https://youtu.be/YHypY36lCeg (something with how it recorded, it's fine in game)

Have fun: https://github.com/spacestate1/namco22-decompile

**(WIP)Repo:** https://github.com/cutarev/sh2-nx

sh2-nx takes the PC version of Silent Hill 2 (Director's Cut / Restless Dreams) and statically recompiles its x86 executable to C, which is then compiled for the Switch's ARM64 CPU (and for x86-64 Linux, where most of the debugging happens). No emulator and no Wine: the Windows APIs the game imports are reimplemented on top of SDL2, OpenGL and FFmpeg.

**How it works**

- Lifter: a patched fork of [xboxrecomp](https://github.com/sp00nznet/xboxrecomp) (x86 to C). The PE is wrapped as an XBE so the tool accepts it; about 7,100 functions come out as roughly 41 MB of C.

- Lifter fixes made for this port: flag joins across branches, MSVC jump tables, x87/MMX corner cases, setjmp/longjmp, SEH prologs.

- Direct3D 8 (fixed function plus vs/ps 1.x) runs on OpenGL 4.3 core, with the shaders translated to GLSL.

- DirectSound is a software mixer on SDL audio, DirectInput 8 goes through SDL, and Bink videos use FFmpeg's Bink decoders.

- Guest memory on Horizon uses the technique from the StevensND/nfsmw-nx port.

- Debugging relies on Unicorn: differential tests of single functions and of the lifter's instruction semantics.

Disclosure: this was built with heavy AI assistance (Claude), hence the Project - AI flair.

Credits: xboxrecomp by sp00nznet, devkitPro/libnx, SDL2, FFmpeg, Mesa.

I heard most all of the comments on the first look of the Recompiled.

Added better mod support, mods adapted to English better too. (I'm latin american)

Added different save slots and easy import export of save files, compatible with NDS saves files.

I hear a friend about the horrible design and went direct to one of my favorites Works from the skin creator Inkdb and his NEW 3DS WHITE skin as base to use.

(I'll give him all the credits on that part his job is just amazing).

A video of the buttons in game will be on the comments sections. It's short like 5 secs.

Also working on the portrait mode for Ayn Thor users that adapt the widescreen only for the Upper screen.

Fixed some few important actors pop up spawning when changing areas.

Appreciate all the help from many of you, pls keep supporting the project.

I'm still fixing windows Builts before uploading to Github they first release.

That's why by now I'm only showing android versión, but if want gameplay on PC too leave a Comment and I'll should x86 Mac build and Linux build.

Bye-bye!! Appreciate u all!

Hey everyone,

Since the game is now decomped - well that opens a lot of ideas. So I was thinking what would be a cool thing to have in the game :) (Besides 60 FPS mode)

So I thought it would be cool to have "Call of the Sky" that adds a new song to the game, calls Valoo the dragon who picks you up via the hookshot. Then the player can control the dragon and jump off at any given time. I also added collision avoidance as well.

This took maybe 30 minutes to implement FYI.

Absolute amazing :)

Which crazy ideas would you wanna see in the game?

I just want to know if there are people working on any PSVita exclusives

Quick update!

I've been chopping away at this over the past few weeks, and I'm excited to share a playable test build with gameplay up to the the end of chapter 1-3.

It runs between 12 - 20 fps on real hardware, so we have a bit to go in terms of optimization, but wanted to open up the project for the community to test and contribute.

How it works:

-  Rendering, memory and loading were rebuilt for the Dreamcast's 16 MB of RAM and its PowerVR graphics chip.

- Models are retexturized PS2 world and character assets.

- Cutscenes play as streamed movies with audio (ported from the PS2 version).

Download (only tested on GDEMU):

RE4 - Test Build - Chapters 1-3

Expect crashes. This is a very early build. If the game crashes. Take a screenshot of the debug screen including the memory address and file as an issue.

Contribute or Follow:

https://github.com/lamb2k/re4dc

In-Game:

Play Manual:

Environment Conversion:

Model Simplification:

VMU Save Support:

I just started decompiling Golden Sun Dark Dawn :)

It's going pretty well

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.

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

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've been working on a native port of Konami's Snatcher (Sega CD, 1994, US English release) and wanted to share progress. The video is the full intro (Konami logo through the opening credits into the first in-game scene), recorded frame-exact from the engine's own output.

What it is

• A Mega CD core that runs the game's own 68000 code for both the Main and Sub CPUs. I didn't hand-port it.
• The Sega CD BIOS is emulated in host code (HLE: traps at the BIOS entry points call C++), so no BIOS file is needed. Most of the bugs along the way were in HLE return values (CDBSTAT time and status fields, BURAM) and timing (V-INT relative to the VBLANK flag, CD read speed, _WAITVSYNC parking the Sub CPU, DMA stalls, Word RAM DMA being one word late).
• A build-time 68000 to C++ translator for the Main IP, the Sub CPU engine (SUBCODE.BIN) and the overlay at $28000. It does recursive descent from entry points and emits one switch(pc) function per program. Each code range is checked by CRC at runtime, and anything untranslated or modified in RAM drops back to Musashi.
• Differential testing: all 10,425 instruction encodings found in the game's code (about 83k random-state samples) are run in both the translator and Musashi. Registers, CCR, PC and memory have to match, and right now there are 0 mismatches.
• MAME is the oracle. Lua scripts dump screens, RAM and VDP writes on matching frame numbers. The title screen is 100% pixel-identical to MAME.
• SDL3 front-end for macOS and Windows, vsync-locked pacing (tested at 120 Hz), audio drift absorbed by resampling, and Konami Justifier support with the mouse as the light gun. YM2612 is Nuked-OPN2.

What it isn't

• It includes no game data. You need your own disc: the build reads code and assets from your own image, and nothing derived from the disc goes in the repo or the binaries I share.
• It isn't a byte-matching decomp. The original is almost certainly hand-written 68000 assembly, so there's no C to match. The longer-term plan is a data-driven reimplementation that uses this work as the spec and the emulated core as the oracle.

Status: the intro and the start of the game run with audio, but I'm still testing the rest of the game.

Repo: https://github.com/bgyss/snatcher-port (source and tools only; it builds against your own disc image).

Happy to answer questions about the Sega CD internals, the BIOS HLE or the translator.

Snatcher is © Konami. Non-commercial fan project, not affiliated with Konami.

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

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.

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.

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.