First step was the full reverse to assembler, second step is to convert the assembler to binary equal compiled C code, all this still on DOS until no assembler code is left, then the porting to Linux,Windows will start
Reversing tends to bring in new bugs and its not easy to find all bugs in such old and reversed code - but so far everything seems to work
try finding open bugs if you got version 451.03 of F-15 around combined with Dosbox or a real DOS
find latest DOS release here: https://github.com/neuviemeporte/f15se2-re/releases
the f15_se2-*.zip file contains the replacement executables for the DOS game
The airforce needs YOU!
I’m not sure you should beat yourself up too much for a Linix* port, emulators are so well supported and ubiquitous, if it works there (not everything does), call it a win!
I use Lutris (https://lutris.net/) for its ease of use.
I can see your a “low level mahn” and this may be more of a quest for you than playing a cool retro game.
Any which way, GREAT WORK!!!!
This isn’t my wheelhouse but I was surprised just how well AI could figure out the intent of the structure of some JavaScript where I had no source maps.
I think, this needs the original game files to run, if I read things correctly. So probably just gonna read the dev journals, rather than fly this particular bird again...
https://robin.tooclever.org took less than a day in API time
C source needs to get compiled on every platform reachable - that is a must :)
You’d just have to make sure the specification doesn’t include actual source snippets (the AI will try this if you don’t specify). Pseudo code would be sufficient I guess where necessary.
One should be honest about what one builds. The F-15 project does that: the aim is the reconstruction of the original game, down to the opcodes; on the other hands it requires the user to provide the original game assets.
Ingested the binary?
(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.)
I must admit the rate of progress currently experienced in the project is overwhelming. A little over a month ago it seemed that we had several more years of laborious rewritting of assembly into C before the second game executable (egame) started looking like something, and the third one (end) still to go for dessert. Meanwhile, as of the time of writing this, all C code has been reconstructed for all executables, all data has been moved from assembly into C, most of the assembly-only code has functional replacements written in C, most routines and data structures have been assigned meaningful names, and we’re looking at forking off the repo for a porting project in the near future.
However, this explosive growth in completeness and capability also means that we’re abandoning the relatively peaceful domain of just looking at whether the reconstructed opcodes match, and we actually need to maintain a running game going forward. The tooling makes sure that the opcodes stay faithful to the original as we continue to make changed, but it cannot catch all bugs, particularly not the ones that have to do with data layout.
Seeing how community involvement has allowed the project to flourish, I was hoping we could ask for a little bit more help. F-15 Strike Eagle 2 reconstruction is now open and ready for test pilots to take to the digital skies and find any bugs that we might have missed. Right now, the latest release is v0.9.1 and it should work with the original game’s 451.03 version with the desert storm expansion pack - just drop the executables into the game folder replacing the original ones (make a backup beforehand), possibly removing the original f15.com to make sure it does not get launched in place of the new f15.exe, and take off. It will not go into the setup screen, instead assuming a MCGA/VGA display with no sound and no joystick. But everything else should work in all 3 parts of the game (mission briefling, flight and debriefing).
If anything does not work, we would appreciate bug reports. We are looking for crashes, graphical glitches, keys not working etc. Consider attaching a screnshot (Ctrl+F5 in dosbox) if it’s useful. A description of what was being done before the issue occured will be helpful to us in reproducing the problem and hopefully developing a fix.
It’s important to notice that this is a bug-for-bug reconstruction, so any behaviour also present in the original game needs to stay as is (for now). The original has some problems with 3d objects disappearing, plane falling towards the sky when inverted and out of fuel etc. So before reporting an issue, it would be best to make sure it does not occur in the original, so keeping a copy around for reference might be a good idea.
Thank you to everybody who decides to help and thanks to everyone who contributed to the project thus far, allowing it to reach this milestone. I’m looking forward to the next ones, and I’m happy y’all are along for the ride.