Don't be surprised about them moving to cloud gaming even more which they already have with Xbox cloud gaming and in the future, the real game will be hidden and simulated behind a world model.
Yes, it uses two already existing tools for the heavy lifting. Remill lifts the x86 machine code to LLVM IR, and LLVM then compiles that IR to ARM64. And no, nobody translates the assembly by hand luckily, not me nor the agent. All of these 150k functions go through this automatic chain I explained before.
What I wrote with Claude is basically everything else: custom LLVM passes, a hand-written runtime that replaces the Windows calls, a Direct3D 11 to Metal layer and the shader translation! Plus fixing the crashes one by one by iterating and playing. All details are in the Pipeline section of the README if you're interested: https://github.com/adrbn/bo2-mac#pipeline
> Remill lifts each function to LLVM IR, a chain of our own passes rewrites that IR, and the result is linked with a Win32 runtime written by hand, whose Direct3D 11 is drawn by Metal. There is no Wine and no JIT: the game runs as native code, in one process. About 150,000 functions are translated across the three executables. Only the short sequences that the copy protection hides run in a small x86 interpreter, and so does any code the translation missed, so a hole is built to cost speed rather than crash the game.
what was your workflow for creating this? there's now extra guardrails around decompiling / reverse engineering, do you think this is still possible to do or were you just lucky enough to do it before the guardrails?
Well it took me almost 4 months using parallel Claude sessions, each one of them working on its own worktree. I also made a point of measuring before considering anything fixed, and I tested and played throughout the whole development so this way I knew the real impact of every change it was applying. I'm yet to start another similar project to see how things have changed in terms of guardrails, but it has not been a problem for me in the last month AFAIK. Sessions keep working without any problem and Codex (Astra) has also been of a great help in addition, when I did encounter some refusals with Claude. Also maybe (big maybe!) the fact the tool only works from a Steam copy helped, I guess.
I would be interested in a write up of how to get started with something like this. I know there are tools like REA now, but it still seems daunting for someone that has never done game development or decompiled anything before.
The README is very much AI slop. Why don't you people write by yourself at least your READMEs? Explain the why? Explain the advantages? You can still ask AI for reviews.
Almost every paragraph makes me want to ask: "so what?"
> There is no Wine and no JIT: the game runs as native code, in one process
> the campaign runs at 51–60 frames per second
So what?
Is it a matter of running the game in itself? Was the game not running on Apple M-series in any way, so you're unlocking something that was impossible before?
Or does the game just ran faster (more FPS), load quicker, render better, what?
There's no comparison to how the game runs on x86, or how it runs on M-series with translation layers (IF it runs).
This is an exact manifestation of the AI slop problem. A lot of details. A lot of "how". A lot of "what". So little "why" - you need to read a lot and in the end your questions are never answered, and you don't understand if the project makes sense at all or is just something "we did it because we could". I'm perfectly happy to read AI generated text if it's properly and clearly written and answers the right questions.
Stuff like this makes me really happy about AI. The convenience that AAA lacks, or that they intentionally withhold, is now within reach.
Don't be surprised about them moving to cloud gaming even more which they already have with Xbox cloud gaming and in the future, the real game will be hidden and simulated behind a world model.
How does it actually recompile, does it use an existing tool? I can’t imagine the agent combs through every routine and hand translates the assembly.
Yes, it uses two already existing tools for the heavy lifting. Remill lifts the x86 machine code to LLVM IR, and LLVM then compiles that IR to ARM64. And no, nobody translates the assembly by hand luckily, not me nor the agent. All of these 150k functions go through this automatic chain I explained before.
What I wrote with Claude is basically everything else: custom LLVM passes, a hand-written runtime that replaces the Windows calls, a Direct3D 11 to Metal layer and the shader translation! Plus fixing the crashes one by one by iterating and playing. All details are in the Pipeline section of the README if you're interested: https://github.com/adrbn/bo2-mac#pipeline
Thanks.
> Remill lifts each function to LLVM IR, a chain of our own passes rewrites that IR, and the result is linked with a Win32 runtime written by hand, whose Direct3D 11 is drawn by Metal. There is no Wine and no JIT: the game runs as native code, in one process. About 150,000 functions are translated across the three executables. Only the short sequences that the copy protection hides run in a small x86 interpreter, and so does any code the translation missed, so a hole is built to cost speed rather than crash the game.
what was your workflow for creating this? there's now extra guardrails around decompiling / reverse engineering, do you think this is still possible to do or were you just lucky enough to do it before the guardrails?
Well it took me almost 4 months using parallel Claude sessions, each one of them working on its own worktree. I also made a point of measuring before considering anything fixed, and I tested and played throughout the whole development so this way I knew the real impact of every change it was applying. I'm yet to start another similar project to see how things have changed in terms of guardrails, but it has not been a problem for me in the last month AFAIK. Sessions keep working without any problem and Codex (Astra) has also been of a great help in addition, when I did encounter some refusals with Claude. Also maybe (big maybe!) the fact the tool only works from a Steam copy helped, I guess.
I would be interested in a write up of how to get started with something like this. I know there are tools like REA now, but it still seems daunting for someone that has never done game development or decompiled anything before.
The README is very much AI slop. Why don't you people write by yourself at least your READMEs? Explain the why? Explain the advantages? You can still ask AI for reviews.
Almost every paragraph makes me want to ask: "so what?"
> There is no Wine and no JIT: the game runs as native code, in one process > the campaign runs at 51–60 frames per second
So what?
Is it a matter of running the game in itself? Was the game not running on Apple M-series in any way, so you're unlocking something that was impossible before?
Or does the game just ran faster (more FPS), load quicker, render better, what?
There's no comparison to how the game runs on x86, or how it runs on M-series with translation layers (IF it runs).
This is an exact manifestation of the AI slop problem. A lot of details. A lot of "how". A lot of "what". So little "why" - you need to read a lot and in the end your questions are never answered, and you don't understand if the project makes sense at all or is just something "we did it because we could". I'm perfectly happy to read AI generated text if it's properly and clearly written and answers the right questions.