I have no doubt that this would be possible for MGS2 as well.
I have been working on an incremental decompilation-based reimplementation (basically how OpenRCT2 was done) of Worms Armageddon for the past 2 months with a lot of help from LLM tools; primarily Claude Code and Ghidra MCP. I've worked on it almost every day, reaching Claude Code Max 5x's 5 hour session limit multiple times every day. Suffice to say as a software rendered, sprite-based 90s PC game, Worms Armageddon is several orders of magnitude simpler than MGS2. Despite that, I think it will be 2-3 more months of work before I can compile a fully independent version of the game.
This is despite the game being an almost ideal candidate for automated RE, as it uses deterministic game logic with built-in checksum checks in replays and multiplayer. I've downloaded all the speedruns I could find for the game (as replay files) and I've retrofitted the replay system into a massively parallel test framework, which simulates over 600 games in about 30 seconds. So Claude can port all game logic independently without much need for manual testing; the replay tests can almost guarantee perfect correctness.
MGS2 doesn't have anything like that, so every ported function requires extensive manual testing. Even with LLM tools, an accurate decomp could take years (unless you're willing spend thousands of $currency per month on it).
For those wondering, there is a public Git repository at https://github.com/paavohuhtala/OpenWA.
The challenge here is readability. Reading the TP source leak you link I think it's even behind the current state of the art, as it's barely above assembly. This is where I suspect even the smallest of LLMs may help, since you don't care that much if it introduces errors.
Only in a very rudimentary sense and definitely not in a working compilation (much less binary equivalent) sense. LLMs have turned this from a gimmick for static analysis into something that actually works pretty well for recompilation projects.
Binary equivalence is the easy part; the hard part is getting something that classifies as readable C. LLMs do not really help reach the "working compilation" part but benefit from it.
>I disagree that they're good at writing compilable code
That was never part of the discussion, because as explained several times now it is irrelevant in this case. The existence of the original binary means all you need to do is match up things, which can be automated completely.
The problem is readability. No one in his right mind would call what they generate "C++". Mine still interjects assembler from time to time (and not the new version that GCC supports, but the older MSVC style) .
LLMs absolutely do not help with the generate working code part, because this is an exact problem that doesn't need nor benefit from an LLM. They can help with the readability part, because here _once you already have a working skeleton_ it doesn't matter that much if they make mistakes, as it is easy to detect.
If what you said was true, the projects mentioned above wouldn't have needed years of arduous work before the age of LLMs came to be.
What is the experience faulty decompilation, and the existence of bugs in the binary?
Could one decompile a binary to a more modern language than C?
Here's the same simple program, written in 3 different ways, producing identical binary compatible code: https://godbolt.org/z/qWrc8fEnn
How does the AI know whether it should produce back the snippet #1, #2 or #3? It does not. It cannot.
Barring obvious edge cases that could show up but don't usually, like intentional race conditions. Timing is the one area where things get iffy.
The person I'm replying to? Who said you will get the same code as if it were the original source?