I think the next 10 years or so are going to see a chucklefuck of games reversed thanks to LLMs, which can easily pattern match and operate on contrivedely optimized assembly and output reasonably accurate C/C++ code. I’m one of many right now using Ghidra + LLM workflow. It’s doing the thing it needs to and I’ve helped several communities revive and port their games this way. It is a huge time saver. While I’d personally prefer an actual source code leak, a working reverse job is good enough, even if it’s partial as long as it’s accurate.
I wonder if we’ll get to a situation where a new game is reversed in the first few months by a team effort. Right now it’s mostly solo devs, but a technical team that’s capable without LLMs is unstoppable with them, and given the nature of modding communities, the only thing they are missing is an LLM to grind away at the details of the game that would otherwise take years to find out.
If you think this port is related to tour point; The source code for Command and Conquer generals (and other C&C games) was released a while back. This port uses that source code. So this port is not based on reverse engineering. The port even states someone else (manually) already did the hard work of porting it to macOS and Linux (so not an LLM):
> Built on EA's GPL v3 source release via fbraz3/GeneralsX (which did the heavy lifting of the macOS/Linux port — this fork adds the iOS/iPadOS port and a set of engine fixes
10 years is far too pessimistic for this being a routine task, I think 2 years max. As you mentioned, you can already do this today by just giving GPT 5.5/Opus 4.8 an IDA/Ghidra tooling (a CLI or MCP, I have a custom CLI for it). You can start with the LLM going from the string anchors and renaming functions/globals, then when you have enough functions, the LLM can start working on typing - IDA has a very powerful typing API for HexRays-decompiled code, you can even type locals and it all persists in a DB.
My custom IDA CLI is just a simple thing on top of IDA Python's integration + ida-domain + some higher-level helpers, and works as a daemon with workers, so a stale/bad request doesn't corrupt an IDA DB (an issue I had when I was using idasql).
A bit offtopic, but: do you have any links to your efforts? I'm curious to see what other people do in this area.
Not yet, unfortunately, but I might in the future. To be honest, it's nothing unique. I got inspired by https://github.com/allthingsida/idasql which I initially used, but it had a lot of bugs, a big codebase size, and IDA's C++ API is really easy to misuse and corrupt a DB, so I had GPT 5.4/5.5 make a new one for itself based on IDA's Python SDK, which is official and doesn't need weird SQL hacks.
Then recently I found https://github.com/bkerler/ida_rpc which seems to be ~60% the same thing as the one I have, the only big difference is that I do not give any special commands to LLMs, they just have to write Python in scripts/inline heredocs to interact with IDA. This lets them do a lot more interesting things since they get a full programming language.
This is an example of how LLMs work with idagent (`ida` is implicitly imported, ida.types, ida.comments is helper's own wrappers): https://paste.debian.net/hidden/cf46a122
More interesting example that was used to let the LLM/me track the rename progress for the initial function renames + gaps (code-looking like bytes that weren't inside of functions, IDA's autoanalysis missed some real functions). Although the game turned out to be small enough with only ~1500 real game functions that needed renames, which was done in ~10 hours of agent time total I think (I didn't parallelize with multiple agents).
https://paste.debian.net/hidden/bf458b3a
To be honest, you can probably have an agent vibecode a similar MVP tool to the one I have in about an hour-two :)
Not the person you asked but I frequently use Claude (Opus primarily) to reverse engineer embedded hardware. It uses a mix of Ghidra, Radare2, and just the arm-none-* tools. I can’t say I have a particular workflow though, I just say “we’re reverse engineering foo.bin. It’s the firmware for a servomotor. We talk to the servo over RS485 and it seems that if I send it command X it will sometimes silently reject the command. Can you dig into the data reception and command parsing layers to see if there’s an explanation. Let’s keep notes in @20260704-reverse-engineer-foo-motor.qmd”
Completely unrelated but I find it amusing in a good way that Oblivion is recognized more favorably now. I never understood the disregard for it (horse armor nonsense aside), as it has a very compelling, unique atmosphere and a not so terrible storyline/writing.
All Bethesda’s game generally suck without mods to a bigger or lesser extent. So it takes a while for a community of enthusiasts to appear but something like Oblivion or Skyrim were a much better experience 5-10 years after release than initially.
Of course then you have Starfield which is so unimaginable uninspiring that nothing can really be done to save it..
Exactly what I was going to say. Oblivion was the first Elder Scrolls game that had level scaling. It's just extremely lazy design that ruins any sense of progress/immersion. In Oblivion/Skyrim there are plenty of mods that remove the scaling, and end up with worlds that are vastly more interesting and immersive. I highly recommend Requiem.
I hate hate hate level scaling. I believe they also introduced it to WoW, which ruins the power fantasy of going back to a lower level area and kicking butt, or the fear of venturing in a higher level area and hauling ass out of there. I agree, lazy game design.
I think Oblivion's reception was mostly in relation to how people felt about Morrowind. Oblivion simplified a lot of what Morrowind did, which drew some ire. Atmospherically, though, people weren't happy that they moved from Morrowind's much more unique fantasy setting, full of massive fungi and swamp-striding bugs and weird demigods, and moved to a much more generic looking medieval countryside. That said, I also appreciate the game's reassessment, because I think some of the factions quest lines are among the best in the series.
I don't think the "it's piracy to use the code generated by an LLM because it closely resembles the code the LLM was trained on" argument has been fought in court yet.
Reverse engineering and pirating are not the same thing (although the former may certainly be used as a means to achieve the latter). As long as you aren't distributing the game, distributing code that legitimate owners of the game can use to run their game on more platforms is not a crime.
In systems engineering this was proven in court when you have one engineer writing specs and another implementing the "samish" system from those specs, but I'm not sure that would relate to any of the art assets made by the original authors of a game. I'd imagine any art, narrative writing or sound would still be considered IP, and without those things you don't have much of a game.
I suspect it won't stop people, and that it won't be much of an issue in a lot of cases. I wouldn't want to be the one to test it in any sort of court though. Not even on the other side of things, where it'll become even more of a nightmare to protect your indie IP on any form of platform which doesn't heavily regulate things.
IMHO, this is an actual good use of what sounds like a person guiding a model to do a mass conversion. Although, I wish the porting docs were a little wordsmithed by a human, the AI generated text style is grating.
The stakes are low, it’s mostly for fun and you can iterate on it. Compare this with Bun which was just like, “hey we converted everything to Bun to Rust from Zig, of course it works, what could possibly go wrong, I’ll totally write up a blogpost (that still doesn’t exist) explaining what we did, you can put this into your production environment soon!”
I don't really get the Bun thing. Bun is running Claude Code which is probably the single most actively used development app there is. You say this was a bad use of LLMs, but it's been in production for a while and I haven't heard of any evidence that Claude Code has increased a significantly larger quantity of errors, segfaults, etc, than before.
Some people, myself included, think that announcing a conversion from Rust to Zig as an experiment then jumping to putting it in the alpha train for public testing/consumption without any real explanation in the span of around 2 weeks is irresponsible and reckless.
Blogposts were promised, details were hinted, but no, it’s just full steam ahead because the AI worked so well. The converted unit tests all worked, all the synthetic tests are okay, so what are you complaining about?
At some point, it’s less about the technical questions and more about getting that pesky human buy-in.
"Yes, the AI rewrote the code. No, we do not pretend that we've scrutinized the code, or that we understand it. It works, tests pass, so we don't care, and so shouldn't you."
The "recklessness" is offered as the new normal. Because it kinda, well, works for them.
The recklessness kinda works for everybody until some point. Go fast and break things... then cash out before investors realize, unless you manage to capture the market so you can keep breaking things because people will swallow.
What's working for them is having a huge amount of resources and very good people to design a cutting edge agent harness, RLHF the hell out of their models, and build out a tremendous amount of inference capacity. I'm sure their process for making code changes in any of their client apps is very fast, but a TUI built around a chatbot is also not a particularly complicated application. So yes it's working for them, but the vibecoding that they are selling is clearly not what they are doing in practice.
What does Bun’s governance look like? Now that Anthropic bought the company are there significant external contributors that would expected to have input on a decision like this?
And why buy it when they could have just called it Run and do the Rust conversion anyways? The license prohibits it, they don’t need the team’s expertise anymore, since they’re running full AI vibecode mode. Makes no sense to me
Seems pretty clear that they do need the team, to direct the LLM effectively.
Also they're probably interested in the team just as an acqui-hire of good developers, and they're probably interested in the marketing value of converting the actual bun to rust via LLMs. But mostly I'd assume it was about needing the team to effectively direct the LLMs.
I get that and I can see an argument that they didn’t really put it as stable, but I suspect the reason it is not the stable version right now is from the massive pushback as other projects and companies started pulling support for Bun because of the loss of confidence rather than any other reason.
The problem is: quickly fixing problems (or preventing problems) benefits from having a good understanding of what the code is doing.
If you do have a suite of automated checks that's comprehensive enough that if it passes, no one will have any problems with the result, I think I'd agree. -- I don't think we're quite there at the point where "programming" is coming up with that suite of automated checks and then just not regarding the source code of the program itself.
I agree that the Bun rewrite is much more reasonable than knee-jerk reactions imply, however:
- I don't think Claude Code is using the Rust version yet in their official build
- Claude Code is not a particularly complicated piece of software from an engineering perspective (nor it's particularly well-engineered, at least at the moment).
So in my book "it runs Claude Code" would be pretty weak evidence that the rewrite is going to be successful (the tests they've done are much better evidence, but that's a topic for another time).
Now, Bun 1.4 doesn't seem to officially exist on https://bun.com/blog or https://github.com/oven-sh/bun/releases, so I can't be 100% sure this is the Rust version. However, I have to do some patching of the Claude Code binary to get it to run on my OS, and version 2.1.181 coincided with some changes that make suspect it's using Rust now.
> I've heard the meme that AI written rust code is absurdly full and safe blocks but... that's pretty funny.
If I understand what happened here correctly this isn't really a case of any such meme, but the result of the porters (heh) telling the LLM to directly convert zig code using unsafe to match the previous code "exactly".
I.e. more like using the LLM as a fancy version of c2rust [1] (which would result in just as much unsafe) than a result of LLMs reaching for escape hatches too liberally.
It's unironically a good practice when you port from an unsafe language (C/Zig) to Rust. Porting isn't refactoring. One should keep the logic mapping one-to-one as much as possible.
Counting instances of "unsafe {" is pretty useless. Unsafe is needed in "safe" code. What it allows is to create a boundary where the caller is the one that uphelds the contract. If the unsafe is in an internal library, it’s much more difficult to misuse.
I agree Claude Code is seemingly (currently) not very well-engineered but I think you may be moderately underestimating how complicated it is/necessarily has to be.
Huh... it looks to me like bun has yet to cut a release post Zig->Rust port (the latest one on github is still on a branch that says it's written in zig in the readme). I assume that nothing is using the rust version yet...
Which also cuts against the complaints about "of course it works [...] you can put this into your production environment soon!" since they don't seem to be asserting either of those things.
The real problem is they explained nothing and just caused a lot of mistrust. The lead developer at Bun working on this project does post here from time to time and I have never seen him answer any of this. I admire his enthusiasm, but this was badly handled mostly from Bun’s side which lead to a bunch of dogpiling.
When someone on another social media platform commented expressed some concern, his response was to ask him what the explicit bug he was talking about was and that he would generate a fix. That sound you hear is the woosh as the point flies by. And in general, this just feels like a consistent problem with Bun.
When you hear a woosh as the point flies by, I see someone attacking a project for using AI rather than any concrete technical reason. Jared's question is to disentangle an actual Rust-related bug report from someone who likes to complain about AI.
I have yet to hear any evidence that the Rust rewrite was harmful. I have no emotional investment in Bun (which I'd never heard of before the rewrite), or Zig (which I also didn't know about), or Rust (which I think is neat and that's about it), so I'm about as unbiased as you can get and from what I saw the conversion was done well, and I haven't heard of massive bugs resulting from the rewrite.
It is probably fine, it is kind of a best case scenario: porting a good code base with lots of unit tests, all hand-written. Not much can go wrong here as the LLM is kept in check by the original code, the tests, and the fact that the topic (a JS engine) is well documented.
The problem is what comes next. They now have code that they don't understand, and they are likely to work on it with AI in the future, but the new features they may introduce later will not have the luxury of hand-written tests and a reference code. So, unless they undertake the massive effort needed to fully understand the Rust code and deal with all these "unsafe", quality is very likely to go down, Microslop style.
It’s always been a fallacy to think that large organizations have code which is understood. There are people somewhere understanding small parts up until the next round of layoffs.
Millions were invested in this project where they fired the expensive experts (me included) and replaced with a small army of cheap devs (which was actually more expensive and less productive than just retaining even one of the experts would have been). Couple years later the inevitable happened and the whole thing was thrown into trash. Code without anyone who understands it is just a liability.
> which is probably the single most actively used development app there is
Seems doubtful, I'd put money on it being something like Visual Studio or Visual Studio Code. Maybe CC could claim the (odious) title of most actively used vibe-coded development app, though.
I have a port of BuildGDX in the project backlog that was basically just throwing Claude at it to go from Java to .NET. The only thing it really got hung up on was Java's byte being signed.
What I ended up with was a port of Duke 3D that uses half the allocated RAM as DukeGDX.
clickbait, right? it did not port it to macos, that was already done. all fable did (and it might've been opus for all we know) is adding the last few commits for ios/ipados support after all of the heavy lifting was done
still cool but the title makes it sound like it was done from scratch
Ya, because the upstream repos already did the majority of the work to port the game to Linux and MacOS. This fork used Fable to add iOS support with touch controls.
> Built on EA's GPL v3 source release via fbraz3/GeneralsX (which did the heavy lifting of the macOS/Linux port — this fork adds the iOS/iPadOS port and a set of engine fixes)
It’s cool that someone took the extra steps to run it on iPad and iOS, but if the README is correct then it was already ported to macOS? Going from Mac to iPad isn’t trivial, but it’s a much smaller jump than porting into the Apple world the first time.
This is another "AI-ism" I noticed, mostly in coding agents - they seem to be very fond of making up new "compound nouns" (and occasionally verbs) to sum up relatively complex and specific concepts into single noun phrases. I wasn't sure if it's to save tokens or if the AI uses this to get a concise "identifier" for a concept that it can refer back to later, but I found it very noticeable.
I find the resulting sentences hard to read, though it does get better if you're aware of that tendency and make a conscious effort to parse the noun phrases. But I guess since it's just intermediate output from coding agents and not text for essays or blog posts, it's fine.
It's a thing in some Germanic languages. Instinct is to merge nouns into word, e.g. 'lawnchair', but that gives you a red squiggly line, but 'lawn chair' also looks wrong, so 'lawn-chair' is the middle ground.
> English word origins are a fascinating rabbit hole.
My favourite example of which is Northern Ireland's Orange Order.
The colour is orange, because that was the Royal colour of the family of the monarch it was named after, William of Orange, who was Dutch, titled after the principality of Orange which is named after the city of Orange which is French which got its name from the Celtic word for forehead or temple.
The colour is named after the fruit, the fruit's name is a corruption "a norange" -> "an orange", which goes back to naranja which goes to Arabic which goes to Classical Persian which goes to Sanskrit.
Meanwhile, the dutch word for the fruit is sinaasappel, Chinese apple, compare with the English word "mandarin" used for many different Chinese things.
I’m (sorry for the lack of humbleness) a very fluent non-native speaker and writer, and this is by far my biggest challenge with Claude. It stitches together 2-4 advanced concepts into one or two words and I always have to ask it to “unpack”.
I don’t think it’s easy on native speakers when it happens, but it’s even harder when you’re not.
Still debating whether these are actually information dense or not. Complexity
gives the appearance of density, but these sentences always come in whole pages at a time while often failing to deliver the needed information.
Yes! It's infuriating. I've tried prohibiting them in my AGENTS.md but it's not 100% effective.
--- AGENTS.md ---
## Plain words, not jargon
Don't use jargon-as-shorthand. Say what you actually mean.
- Don't say "load-bearing assumptions". Say "the assumptions the xyz depends on".
- Don't say "cross-service". Name both services, e.g. "whether the X
service can derive duration without calling the Y service". "Cross-X" is
confusing because it hides which things are involved.
- Don't deliver verdicts as abstract noun-phrases like "Cross-RCA
double-counting is unfounded". Say it plainly: "I checked whether the same
root cause gets counted twice across RCA runs, and it doesn't."
## No earth-shattering declarations
Don't hype findings. Skip "a critical finding changes everything", "now I have
the full picture", "this changes the game", etc. Just state what you found
plainly. Most findings are ordinary; report them that way.
## Don't reflexively hedge a "yes"
When the answer is yes, say yes. Don't soften every positive answer with a
caveat: it erodes confidence in the "yes". Only add a caveat when there's a
genuine, specific uncertainty worth flagging.
On another note, I find AI instructions like this (e.g. "Don't hype findings. Skip "a critical finding changes everything",...") more harm than good in my own uses. It changes behavior in subtle ways that makes it less predictable to me. I'd rather it has its own AI-isms and quirks, that I've fully gotten used to, and I know what to expect. I know when it says certain things, in certain ways, that's what I think it means. Quirks and AI-isms don't annoy me, I get used to how it states things.
Lol! Good point. I did use Claude to write the rule, and it ironically wrote the exact thing I asked it to avoid. I agree that it might be best to use the model as-is, to get the intended experience.
Also I find it interesting to learn the jargon. It basically compacts information in fewer words, although more complex words. But when you are familiar with the jargon, you can unpack the sentences in your mind. And like that, you need less text to read and write prompts. So less reading, writing, and tokens!
Yeah, I wonder if part of the reasoning is built around those phrases, and therefore it can't get rid of them easily.
> "now I have the full picture"
I always interpreted that phrase as a sort of marker to delimit the phase in which it explores the codebase and gathers information from the phase in which it implements the changes.
Not sure if it's still done, but I think some months ago there was discussion that some of the phrases are injected by the inference loop to "steer" the model - e.g. "But wait" if a thought block was too short etc. Obviously such phrases couldn't be influenced by the prompt.
I thought it was just Opus 4.7 and 4.8 that did this. Do other models do this too?
Anyway: in my case Opus absolutely did not follow a similar instruction in the CLAUDE.md file. (But then again: it hardly followed _any_ CLAUDE.md instruction properly)
It's stupid, but have you tried telling it to follow it? "Make sure to follow the guidelines from AGENTS/CLAUDE.md" etc, seems to (sadly) make some difference in most harnesses and models.
For me, Opus 4.8's thinking traces for the chatbot will sometimes willingly ignore instructions, saying something along the lines of "I've noticed an instruction in the system instructions that states I shouldn't do this, but if I don't do this, I'll not provide the answer the user is looking for. I will ignore that instruction."
In all my CLAUDE.md and AGENTS.md files I have a line to fix pre-existing issues. I don’t know what it is but every agent I’ve tried through Claude code (including deepseek and GLM) will actively try to avoid fixing pre-existing issues. I even added hooks to Claude and git to try to get them fixed. If I leave a bailout for myself agents will find it sit and ask if it can push with no-verify or an environment variable in the case of Claude hooks instead of trying to fix an issue it didn’t cause.
I’d recommend to instead write a de-slop skill that instructs to launch a sub agent with fresh context, and analyze for such phrases in the new commits, and remove those. Find -> fix just works better than preemptive instructions, in my experience.
And if you manage to do this automatically before committing, you’ve built the backpressure everybody is talking about.
"The model refuses to follow my specific word detail prompts" and "The model refuses to perform hacking attempts" are on the same side of the model refusing to do something baked into it though.
Few ever cared. Find one non-pedant who would object to the personification that follows:
"The evening settled over the city, drawing the light out of the streets one corner at a time. Windows blinked awake with lamplight, and the wind moved through the alleys restlessly, leaves brushing against walls before gathering themselves along the pavement. In the distance, the river kept its steady argument with the stone embankments. When the night pressed in, the weather became increasingly angry, until it was a raging storm."
In the affective sense, evenings don't settle, and street lights are not drawn out, windows don't blink, and wind isn't restless. Weather can neither be angry, nor rage.
But such personification is a natural part of how the English speak.
> Built on EA's GPL v3 source release via fbraz3/GeneralsX (which did the heavy lifting of the macOS/Linux port — this fork adds the iOS/iPadOS port and a set of engine fixes).
Right? All Fable did was a ported an already cross platform project to ios. Does not look like any sort of heavy lifting there, opus 4.6 would do just fine
I read this and laugh a bit because just 7 months ago the bar was so much lower and now we go "well duh of course it was able to make a working ios app from a game made 20 years ago... a game that was made 3 years before the first iPhone"
Was the bar that much lower, or is that some people on this thread are misrepresenting what the project actually is?
EA Games open sourced the original C&C Generals source code a year ago.
GeneralsX is a fork of the original source code. The fork changes the code to be easier to be ported to other platforms, which GeneralsX provides native Linux and macOS builds.
This project adds a iOS target for the GeneralsX project, the iOS port was made using Claude Fable.
It is cool that a LLM was able to create a iOS port? Yes, but saying like if it was something that was hard or that it would take too much time to do before LLMs is a bit disingenuous in my opinion, especially because the GeneralsX had already done the bulk of the effort of making the code portable in the first place, and that there was already a macOS port.
For reference, the iOS port only needed to add 2,179 lines of code on files that already existed on GeneralsX, and that's not excluding comments, which Claude loves to add some LARGE comments, and things that are iOS app specific, like the app's Info.plist.
I wanna know if these techniques would be useful for Emperor: Battle for Dune (2001). It's the first 3D RTS by Westwood Studios, predating C&C Generals by just a couple years. It's popularity was hampered by intellectual property disputes and a introduction of a new faction that diverged from the book series lore. The gameplay, soundtrack, and campaign missions were awesome.
I remember that game! Cinematics! and some units had dune realistic shields so when hit with laser, both attacker and defender died. I don't think i've finished it, ending had some worm timer mission i couldn't get to in time.
Emperor was a great game. My only real complaint was the five sub-factions seemed to be imbalanced. I’d like to revisit to see if the was missing something.
Amazing. I have always maintained that Fallout 1 and 2 have nearly perfect UI for mobile. RTS games are hard to port directly while turn based games seem like a very natural fit, as long as they aren’t very reliant on full keyboard control. Fallout does not!
no way fable did this. It would have stopped after the words "command and conquer" and nerfed you to opus (while also landing you on some nsa watch list)
I’ve been using it to use Ghidra to do reverse engineering for modding Zelda: Tears of the Kingdom. Pre-ban it would flag immediately, post-ban it _rarely_ flagged anything and when it did I realized I could just make a memory telling it to convert reverse engineering speech into game development speech, not mentioning pointers, memory, addresses and decompiling. Then the flags mostly went away.
You can sidestep flags by just compacting and then changing the model back at any rate.
The issue with these kind of porting is edge case bugs - far smaller project/physic simulation has hit the same thing especially when original code isn't exactly clean, or sometimes only worked because of a logic bug.
This means you can play for maybe 10 minutes on the happy path but just as you are getting into the zone either a CTD or some strange event would make the game/simulation unplayable.
And while debugging is made easier, it's much more effort than telling the model to convert the code. Hence it's usually not done in these demos.
Am I reading that right? It makes API calls that go through 5 different layers before actually getting rendered? That's kind of crazy. I'm surprised it works, although I guess the underlying libraries are solid enough that it shouldn't be unexpected.
Technically there're just 3 layers: DXVK over MoltenVK over Metal. D3D8 and Vulkan here are just the APIs implemented by those adapter layers.
There're some D3D implementations over Metal that could skip the Vulkan layer but none implement the old D3D8 so you'd still need another layer that implements e.g. D3D8 over D3D9-11. Also, DXVK and MoltenVK have got a lot of traction and fixes on their own, so they're probably the most accurate pipeline for D3D on Metal.
Apple never released a driver that supports Vulkan out of the box, therefore MoltenVK was born, which translates Vulkan IR to Metal source then recompiles to Metal shaders.
This was the pipeline in Proton for macOS (I'm not sure if it's still is the case, been quite a while since I checked).
All right, when someone will do this for Railroad Tycoon Deluxe, Master of Magic, Master of Orion II, I will have to waste hundreds of hours playing these again... And it will hopefully be much more fun, because the computer "AI" will most likely be stronger / more interesting.
You can do this yourself with LLMs, but I admit that it's still not a trivial process. For the actual best results and the highest chance of progressing quickly, you really need a $200 OpenAI/Anthropic sub and a lot of free time. I seriously recommend OpenAI over Anthropic for this, as in my experience GPT 5.5 is far more thorough in reverse engineering and makes mistakes less often.
Then, you first need some tooling, either Ghidra (open-source) or IDA (paid), and some tooling to expose them to an LLM. I have a custom IDA Python-based CLI that lets LLMs trivially call into IDA's Python APIs from CLI, but there are tens of different Ghidra/IDA MCP/CLI/SQL projects out there.
After that, it becomes more mechanical, you just let the agent (or multiple agents) explore and start renaming (easier to start with functions + globals), better if it's something that's directly applied to the suite you're using, so that all names show up everywhere. This is actually quite a quick process, especially for older/smaller games. After you have enough function names, you need to instruct and have LLMs add actual types, so that the decompile doesn't have raw casts and offsets, but real fields + types. They will also need to apply types to globals and functions.
Afterwards comes the hardest part - you can export this very well named/annotated decompile, and do one of:
1) Have the LLM try to directly polish the code enough to be compilable. Despite of the decompile quality, this isn't as hard as it sounds.
2) Have the LLM recreate the project from scratch in another language, something like https://banteg.xyz/posts/crimsonland/. This can be easier to get initial results, but you're sure to hit tons of bugs due to the differences in implementations.
The 1st approach is more thorough, especially because you can find a matching C/C++ compiler and start doing actual decomp.dev-like work - binary matching functions so your source code compiles down to the exact bytes as in the original binary. This is the longest, hardest part, human community projects take years to complete, and LLMs still struggle with getting matches for 100%, so you might spend weeks-months, and tons of LLM usage - an agent can take like an hour to match a single 1000-byte function in worst case.
As a small note - you do not need to binary match 100% to have the game be absolutely playable. Compilers are often very tricky to lead, so you might already have the code that does exactly the same thing, but just a different local variable layout might make the compiler use different registers.
Fable should take credit for porting to iOS with a touch UI. But that's about it, the renderer and macOS port were already done, I agree that OP is paltering.
For that to be click bait it implies people wouldn’t have clicked on it if any other model were used. IMO the more interesting fact is they ported a game over to iOS.
I've been doing something similar for some of my favourite older games. But the "byte for byte" claim has me worried. Isn't simply decompiling the sourcecode from the binary and releasing that problematic?
It's not the "clean room" approach and companies could still claim it violates some kind of copyright and get it taken down.
That's my understanding. Decompilation is legally protected in the US, and you can do a reimplementation based on a decompilation. Sony v connectix is aiui the precedent.
Theoretically you could clean room by having different agents/models/context windows to do both decompilation and reimplementation. This is untested in court afaik and I don't think anyone wants to spend money to find out.
There was a non-clean room reimplementation of gta3 a few years ago. The gta publisher DMCAd and of course the fans who did it didn't have any money to fight in court (and probably couldn't find anyone who would take a big complicated case on such bad facts pro bono). https://www.gamingonlinux.com/2021/02/take-two-interactive-h...
No one seems to be worried about the fact that a vibe-coded app or conversion or rewrite is not copyright-able. It is not a derivative, it's a machine translation, without a human author.
So if that is released to the public, it's in the public domain, no license is applicable.
And maybe it wasn't even Fable, they might have downgraded to Opus.
This is the kind of frequent misinformation that makes me skeptical of Anthropic LLM claims. Whenever I compare them to GPT 5.5 on my web dev workflows, they seem to trade blows, even Fable, which I started testing since it was re-enabled.
Also I bet any decent LLM could have done such port. Think GLM 5.2 or similar which would probably work better because it doesn't constantly try to guess if I'm a terrorist trying to hack goverments or develop some biological weapon.
People just don't have the resources to compare LLMs and imply whatever they used is the best thing ever and unlocked some new workflow.
This project is a fork and all it does is add iOS support. Commits by the repo fork owner begin 19 hours ago, so very plausible those are done with Fable. But I agree it's very unclear to me if adding iOS support was some task only Fable could accomplish over prior models.
I spent countless hours on this game as a kid and as I got older I found that trying to go back and play the game got more and more difficult as the technology scaled beyond the platform it was originally intended for.
A great use for what AI can help with, especially in the hands of dedicated fans. Maybe I will find some time to try and experiment with custom maps or units, the modding scene of C&C Generals was always pretty lively.
Absolutely not to be confused with the equally AI-assisted recent port of Command&Conquer (1995) to the Atari ST. https://indyjo.itch.io/commandconquer
Red alert 2 was released in 2000, which means it was developed probably in 1998->1999.
Life was different back then. Source control systems were a LOT worse (this is CVS era for open source development). We certainly weren't in the current era where everyone wants to play these old games on their phones now.
What almost certainly happened is all copies of the source were simply lost. They may have sat on someone's hard drive, a team server hard drive, or somewhere else. It's possible they didn't have more than a few copies while development was ongoing.
Everything will be lost unless it's somebody's job to preserve it. It's pretty common to close game studios or lay off the entire development team while simultaneously scolding them about "stealing" IP so the predictable result is the code being lost.
I was bitching here the other day about GTA VI being locked down so I can't pass it on like a favorite book. But maybe if I just archive the whole package, a not-so-distant-future-ai will be able to rehydrate it onto any handy future platform at low cost.
Assuming nothing like DRM goes out of its way to prevent it, I’d be willing to bet significant money that by the time GTA6 is retro enough to require porting to “modern” platforms, precisely that sort of porting will not only be possible, it’ll be so commonplace that it won’t even merit an HN post when it happens.
reasonably it works quite close to the lingo, but this is way difficult, and not just from being rusty. steve had most things triggered on the animation frame, which opus hasnt quite figured out by looking at the code and pulling stuff out of the .dir
i do remember that playing at double scale was a lot harder in general, but theres a really clear cooldown missing between attackes
One big caveat with iPad and mobile, though, is battery usage. I strongly suspect that power consumption is the reason that a number of games made it to Mac, but not iPad.
Well interface on mobile devices vs traditional computers is a bit different. Game devs can’t even have consistent controller support. Supporting touch is almost never worth it.
I vibe code myself to sleep and implemented a rewrite of civ1 in Common Lisp. It works well, has all the DOS nostalgia I wanted (uses the same sprites etc.) 10/10 will continue doing this kind of shit.
> Built on EA's GPL v3 source release via fbraz3/GeneralsX (which did the heavy lifting of the macOS/Linux port — this fork adds the iOS/iPadOS port and a set of engine fixes)
Fable added 19 commits on top of the parent fork, which did not use AI.
> Long sessions on iPad can be killed by iOS for memory (~3 GB+ resident); the app exits to the home screen with no dialog. Session logs (current + previous) are in the Files app under the game's folder. Under investigation.
Wait. It's a port from a game from 2003. I don't think PC had 4 GB of memory back then (unless my memory is fuzzy, ah!): I mean, maybe some had that, but not the majority. I doubt the requirements for the original C&C Generals were 4 GB of memory.
OK, I just checked on a box of C&C Generals on eBay: requirement 128 MB of RAM (I know I could have asked a LLM, but checking a picture of an actual box is kinda fun).
I understand the need for a bit more graphics etc. but that's still a big jump: if the reqs were 128 MB or RAM for the PC, the game wasn't using that.
So we're talking something like a 32x inflation in RAM usage during the port (unless I didn't understand the caveat).
Why can't a game requiring 128 MB in 2003 run on machine 20 years more recent without using all the RAM?
Is there a plausible reason or are we to consider that when porting using Fable, we can expect the RAM usage of a program to go up by 32x?
EDIT: the original game has more asset than I would have guessed, skimming through the port's docs I found this:
> the game requires .big archive files (INIZH.big, MapsZH.big, etc.) totaling 4-5 GB. These files cannot be committed to repository due to copyright (EA Games property).
4 / 5 GB is not nothing. I wonder if the memory issue could be related to the way these are loaded?
32x memory isn't that big of a jump if you go from storing a bunch of low res, low color count textures to a bunch of high res, high color count ones. I don't know if that's what's going on here but given the advertised "DirectX 8 → DXVK → Vulkan → MoltenVK → Metal" rendering pipeline I could easily see some leaky abstractions there that end up consuming a bit more memory than originally.
The parent of the parent project has ground truth replays, which get compared to new PRs. The game uses lockstep networking, so this is required to prevent desyncs.
EA released the Generals source under GPL v3, the GeneralsX project got it running on macOS/Linux, and I've taken it the rest of the way: native iOS and iPadOS builds of Zero Hour, plus Apple Silicon macOS.
What works (all verified on a real iPad and iPhone):
Campaign, Skirmish, and Generals Challenge: full missions, objectives, cutscenes, saves
All audio: music, unit voices, EVA announcements, Challenge taunts, briefing FMVs
Touch controls built for RTS: tap select, drag a selection box, long-press deselect, two-finger camera pan, pinch zoom
Self-contained install: game data ships inside the app bundle
It's the real engine: unmodified game logic compiled for ARM64, rendering DirectX 8 → DXVK → Vulkan → MoltenVK → Metal. Not emulation, not streaming.
No game assets are included or distributed. You need your own copy (Steam sells Zero Hour) and a script pulls the data from your own account. Code is GPL v3.
Building: macOS is about four commands; iPhone/iPad needs Xcode and a free Apple developer account since you sideload your own build. Known issues (long-session memory on iPad, a rare backgrounding crash) are documented in the README.
Credit: fbraz3/GeneralsX did the heavy macOS/Linux lifting, TheSuperHackers keep the community codebase alive, and EA did a genuinely good thing releasing the source. The engine fixes I found are heading upstream so every platform benefits.
(And of course, not affiliated with or endorsed by EA, and sorry China had to deal with all of those particle cannons in that demo video)
You take credit for porting it to "Apple Silicon" macOS, both here and in the title, but that already seems to work upstream? On a quick look I didn't see any commit message of yours addressing macOS rather than iOS. What exactly did you add there?
When someone ported pylint to rust this place was full of ‘who will maintain this’ and met with blank stares when the answer was ‘what do you mean’ or ‘it’ll maintain itself’.
Good job. It was inevitable, but still someone had to, please excuse me, say the words.
Given the game is stable and the changes would be at the integration points, and Fable was able to do the direct integration, why would the answer not be “it’ll maintain itself” at some abstract level. The decision to maintain open source is up to the maintainers and I think the answer is “no one” 99.99% of the time, but I’ll wager if someone is willing to spend the tokens on it, a CI reintegration agent would do just fine in keeping it working as the underlying dependencies have required changes (which would really be only major changes in apple apis that aren’t backwards compatible.”
Pylint is different because it’s working against a necessarily dynamic wavefront that it has to keep parity with as it advances. All python changes, ecosystem adaptations, etc - and maintaining that with an AI harness in CI would never work. It would require a concerted effort and thought along the way.
So it’s sort of a different beast all together. In fact I think this is a great demonstration of using AI to resurrect technology built for X to work with Y, where X is dead and Y is current. Automating this feels like a net positive and because the original software is “finished” there isn’t decision making and strategy required.
These LLMs are remarkable. I used Opus to revive for myself abandoned software and bring it up to date with the latest versions of the frameworks so I could add some features. And there's other software which I vendor and merge in upstream changes and self-manage. This would have been a near-impossibility in the past.
"Who will maintain this?" appears to be "Me with an agent". And it's great.
I think the next 10 years or so are going to see a chucklefuck of games reversed thanks to LLMs, which can easily pattern match and operate on contrivedely optimized assembly and output reasonably accurate C/C++ code. I’m one of many right now using Ghidra + LLM workflow. It’s doing the thing it needs to and I’ve helped several communities revive and port their games this way. It is a huge time saver. While I’d personally prefer an actual source code leak, a working reverse job is good enough, even if it’s partial as long as it’s accurate.
I wonder if we’ll get to a situation where a new game is reversed in the first few months by a team effort. Right now it’s mostly solo devs, but a technical team that’s capable without LLMs is unstoppable with them, and given the nature of modding communities, the only thing they are missing is an LLM to grind away at the details of the game that would otherwise take years to find out.
If you think this port is related to tour point; The source code for Command and Conquer generals (and other C&C games) was released a while back. This port uses that source code. So this port is not based on reverse engineering. The port even states someone else (manually) already did the hard work of porting it to macOS and Linux (so not an LLM):
> Built on EA's GPL v3 source release via fbraz3/GeneralsX (which did the heavy lifting of the macOS/Linux port — this fork adds the iOS/iPadOS port and a set of engine fixes
Then the title is incorrect. Generals has been on the macOS App Store for years.
> Then the title is incorrect. Generals has been on the macOS App Store for years.
Neither the HN submission or GitHub repository says it's first or novel though? Just that it's (another) port of it?
10 years is far too pessimistic for this being a routine task, I think 2 years max. As you mentioned, you can already do this today by just giving GPT 5.5/Opus 4.8 an IDA/Ghidra tooling (a CLI or MCP, I have a custom CLI for it). You can start with the LLM going from the string anchors and renaming functions/globals, then when you have enough functions, the LLM can start working on typing - IDA has a very powerful typing API for HexRays-decompiled code, you can even type locals and it all persists in a DB.
My custom IDA CLI is just a simple thing on top of IDA Python's integration + ida-domain + some higher-level helpers, and works as a daemon with workers, so a stale/bad request doesn't corrupt an IDA DB (an issue I had when I was using idasql).
A bit offtopic, but: do you have any links to your efforts? I'm curious to see what other people do in this area.
Have you published your IDA CLI anywhere? I'd be interested to see what that looks like
Not yet, unfortunately, but I might in the future. To be honest, it's nothing unique. I got inspired by https://github.com/allthingsida/idasql which I initially used, but it had a lot of bugs, a big codebase size, and IDA's C++ API is really easy to misuse and corrupt a DB, so I had GPT 5.4/5.5 make a new one for itself based on IDA's Python SDK, which is official and doesn't need weird SQL hacks.
Then recently I found https://github.com/bkerler/ida_rpc which seems to be ~60% the same thing as the one I have, the only big difference is that I do not give any special commands to LLMs, they just have to write Python in scripts/inline heredocs to interact with IDA. This lets them do a lot more interesting things since they get a full programming language.
This is an example of how LLMs work with idagent (`ida` is implicitly imported, ida.types, ida.comments is helper's own wrappers): https://paste.debian.net/hidden/cf46a122
More interesting example that was used to let the LLM/me track the rename progress for the initial function renames + gaps (code-looking like bytes that weren't inside of functions, IDA's autoanalysis missed some real functions). Although the game turned out to be small enough with only ~1500 real game functions that needed renames, which was done in ~10 hours of agent time total I think (I didn't parallelize with multiple agents). https://paste.debian.net/hidden/bf458b3a
To be honest, you can probably have an agent vibecode a similar MVP tool to the one I have in about an hour-two :)
Would you please explain more your Ghidra+LLM workflow? What you are doing and how does the LLM help you? Thanks!
Not the person you asked but I frequently use Claude (Opus primarily) to reverse engineer embedded hardware. It uses a mix of Ghidra, Radare2, and just the arm-none-* tools. I can’t say I have a particular workflow though, I just say “we’re reverse engineering foo.bin. It’s the firmware for a servomotor. We talk to the servo over RS485 and it seems that if I send it command X it will sometimes silently reject the command. Can you dig into the data reception and command parsing layers to see if there’s an explanation. Let’s keep notes in @20260704-reverse-engineer-foo-motor.qmd”
It works great just like that.
I hope we get Skyblivion soon
Completely unrelated but I find it amusing in a good way that Oblivion is recognized more favorably now. I never understood the disregard for it (horse armor nonsense aside), as it has a very compelling, unique atmosphere and a not so terrible storyline/writing.
All Bethesda’s game generally suck without mods to a bigger or lesser extent. So it takes a while for a community of enthusiasts to appear but something like Oblivion or Skyrim were a much better experience 5-10 years after release than initially.
Of course then you have Starfield which is so unimaginable uninspiring that nothing can really be done to save it..
To me, the level scaling just completely annihilates the game. Why even have a leveling system if practically everything just stays leveled with you?
Exactly what I was going to say. Oblivion was the first Elder Scrolls game that had level scaling. It's just extremely lazy design that ruins any sense of progress/immersion. In Oblivion/Skyrim there are plenty of mods that remove the scaling, and end up with worlds that are vastly more interesting and immersive. I highly recommend Requiem.
I hate hate hate level scaling. I believe they also introduced it to WoW, which ruins the power fantasy of going back to a lower level area and kicking butt, or the fear of venturing in a higher level area and hauling ass out of there. I agree, lazy game design.
I think Oblivion's reception was mostly in relation to how people felt about Morrowind. Oblivion simplified a lot of what Morrowind did, which drew some ire. Atmospherically, though, people weren't happy that they moved from Morrowind's much more unique fantasy setting, full of massive fungi and swamp-striding bugs and weird demigods, and moved to a much more generic looking medieval countryside. That said, I also appreciate the game's reassessment, because I think some of the factions quest lines are among the best in the series.
Your take is very interesting, but please do not forget that pirating games is a crime.
I don't think the "it's piracy to use the code generated by an LLM because it closely resembles the code the LLM was trained on" argument has been fought in court yet.
Reverse engineering and pirating are not the same thing (although the former may certainly be used as a means to achieve the latter). As long as you aren't distributing the game, distributing code that legitimate owners of the game can use to run their game on more platforms is not a crime.
In systems engineering this was proven in court when you have one engineer writing specs and another implementing the "samish" system from those specs, but I'm not sure that would relate to any of the art assets made by the original authors of a game. I'd imagine any art, narrative writing or sound would still be considered IP, and without those things you don't have much of a game.
I suspect it won't stop people, and that it won't be much of an issue in a lot of cases. I wouldn't want to be the one to test it in any sort of court though. Not even on the other side of things, where it'll become even more of a nightmare to protect your indie IP on any form of platform which doesn't heavily regulate things.
Depends on the jurisdiction? However usually it is a civil matter not an actual crime..
IMHO, this is an actual good use of what sounds like a person guiding a model to do a mass conversion. Although, I wish the porting docs were a little wordsmithed by a human, the AI generated text style is grating.
The stakes are low, it’s mostly for fun and you can iterate on it. Compare this with Bun which was just like, “hey we converted everything to Bun to Rust from Zig, of course it works, what could possibly go wrong, I’ll totally write up a blogpost (that still doesn’t exist) explaining what we did, you can put this into your production environment soon!”
I don't really get the Bun thing. Bun is running Claude Code which is probably the single most actively used development app there is. You say this was a bad use of LLMs, but it's been in production for a while and I haven't heard of any evidence that Claude Code has increased a significantly larger quantity of errors, segfaults, etc, than before.
Some people, myself included, think that announcing a conversion from Rust to Zig as an experiment then jumping to putting it in the alpha train for public testing/consumption without any real explanation in the span of around 2 weeks is irresponsible and reckless.
Blogposts were promised, details were hinted, but no, it’s just full steam ahead because the AI worked so well. The converted unit tests all worked, all the synthetic tests are okay, so what are you complaining about?
At some point, it’s less about the technical questions and more about getting that pesky human buy-in.
They are looking for a different human buy-in.
"Yes, the AI rewrote the code. No, we do not pretend that we've scrutinized the code, or that we understand it. It works, tests pass, so we don't care, and so shouldn't you."
The "recklessness" is offered as the new normal. Because it kinda, well, works for them.
The recklessness kinda works for everybody until some point. Go fast and break things... then cash out before investors realize, unless you manage to capture the market so you can keep breaking things because people will swallow.
What's working for them is having a huge amount of resources and very good people to design a cutting edge agent harness, RLHF the hell out of their models, and build out a tremendous amount of inference capacity. I'm sure their process for making code changes in any of their client apps is very fast, but a TUI built around a chatbot is also not a particularly complicated application. So yes it's working for them, but the vibecoding that they are selling is clearly not what they are doing in practice.
They’re not talking about the chatbot TUI. The chatbot TUI was and is in JavaScript. They’ve ported the JavaScript runtime.
Not GP but the js runtime has a long tail of case edges you simply can't emulate with a single app.
It surely does. I’m also extremely worried about the way they’ve decided to go with the port.
What does Bun’s governance look like? Now that Anthropic bought the company are there significant external contributors that would expected to have input on a decision like this?
And why buy it when they could have just called it Run and do the Rust conversion anyways? The license prohibits it, they don’t need the team’s expertise anymore, since they’re running full AI vibecode mode. Makes no sense to me
Seems pretty clear that they do need the team, to direct the LLM effectively.
Also they're probably interested in the team just as an acqui-hire of good developers, and they're probably interested in the marketing value of converting the actual bun to rust via LLMs. But mostly I'd assume it was about needing the team to effectively direct the LLMs.
IMO it’s reckless to not pin down ones dependencies. No need to pull the latest experimental hotness
I get that and I can see an argument that they didn’t really put it as stable, but I suspect the reason it is not the stable version right now is from the massive pushback as other projects and companies started pulling support for Bun because of the loss of confidence rather than any other reason.
How about testing the output? Seems like the ultimate test. If the output's still good, I guess the rewrite didn't hurt.
Testing can expose errors, but it can’t prove correctness.
Kindof.
The problem is: quickly fixing problems (or preventing problems) benefits from having a good understanding of what the code is doing.
If you do have a suite of automated checks that's comprehensive enough that if it passes, no one will have any problems with the result, I think I'd agree. -- I don't think we're quite there at the point where "programming" is coming up with that suite of automated checks and then just not regarding the source code of the program itself.
I agree that the Bun rewrite is much more reasonable than knee-jerk reactions imply, however:
- I don't think Claude Code is using the Rust version yet in their official build
- Claude Code is not a particularly complicated piece of software from an engineering perspective (nor it's particularly well-engineered, at least at the moment).
So in my book "it runs Claude Code" would be pretty weak evidence that the rewrite is going to be successful (the tests they've done are much better evidence, but that's a topic for another time).
> - I don't think Claude Code is using the Rust version yet in their official build
No, I'm pretty sure it is, actually, since June 17:
https://code.claude.com/docs/en/changelog#2-1-181
>> Upgraded the bundled Bun runtime to 1.4
Now, Bun 1.4 doesn't seem to officially exist on https://bun.com/blog or https://github.com/oven-sh/bun/releases, so I can't be 100% sure this is the Rust version. However, I have to do some patching of the Claude Code binary to get it to run on my OS, and version 2.1.181 coincided with some changes that make suspect it's using Rust now.
https://news.ycombinator.com/item?id=48609168
https://grigio.org/bun-1-4-the-controversial-ai-driven-rewri...
> 13,044 unsafe blocks in the resulting Rust code (hand-written Rust projects of similar size average ~73)
Grok is this true?
I've heard the meme that AI written rust code is absurdly full and safe blocks but... that's pretty funny.
Hang on. A claim like that can be verified with a single grep! Give me a minute...
Hey, that's progress!> I've heard the meme that AI written rust code is absurdly full and safe blocks but... that's pretty funny.
If I understand what happened here correctly this isn't really a case of any such meme, but the result of the porters (heh) telling the LLM to directly convert zig code using unsafe to match the previous code "exactly".
I.e. more like using the LLM as a fancy version of c2rust [1] (which would result in just as much unsafe) than a result of LLMs reaching for escape hatches too liberally.
[1] https://github.com/immunant/c2rust
This is ironically a skill issue in prompting, especially if they had Fable access - or, more likely, they just really, truly don’t care.
It's unironically a good practice when you port from an unsafe language (C/Zig) to Rust. Porting isn't refactoring. One should keep the logic mapping one-to-one as much as possible.
The high number of unsafe blocks is a good sign.
Counting instances of "unsafe {" is pretty useless. Unsafe is needed in "safe" code. What it allows is to create a boundary where the caller is the one that uphelds the contract. If the unsafe is in an internal library, it’s much more difficult to misuse.
I agree Claude Code is seemingly (currently) not very well-engineered but I think you may be moderately underestimating how complicated it is/necessarily has to be.
What are those complications?
Last I heard Claude Code devs were trying to compare their app to a game engine or rendering system.
This was summarily ridiculed. Are you saying that writing a game engine is easier than writing Claude Code?
> it's been in production for a while
Huh... it looks to me like bun has yet to cut a release post Zig->Rust port (the latest one on github is still on a branch that says it's written in zig in the readme). I assume that nothing is using the rust version yet...
Which also cuts against the complaints about "of course it works [...] you can put this into your production environment soon!" since they don't seem to be asserting either of those things.
The real problem is they explained nothing and just caused a lot of mistrust. The lead developer at Bun working on this project does post here from time to time and I have never seen him answer any of this. I admire his enthusiasm, but this was badly handled mostly from Bun’s side which lead to a bunch of dogpiling.
When someone on another social media platform commented expressed some concern, his response was to ask him what the explicit bug he was talking about was and that he would generate a fix. That sound you hear is the woosh as the point flies by. And in general, this just feels like a consistent problem with Bun.
When you hear a woosh as the point flies by, I see someone attacking a project for using AI rather than any concrete technical reason. Jared's question is to disentangle an actual Rust-related bug report from someone who likes to complain about AI.
I have yet to hear any evidence that the Rust rewrite was harmful. I have no emotional investment in Bun (which I'd never heard of before the rewrite), or Zig (which I also didn't know about), or Rust (which I think is neat and that's about it), so I'm about as unbiased as you can get and from what I saw the conversion was done well, and I haven't heard of massive bugs resulting from the rewrite.
It is probably fine, it is kind of a best case scenario: porting a good code base with lots of unit tests, all hand-written. Not much can go wrong here as the LLM is kept in check by the original code, the tests, and the fact that the topic (a JS engine) is well documented.
The problem is what comes next. They now have code that they don't understand, and they are likely to work on it with AI in the future, but the new features they may introduce later will not have the luxury of hand-written tests and a reference code. So, unless they undertake the massive effort needed to fully understand the Rust code and deal with all these "unsafe", quality is very likely to go down, Microslop style.
It’s always been a fallacy to think that large organizations have code which is understood. There are people somewhere understanding small parts up until the next round of layoffs.
Millions were invested in this project where they fired the expensive experts (me included) and replaced with a small army of cheap devs (which was actually more expensive and less productive than just retaining even one of the experts would have been). Couple years later the inevitable happened and the whole thing was thrown into trash. Code without anyone who understands it is just a liability.
> which is probably the single most actively used development app there is
Seems doubtful, I'd put money on it being something like Visual Studio or Visual Studio Code. Maybe CC could claim the (odious) title of most actively used vibe-coded development app, though.
> Yes, Claude Code uses Bun. In fact, Claude Code relies on it as a core dependency and ships as a self-contained Bun executable.
I... somehow did not know that.
You missed the day when they had their bun build misconfigured which ended up leaking the entirety of Claude Code's codebase? (I wish I was joking)
The best part is how little it mattered. Everyone just shrugged.
Pretty sure the author of Bun stated this was not related to Bun here on HN.
Wait is the new CC running on the vibe coded Bun?
I have a port of BuildGDX in the project backlog that was basically just throwing Claude at it to go from Java to .NET. The only thing it really got hung up on was Java's byte being signed.
What I ended up with was a port of Duke 3D that uses half the allocated RAM as DukeGDX.
The model did the work, probably has it all in its context window, so it may actually be better placed here to write the docs.
IMHO, this is an actual good use of what sounds like a person guiding a model to do a mass conversion.
This is quite the understatement. Actually, it's probably the understatement of the year.
"Pretty good, not bad, great use case".
Dude. Fable fucking did what?
It added iOS support, the upstream repo had already ported the game to Linux and MacOS.
It hallucinated that people play games on Apple products.
clickbait, right? it did not port it to macos, that was already done. all fable did (and it might've been opus for all we know) is adding the last few commits for ios/ipados support after all of the heavy lifting was done
still cool but the title makes it sound like it was done from scratch
Diff of the changes Fable added to the parent fork (which does not appear to have used AI): https://github.com/ammaarreshi/Generals-Mac-iOS-iPad/compare... for those curious.
That is really not a lot. A human could have easily done this. How much did it cost / how many tokens were spent?
Ya, because the upstream repos already did the majority of the work to port the game to Linux and MacOS. This fork used Fable to add iOS support with touch controls.
Ah, yet another clickbait post, great.
The title is contradicted by the README:
> Built on EA's GPL v3 source release via fbraz3/GeneralsX (which did the heavy lifting of the macOS/Linux port — this fork adds the iOS/iPadOS port and a set of engine fixes)
It’s cool that someone took the extra steps to run it on iPad and iOS, but if the README is correct then it was already ported to macOS? Going from Mac to iPad isn’t trivial, but it’s a much smaller jump than porting into the Apple world the first time.
> (tap-select, drag-box, long-press deselect, two-finger scroll, pinch zoom)
This is another "AI-ism" I noticed, mostly in coding agents - they seem to be very fond of making up new "compound nouns" (and occasionally verbs) to sum up relatively complex and specific concepts into single noun phrases. I wasn't sure if it's to save tokens or if the AI uses this to get a concise "identifier" for a concept that it can refer back to later, but I found it very noticeable.
I find the resulting sentences hard to read, though it does get better if you're aware of that tendency and make a conscious effort to parse the noun phrases. But I guess since it's just intermediate output from coding agents and not text for essays or blog posts, it's fine.
Haha, I do that too sometimes.
It's a thing in some Germanic languages. Instinct is to merge nouns into word, e.g. 'lawnchair', but that gives you a red squiggly line, but 'lawn chair' also looks wrong, so 'lawn-chair' is the middle ground.
First time I realised this was GCSE History lessons, looking at first world war posters like this one and going "huh, to-day with a hyphen…"
https://www.iwm.org.uk/collections/item/object/27774
Badnami is Persian and literally means bad-name (like defamation of character).
English word origins are a fascinating rabbit hole.
> English word origins are a fascinating rabbit hole.
My favourite example of which is Northern Ireland's Orange Order.
The colour is orange, because that was the Royal colour of the family of the monarch it was named after, William of Orange, who was Dutch, titled after the principality of Orange which is named after the city of Orange which is French which got its name from the Celtic word for forehead or temple.
The colour is named after the fruit, the fruit's name is a corruption "a norange" -> "an orange", which goes back to naranja which goes to Arabic which goes to Classical Persian which goes to Sanskrit.
Meanwhile, the dutch word for the fruit is sinaasappel, Chinese apple, compare with the English word "mandarin" used for many different Chinese things.
I’m (sorry for the lack of humbleness) a very fluent non-native speaker and writer, and this is by far my biggest challenge with Claude. It stitches together 2-4 advanced concepts into one or two words and I always have to ask it to “unpack”.
I don’t think it’s easy on native speakers when it happens, but it’s even harder when you’re not.
Its hard for native speakers. Information density makes for rough reading.
Still debating whether these are actually information dense or not. Complexity gives the appearance of density, but these sentences always come in whole pages at a time while often failing to deliver the needed information.
Maybe LLMs are just Germans.
That's the G in AGI.
Artificial German Ingenieurwerk
This isn't good news...
Yes! It's infuriating. I've tried prohibiting them in my AGENTS.md but it's not 100% effective.
--- AGENTS.md ---
## Plain words, not jargon
Don't use jargon-as-shorthand. Say what you actually mean.
- Don't say "load-bearing assumptions". Say "the assumptions the xyz depends on".
- Don't say "cross-service". Name both services, e.g. "whether the X service can derive duration without calling the Y service". "Cross-X" is confusing because it hides which things are involved.
- Don't deliver verdicts as abstract noun-phrases like "Cross-RCA double-counting is unfounded". Say it plainly: "I checked whether the same root cause gets counted twice across RCA runs, and it doesn't."
## No earth-shattering declarations
Don't hype findings. Skip "a critical finding changes everything", "now I have the full picture", "this changes the game", etc. Just state what you found plainly. Most findings are ordinary; report them that way.
## Don't reflexively hedge a "yes"
When the answer is yes, say yes. Don't soften every positive answer with a caveat: it erodes confidence in the "yes". Only add a caveat when there's a genuine, specific uncertainty worth flagging.
Is "jargon-as-shorthand" not exactly that?
On another note, I find AI instructions like this (e.g. "Don't hype findings. Skip "a critical finding changes everything",...") more harm than good in my own uses. It changes behavior in subtle ways that makes it less predictable to me. I'd rather it has its own AI-isms and quirks, that I've fully gotten used to, and I know what to expect. I know when it says certain things, in certain ways, that's what I think it means. Quirks and AI-isms don't annoy me, I get used to how it states things.
Lol! Good point. I did use Claude to write the rule, and it ironically wrote the exact thing I asked it to avoid. I agree that it might be best to use the model as-is, to get the intended experience.
Also I find it interesting to learn the jargon. It basically compacts information in fewer words, although more complex words. But when you are familiar with the jargon, you can unpack the sentences in your mind. And like that, you need less text to read and write prompts. So less reading, writing, and tokens!
Yeah, I wonder if part of the reasoning is built around those phrases, and therefore it can't get rid of them easily.
> "now I have the full picture"
I always interpreted that phrase as a sort of marker to delimit the phase in which it explores the codebase and gathers information from the phase in which it implements the changes.
Not sure if it's still done, but I think some months ago there was discussion that some of the phrases are injected by the inference loop to "steer" the model - e.g. "But wait" if a thought block was too short etc. Obviously such phrases couldn't be influenced by the prompt.
Yes these things happen as part of RL Training. Same way that you can see the "But wait ..." phrases in thinking traces. They get rewarded.
Out of curiosity, how does something like "But wait..." get rewarded?
I thought it was just Opus 4.7 and 4.8 that did this. Do other models do this too?
Anyway: in my case Opus absolutely did not follow a similar instruction in the CLAUDE.md file. (But then again: it hardly followed _any_ CLAUDE.md instruction properly)
It's stupid, but have you tried telling it to follow it? "Make sure to follow the guidelines from AGENTS/CLAUDE.md" etc, seems to (sadly) make some difference in most harnesses and models.
For me, Opus 4.8's thinking traces for the chatbot will sometimes willingly ignore instructions, saying something along the lines of "I've noticed an instruction in the system instructions that states I shouldn't do this, but if I don't do this, I'll not provide the answer the user is looking for. I will ignore that instruction."
In all my CLAUDE.md and AGENTS.md files I have a line to fix pre-existing issues. I don’t know what it is but every agent I’ve tried through Claude code (including deepseek and GLM) will actively try to avoid fixing pre-existing issues. I even added hooks to Claude and git to try to get them fixed. If I leave a bailout for myself agents will find it sit and ask if it can push with no-verify or an environment variable in the case of Claude hooks instead of trying to fix an issue it didn’t cause.
I’d recommend to instead write a de-slop skill that instructs to launch a sub agent with fresh context, and analyze for such phrases in the new commits, and remove those. Find -> fix just works better than preemptive instructions, in my experience.
And if you manage to do this automatically before committing, you’ve built the backpressure everybody is talking about.
Can you point to some examples? Also I wonder if this needs to be very model/harness specific? Like even model version, subversion.
And probably that should be run in different harness or with custom system prompt? Since they introduce quirks and glitches as well.
(somehow this motivated me to resurrect HN account)
NO DEFORMED FINGERS!!!
> Yes! It's infuriating.
No, it’s good. When they stop doing this, it’ll be harder spot the machine slop.
It’s crazy that straightforward rules like this can’t be followed and yet they think they can gate Fable
"The model refuses to follow my specific word detail prompts" and "The model refuses to perform hacking attempts" are on the same side of the model refusing to do something baked into it though.
That rule can be followed, but it gets a little tricky when mixed up with the other ten thousand rules that it's following at any given time.
Excessive-hyphenization is ai-hyperfixation
That’s… about how I might have written that.
That and finishing a statement with an em dash — that’s what AI does.
That, and also the very long comma-separated lists with sometimes 10+ items.
FYI, AI isn't fond of a goddamn thing. They have token prediction quirks that don't follow typical English.
Few ever cared. Find one non-pedant who would object to the personification that follows:
In the affective sense, evenings don't settle, and street lights are not drawn out, windows don't blink, and wind isn't restless. Weather can neither be angry, nor rage.But such personification is a natural part of how the English speak.
Personification =/= anthropomorphization
Personification is a figure of speech. What you say is technically correct but we don't need to declare this every time humans discuss how LLMs work.
> Built on EA's GPL v3 source release via fbraz3/GeneralsX (which did the heavy lifting of the macOS/Linux port — this fork adds the iOS/iPadOS port and a set of engine fixes).
I have a Renegade one going that does all of this from scratch (different engine) so it's def more than capable!
Regardless of other ongoing work, title seems inaccurate? Doesn't sound like fable did any porting to macos
Old renegade? Damn that was one of the first app.I played on a pc.bqck when I had 8086 hercules graphics card. Bring it back please!
I assume he means Command and Conquer: Renegade
Right? All Fable did was a ported an already cross platform project to ios. Does not look like any sort of heavy lifting there, opus 4.6 would do just fine
I read this and laugh a bit because just 7 months ago the bar was so much lower and now we go "well duh of course it was able to make a working ios app from a game made 20 years ago... a game that was made 3 years before the first iPhone"
Was the bar that much lower, or is that some people on this thread are misrepresenting what the project actually is?
EA Games open sourced the original C&C Generals source code a year ago.
GeneralsX is a fork of the original source code. The fork changes the code to be easier to be ported to other platforms, which GeneralsX provides native Linux and macOS builds.
This project adds a iOS target for the GeneralsX project, the iOS port was made using Claude Fable.
It is cool that a LLM was able to create a iOS port? Yes, but saying like if it was something that was hard or that it would take too much time to do before LLMs is a bit disingenuous in my opinion, especially because the GeneralsX had already done the bulk of the effort of making the code portable in the first place, and that there was already a macOS port.
For reference, the iOS port only needed to add 2,179 lines of code on files that already existed on GeneralsX, and that's not excluding comments, which Claude loves to add some LARGE comments, and things that are iOS app specific, like the app's Info.plist.
"it was able to get a macOS port of a 20 year old game to run on iOS"
still very cool, and sci fi not long ago
This needs a backport to Winx64 since this game runs like crap on modern windows
I wanna know if these techniques would be useful for Emperor: Battle for Dune (2001). It's the first 3D RTS by Westwood Studios, predating C&C Generals by just a couple years. It's popularity was hampered by intellectual property disputes and a introduction of a new faction that diverged from the book series lore. The gameplay, soundtrack, and campaign missions were awesome.
I remember that game! Cinematics! and some units had dune realistic shields so when hit with laser, both attacker and defender died. I don't think i've finished it, ending had some worm timer mission i couldn't get to in time.
Try it before July 7 when Fable disappears from Claude Code subscription pricing.
Where's it go after that?
Billed at unsubsidized (and very expensive) API rates.
This was one of the best RTS of the era. Still holds up today. The music was also very good.
Emperor was a great game. My only real complaint was the five sub-factions seemed to be imbalanced. I’d like to revisit to see if the was missing something.
Let me give it a go :)
Came here to see if anyone mentioned Dune Emperor. Would love to see someone succeed
Legend in the pub.
This is not Dune 2000 ? https://www.openra.net/download/#linux
No, this was a far superior sequel to Dune 2000.
I loved this game. First RTS I ever played :)
Amazing. I have always maintained that Fallout 1 and 2 have nearly perfect UI for mobile. RTS games are hard to port directly while turn based games seem like a very natural fit, as long as they aren’t very reliant on full keyboard control. Fallout does not!
no way fable did this. It would have stopped after the words "command and conquer" and nerfed you to opus (while also landing you on some nsa watch list)
I’ve been using it to use Ghidra to do reverse engineering for modding Zelda: Tears of the Kingdom. Pre-ban it would flag immediately, post-ban it _rarely_ flagged anything and when it did I realized I could just make a memory telling it to convert reverse engineering speech into game development speech, not mentioning pointers, memory, addresses and decompiling. Then the flags mostly went away.
You can sidestep flags by just compacting and then changing the model back at any rate.
post-ban I've even had Opus 4.8 say it cannot let me continue (I was analyzing a nodejs heap dump)
lol, I'd expect that as it starts reading of sections of code dealing with the chinese and terrorist factions.
For any fellow idiot following behind, the below error means you haven't paid for the game in Steam.
> "ERROR! Failed to install app '2732960' (No subscription)"
This is of course mentioned in the read me.
The issue with these kind of porting is edge case bugs - far smaller project/physic simulation has hit the same thing especially when original code isn't exactly clean, or sometimes only worked because of a logic bug.
This means you can play for maybe 10 minutes on the happy path but just as you are getting into the zone either a CTD or some strange event would make the game/simulation unplayable.
And while debugging is made easier, it's much more effort than telling the model to convert the code. Hence it's usually not done in these demos.
This is a OS port (iOS) of an existing functional and maintained fork (MacOS) of the official release (Windows).
Most of these low-hanging bugs would have been caught upstream by now.
> rendering DirectX 8 → DXVK → Vulkan → MoltenVK → Metal
Am I reading that right? It makes API calls that go through 5 different layers before actually getting rendered? That's kind of crazy. I'm surprised it works, although I guess the underlying libraries are solid enough that it shouldn't be unexpected.
Technically there're just 3 layers: DXVK over MoltenVK over Metal. D3D8 and Vulkan here are just the APIs implemented by those adapter layers.
There're some D3D implementations over Metal that could skip the Vulkan layer but none implement the old D3D8 so you'd still need another layer that implements e.g. D3D8 over D3D9-11. Also, DXVK and MoltenVK have got a lot of traction and fixes on their own, so they're probably the most accurate pipeline for D3D on Metal.
Apple never released a driver that supports Vulkan out of the box, therefore MoltenVK was born, which translates Vulkan IR to Metal source then recompiles to Metal shaders.
This was the pipeline in Proton for macOS (I'm not sure if it's still is the case, been quite a while since I checked).
All right, when someone will do this for Railroad Tycoon Deluxe, Master of Magic, Master of Orion II, I will have to waste hundreds of hours playing these again... And it will hopefully be much more fun, because the computer "AI" will most likely be stronger / more interesting.
You can do this yourself with LLMs, but I admit that it's still not a trivial process. For the actual best results and the highest chance of progressing quickly, you really need a $200 OpenAI/Anthropic sub and a lot of free time. I seriously recommend OpenAI over Anthropic for this, as in my experience GPT 5.5 is far more thorough in reverse engineering and makes mistakes less often.
Then, you first need some tooling, either Ghidra (open-source) or IDA (paid), and some tooling to expose them to an LLM. I have a custom IDA Python-based CLI that lets LLMs trivially call into IDA's Python APIs from CLI, but there are tens of different Ghidra/IDA MCP/CLI/SQL projects out there.
After that, it becomes more mechanical, you just let the agent (or multiple agents) explore and start renaming (easier to start with functions + globals), better if it's something that's directly applied to the suite you're using, so that all names show up everywhere. This is actually quite a quick process, especially for older/smaller games. After you have enough function names, you need to instruct and have LLMs add actual types, so that the decompile doesn't have raw casts and offsets, but real fields + types. They will also need to apply types to globals and functions.
Afterwards comes the hardest part - you can export this very well named/annotated decompile, and do one of:
1) Have the LLM try to directly polish the code enough to be compilable. Despite of the decompile quality, this isn't as hard as it sounds.
2) Have the LLM recreate the project from scratch in another language, something like https://banteg.xyz/posts/crimsonland/. This can be easier to get initial results, but you're sure to hit tons of bugs due to the differences in implementations.
The 1st approach is more thorough, especially because you can find a matching C/C++ compiler and start doing actual decomp.dev-like work - binary matching functions so your source code compiles down to the exact bytes as in the original binary. This is the longest, hardest part, human community projects take years to complete, and LLMs still struggle with getting matches for 100%, so you might spend weeks-months, and tons of LLM usage - an agent can take like an hour to match a single 1000-byte function in worst case.
As a small note - you do not need to binary match 100% to have the game be absolutely playable. Compilers are often very tricky to lead, so you might already have the code that does exactly the same thing, but just a different local variable layout might make the compiler use different registers.
How is it done "using Fable" when the first commit was Feb last year??
He forked GeneralsX and added just the last few commits.
Still seems weird to give fable credit when the heavy lifting was already done.
Fable should take credit for porting to iOS with a touch UI. But that's about it, the renderer and macOS port were already done, I agree that OP is paltering.
The port was done by Fable.
Probably not exclusively using Fable.
Yeah which is a bit underhanded. Because the implication of "using Fable" is that it was done in under ... a week? So it's just a bit of click bait.
For that to be click bait it implies people wouldn’t have clicked on it if any other model were used. IMO the more interesting fact is they ported a game over to iOS.
I dunno... Command and Conquer ported to macOS/iPad in 18 months using AI coding agents probably wouldn't have the same ring to it
The port to MacOS is from the parent upstream repo, which also has it working on Linux, this fork added iOS support.
That's nearly every single article on the front page of HN nowadays that talks about AI related stuff
It wasn't, this is just another free marketing piece for Anthropic.
I'm doing something similar, using AI to make Battle for Middle Earth (same engine) "open source" with AI: https://github.com/dginovker/BFME-Source-Code
I've been doing something similar for some of my favourite older games. But the "byte for byte" claim has me worried. Isn't simply decompiling the sourcecode from the binary and releasing that problematic?
It's not the "clean room" approach and companies could still claim it violates some kind of copyright and get it taken down.
That's my understanding. Decompilation is legally protected in the US, and you can do a reimplementation based on a decompilation. Sony v connectix is aiui the precedent.
Theoretically you could clean room by having different agents/models/context windows to do both decompilation and reimplementation. This is untested in court afaik and I don't think anyone wants to spend money to find out.
There was a non-clean room reimplementation of gta3 a few years ago. The gta publisher DMCAd and of course the fans who did it didn't have any money to fight in court (and probably couldn't find anyone who would take a big complicated case on such bad facts pro bono). https://www.gamingonlinux.com/2021/02/take-two-interactive-h...
Sweet!!
No one seems to be worried about the fact that a vibe-coded app or conversion or rewrite is not copyright-able. It is not a derivative, it's a machine translation, without a human author.
So if that is released to the public, it's in the public domain, no license is applicable.
Title is click bait.
This started back in February and looking at commits, Fable did only a small part of the latest commits. 19 commits out of 2000:
https://github.com/ammaarreshi/Generals-Mac-iOS-iPad/commits...
And maybe it wasn't even Fable, they might have downgraded to Opus.
This is the kind of frequent misinformation that makes me skeptical of Anthropic LLM claims. Whenever I compare them to GPT 5.5 on my web dev workflows, they seem to trade blows, even Fable, which I started testing since it was re-enabled.
Also I bet any decent LLM could have done such port. Think GLM 5.2 or similar which would probably work better because it doesn't constantly try to guess if I'm a terrorist trying to hack goverments or develop some biological weapon.
People just don't have the resources to compare LLMs and imply whatever they used is the best thing ever and unlocked some new workflow.
I have seen little improvement since Opus 4.6.
This project is a fork and all it does is add iOS support. Commits by the repo fork owner begin 19 hours ago, so very plausible those are done with Fable. But I agree it's very unclear to me if adding iOS support was some task only Fable could accomplish over prior models.
>No game assets are included or distributed. You need your own copy (Steam, ~$5 on sale).
Damn, I still have the CD in one of my unopened boxes from our last move.
I spent countless hours on this game as a kid and as I got older I found that trying to go back and play the game got more and more difficult as the technology scaled beyond the platform it was originally intended for.
A great use for what AI can help with, especially in the hands of dedicated fans. Maybe I will find some time to try and experiment with custom maps or units, the modding scene of C&C Generals was always pretty lively.
Good job, but the parent fork already did macOS, so this wasn't too hard.
Absolutely not to be confused with the equally AI-assisted recent port of Command&Conquer (1995) to the Atari ST. https://indyjo.itch.io/commandconquer
Is there any hope for Red Alert 2?
Looks like EA did open source the game (only the first maybe)
https://github.com/electronicarts/CnC_Red_Alert
This seems to be the most active port saying it works on a Mac/Linux https://github.com/Daft-Freak/CnC_and_Red_Alert
I wish they open sourced RA2 - I love that game, I heard they lost the source code :/
Yes, they have also lost Tiberian Sun and Firestorm I think.. very unfortunate.
That's wild. How does that happen?
Red alert 2 was released in 2000, which means it was developed probably in 1998->1999.
Life was different back then. Source control systems were a LOT worse (this is CVS era for open source development). We certainly weren't in the current era where everyone wants to play these old games on their phones now.
What almost certainly happened is all copies of the source were simply lost. They may have sat on someone's hard drive, a team server hard drive, or somewhere else. It's possible they didn't have more than a few copies while development was ongoing.
Everything will be lost unless it's somebody's job to preserve it. It's pretty common to close game studios or lay off the entire development team while simultaneously scolding them about "stealing" IP so the predictable result is the code being lost.
You can always play it in the browser https://news.ycombinator.com/item?id=45991853, sadly no Yuri's Revenge is possible there though
they lost the original assets so afaik they arent gonna make a remaster
cnc-ddraw i think would get it to run fine on a steam deck though, so you should be able to play it without much issue
I was bitching here the other day about GTA VI being locked down so I can't pass it on like a favorite book. But maybe if I just archive the whole package, a not-so-distant-future-ai will be able to rehydrate it onto any handy future platform at low cost.
Assuming nothing like DRM goes out of its way to prevent it, I’d be willing to bet significant money that by the time GTA6 is retro enough to require porting to “modern” platforms, precisely that sort of porting will not only be possible, it’ll be so commonplace that it won’t even merit an HN post when it happens.
ive had opus try movin Merlin's revenge up from director/shockwave.
the result: http://jhedin.github.io/merlin-s-revenge/
reasonably it works quite close to the lingo, but this is way difficult, and not just from being rusty. steve had most things triggered on the animation frame, which opus hasnt quite figured out by looking at the code and pulling stuff out of the .dir
i do remember that playing at double scale was a lot harder in general, but theres a really clear cooldown missing between attackes
Generals. I never played this one. 2003? So you have to buy it on steam then this installer will allow you to play it on iPad?
It needs the assets from the original game. The creator of this project can’t legally redistribute those assets, so you have to provide them yourself.
Got it. Think I understand. Wow so retro.
Very cool.
One big caveat with iPad and mobile, though, is battery usage. I strongly suspect that power consumption is the reason that a number of games made it to Mac, but not iPad.
Well interface on mobile devices vs traditional computers is a bit different. Game devs can’t even have consistent controller support. Supporting touch is almost never worth it.
I have wireless game controllers for both Mac and mobile. They do support them.
In the old days this would have required a proper team...
The code appears to be based on other people's forks:
> The naive plan (port EA's raw source) is a multi-month job. The actual job was "port the best community fork," which was a one-session job.
https://github.com/ammaarreshi/Generals-Mac-iOS-iPad/blob/ma...
Well, like most stuff used in AI training.
Still, it represents a possible way how AI gets rid of team members.
Worked for me; it was a nice surprise.
I vibe code myself to sleep and implemented a rewrite of civ1 in Common Lisp. It works well, has all the DOS nostalgia I wanted (uses the same sprites etc.) 10/10 will continue doing this kind of shit.
> rendering DirectX 8 → DXVK → Vulkan → MoltenVK → Metal
Another great case study in why native Vulkan drivers would be a boon for Apple's mobile computing. That's quite the render pipeline...
I wonder if this will work on my iPad 3, maybe with some Swift... 3 backport code?
I just noticed a Flatpak folder in the repo. Does MacOS Support Flatpak somehow??
upstream is a MacOS+linux build. https://github.com/fbraz3/GeneralsX.
Does this work with Generals Online (Zero Hour mod)?
I tell folks there's a chance GTA6 will be ported to PC before it's officially released to PC.
This is one of the best of Command and Conquer games.
Tiberian Sun next.
Finally, I can play Zero Hour everywhere
Do homeworld next *_*
Absolutely insane that Fable 5 was able to pull this off although I'm curious how much it cost
It seems it didn't:
> Built on EA's GPL v3 source release via fbraz3/GeneralsX (which did the heavy lifting of the macOS/Linux port — this fork adds the iOS/iPadOS port and a set of engine fixes)
Fable added 19 commits on top of the parent fork, which did not use AI.
You can see the diff of what Fable added here: https://github.com/ammaarreshi/Generals-Mac-iOS-iPad/compare...
Very curious how much it cost to do this.
someone do it for debian, omg. i use debian family, it has been years, i haven't played this gem
I can't tell you how many new hours I've poured in it since bringing it to my iPad
fbraz3/GeneralsX
This is an actual dream come true
Right!!
> Long sessions on iPad can be killed by iOS for memory (~3 GB+ resident); the app exits to the home screen with no dialog. Session logs (current + previous) are in the Files app under the game's folder. Under investigation.
Wait. It's a port from a game from 2003. I don't think PC had 4 GB of memory back then (unless my memory is fuzzy, ah!): I mean, maybe some had that, but not the majority. I doubt the requirements for the original C&C Generals were 4 GB of memory.
OK, I just checked on a box of C&C Generals on eBay: requirement 128 MB of RAM (I know I could have asked a LLM, but checking a picture of an actual box is kinda fun).
I understand the need for a bit more graphics etc. but that's still a big jump: if the reqs were 128 MB or RAM for the PC, the game wasn't using that.
So we're talking something like a 32x inflation in RAM usage during the port (unless I didn't understand the caveat).
Why can't a game requiring 128 MB in 2003 run on machine 20 years more recent without using all the RAM?
Is there a plausible reason or are we to consider that when porting using Fable, we can expect the RAM usage of a program to go up by 32x?
EDIT: the original game has more asset than I would have guessed, skimming through the port's docs I found this:
> the game requires .big archive files (INIZH.big, MapsZH.big, etc.) totaling 4-5 GB. These files cannot be committed to repository due to copyright (EA Games property).
4 / 5 GB is not nothing. I wonder if the memory issue could be related to the way these are loaded?
32x memory isn't that big of a jump if you go from storing a bunch of low res, low color count textures to a bunch of high res, high color count ones. I don't know if that's what's going on here but given the advertised "DirectX 8 → DXVK → Vulkan → MoltenVK → Metal" rendering pipeline I could easily see some leaky abstractions there that end up consuming a bit more memory than originally.
AI is a data Xerox you can copy and transform anything with it (c)
Does it actually play identically or is there going to be weird bugs all over the place?
Seems like an impossible ask to verify if you don't have an immense test suite that covers everything.
The parent of the parent project has ground truth replays, which get compared to new PRs. The game uses lockstep networking, so this is required to prevent desyncs.
EA released the Generals source under GPL v3, the GeneralsX project got it running on macOS/Linux, and I've taken it the rest of the way: native iOS and iPadOS builds of Zero Hour, plus Apple Silicon macOS.
What works (all verified on a real iPad and iPhone):
Campaign, Skirmish, and Generals Challenge: full missions, objectives, cutscenes, saves All audio: music, unit voices, EVA announcements, Challenge taunts, briefing FMVs Touch controls built for RTS: tap select, drag a selection box, long-press deselect, two-finger camera pan, pinch zoom Self-contained install: game data ships inside the app bundle It's the real engine: unmodified game logic compiled for ARM64, rendering DirectX 8 → DXVK → Vulkan → MoltenVK → Metal. Not emulation, not streaming.
No game assets are included or distributed. You need your own copy (Steam sells Zero Hour) and a script pulls the data from your own account. Code is GPL v3.
Repo, with a full engineering log of every bug and fix (the black-minimap one is a 2003 texture-format fallback that ate the alpha channel; worth a read if you like archaeology): https://github.com/ammaarreshi/Generals-Mac-iOS-iPad/blob/ma...
Building: macOS is about four commands; iPhone/iPad needs Xcode and a free Apple developer account since you sideload your own build. Known issues (long-session memory on iPad, a rare backgrounding crash) are documented in the README.
Credit: fbraz3/GeneralsX did the heavy macOS/Linux lifting, TheSuperHackers keep the community codebase alive, and EA did a genuinely good thing releasing the source. The engine fixes I found are heading upstream so every platform benefits.
(And of course, not affiliated with or endorsed by EA, and sorry China had to deal with all of those particle cannons in that demo video)
You take credit for porting it to "Apple Silicon" macOS, both here and in the title, but that already seems to work upstream? On a quick look I didn't see any commit message of yours addressing macOS rather than iOS. What exactly did you add there?
Great stuff
I found the bundle scripts already prefer VULKAN_SDK/VULKAN_SDK_ROOT, but the build script only scans ~/VulkanSDK
Don’t worry - China inf is for noobs
https://youtu.be/WqWFYOxjZ54?si=1pH6Z1D33TOT4Qmg&t=453
nice!
When someone ported pylint to rust this place was full of ‘who will maintain this’ and met with blank stares when the answer was ‘what do you mean’ or ‘it’ll maintain itself’.
Good job. It was inevitable, but still someone had to, please excuse me, say the words.
Given the game is stable and the changes would be at the integration points, and Fable was able to do the direct integration, why would the answer not be “it’ll maintain itself” at some abstract level. The decision to maintain open source is up to the maintainers and I think the answer is “no one” 99.99% of the time, but I’ll wager if someone is willing to spend the tokens on it, a CI reintegration agent would do just fine in keeping it working as the underlying dependencies have required changes (which would really be only major changes in apple apis that aren’t backwards compatible.”
Pylint is different because it’s working against a necessarily dynamic wavefront that it has to keep parity with as it advances. All python changes, ecosystem adaptations, etc - and maintaining that with an AI harness in CI would never work. It would require a concerted effort and thought along the way.
So it’s sort of a different beast all together. In fact I think this is a great demonstration of using AI to resurrect technology built for X to work with Y, where X is dead and Y is current. Automating this feels like a net positive and because the original software is “finished” there isn’t decision making and strategy required.
These LLMs are remarkable. I used Opus to revive for myself abandoned software and bring it up to date with the latest versions of the frameworks so I could add some features. And there's other software which I vendor and merge in upstream changes and self-manage. This would have been a near-impossibility in the past.
"Who will maintain this?" appears to be "Me with an agent". And it's great.
That was me! Checkout my latest Fable project with 4D splats: https://news.ycombinator.com/item?id=48786245