There is more normal looking code in other files. It sounds like the original game had animation data (or similar) embedded in the C code.

Not a surprise. Now the fun works starts: Deriving semantics from psuedo-assembly.

You might find it interesting that I am working on AI-driven decomp of a PS1 game not by matching bytes but by having agents produce C code and test code. Agents submit a C proposal to the harness, the harness compiles their C proposal for the original function, then the test suite provided by the implementer runs against the original machine code and the compiled C code version. The line and branch coverage of both must be 100% and given identical inputs and starting RAM, the function return value and RAM state and RAM/MMIO read write sequence must be identical. This is done with a small MIPS simulator which can run all the tests extremely fast.

The reason I’m finding this is much faster than a traditional decomp is that while it’d be nice for the bytes to match, finding the perfect blend of compiler version, compiler args, permitting variables etc to try and find the perfect register assignments, etc is all very time consuming. My ultimate goal is not a byte for byte match, that’s just one way to ensure correctness. I’ve found agents are much faster and effective at reading the original assembly and understanding what’s going on then writing semantically equivalent C.

Making a function fully matching by virtue of hacks like this is mostly not harmful to the ability to understand the code, but is a useful tool in ensuring that the code as a whole really is matching and identical to the original. Otherwise, it's difficult to prove.

There is also value in decomps beyond just understanding and general interest. They can also be used to make more advanced mods, better translation patches, etc. The fidelity here matters, like having asm code accessing structures makes it hard to modify structures, but any fidelity improvement beyond pure asm is very welcome.

Of course I still prefer to try to recover the original code that caused the compiler to do what it did, but it's a really challenging problem sometimes. I've been working on decompiling code from old versions of MSVC for literally years now and you accumulate some knowledge of what things impact register allocation or the order of symbols but some of it comes from things that get fully erased from the source. Like for example, debug builds generally seem to retain symbols that aren't actually referenced anywhere, but those symbols only actually make it into an object file if they are. For functions that were only ever inlined and not actually referenced anywhere... They still wind up in the object files and thus in debug builds, despite nothing referencing them. They are also COMDAT any'd because they can appear in multiple objects legally, which means the exact object that winds up retaining it in the final linked executable is arbitrary (and the compilation flags of the object containing it, too - I bet that was fun for developers to debug.) This is incredibly useful but very challenging, needless to say. It may even be feasible to construct examples that would be legitimately infeasible to simply guess back to equivalent source, which I suspect is a major reason why until it was finally shown to be possible in larger scale projects many people wrote fully matching decomps off as a fool's errand..

Correct, this is just hacks for stuff you didn't manage to match exactly. Either that or your build environment isn't the same. Sadly, there are things which aren't really possible to reproduce in a byte-identical manner, things like exact file layout or variable declaration order, compilation order and that kinda stuff. And they might cause small but equivalent changes like different inlining/optimisation decisions, so it's really tricky to get it byte-exact.

The OOT and MM decomp had a bruteforcer tool that would reorder lines until the register allocation matched.

Certainly, it's better if you don't have these. But if I was working on something like this, I think you release when you have something that covers most of the territory, and then refine it over time.

Maybe someone else comes and helps out here and there.

> given how committed Capcom is to making sure RE4 is ported absolutely everywhere

Heh. I was just looking at the RE family on Steam. Nothing over a fiver.

I guess they really did make it more convenient than piracy.

You also get to add your own copyright since decompilation is also a creative enough process. There can be more than one copyright holder in a work.

I'm pretty curmudgeony on 3D games. The gamecube and friends were the 2nd generation of 3D first game systems and most games that sold well were not simply am existing genre game but with 3D objects that will poke your eyes out.

Doesn't mean I liked them, or that they wouldn't have been better as a 2D game. But IMHO the graphics stopped distracting from fun games... OTOH, I played plenty of games on the Atari 2600 were the player character wasn't much more than a chonky pixel :p

Those games like for N64 never really emulated great. I can see the motivation for those games to finally get nice gameplay on other platforms.

RE4 isn't really an early 3D game. It was a late GameCube title almost a decade after Quake.

There has been some 2D decomps too, Pokemon Red/Blue being the biggest I can think of. I can also imagine they make more sense for the 3D consoles where games tended to be written in higher level languages than raw assembly.

There are many HD texture projects

The whole readme is extremely Claude-written, its dense Claudish style leaks from every sentence ;)

And what’s wrong with that? Nothing. AI is an amazing tool that has made me and many other more productive. It’ll only get better and stronger.

Of course it was possible before.

You could put an Einstein paper on a photocopier, mask the author, put your name in the place and publish. Except everyone would have thought you are an idiot.

You could clone the Linux kernel, erase all copyrights and release under Idiux. Except everyone would have thought you are an idiot.

Now that there are laundering machines financed with unlimited printed and previously stolen money a large number of developers affirms and praises the idiots.

In the early days of emulation, there were tons of low-quality and imprecise emulator backends. If you wanted to play a dozen SNES games, you usually needed a half-dozen emulators to get them all to boot to the main menu. They were disparate efforts usually led by 1 or 2 people that wanted to get a Super Famicom game to run, and then gave up on implementing or fixing support for other games.

We live in a golden age of emulation because that attitude died out. With more powerful computers (and less hack-oriented development) it became possible to properly emulate a complete console with a high level of accuracy. For preservationist purposes, accurate emulation is much more important than being the first to emulate a game, or even being able to decompile it. The only reason that we can point and laugh at low-quality efforts like Nintendo Switch Online is because the community cares even more than Nintendo did. The reason Wine/DXVK/Proton works so well is because it didn't fracture itself into a thousand downstream forks to fix one specific game. It's a holistic effort.

A lot of the hand-wringing comes from a justified place that doesn't want to see emulation backslide into a bazaar-like community. You're free to disagree with their logic and vibe-code a thousand game decomps, but in all likelihood emulation will be a more popular choice for the foreseeable future. Lots of people emulate stuff on their iPhone or Steam Deck, almost nobody is playing a game decomp on it though. I can't imagine AI tipping the scales on decomp popularity, especially among average Joes.