I just checked a few more. It looks it can sometimes tell the intent of a stack variable and give it a name. But anything working with data looks like above.
The puzzle is then trying to piece the context back together by probing the game to recover something that approximately resembles what the original code might have looked like.
Eventually you can do things like Dusklight for advanced modding and feature implementation.
Despite all "hate" against AI in the (retro)-gaming scene I'm genuinely excited to see these kind of projects (not sure if this one involved any kind of AI) and emulation.
From a technical perspective emulation is absolutely amazing, it requires deep technical knowledge, an excellent understanding of the source system and the optimisations are on another level.
As someone heavily involved in the retro gaming tech space, I've seen a lot of people using AI there and it's really disappointing to me. You're right that it takes a lot of technical knowledge and deep understanding of the system, and the whole point of the endeavor is the process of getting that knowledge and becoming an expert in the system. It's a hobby, not a job; the end goal of a working emulator or whatever is just motivation to carry you along that process of learning.
So having Claude one-shot a NES emulator is almost pointless to me. You're using and looking at source code for an emulator you didn't write -- and you can learn from that, but it's not the same thing and doesn't require you to really understand a CPU the way you would by, say, observing a deviation in game behavior and staring at trace logs to figure out the exact instruction you emulated incorrectly.
It's not all bad -- AI is a great research tool and can automate some of the tedious parts (writing out an instruction decoder by hand is miserable). But using it to just...skip over the effort of doing a project defeats the whole purpose of doing those projects in the first place.
I don't want to be gatekeepy or curmudgeonly or "back in my day..." about it. But for me, my entire career path is due to skills and knowledge I learned spending several years of my life as a teenager figuring out how to write an NES emulator as a relative beginner to programming. And so I feel like using AI for this is depriving the next generation of that learning process. In addition, there are only so many retro games, and fewer popular ones. There's only so much unexplored territory to discover, and doing it with AI deprives another person of that experience and deprives that game's community of someone who might have been able to find a "home" working on projects related to that game.
> AI allows players to have decompiled and in turn ports of games to new platforms, enhanced versions of the game, etc.
We're ten years too early to do what you're suggesting. You need a really, really good understanding of the decompiled codebase and the original game and platform to port or implement new features.
You can't really ask "Claude, make Ocarina Of Time Widescreen" and expect it to work.
We're not ten years early. If you can afford the tokens, and can course-correct the agent when it gets off in the weeds, AI can do 95% of the grunt work of a decomp now.
Also, "widescreen OOT" is probably tweaking a pair of projection matrix floats in the binary so that might not be a great example :)
You could absolutely do that, because it's a narrow, targeted change. I give it 10% odds Claude could make that change to a binary ROM and 70% to a decomp.
> AI allows players to have decompiled and in turn ports of games to new platforms, enhanced versions of the game, etc.
To what end? The biggest benefit of tinkering with 40-year-old hardware is the experience of doing so. The knowledge and intuition you learn about how computers really work; the friendships you develop through collaboration with others, through asking for help with your projects and helping others with theirs; and the relaxing Saturday afternoons spent investigating and debugging and experimenting. The "benefit" of having a game that's been recompiled to a native executable for your PC or whatever is marginal compared to the benefit of the process to get to that point. That end goal is just a lighthouse to keep you on track, and when you get there maybe you'll play the recompiled game once to celebrate a job well done before moving on to another project.
If writing software is a means to an end, then there's value in anything that reduces the effort to get to that end. But as I see it, retro gaming projects are mostly an end to a means.
> Seems pretty egoistical when nobody's forcing you to use AI in any way, it provides an objective benefit to other people.
I have three fundamental claims:
- There is little to no positive benefit to using AI for hobby projects whose completion provides little to no intrinsic value.
- Choosing to do so has a negative impact on you, as it bypasses an incredibly valuable learning experience.
- Choosing to do so has a negative impact on others, as it takes away someone else's project opportunity (there are a finite amount of popular retro games, and many people prefer to work on novel projects rather than recreating something that has already been done).
I'm not sure what's "egoistical" about that, and I'd love if you could elaborate on that because I'm still wrestling with the ethics and implications of all this myself. The way I see it, it's better if I choose to forgo the use of AI on my projects, and I think others should choose the same.
---
Many years back, one retro gaming community I'm a part of had a prolific contributor who was extremely knowledgeable about the game, but also incredibly abrasive. He was the most knowledgeable person in the community at the time, and held this over others; discrediting their achievements, discouraging their attempts to learn, constantly starting fights and driving many good people out of the community. Yet he was allowed to remain in the community for many years, because everyone thought we needed his expertise.
Eventually the community came to the realization that it's just a video game and we don't "need" anything at all. None of the long-term community members are really here for the game anymore; we're here for the experience and the camaraderie. So we should make decisions (like kicking out this member) that are technically suboptimal for the game (at least in the short term), but better for fostering the community.
In a similar vein, using AI within these sorts of hobby spaces may allow faster progress on such projects, but it takes away the value of completing the projects in the first place, to the detriment of both the individual and the community.
> To what end? The biggest benefit of tinkering with 40-year-old hardware is the experience of doing so.
The biggest benefit to you. Other people, most people in fact, just like the game and want to enjoy it in new ways. They don't care about the code or reverse engineering itself. That people now benefit that it's easy to decompile because otherwise outside of really big titles like sm64, probably nobody is going to take the effort to manually decompile a less popular game.
That's the egoistical part.
Nobody is forcing you to use AI. And it's not really any different to how people would build their own NES emulators to learn instead of just grabbing whatever best NES emulator already exist.
I think my biggest issue with that is that people who just want to replay a game in a fresh way once or twice aren't the kind of people who are going to stick around and form a community; and those communities are what foster the creativity which brings freshness and depth to the games. I see it as quite similar to AI music creation, which, sure, allows people access to music that didn't exist before without putting in the effort, but in doing so it replaces what has historically been a community endeavor with a highly individualist, consumerist one.
My perspective is biased by the fact that such communities are an important part of my life. I don't want to see my years-long collaborations and friendships made obsolete by someone looking for an afternoon of nostalgia. And maybe everything will be fine, and the AI-users and the community-builders will go their separate ways and leave each other alone. But communities which exist today are having to ask how we should relate to AI, and my conclusion is that it's best kept out of hobbyist spaces if we want those spaces to continue to exist.
To be able to play retro games on current hardware/OS?
Why does it always need to be so complicated - I have zero interest in learning about these legacy platforms but I definitely want to play some nostalgic games.
Mindboggling that you see this as a negative and even want to kick out people to “protect” the community
Also to fix bugs. Someone recently ran Shadowrun (Genesis) disassembly through chatgpt and discovered that weapon upgrades were completely broken (using the wrong value as an index and ending up reading character stats as upgrade flags), defensive spells actually buffed your enemies, not you, etc. and released a romhack to fix things.
Lately I've seen this statement that I agree with: for some people, a hobby is a means to an end (which means using AI to achieve the goal is a heresy), for others, it is the end in itself (which it isn't).
Sorry, what? The benefit is that we have these games to play. That is the intrinsic benefit. Most of us don't care about the other things you listed when all we want to do is play old games. You're free to value those things in this context and that's fine, but it's weird to impose those values on others when they're providing what people want.
Much like you, anyone who wants to get deep into emulation and reverse engineering will. They will do so because AI cant quite do what they want, and probably because they are curious. The upside is that when they are that deep they will have a bot to ask questions of along the way, and they will recognise where it comes up short eventually.
Yes people will lazy their way out of it. Many of us program, but few of us ever bothered to learn, with fluency, assembly. Those who wanted to did, and those who didnt stuck to higher level languages.
I don't see why the goal of a decomp needs to be "learning how to decomp"--although I guarantee you that working on one, even AI-assisted, will teach you those skills.
Personally, I think it's fascinating to see how the industry greats actually made the magic happen. Everyone talks about the endless fine-tuning of controls that Miyamoto asked for in SM64: now we get to see what that actually looks like! Or maybe the game had a hidden secret debug menu that no one's ever seen in 20 years, or an unfinished character is hiding in the code.
Maybe my perspective is different because I've worked on games for most of my career, so seeing how _other_ teams solved the hard challenges is exciting for me.
I don't get it. Your purpose is to learn, why should someone else doing whatever they want be an impediment? You aren't racing to the market, you aren't pursuing the same objective. If your motivation is the learning process, an existing AI assisted, AI vibed or human created emulator doesn't stop you from writing your own and learning exactly the same way
It's sad that the community isn't exactly doing their best to separate developers using AI to debug poorly understood quirks and bugs of their emulation projects from those screaming "computah! Decompile me a Super Smash Bros".
MAME is doing some amazing reverse engineering work on some more recent arcade boards by using AI[1] that would've taken decades to do so by hand, and it's being conflated with some rando committing to github the result of 5 hours of Claude stirring over the Golden Eye N64 rom and then publishing on twitter "Done, here's my Patreon link, please and thank you".
Those most-intelligent of humans who carefully memorized verbally the most important civilizational facts known had the same reaction to the invention of writing.
You are clearly a wizard of a prior era. But it is a new era.
"For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom, for they will read many things without instruction and will therefore seem [275b] to know many things, when they are for the most part ignorant and hard to get along with, since they are not wise, but only appear wise."
That is a fictional objection raised by the Egyptian god Amun to the Egyptian god Thoth, who was supposed by the Egyptians to have invented music and writing, and was supposed by the Greeks to have invented absolutely everything else too, including botany, surveying, and government.
It's also a critique of writing, written by Plato, to impress on us that Socrates was great orator (or arguer) and was better that way. But it's not somebody's reaction to the invention of writing. It's an imagined reaction to the invention of writing.
Be wonderful if you approached a translated piece, by first considering the time and culture that produced it. Understanding the intent, rather than quoting it out of place.
This is a political critique, on the rule of law (writing) over attempting to treat things on a case by case basis (philosophy).
Quoting it, without understanding it, is part of that author's complaint.
I browsed through a few random files in that repo. There are high-quality code comments everywhere I looked. AI is the perfect tool to do this sort of thing. Can you imagine a human sitting down and documenting a million lines of decompiled code from a dev team 20 years ago?
Boggles my mind that there is hate for AI in retro-gaming. It's all about making existing things work. If it works and plays well, who cares if Claude did it in an afternoon or some human who spent a year of his life. In fact, I'd rather have Claude do it. Humans will get bored, get involved in community drama, disappear, etc. Unfortunate for the humans who are seeing their life's contribution to the scene made obsolete by a few kilowatt-hours in a datacenter, but good for the rest of us.
the comments are really not high-quality. There's a lot of words in places where only a few would be much clearer.
This isn't to say it's impossible to guide good context-aware commenting style from.an AI, but there would be much terser/usable comments on all of the weapons source for example.
The biggest problem with this stuff is, as usual, that the people guiding the AI don't know what "good" decomps etc look like IMO. AI tool usage tends to reflect ones own tastes and understanding.
Can't really decipher what line 21 is saying so I concede there could be some slop in there. But the comments on lines 27-30 seem to be informative and give some context that the code doesn't have.
Granted, I'm not an expert on RE4's source code, but the comments look helpful enough.
I didn't say they were wrong, I said they were not high-quality.
Every company works in their own way, but I highly doubt the original source would have a big paragraph at the top instead of a more "structured" comment. Or maybe even nothing at all!
Here's a "counterexample": the pistol code for half life 2[0]. Comments are pretty sparse because it's all relatively self explanatory. The comments that are present are to point out things that are not so.
You end up with something that's easy to work with and where you're not trying to read a paragraph of text that enumerates a bunch of properties of the code in the file in no particular order.
Some things are important context for the whole file. Some things are important context for a fragment of code. Some things ... are simply not that important to note.
I really like a small or larger comment above each function and more, even if people often say "less is more" - I disagree. Comment everything! It won't hurt. And people who don't like it can remove them and feel mighty.
I think the AI involvement makes this feel very different. Right now it’s just recomp/decomp of older titles, but it feels like a stepping stone to just automated plagiarism of basically any game.
I really think the hate is just masked jealousy, now project managers, tpms and line managers can submit rather substantial code. That wasn’t possible before and it took away some value from devs (I say this as a dev of more than 25 years). I watch PM fix issues now instead of waiting for a dev. I understand the anger but these tools are not going away
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.
> 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.
Well... it sorta did, on the other hand the scope of the project is just too big for any of those forks to survive more than a few releases. There's a multitude of various Proton releases with a single-game support. The android-oriented builds are even a bigger of a mess.
I don't think that's right. I helped work on SNES9X in the early 2000s and it ran nearly everything perfectly.
Sure there were smaller emulators which didn't work well, that's understandable. But gamers didn't need more than one or two emulators to play every game that existed; you just needed to pick the right ones.
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.
From a preservation perspective, this is one of the least useful decomps ever, given how committed Capcom is to making sure RE4 is ported absolutely everywhere (kidding!)
Made using the leaked debug build and its symbols, which shows how meaningful the work the game preservation community that acquires and distributes these things is.
OTOH this is pretty off-putting:
> Where the compiler needed a particular source shape to reproduce a register choice or a schedule and no natural spelling was found, the construct is marked with a // COMPILER-DIFF: comment (644 of them: dead tests, empty asm("") launders and anchors, register T x asm("rN") pins, padding statements).
To me the value of a decomp isn't reproducing the original bytes per se (we already have the original bytes after all) - it's about reconstructing the understanding of the original game as represented by human-readable source code; getting byte-for-byte is just an indication that you've gotten it right. Needing to add a bunch of slop to force the compiler to match the original output is actually just an indication that you've gotten it wrong - and it's a demonstration of the danger of Goodhart's law, especially as it applies to AI.
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.
That's a great approach, I think byte matching is just popular because it's extremely easy to test in the end: are the bytes the same? While your approach requires putting far more trust into the tests.
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..
Working on a decomp hobby project now, and "100% matching" on an individual function can be so deceptive! These two functions could look identical in assembly:
void foo() { bar(); }
int foo(int x, float y) { return bar(x, y); }
This is because parameter-passing and return-value handling can sometimes be done in zero instructions in PPC, if the values are already in the right registers. So you need to continually go back and reassess old functions once you learn the signatures of newer ones!
Oh yeah - absolutely. This isn't even just a PowerPC thing - it happens more generally, because usually if you're forwarding both arguments and return values for a function that has the same calling conventions, you don't really have to do much adaptation, everything was already set up for you. It hit me a ton on x86 when I first started my journey into trying to reverse engineer. It still occasionally hits me, especially when I'm relying too hard on decompiler output and not paying enough attention.
There are plenty of examples where two very semantically different source codes can have the same output, which is really counter-intuitive when combined with the difficulty that often comes with trying to find a single source code that does match.
This is just another reason why debug information is such a godsend; having symbol names for C++ code will usually give you most of the function signature, and type information will give you the rest. That greatly enriches the disassembly, and the automated decompilation output, and no doubt constrains the number of possible source codes that could match both the output and the debug information, somewhat alleviating this issue.
Yup. Unfortunately the project I'm working on does not have any debug info. There are not even lingering __FILE__ strings anywhere. Just picking out the TU bounds has been a chore!
It's a huge benefit that things like the OS and SDK are known and predictable. This got me a foothold. Otherwise I would have gotten nowhere.
I'm still impressed that this decomp has macros (fully lost in the assembly) and nearly-100% meaningful variable names and struct layouts. That's not easy!
Float constants are stored as data which is deduplicated on a per-TU basis. So if my TU has 1.0 and 0.0 in it, every function in that TU which uses those numbers will load from the same address. The next TU will get its own dedicated 1.0 and 0.0 constants.
That is pretty clever. In a particularly C++ heavy program I was able to find decent splits by starting around where the vtables were stored and searching from there, which was helpful since they also often pointed into the relevant part of the .text section. The repeating floats thing definitely seems to ring true though. For old MSVC it seems like it will emit floats even if they aren't directly referenced, if they happen to be referenced by inline functions that are not used. That adds another challenge if you want to get really close to the actual original source: figuring out what those inline functions actually are instead of just dropping a dummy that references them and is never used :) But I'd say that's extra credit, if you ever got to the point where that was the only remaining debt...
For sure, actually mirroring the shape of inlined code properly rather than just emitting code N times is already extra credit as far as I'm concerned. I've got enough loose ends without chasing that sort of thing!
With /LTCG /GL I don't think it's possible to get matching (or at least it's a very tall order), the codegen is wayy too volatile for an exact match and since inlining and reg alloc work on heuristics with thresholds it really cascades. Even stuff like what order you declare your locals in or the exact frontend syntax can mess things up...
Most people are working on builds where debug information was either inadvertently or sometimes intentionally included (e.g. for beta releases sometimes debug builds with debug info would ship for sake of making things easier.) These builds usually don't have all of the normal release optimizations on. That makes it much more likely to get a match.
I haven't tried this, but I also suspect that once you have a lot of code fully matching, it might make it possible to ratchet your way up further into builds that you don't have debug information for, that may have more aggressive compilation options. I am not sure if you would manage to get /LTCG builds fully matching even with this advantage, but it's going to be the best shot at it. You're possibly 90% of the way there already.
Hey I'm not working in matching something with LTCG atm :) I'm just saying in general.
And yes if you have a pdb / an Od build then things are much easier, I was assuming arbitrary game i.e. release binaries.
The "knowledge laundering" approach you describe might help in reconstructing headers, class layouts and function names which is a godsend although I don't think it would be enough to get a match. Getting functionally equivalent code is muuuch easier (although there's the problem of "how do you verify that without running every function")
Yeah, this is probably true. I've done non-matching decompilations of modern software up to a few hundred kilobytes worth of code - it is challenging but doable. I have no idea how hard it would be to get to matching with LTCG no matter where you start from. If it was genuinely not practically possible for computational reasons I would be unsurprised.
AI is pretty powerful for decompilation, especially because you can also just have an LLM go and start reverse engineering bits of the linker and compiler if you want. (I suspect this decomp is AI assisted if the Clauded out README is any indication.) Maybe future models will be able to come up with clever and novel ways to reduce the number of possibilities and converge faster on possible matching source codes. Or maybe not; I think Astra is the best LLMs have ever been at decompilation and yet I find LLMs frustrating and prone to getting deeply stuck in local maxima in my experimentation.
Yeah IMO the next big thing will be a way of verifying equivalence while filtering out the "noise" differences in optimisation. Otherwise you can't really decide whether you got it correct or not.
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.
"assign all these pointers to the correct types, a wrong guess leads to different COMDAT folding"
"get the order of local variables in this function right, otherwise the register allocation doesn't match. Oh and there's 150 local variables just in this function, good luck trying them all"
"Find out the translation unit boundaries exactly (assume there's no pdb otherwise this is trivial) and after doing so, figure out the order they were compiled in, otherwise it won't match"
"brute force the compilation flags for the project and if you're done, also bruteforce it for the CRT or any other middleware which usually came prebuilt so it doesn't match the main game"
Indeed it's a shitload of work. It's also possible and has been done. You don't have to only use global brute-force - you could also reverse engineer the compiler. The OOT/MM decomps achieved completeness without //COMPILERDIFF.
Correct me if I'm wrong (I'm not very well-versed in game decomp scenes) but aren't all those bytematched decomps from 90s or at the latest early 2000s games? They didn't have global optimisation (MSVC introduced it in VS .NET or 2003 I think and many games didn't use it until later)
So these are mostly problems with more advanced compilers yk
Correct, N64 and PS1 era projects can essentially always be strictly tackled one function at a time. There are very minor things (like string literal sharing) where some earlier function can affect later function, but the workarounds are comparatively simple.
On the other hand, I have heard even old MSVC is a nightmare. Various things are affected by hash table ordering (so the names of variables matter in some situations), stuff like order of #includes mattering, etc.
Yuuuup exactly. I guess this is masked because old 90s games are often more culturally significant so people haven't found these problems yet but yes, these are serious challenges.
You're probably thinking of https://github.com/simonlindholm/decomp-permuter, which is used across many more decomp projects (and can do a lot more than swap lines). It's a huge help, but it's by no means enough for all regalloc differences; there's lots of stuff it cannot do.
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.
There are some absolutely insane ideas in the decomp space about how copyright works.
You took a copyrighted work, did some lossless mathematical transformations on it, and have created an artifact that reproduces the original copyrighted work with perfect fidelity every time. From a legal perspective, this is effectively identical to zipping and unzipping a copyrighted file. You won't have much luck claiming that the intermediate Zip file is somehow free of copyright.
The legal problem is the original taint of using a copyrighted work (expressly contrary to its license), and the fact that nothing transformative is occurring here sufficient to enliven the defense of fair use. (Not even close, and no, this is nowhere near the realm of being arguable. The fact that this spits out a copyrighted work 'byte for byte' is a stake through the heart of any such argument.)
Decomp projects are cool, but if you work on them, please be aware that you're taking a risk, and some video game companies are famously litigious, even for old games.
If reverse engineering is legal, why wouldn't this be? By reverse engineering you take a closed source program and gradually figure out how it works, eventually ending up with source code that can be transformed into a binary that implements the same function. Reverse engineering would have to be illegal if what you say is true, because the source code you obtained from a copyrighted work is "tainted".
There are also creative choices made in reverse engineering because there are many possible source codes that could compile to the same executable output. The author has to make countless choices around how to interpret assembly as higher level language constructs, and code organization in terms of functions and variables used. This isn't anything like zipping and unzipping some file, it's not a one to one transformation. As you can see we can absolutely have byte for byte identical output without having access to the original source code.
I agree that it would be copyright infringement if you distribute the original game assets (sounds, fonts, textures, models), but I strongly disagree when it comes to the source code because of above factors.
And clearly distributing reversed source code without those assets would not enable someone to even obtain the original binary. They'd need to already have them in the first place (e.g. by buying the game and dumping them).
Also this is anecdotal but Nintendo is known for being quite belligerent with their copyright enforcement, they will take down various fan games in the name of protecting their IP. However to this day there are multiple full byte for byte decomps of Pokémon GBC games available on GitHub that haven't received so much as a DMCA takedown. Why wouldn't they care to take them down unless they couldn't do anything about reverse engineering? Nintendo still profits from reselling their old games after all (under their "Virtual Console" releases). The pattern repeats with Nintendo game console emulators, the only reason Nintendo is able to take some of them down is when these emulators include decryption keys for ROMs, they have never had a case for taking down an emulator on the basis of it behaving identically to the hardware they sell.
Both in theory and in practice I fail to see why you would be right that game decomps are illegal or even in the gray area.
> Reverse engineering would have to be illegal if what you say is true, because the source code you obtained from a copyrighted work is "tainted".
Yes. It often is. Hence why we have "clean room" practices to avoid the taint.
There's a reason "legality" is one of the headlines on the reverse engineering wiki page.
The headliner legal case in the US being Sega v. Accolade, which said that reverse-engineering to discover functions is fine if no documentation exists, but almost all other options are not fair use.
As for Nintendo, I guess you missed that they throw gigantic DCMAs at GitHub all the time? [1]
> Yes. It often is. Hence why we have "clean room" practices to avoid the taint.
You refer to the Wikipedia page on the legality of reverse engineering which says reverse engineering is often legal, contrary to what you say.
And the clean room practice is not reverse engineering as I use the term here. When I say reverse engineering I mean using actual binary disassembly to construct your own version of the source code, not "cloning" a piece of software by only looking at the results it produces from the outside. You may want to avoid the questions altogether and that's fine but clean room practice doesn't answer the question on the legality of reveng itself.
There are specific cases in which you can't reverse engineer: if you agree to a EULA that says you can't reverse engineer. Or if you run afoul of DMCA by for example distributing tools to circumvent DRM alongside your reverse engineered game console emulator, as I said. But in the general case my previous comment applies.
> "legality" is one of the headlines on fhe reverse engineering wiki page.
The legal question is always raised when one party does something another party doesn't want, even if it's legal. Companies selling proprietary tech understandably don't like having it reverse engineered. But reverse engineering has merits as mentioned in my original comment provided you don't violate other laws like distributing copyrighted assets with your source release.
The Sega v Accolade case you refer to concludes reverse engineering is OK in the absence of docs describing the workings of a system. But that's the typical case in reverse engineering! You don't have docs for the algorithm and implementation of a proprietary game or its engine. If you had such documentation you could just write your own implementation using the docs, without reverse engineering in the first place. Needless to say proprietary devs never provide such docs for obvious reasons, they don't want to make it easier to no benefit for themselves.
> As for Nintendo, I guess you missed that they throw gigantic DCMAs at GitHub all the time?
Very misleading. The Nintendo DMCA you link to here is a takedown of forks of specifically the RyujinX emulator, which they had a right to take down under the DMCA because RyujinX included tools to circumvent Nintendo consoles' ROM encryption. Exactly what I refer to in my original comment. To emulate a Nintendo Switch you need to use decryption keys from the console, but distributing the keys or tools to dump those crypto keys from your console is itself illegal. Here the emulator was not taken down because it implements the actual workings of a Nintendo Switch (reverse engineered), it was taken down because under DMCA you can't legally distribute tools to circumvent encryption (think DRM removal for different movies/audiobooks or game cracking). This case doesn't prove RevEng is illegal, other highly popular emulators like VisualBoyAdvance and Dolphin were not taken down by Nintendo because they don't do what RyujinX, Citra, and yuzu did. Again I said exactly this earlier.
I'm so emotionally torn about all the awesome decompilation work done.
Too bad all the cool decompilation is happening for games on early 3D centric consoles. I say this a Quake fanatic. Low res textures combined with that blurry bilinear style filtering is a look that's not easy to love. It's just a generational thing I guess.
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
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.
GB games are written in assembly, so decomp means marking sections as code or data, then commenting the crap out of it. The earliest Nintendo consoles to use C were the N64 and the GBA.
It's a 2005 game. Yeah it's running on 2001 tech but it still has all the lessons learned from the previous years both in terms of 3D game design and getting the most out of the hardware. Would you call Doom 3 an early 3D game? It can run on 2001 hardware too. Or Half-Life 2?
I hope that the CC0 license doesn't make any problems. It might though since decompilation does not remove the copyright of Capcom. Maybe just hope that they just don't care anymore
Cool, could maybe eventually have a version blind people like me can play through this. A lot of blind vibe coders have been working on making decompiled games accessible.
Tangential: I have no issue with it, but this seems by README writing style to be AI-assisted. As time goes on, whether AI was used or not will become far less a point of interest - if the project is good it is good.
The unceremonious use of (what I speculate is) AI-assistance is becoming more normal. I think a lot of people who were die-hard skeptics will just quietly protest less and less. Also, for people who use it well and poorly alike, the urge to not advertise any AI-use at all is common today. People who know how to use it well don't feel the need to explain themselves to unreasonable absolutist skeptics.
I opened a file at random. This looks more like emulating the behavior in compilable C syntax rather than recovering the game's programming
void Em1eWeaponSet(cEm10* em) { Em10Work* w = EM10_WK(em);
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.
I just checked a few more. It looks it can sometimes tell the intent of a stack variable and give it a name. But anything working with data looks like above.
Yes, that is how decompilation projects work.
The puzzle is then trying to piece the context back together by probing the game to recover something that approximately resembles what the original code might have looked like.
Eventually you can do things like Dusklight for advanced modding and feature implementation.
Not a surprise. Now the fun works starts: Deriving semantics from psuedo-assembly.
How is this more readable to a human than the binary ?
It’s not.
Despite all "hate" against AI in the (retro)-gaming scene I'm genuinely excited to see these kind of projects (not sure if this one involved any kind of AI) and emulation.
From a technical perspective emulation is absolutely amazing, it requires deep technical knowledge, an excellent understanding of the source system and the optimisations are on another level.
As someone heavily involved in the retro gaming tech space, I've seen a lot of people using AI there and it's really disappointing to me. You're right that it takes a lot of technical knowledge and deep understanding of the system, and the whole point of the endeavor is the process of getting that knowledge and becoming an expert in the system. It's a hobby, not a job; the end goal of a working emulator or whatever is just motivation to carry you along that process of learning.
So having Claude one-shot a NES emulator is almost pointless to me. You're using and looking at source code for an emulator you didn't write -- and you can learn from that, but it's not the same thing and doesn't require you to really understand a CPU the way you would by, say, observing a deviation in game behavior and staring at trace logs to figure out the exact instruction you emulated incorrectly.
It's not all bad -- AI is a great research tool and can automate some of the tedious parts (writing out an instruction decoder by hand is miserable). But using it to just...skip over the effort of doing a project defeats the whole purpose of doing those projects in the first place.
I don't want to be gatekeepy or curmudgeonly or "back in my day..." about it. But for me, my entire career path is due to skills and knowledge I learned spending several years of my life as a teenager figuring out how to write an NES emulator as a relative beginner to programming. And so I feel like using AI for this is depriving the next generation of that learning process. In addition, there are only so many retro games, and fewer popular ones. There's only so much unexplored territory to discover, and doing it with AI deprives another person of that experience and deprives that game's community of someone who might have been able to find a "home" working on projects related to that game.
> the whole point of the endeavor is the process of getting that knowledge and becoming an expert in the system
There's nothing stopping you from making an emulator without using AI or whichever way you think is best for your own learning.
AI allows players to have decompiled and in turn ports of games to new platforms, enhanced versions of the game, etc.
Seems pretty egoistical when nobody's forcing you to use AI in any way, and it provides an objective benefit to other people.
> AI allows players to have decompiled and in turn ports of games to new platforms, enhanced versions of the game, etc.
We're ten years too early to do what you're suggesting. You need a really, really good understanding of the decompiled codebase and the original game and platform to port or implement new features.
You can't really ask "Claude, make Ocarina Of Time Widescreen" and expect it to work.
We're not ten years early. If you can afford the tokens, and can course-correct the agent when it gets off in the weeds, AI can do 95% of the grunt work of a decomp now.
Also, "widescreen OOT" is probably tweaking a pair of projection matrix floats in the binary so that might not be a great example :)
You could absolutely do that, because it's a narrow, targeted change. I give it 10% odds Claude could make that change to a binary ROM and 70% to a decomp.
You're underestimating how good models are. I'm pretty sure you could in fact prompt that and have it work.
trivial task for fable
> AI allows players to have decompiled and in turn ports of games to new platforms, enhanced versions of the game, etc.
To what end? The biggest benefit of tinkering with 40-year-old hardware is the experience of doing so. The knowledge and intuition you learn about how computers really work; the friendships you develop through collaboration with others, through asking for help with your projects and helping others with theirs; and the relaxing Saturday afternoons spent investigating and debugging and experimenting. The "benefit" of having a game that's been recompiled to a native executable for your PC or whatever is marginal compared to the benefit of the process to get to that point. That end goal is just a lighthouse to keep you on track, and when you get there maybe you'll play the recompiled game once to celebrate a job well done before moving on to another project.
If writing software is a means to an end, then there's value in anything that reduces the effort to get to that end. But as I see it, retro gaming projects are mostly an end to a means.
> Seems pretty egoistical when nobody's forcing you to use AI in any way, it provides an objective benefit to other people.
I have three fundamental claims:
- There is little to no positive benefit to using AI for hobby projects whose completion provides little to no intrinsic value.
- Choosing to do so has a negative impact on you, as it bypasses an incredibly valuable learning experience.
- Choosing to do so has a negative impact on others, as it takes away someone else's project opportunity (there are a finite amount of popular retro games, and many people prefer to work on novel projects rather than recreating something that has already been done).
I'm not sure what's "egoistical" about that, and I'd love if you could elaborate on that because I'm still wrestling with the ethics and implications of all this myself. The way I see it, it's better if I choose to forgo the use of AI on my projects, and I think others should choose the same.
---
Many years back, one retro gaming community I'm a part of had a prolific contributor who was extremely knowledgeable about the game, but also incredibly abrasive. He was the most knowledgeable person in the community at the time, and held this over others; discrediting their achievements, discouraging their attempts to learn, constantly starting fights and driving many good people out of the community. Yet he was allowed to remain in the community for many years, because everyone thought we needed his expertise.
Eventually the community came to the realization that it's just a video game and we don't "need" anything at all. None of the long-term community members are really here for the game anymore; we're here for the experience and the camaraderie. So we should make decisions (like kicking out this member) that are technically suboptimal for the game (at least in the short term), but better for fostering the community.
In a similar vein, using AI within these sorts of hobby spaces may allow faster progress on such projects, but it takes away the value of completing the projects in the first place, to the detriment of both the individual and the community.
> To what end? The biggest benefit of tinkering with 40-year-old hardware is the experience of doing so.
The biggest benefit to you. Other people, most people in fact, just like the game and want to enjoy it in new ways. They don't care about the code or reverse engineering itself. That people now benefit that it's easy to decompile because otherwise outside of really big titles like sm64, probably nobody is going to take the effort to manually decompile a less popular game.
That's the egoistical part.
Nobody is forcing you to use AI. And it's not really any different to how people would build their own NES emulators to learn instead of just grabbing whatever best NES emulator already exist.
I think my biggest issue with that is that people who just want to replay a game in a fresh way once or twice aren't the kind of people who are going to stick around and form a community; and those communities are what foster the creativity which brings freshness and depth to the games. I see it as quite similar to AI music creation, which, sure, allows people access to music that didn't exist before without putting in the effort, but in doing so it replaces what has historically been a community endeavor with a highly individualist, consumerist one.
My perspective is biased by the fact that such communities are an important part of my life. I don't want to see my years-long collaborations and friendships made obsolete by someone looking for an afternoon of nostalgia. And maybe everything will be fine, and the AI-users and the community-builders will go their separate ways and leave each other alone. But communities which exist today are having to ask how we should relate to AI, and my conclusion is that it's best kept out of hobbyist spaces if we want those spaces to continue to exist.
To be able to play retro games on current hardware/OS?
Why does it always need to be so complicated - I have zero interest in learning about these legacy platforms but I definitely want to play some nostalgic games.
Mindboggling that you see this as a negative and even want to kick out people to “protect” the community
Also to fix bugs. Someone recently ran Shadowrun (Genesis) disassembly through chatgpt and discovered that weapon upgrades were completely broken (using the wrong value as an index and ending up reading character stats as upgrade flags), defensive spells actually buffed your enemies, not you, etc. and released a romhack to fix things.
Lately I've seen this statement that I agree with: for some people, a hobby is a means to an end (which means using AI to achieve the goal is a heresy), for others, it is the end in itself (which it isn't).
Sorry, what? The benefit is that we have these games to play. That is the intrinsic benefit. Most of us don't care about the other things you listed when all we want to do is play old games. You're free to value those things in this context and that's fine, but it's weird to impose those values on others when they're providing what people want.
Much like you, anyone who wants to get deep into emulation and reverse engineering will. They will do so because AI cant quite do what they want, and probably because they are curious. The upside is that when they are that deep they will have a bot to ask questions of along the way, and they will recognise where it comes up short eventually.
Yes people will lazy their way out of it. Many of us program, but few of us ever bothered to learn, with fluency, assembly. Those who wanted to did, and those who didnt stuck to higher level languages.
I don't see why the goal of a decomp needs to be "learning how to decomp"--although I guarantee you that working on one, even AI-assisted, will teach you those skills.
Personally, I think it's fascinating to see how the industry greats actually made the magic happen. Everyone talks about the endless fine-tuning of controls that Miyamoto asked for in SM64: now we get to see what that actually looks like! Or maybe the game had a hidden secret debug menu that no one's ever seen in 20 years, or an unfinished character is hiding in the code.
Maybe my perspective is different because I've worked on games for most of my career, so seeing how _other_ teams solved the hard challenges is exciting for me.
I don't get it. Your purpose is to learn, why should someone else doing whatever they want be an impediment? You aren't racing to the market, you aren't pursuing the same objective. If your motivation is the learning process, an existing AI assisted, AI vibed or human created emulator doesn't stop you from writing your own and learning exactly the same way
It's sad that the community isn't exactly doing their best to separate developers using AI to debug poorly understood quirks and bugs of their emulation projects from those screaming "computah! Decompile me a Super Smash Bros".
MAME is doing some amazing reverse engineering work on some more recent arcade boards by using AI[1] that would've taken decades to do so by hand, and it's being conflated with some rando committing to github the result of 5 hours of Claude stirring over the Golden Eye N64 rom and then publishing on twitter "Done, here's my Patreon link, please and thank you".
[1]https://mamedev.emulab.it/haze/2026-working-with-what-we-hav...
A lot of people just want to play "Smash Bros" on their iPad or get native ulatrawide support on "Majora's Mask".
This might be a product vs. eng split, but "whole point of the endeavor" isn't the same for everyone.
Those most-intelligent of humans who carefully memorized verbally the most important civilizational facts known had the same reaction to the invention of writing.
You are clearly a wizard of a prior era. But it is a new era.
No they didn't.
They really did. And through great irony, such objections are preserved.
https://www.historyofinformation.com/detail.php?id=3439
"For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom, for they will read many things without instruction and will therefore seem [275b] to know many things, when they are for the most part ignorant and hard to get along with, since they are not wise, but only appear wise."
That is a fictional objection raised by the Egyptian god Amun to the Egyptian god Thoth, who was supposed by the Egyptians to have invented music and writing, and was supposed by the Greeks to have invented absolutely everything else too, including botany, surveying, and government.
It's also a critique of writing, written by Plato, to impress on us that Socrates was great orator (or arguer) and was better that way. But it's not somebody's reaction to the invention of writing. It's an imagined reaction to the invention of writing.
Wait, you're saying that writing wasn't invented by a guy with an ibis head?
Be wonderful if you approached a translated piece, by first considering the time and culture that produced it. Understanding the intent, rather than quoting it out of place.
This is a political critique, on the rule of law (writing) over attempting to treat things on a case by case basis (philosophy).
Quoting it, without understanding it, is part of that author's complaint.
I browsed through a few random files in that repo. There are high-quality code comments everywhere I looked. AI is the perfect tool to do this sort of thing. Can you imagine a human sitting down and documenting a million lines of decompiled code from a dev team 20 years ago?
Boggles my mind that there is hate for AI in retro-gaming. It's all about making existing things work. If it works and plays well, who cares if Claude did it in an afternoon or some human who spent a year of his life. In fact, I'd rather have Claude do it. Humans will get bored, get involved in community drama, disappear, etc. Unfortunate for the humans who are seeing their life's contribution to the scene made obsolete by a few kilowatt-hours in a datacenter, but good for the rest of us.
> Can you imagine a human sitting down and documenting a million lines of decompiled code from a dev team 20 years ago?
Yes: https://patrickjohnston.org/bank/index.html
the comments are really not high-quality. There's a lot of words in places where only a few would be much clearer.
This isn't to say it's impossible to guide good context-aware commenting style from.an AI, but there would be much terser/usable comments on all of the weapons source for example.
The biggest problem with this stuff is, as usual, that the people guiding the AI don't know what "good" decomps etc look like IMO. AI tool usage tends to reflect ones own tastes and understanding.
Are the comments wrong or just not concise?
I looked at https://github.com/adonis-singh/re4/blob/master/src/wep/objM...
Can't really decipher what line 21 is saying so I concede there could be some slop in there. But the comments on lines 27-30 seem to be informative and give some context that the code doesn't have.
Granted, I'm not an expert on RE4's source code, but the comments look helpful enough.
I didn't say they were wrong, I said they were not high-quality.
Every company works in their own way, but I highly doubt the original source would have a big paragraph at the top instead of a more "structured" comment. Or maybe even nothing at all!
Here's a "counterexample": the pistol code for half life 2[0]. Comments are pretty sparse because it's all relatively self explanatory. The comments that are present are to point out things that are not so.
You end up with something that's easy to work with and where you're not trying to read a paragraph of text that enumerates a bunch of properties of the code in the file in no particular order.
Some things are important context for the whole file. Some things are important context for a fragment of code. Some things ... are simply not that important to note.
[0]: https://github.com/ValveSoftware/source-sdk-2013/blob/master...
I really like a small or larger comment above each function and more, even if people often say "less is more" - I disagree. Comment everything! It won't hurt. And people who don't like it can remove them and feel mighty.
I think the AI involvement makes this feel very different. Right now it’s just recomp/decomp of older titles, but it feels like a stepping stone to just automated plagiarism of basically any game.
I really think the hate is just masked jealousy, now project managers, tpms and line managers can submit rather substantial code. That wasn’t possible before and it took away some value from devs (I say this as a dev of more than 25 years). I watch PM fix issues now instead of waiting for a dev. I understand the anger but these tools are not going away
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.
> 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.
Well... it sorta did, on the other hand the scope of the project is just too big for any of those forks to survive more than a few releases. There's a multitude of various Proton releases with a single-game support. The android-oriented builds are even a bigger of a mess.
I don't think that's right. I helped work on SNES9X in the early 2000s and it ran nearly everything perfectly.
Sure there were smaller emulators which didn't work well, that's understandable. But gamers didn't need more than one or two emulators to play every game that existed; you just needed to pick the right ones.
As long as they are the ones on the Sev 1 bridge when shit is down 6 months later I'm happy for them.
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.
[flagged]
[flagged]
From a preservation perspective, this is one of the least useful decomps ever, given how committed Capcom is to making sure RE4 is ported absolutely everywhere (kidding!)
Made using the leaked debug build and its symbols, which shows how meaningful the work the game preservation community that acquires and distributes these things is.
OTOH this is pretty off-putting:
> Where the compiler needed a particular source shape to reproduce a register choice or a schedule and no natural spelling was found, the construct is marked with a // COMPILER-DIFF: comment (644 of them: dead tests, empty asm("") launders and anchors, register T x asm("rN") pins, padding statements).
To me the value of a decomp isn't reproducing the original bytes per se (we already have the original bytes after all) - it's about reconstructing the understanding of the original game as represented by human-readable source code; getting byte-for-byte is just an indication that you've gotten it right. Needing to add a bunch of slop to force the compiler to match the original output is actually just an indication that you've gotten it wrong - and it's a demonstration of the danger of Goodhart's law, especially as it applies to AI.
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.
That's a great approach, I think byte matching is just popular because it's extremely easy to test in the end: are the bytes the same? While your approach requires putting far more trust into the tests.
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..
Working on a decomp hobby project now, and "100% matching" on an individual function can be so deceptive! These two functions could look identical in assembly:
void foo() { bar(); }
int foo(int x, float y) { return bar(x, y); }
This is because parameter-passing and return-value handling can sometimes be done in zero instructions in PPC, if the values are already in the right registers. So you need to continually go back and reassess old functions once you learn the signatures of newer ones!
Oh yeah - absolutely. This isn't even just a PowerPC thing - it happens more generally, because usually if you're forwarding both arguments and return values for a function that has the same calling conventions, you don't really have to do much adaptation, everything was already set up for you. It hit me a ton on x86 when I first started my journey into trying to reverse engineer. It still occasionally hits me, especially when I'm relying too hard on decompiler output and not paying enough attention.
There are plenty of examples where two very semantically different source codes can have the same output, which is really counter-intuitive when combined with the difficulty that often comes with trying to find a single source code that does match.
This is just another reason why debug information is such a godsend; having symbol names for C++ code will usually give you most of the function signature, and type information will give you the rest. That greatly enriches the disassembly, and the automated decompilation output, and no doubt constrains the number of possible source codes that could match both the output and the debug information, somewhat alleviating this issue.
Yup. Unfortunately the project I'm working on does not have any debug info. There are not even lingering __FILE__ strings anywhere. Just picking out the TU bounds has been a chore!
It's a huge benefit that things like the OS and SDK are known and predictable. This got me a foothold. Otherwise I would have gotten nowhere.
I'm still impressed that this decomp has macros (fully lost in the assembly) and nearly-100% meaningful variable names and struct layouts. That's not easy!
How in the world are you finding reasonable TU boundaries, without debug info? I've always been puzzled by this in particular.
Float constants are stored as data which is deduplicated on a per-TU basis. So if my TU has 1.0 and 0.0 in it, every function in that TU which uses those numbers will load from the same address. The next TU will get its own dedicated 1.0 and 0.0 constants.
That is pretty clever. In a particularly C++ heavy program I was able to find decent splits by starting around where the vtables were stored and searching from there, which was helpful since they also often pointed into the relevant part of the .text section. The repeating floats thing definitely seems to ring true though. For old MSVC it seems like it will emit floats even if they aren't directly referenced, if they happen to be referenced by inline functions that are not used. That adds another challenge if you want to get really close to the actual original source: figuring out what those inline functions actually are instead of just dropping a dummy that references them and is never used :) But I'd say that's extra credit, if you ever got to the point where that was the only remaining debt...
For sure, actually mirroring the shape of inlined code properly rather than just emitting code N times is already extra credit as far as I'm concerned. I've got enough loose ends without chasing that sort of thing!
With /LTCG /GL I don't think it's possible to get matching (or at least it's a very tall order), the codegen is wayy too volatile for an exact match and since inlining and reg alloc work on heuristics with thresholds it really cascades. Even stuff like what order you declare your locals in or the exact frontend syntax can mess things up...
Most people are working on builds where debug information was either inadvertently or sometimes intentionally included (e.g. for beta releases sometimes debug builds with debug info would ship for sake of making things easier.) These builds usually don't have all of the normal release optimizations on. That makes it much more likely to get a match.
I haven't tried this, but I also suspect that once you have a lot of code fully matching, it might make it possible to ratchet your way up further into builds that you don't have debug information for, that may have more aggressive compilation options. I am not sure if you would manage to get /LTCG builds fully matching even with this advantage, but it's going to be the best shot at it. You're possibly 90% of the way there already.
Hey I'm not working in matching something with LTCG atm :) I'm just saying in general.
And yes if you have a pdb / an Od build then things are much easier, I was assuming arbitrary game i.e. release binaries.
The "knowledge laundering" approach you describe might help in reconstructing headers, class layouts and function names which is a godsend although I don't think it would be enough to get a match. Getting functionally equivalent code is muuuch easier (although there's the problem of "how do you verify that without running every function")
Yeah, this is probably true. I've done non-matching decompilations of modern software up to a few hundred kilobytes worth of code - it is challenging but doable. I have no idea how hard it would be to get to matching with LTCG no matter where you start from. If it was genuinely not practically possible for computational reasons I would be unsurprised.
AI is pretty powerful for decompilation, especially because you can also just have an LLM go and start reverse engineering bits of the linker and compiler if you want. (I suspect this decomp is AI assisted if the Clauded out README is any indication.) Maybe future models will be able to come up with clever and novel ways to reduce the number of possibilities and converge faster on possible matching source codes. Or maybe not; I think Astra is the best LLMs have ever been at decompilation and yet I find LLMs frustrating and prone to getting deeply stuck in local maxima in my experimentation.
Yeah IMO the next big thing will be a way of verifying equivalence while filtering out the "noise" differences in optimisation. Otherwise you can't really decide whether you got it correct or not.
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.
Why wouldn't those be possible to reproduce?
"assign all these pointers to the correct types, a wrong guess leads to different COMDAT folding"
"get the order of local variables in this function right, otherwise the register allocation doesn't match. Oh and there's 150 local variables just in this function, good luck trying them all"
"Find out the translation unit boundaries exactly (assume there's no pdb otherwise this is trivial) and after doing so, figure out the order they were compiled in, otherwise it won't match"
"brute force the compilation flags for the project and if you're done, also bruteforce it for the CRT or any other middleware which usually came prebuilt so it doesn't match the main game"
Should I continue;)
Indeed it's a shitload of work. It's also possible and has been done. You don't have to only use global brute-force - you could also reverse engineer the compiler. The OOT/MM decomps achieved completeness without //COMPILERDIFF.
Correct me if I'm wrong (I'm not very well-versed in game decomp scenes) but aren't all those bytematched decomps from 90s or at the latest early 2000s games? They didn't have global optimisation (MSVC introduced it in VS .NET or 2003 I think and many games didn't use it until later)
So these are mostly problems with more advanced compilers yk
Correct, N64 and PS1 era projects can essentially always be strictly tackled one function at a time. There are very minor things (like string literal sharing) where some earlier function can affect later function, but the workarounds are comparatively simple.
On the other hand, I have heard even old MSVC is a nightmare. Various things are affected by hash table ordering (so the names of variables matter in some situations), stuff like order of #includes mattering, etc.
Yuuuup exactly. I guess this is masked because old 90s games are often more culturally significant so people haven't found these problems yet but yes, these are serious challenges.
The OOT and MM decomp had a bruteforcer tool that would reorder lines until the register allocation matched.
You're probably thinking of https://github.com/simonlindholm/decomp-permuter, which is used across many more decomp projects (and can do a lot more than swap lines). It's a huge help, but it's by no means enough for all regalloc differences; there's lots of stuff it cannot do.
> 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.
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.
CC0, on the decompilation of a copyrighted work? That's... Not the way it works.
You inherit the copyright from the original, as this is derivative.
There's a reason decompilation has always been a grey area of seeing whether or not the copyright holder cares.
There are some absolutely insane ideas in the decomp space about how copyright works.
You took a copyrighted work, did some lossless mathematical transformations on it, and have created an artifact that reproduces the original copyrighted work with perfect fidelity every time. From a legal perspective, this is effectively identical to zipping and unzipping a copyrighted file. You won't have much luck claiming that the intermediate Zip file is somehow free of copyright.
The legal problem is the original taint of using a copyrighted work (expressly contrary to its license), and the fact that nothing transformative is occurring here sufficient to enliven the defense of fair use. (Not even close, and no, this is nowhere near the realm of being arguable. The fact that this spits out a copyrighted work 'byte for byte' is a stake through the heart of any such argument.)
Decomp projects are cool, but if you work on them, please be aware that you're taking a risk, and some video game companies are famously litigious, even for old games.
If reverse engineering is legal, why wouldn't this be? By reverse engineering you take a closed source program and gradually figure out how it works, eventually ending up with source code that can be transformed into a binary that implements the same function. Reverse engineering would have to be illegal if what you say is true, because the source code you obtained from a copyrighted work is "tainted".
There are also creative choices made in reverse engineering because there are many possible source codes that could compile to the same executable output. The author has to make countless choices around how to interpret assembly as higher level language constructs, and code organization in terms of functions and variables used. This isn't anything like zipping and unzipping some file, it's not a one to one transformation. As you can see we can absolutely have byte for byte identical output without having access to the original source code.
I agree that it would be copyright infringement if you distribute the original game assets (sounds, fonts, textures, models), but I strongly disagree when it comes to the source code because of above factors. And clearly distributing reversed source code without those assets would not enable someone to even obtain the original binary. They'd need to already have them in the first place (e.g. by buying the game and dumping them).
Also this is anecdotal but Nintendo is known for being quite belligerent with their copyright enforcement, they will take down various fan games in the name of protecting their IP. However to this day there are multiple full byte for byte decomps of Pokémon GBC games available on GitHub that haven't received so much as a DMCA takedown. Why wouldn't they care to take them down unless they couldn't do anything about reverse engineering? Nintendo still profits from reselling their old games after all (under their "Virtual Console" releases). The pattern repeats with Nintendo game console emulators, the only reason Nintendo is able to take some of them down is when these emulators include decryption keys for ROMs, they have never had a case for taking down an emulator on the basis of it behaving identically to the hardware they sell.
Both in theory and in practice I fail to see why you would be right that game decomps are illegal or even in the gray area.
> Reverse engineering would have to be illegal if what you say is true, because the source code you obtained from a copyrighted work is "tainted".
Yes. It often is. Hence why we have "clean room" practices to avoid the taint.
There's a reason "legality" is one of the headlines on the reverse engineering wiki page.
The headliner legal case in the US being Sega v. Accolade, which said that reverse-engineering to discover functions is fine if no documentation exists, but almost all other options are not fair use.
As for Nintendo, I guess you missed that they throw gigantic DCMAs at GitHub all the time? [1]
https://github.com/github/dmca/blob/master/2025/02/2025-02-2...
> Yes. It often is. Hence why we have "clean room" practices to avoid the taint.
You refer to the Wikipedia page on the legality of reverse engineering which says reverse engineering is often legal, contrary to what you say. And the clean room practice is not reverse engineering as I use the term here. When I say reverse engineering I mean using actual binary disassembly to construct your own version of the source code, not "cloning" a piece of software by only looking at the results it produces from the outside. You may want to avoid the questions altogether and that's fine but clean room practice doesn't answer the question on the legality of reveng itself.
There are specific cases in which you can't reverse engineer: if you agree to a EULA that says you can't reverse engineer. Or if you run afoul of DMCA by for example distributing tools to circumvent DRM alongside your reverse engineered game console emulator, as I said. But in the general case my previous comment applies.
> "legality" is one of the headlines on fhe reverse engineering wiki page.
The legal question is always raised when one party does something another party doesn't want, even if it's legal. Companies selling proprietary tech understandably don't like having it reverse engineered. But reverse engineering has merits as mentioned in my original comment provided you don't violate other laws like distributing copyrighted assets with your source release.
The Sega v Accolade case you refer to concludes reverse engineering is OK in the absence of docs describing the workings of a system. But that's the typical case in reverse engineering! You don't have docs for the algorithm and implementation of a proprietary game or its engine. If you had such documentation you could just write your own implementation using the docs, without reverse engineering in the first place. Needless to say proprietary devs never provide such docs for obvious reasons, they don't want to make it easier to no benefit for themselves.
> As for Nintendo, I guess you missed that they throw gigantic DCMAs at GitHub all the time?
Very misleading. The Nintendo DMCA you link to here is a takedown of forks of specifically the RyujinX emulator, which they had a right to take down under the DMCA because RyujinX included tools to circumvent Nintendo consoles' ROM encryption. Exactly what I refer to in my original comment. To emulate a Nintendo Switch you need to use decryption keys from the console, but distributing the keys or tools to dump those crypto keys from your console is itself illegal. Here the emulator was not taken down because it implements the actual workings of a Nintendo Switch (reverse engineered), it was taken down because under DMCA you can't legally distribute tools to circumvent encryption (think DRM removal for different movies/audiobooks or game cracking). This case doesn't prove RevEng is illegal, other highly popular emulators like VisualBoyAdvance and Dolphin were not taken down by Nintendo because they don't do what RyujinX, Citra, and yuzu did. Again I said exactly this earlier.
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.
The main reason you'd avoid this is to stop the first copyright holder from wanting to sue you - not because it's actually invalid.
If what you committed was piracy, then no. It doesn't matter how creative you were. You only get rights, were first you had a right to use.
If you are "significantly similar", you are probably infringing.
Feel free to explore the myriad of precedent setting cases in the music remix community.
“byte-identical” is one of Claude’s favorite expressions
Definitely one of Claude's load-bearing terms.
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.
Yes and at some point it won't even need YOU anymore.
I'm so emotionally torn about all the awesome decompilation work done.
Too bad all the cool decompilation is happening for games on early 3D centric consoles. I say this a Quake fanatic. Low res textures combined with that blurry bilinear style filtering is a look that's not easy to love. It's just a generational thing I guess.
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.
GB games are written in assembly, so decomp means marking sections as code or data, then commenting the crap out of it. The earliest Nintendo consoles to use C were the N64 and the GBA.
True, not the earliest gen. But it's a 2001 console (not 2004) despite this being a 2004 title.
It's a 2005 game. Yeah it's running on 2001 tech but it still has all the lessons learned from the previous years both in terms of 3D game design and getting the most out of the hardware. Would you call Doom 3 an early 3D game? It can run on 2001 hardware too. Or Half-Life 2?
There are many HD texture projects
I hope that the CC0 license doesn't make any problems. It might though since decompilation does not remove the copyright of Capcom. Maybe just hope that they just don't care anymore
[dead]
Cool, could maybe eventually have a version blind people like me can play through this. A lot of blind vibe coders have been working on making decompiled games accessible.
Tangential: I have no issue with it, but this seems by README writing style to be AI-assisted. As time goes on, whether AI was used or not will become far less a point of interest - if the project is good it is good.
The unceremonious use of (what I speculate is) AI-assistance is becoming more normal. I think a lot of people who were die-hard skeptics will just quietly protest less and less. Also, for people who use it well and poorly alike, the urge to not advertise any AI-use at all is common today. People who know how to use it well don't feel the need to explain themselves to unreasonable absolutist skeptics.
- special and maybe even a stupid request
- can someone skilled and passionate look into doing some of the older ubi titles?
- like maybe rainbow six vegas 1/2 or
- splinter cell games?
How many tokens and which models were used?
The real question is if it's relocatable or not (still works correctly if you add or remove bytes)
[dead]