I've used to same technique to get Fallout: New Vegas running on Asahi Linux on MacOS. Its quite a step, but https://github.com/doitsujin/dxvk makes it possible to skip a lot of work and get the game running in day. You can then make any changes you want, so I'm running fallout nv on a wide display in native resolution and some graphical improvements. Realtime whole world shadow maps, SSAO, tonemap + color grading, FXAA and Hor+ FOV.
Gives me a solid 60fps most of the time, with only the occasianal bug here and there that is often fixed in no time. Luckily i've added 10min auto save quite quickly, so that it does not cause that big of a problem.
Aside from the fun of both getting the game to work on this machine, and the fun of actually being able to play the game, it is a great way to find creative ways to work with LLM. Building out dev tools on the way that works for an LLM etc.
Crossaover is Wine, just the commercial edition.
And Rosetta solves the exact opposite problem from Wine: same OS but different CPU architecture so it recompiles those x86 CPU instructions into ARM64 instructions and Apple specifically does not call it an emulator. It doesn't emulate an OS but it does user-mode CPU emulation so I don't know what it should be called.
> It doesn't emulate an OS but it does user-mode CPU emulation so I don't know what it should be called.
An emulator. In the context of computing translation software, "emulation" generally refers to emulating hardware rather than software. Hence why WINE Is Not an Emulator :)
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.
Moving to cloud gaming would mean cutting off any chance of selling to most of the world. >50ms for user input is very noticable, and >100ms people just won't pay for it. You also need very low packet loss and a reasonable amount of bandwidth. Those three requirements can be met for most (but notably not all!) of NA... but elsewhere? Not as much.
>Massive chance these recompilations just ruined gaming for everyone.
Nah that was microtransactions and associated corporate greed.
If we have good enough AI to force companies to do this, we have good enough AI to build any shit we want and we'll build better shit than what these companies are putting out.
There are many levels to "ruined" and it always can get worse.
>> and we'll build better shit than what these companies are putting out.
feel free to share what you've built. Sure its possible just need to be real here - 1% will be good, 99% will be slop.
And that 1% will down in that slop.
As a result though in theory you can make some games better than existing ones - the overall effect is net negative.
Video game piracy has been around for decades, you can get a cracked copy of nearly every game. Even some games like Black Ops II has a custom server browser and matchmaking servers for pirated copies.
This is impressive. Besides personal use gaming, it has a lot of interesting opportunities... Elsewhere OP said it was 4 months of Claude, which is very fas for something this complicated.
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
My big question: How did you get Claude to do reverse engineering work on a game without it getting cold feet and telling you it can't do that due to breaking ToS?
Out of curiosity, why not adopt Wine instead of hand rolling the Win32 API layer, and also why not use MoltenVK + dxvk for rendering? Have you tried these alternatives to compare the performance?
The thing is that both Wine and DXVK would still need the original x86 code to run through Rosetta. Which is exactly what I wanted gone. Here it’s all ARM64 before the game even starts. DXVK is also a Windows DLL that reaches Vulkan through Wine so without Wine I can’t really use it. And BO2 is 32-bit, so every Windows and D3D11 call has to be adapted anyway! Going straight to Metal ended up simpler :) No benchmark against them yet but it’s on my list! There is a short explanation in the README too if you're curious: https://github.com/adrbn/bo2-mac#pipeline
Uh it's a cool project for sure even if its getting hard to keep these apart and seems kind of strange to do all that targeted solely on game ... but cool!
This is very confusing to read, though:
What I wrote with Claude: [...] a hand-written runtime
To me you have to pick one or the other. Claude has no hands.
> 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.
Check the repo: the README already has a Method, Findings and Pipeline section, so that's kind of the start of a guide already.
If you want something simpler to begin with, look at N64Recomp (that's what gave us the PC ports of Zelda Majora's Mask) or XenonRecomp (Xbox 360, used for Sonic Unleashed), they're static recompilations too and way better documented than mine as of now haha. And to look inside an executable, Ghidra is free (made by the NSA, fun fact). A proper write-up might come at some point, but no promises on a date :)
Also, I had never done anything like this before either!
any guardrail claude throws up at me during my decomplication efforts I simply get around by saying "oh thats a false positive" or "this is for education" or "im doing this so i can fix the issue"... its a laughable "guardrail"
Thanks a lot! The original exe is around 13 MB per mode, mine is more between 500 and 800 MB each. Basically every x86 instruction becomes a bunch of ARM64 ones, and there is also a lot of extra code for the CPU state. Still runs at 60fps tho, so as long as you have decent storage it's not that much of a problem :)
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.
The why is in my post actually, BO2 never came out on Mac. On M chips you'd have to go through CrossOver and Rosetta, here it's native ARM64 so I can fix things and add stuff like split-screen, which the PC version never had. Fair point on the CrossOver benchmark, I haven't done it yet. I'll add a why section to the README, thanks.
To answer your last question also: yes, the PC version can be patched, that’s what mods like Plutonium do actually :) But it still wouldn’t run on a Mac, which is the main point here. And the rest of the features, like split-screen being worked on currently, are nothing but a bonus on top.
Actually it wasn't really playable on M-series before. AppleGamingWiki lists it as unplayable on CrossOver and not supported on Rosetta 2. The only way was a Windows ARM VM in Parallels, and reports go from 1fps in matches on an M1 Max to 60-80fps on M3/M4 chips. On my base 2020 M1 it now runs at 51-60fps, natively, no Windows license or VM needed. That's the why :)
https://www.applegamingwiki.com/wiki/Call_of_Duty:_Black_Ops... (Took me two minutes to find, human brain included :)
Disregard the whiners and trolls, I found what you did really interesting and inspiring.
I didn't know about remill before and finding such a good display of its capabilities was fantastic because I've been thinking about doing something similar for an old-ish geological research system that runs on a sparc system.
Similarly to your case I don't aim to subdue the licensing system or do anything else but ensure that the system can run on current x86 hardware (mostly for fun).
So yeah, it was a long way of saying "thanks for sharing your project and methodology, I think it's really cool and I don't mind the AI text at all"
Thanks a lot, really appreciate it! Also, remill supports SPARC too. So your geological system should be doable with the same approach. Good luck with it, happy to help if you get stuck :)
Sentiment analysis is a successful commercial usage of this class of technology, and engaging with that may help prevent you from gaslighting and weaseling. Cannot you classify complaints that you generate?
Gives me a solid 60fps most of the time, with only the occasianal bug here and there that is often fixed in no time. Luckily i've added 10min auto save quite quickly, so that it does not cause that big of a problem.
Aside from the fun of both getting the game to work on this machine, and the fun of actually being able to play the game, it is a great way to find creative ways to work with LLM. Building out dev tools on the way that works for an LLM etc.
Not sure about the other two, but WINE Is Not an Emulator. It's in the name :)
An emulator. In the context of computing translation software, "emulation" generally refers to emulating hardware rather than software. Hence why WINE Is Not an Emulator :)
The AI will still recreate a game that it can view and interact with.
Massive chance these recompilations just ruined gaming for everyone.
Like on your own- do whatever.
As soon as you share it - you actually harm players, not help them
Nah that was microtransactions and associated corporate greed.
If we have good enough AI to force companies to do this, we have good enough AI to build any shit we want and we'll build better shit than what these companies are putting out.
>> and we'll build better shit than what these companies are putting out. feel free to share what you've built. Sure its possible just need to be real here - 1% will be good, 99% will be slop. And that 1% will down in that slop.
As a result though in theory you can make some games better than existing ones - the overall effect is net negative.
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
This is very confusing to read, though:
What I wrote with Claude: [...] a hand-written runtime
To me you have to pick one or the other. Claude has no hands.
If you want something simpler to begin with, look at N64Recomp (that's what gave us the PC ports of Zelda Majora's Mask) or XenonRecomp (Xbox 360, used for Sonic Unleashed), they're static recompilations too and way better documented than mine as of now haha. And to look inside an executable, Ghidra is free (made by the NSA, fun fact). A proper write-up might come at some point, but no promises on a date :)
Also, I had never done anything like this before either!
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.
Thanks for adding the Why in your readme, btw :-)
By the way, the why in the README is still unclear:
Your post says:
> see if I could make it work on my 2020 MacBook Pro
This seems to imply that it didn't work on the 2020 MacBook Pro (which I suppose is the M1)
> On Apple Silicon the usual way to play it is Wine or CrossOver on top of Rosetta 2, which translate the game while it runs
This is from the README. So, it was playable on M-series already? Just not natively? Then, what kind of benefits does your translator offer?
> so I can fix things and add stuff like split-screen, which the PC version never had
So THIS is the advantage? I'm not sure why this advantage would be limited to the ARM64 version BTW; cannot you patch the original?
That's the why I'm asking for, and that's where LLMs suck, and where you need to have your human brain & skills actually work.
I didn't know about remill before and finding such a good display of its capabilities was fantastic because I've been thinking about doing something similar for an old-ish geological research system that runs on a sparc system.
Similarly to your case I don't aim to subdue the licensing system or do anything else but ensure that the system can run on current x86 hardware (mostly for fun).
So yeah, it was a long way of saying "thanks for sharing your project and methodology, I think it's really cool and I don't mind the AI text at all"