(This post is part of a series on the subject of my hobby project, which is recreating the C source code for the 1989 game F-15 Strike Eagle II by reverse engineering the original binaries.)

This post is going to be less technical than usual, and instead I’m going to summarize what has happened in the project over the last few months. There’s been a frenzy of developments, so there’s a lot to cover.

First, as mentioned before, the source code reconstruction is more or less complete. I still have some things I would like to do with it, like make the data segment layout match, try for 1:1 binary equality with the original, and have the remaining assembly code better commented and building with MASM under DOS instead of UASM. Also, it will probably continue to receive updates with name refactoring and routine documentation in the future. But, for all intents and purposes, it is now “complete”.

Second, the modern port is now also “complete” in that it covers the entirety of the original game and is fully playable. Additionally, multiple improvements have been implemented in it compared to the original, with just the high resolution being a complete game changer. I think it looks real cool in high res, even with the simple, flat polygons:

EX1 EX2

Contributors have also made an exporter and viewer/editor for the game’s internal data. Here are examples of loading F15’s .3d3 files exported into .glb in Blender, and the standalone model viewer. Right now, the process only works forward, meaning it’s not yet possible to create custom models or maps for the game, but being able to see the 3D shapes that make up the game up close and personal is frankly an amazing achievement.

Blender1 Blender2
Blender3 3D viewer

Going forward, work on the port is going to continue implementing more new features from the wisthlist, and fixing any bugs that pop up.

So, how did we get here?

This is admittedly amazing progress, given that in May of 2026 the project was completely stalled on the reconstruction part, at a stage which I would estimate as 40% complete in total. I can’t take much credit for that, most of the work has been completed within a couple weeks by @AJenbo using LLMs and apparently not sleeping at all. I tried to keep up for a while, but quickly noticed I was mostly in the way, so decided to step back and let nature take its course. I contributed some bits here and there, but it was @AJenbo who carried the reconstruction on his back, with some critically important contributions from @xor2003 at the eleventh hour.

Then, the story repeated itself with the port. I barely managed to create a repo with a barebones SDL3 application and some CMake scaffolding to make it build, before @AJenbo unloaded into it, making the game playable within days, and started dropping new features soon after. Having limited 3D programming experience and not too much time on my hands, again, I had to make my peace with it and contribute where I could, mostly with testing and reporting bugs. To this day, I am not very familiar with the code.

Meanwhile, @xor2003 was again making great progress with the asset extractor and viewer. To me, this is one of the most amazing outcomes of the project, as I’ve always dreamed of being able to see the building blocks of the game, and now I can.

Then, around July, the torrent of PRs slowed down. The project reached a plateau, and I was free to jump back in.

All is well, then?

Not entirely. Oh, the project is doing great, it’s just me who’s kind of borked.

Ironically, even though I didn’t do most of the work, I’m feeling completely drained by the experience of the last couple of months. I guess it’s the combination of the rapid pace, the multiple failed attempts to catch up, and ultimately having to swallow my pride and admit that for the good of the project, the best I can do right now is do nothing – all of that took its toll. I’m completely burned out and can’t look at F15 right now. All of my dreams came true, I was handed the working code to F15 and I guess it felt nice, but it was just too much too fast. I’m not sure it makes sense, but that’s where I am right now.

I’m pretty certain I’m going to pull it together and eventually get back to it, but I have no idea when that might be, and I’m not going to force it. For a hobby project, this can’t feel like a chore for me to be able to do it.

Aren’t we forgetting something?

Yes, there’s the whole aspect of LLM involvement, and how it worked out for the project. I’ve been asked that, so might as well write it up here.

First, I’m not going to comment on the overall aspect of the influence of LLM usage on software development, whether it’s good, bad, useful or not. Neither am I going to go into the economics of running LLMs, the business models of AI companies, or whether we’re in an investment bubble. These are difficult topics with everybody having different guesses, where the truth is probably we’re going to have to wait and see how it turns out. I’m just going to focus on my experience and this particular project.

There’s no point denying it, after the initial period of discovery, the manual transcription of assembly into C quickly became a chore. It’s the kind of job that’s perfect for offloading to a machine - relatively simple but tedious, rules are “fuzzy” (not easily codified), and there’s a quick method of verification for correctness (my tooling). I was thinking of applying “machine learning” to it years ago, even before the current “AI” boom, except back then I envisioned having to train a model for it myself. I never would have believed capable models, possible to interact with in natural language, would become available within my lifetime. So the bottom line is, I’m happy I didn’t have to transcribe all the assembly manually, and I consider this a very positive outcome for the project.

Next, there was the quick jump over from the reconstruction to the port, making it playable, fixing bugs and implementation of the first improvements over the original. That was a bit tougher to swallow, probably mostly because it was concerning technical aspects which I’m not familiar with, particularly 3D graphics programming, so I had to swallow my pride. But I could not complain, because this was done with the LLM purely used as a force multiplier, with the PRs for the new features being relatively small, comprehensible and atomic. Also, seeing the game grow into something playable before my eyes was pretty exciting, even if it wasn’t me driving it.

Finally, I have to talk about the “other” PRs. These include the LLM-generated unit tests, which are mostly incomprehensible to me, and it seems their main purpose is to be able to claim other LLM-generated PRs are fine, because they pass the test suite. So, in essence, the machine’s output is correct because the machine said it was. To me, this is ass-backward. If you want to have a degree of control over your software, you either write the code yourself and have the machine test it, or have the machine write the code, but you write the tests for it to keep it in check. Doesn’t even have to be complete at the beginning, just add some high-level guardrails and refine as needed over time. But bottom line, if you let the LLM do both, you essentially don’t have a clue what’s in there. You may claim that’s fine, we don’t need to know, having the features for free is nice, isn’t it? Way I see it, there’s no free lunch, there’s always a price to pay. If it’s not literally the price of tokens once the AI companies stop subsidizing their compute, it will be in the cost of maintenance when the LLM goes cuckoo and can’t find its way around in the mess it’s made any more. I don’t want to throw this project away in a year or two and start from scratch.

There were many PRs like this contributed to the project. Most of them were submitted apparently with no oversight, just huge dumps of code at my doorstep. Many of them contributed huge features from the wishlist like in-game menus, deterministic replay, high definition HUD with Unicode fonts. Even multiplayer was vibecoded and presumably working. The temptation was considerable. But the code review left a bitter taste in my mouth. Why should I read it if the contributor clearly didn’t bother to? And if I’m not supposed to read it either, what is even the point of the review?

Next, I naively tried to legislate the problem away. I came up with “project guidelines”, requesting that PRs were to be small, readable and doing one thing at a time. The next day, the huge PRs were gone. In their stead, 20 small ones were raised. Ultimately, I decided to reject them all. This is an open source project, so people can continue to do whatever they wish in their private forks, even make the game sing Hello Dolly for all I care. I’m going to maintain a version that may be a bit backward, but possible to work on by humans. I need this to be fun, and to me, making and figuring out things is fun. Watching a black box spit out a solution is not fun. In the business world, nobody cares about fun, just shipping quickly, and that’s fine. Even there, we still haven’t figured out if “AI” is a net plus for productivity, when to use it, and when not. But for this project, it’s like I’m a car factory worker on a 10 hour shift at the conveyor line, and working on a car restoration in my garage after hours. I can’t bring the fucking conveyor line into my garage, or I’ll lose all enthusiasm for it.

So here’s hoping I do actually manage a comeback. But even if I don’t, that’s fine. The project has a life of its own now, and people are doing cool stuff with it. We even have F-19 decompiled already. I am happy I was able to get this thing started and contribute a little towards all these achievements.