F-15 Strike Eagle 2 source port

<p align="center"> <img src="screenshots/title.png" width="50%" alt="F-15 title screen"> </p>

This is a work in progress project to port, fix and enhance the reconstructed source code of the Microprose game F-15 Strike Eagle 2 v451.03 (the definitive 1991 Desert Storm expansion disk version) for modern architectures.

Unlike the old project, whose aim was a bug-for-bug, instruction-level faithful reconstruction of the game's source code for the orginal MS-DOS platform and the MS C v5.1 compiler, here we aim to keep as much of the game's spirit intact, while taking it forward into the 21st century with modern compilers and libraries, better graphics and enhanced features.

The repository was forked off from tag v0.9.2, and the projects continue to diverge from there, but the idea is for the reconstruction to see occasional backports from this project which provide bugfixes, clarify or document the original code, but of course these will need to make sure to preserve the contract of the reconstruction's instruction-level identity with the original.

The project uses the SDL3 library for the graphical frontend.

Development journal: https://neuviemeporte.github.io/category/f15-se2

Status

The entire game is playable, rendering and input handling is ported to SDL, sound works using Adlib emulation through Nuked-OPL3 and joystick/gamepad input is supported (though not configurable right now). Multiple improvements have been implemented including high resolution and widescreen support with some bugs from the original having been fixed too. Work is ongoing to add more features and eliminate bugs.

Screenshots

<div align="center"> <table> <tr> <td align="center"> <a href="screenshots/screen1.png"><img src="screenshots/screen1.png" width="150"></a> </td> <td align="center"> <a href="screenshots/screen2.png"><img src="screenshots/screen2.png" width="150"></a> </td> <td align="center"> <a href="screenshots/screen3.png"><img src="screenshots/screen3.png" width="150"></a> </td> </tr> <tr> <td align="center"> <a href="screenshots/screen4.png"><img src="screenshots/screen4.png" width="150"></a> </td> <td align="center"> <a href="screenshots/screen5.png"><img src="screenshots/screen5.png" width="150"></a> </td> <td align="center"> <a href="screenshots/screen6.png"><img src="screenshots/screen6.png" width="150"></a> </td> </tr> </table> </div>

Completed improvements

These are bugfixes and new features which were not part of the original game that have been added by this project.

1. The original was limited to 15 FPS with a convoluted time scale implementation to make sure the game engine kept up with rendering. This has been eliminated, with the game engine being decoupled from rendering, so now it plays much smoother.
2. Input loop has been upgraded to an SDL event pump which should make it deal with simultaneous inputs much bettern and improve general responsiveness.
3. The game originally supported 4 levels of detail (0-3, switchable with Alt-D), with the highest one still suffering from limited draw distance. An additional level of detail (4) has been implemented with unlimited draw distance, and enabled by default.
4. Rendering has been moved out of the bespoke software engine that was capped at 320x200 resolution (still available with the F15_RENDER=software envvar) and into OpenGL (with MSAA), enabling higher resolutions (including widescreen), improved clarity and overall nicer graphics (particularly the horizon now has fog). At a later time, perhaps it will also be possible to upgrade the original software renderer to support higher resolutions.
5. Smooth movement and high resolution 3D rendering of cockpit display screens.
6. Air targets are now also selectable with the T key, just like ground targets.
7. Widescreen is supported with correct aspect ratio.
8. 3D object occlusion was fixed, was difficult due to the engine handling the draw order and aspects of rendering in an unorthodox way, many models containing coplanar surfaces which would z-fight; solved by introducing depth bias.
9. Gun spread and target hitboxes are improved, it is actually possible to aim the gun now.
10. Missiles follow the actually selected targets instead of the closest one.
11. Asset converters allow loading original 3D models into modeling software, could lead to better/more models in the future. Fonts and sprites are also exported.
12. The game was ported back to DOS, running in 32bit protected mode

Planned improvements

These are things that are broken or missing from the original, and which we plan to implement some day. Essentially a wishlist.

1. Make the missiles more difficult to evade, as it's currently trivial (just beam them, i.e. put them on approx 90deg angle to the plane). Implement quasi-realistic missile energy management with self propelled/ballistic stages and gradual reduction in maneuverability. Denser air at lower altitudes should influence missile drag. Terrain masking should make missiles lose track.
2. Countermeasures (chaff/flare) are too effective (100%) against missiles. Take missile aspect into account, e.g. chaff should not do much for a missile coming straight on, and flares should be less effective against a heat seeker missile coming from the rear.
3. Make enemy plane AI more capable, right now planes are barely a nuisance, slow, barely maneuvering, will rarely shoot missiles, not sure getting hit by gunfire is even possible.
4. More realistic player aircraft handling, right now it's too responsive, turns too quickly.
5. Implement missile trails for better situational awareness/cool visuals.
6. Make the target view in the right display show the actual view of the target from the player's perspective, right now it's just drawn on top of fake ground and sky.
7. In-game menu for configuration (keyboard/joystick binds, video resolution, turn engine sounds on and off, ...)
8. Better damage model for player aircraft, currently being hit by a missile only results in a small drop of maximum RPM. Simulate full/partial loss of stability, broken systems, weapons, hydraulics etc., up to instant destruction.
9. More varied terrain and water, these are completely flat with occasional pyramids that are supposed to represent mountains. It can continue to be flat shaded/polygon based to not change the look of the game too much, but we definitely need more vertices and/or textures.
10. Better clouds and smoke effects, right now these are solid polygons in mid air.
11. Add more information (altitude/speed) to the target display MFD for airborne targets.
12. Let player skip the ejection sequence and go straight to debriefing.
13. Implement a full 3D cockpit with 3DOF/6DOF head movement with the hat switch and/or TrackIR.
14. Map and 3D model editors. (Some progress has been made but not complete)
15. VR support. (Some initial progress made with OpenXR for Linux/X11)
16. Multiplayer.

Known bugs

Problems with the game that were introduces by the port, and to the best of our knowledge are not present in the original.

1. There seem to be some kind of gimbal lock problems with the input; pointing the plane straight up or straight down, then rolling 90 degrees to either side and pulling on the stick seems to have little to no effect sometimes.
2. The bearing (BRG) value on the airborne target screen is broken, mostly stuck on one value even though target is visibly turning.
3. There's sometimes flickering beneath and above the left display (map) in the cockpit.
4. Shaking in the cockpit after getting hit is too long.
5. The font color at the bottom of the pilot select screen is sometimes wrong, should be red like the score text.
6. When on the airfield/carrier, can see through to the ground on the sides of the view (exposed by widescreen support). Also, carrier geometry sometimes flickers beneath the player.
7. Some z-fighting still visible, e.g. on the underside of the player aircraft in external view.

Building

The build system is CMake with Ninja being used as the generator backend. It's been built successfully with both gcc and Clang. To build, run:

$ cmake --preset <preset-name> # only needed the first time around, or when making changes to cmake files
$ cmake --build build

The project includes the default preset base-ninja in CMakePresets.json. It's possible to manually override platform-specific values for the build using CMake's user presets.

Linux

On Ubuntu, I got to build with the default preset. The only thing needed was to install SDL3 with apt:

$ sudo apt install libsdl3-dev
$ cmake --preset base-ninja
$ cmake --build build

Windows

To build on Windows using llvm-mingw, I use this CMakeUserPresets.json:

{
  "version": 3,
  "configurePresets": [
    {
      "name": "windows-clang",
      "inherits": "base-ninja",
      "displayName": "Local Windows Clang + SDL3",
      "environment": {
        "CC": "D:/utility/llvm-mingw-20260616-ucrt-x86_64/bin/clang.exe",
        "CXX": "D:/utility/llvm-mingw-20260616-ucrt-x86_64/bin/clang++.exe"
      },
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": "Debug",
        "CMAKE_PREFIX_PATH": "D:/code/SDL3-3.4.10/x86_64-w64-mingw32"
      }
    }
  ]
}

MSVC works too:

    {
      "name": "windows-msvc",
      "inherits": "base-ninja",
      "displayName": "Local Windows MSVC + SDL3",
      "architecture": {
        "value": "x64",
        "strategy": "external"
      },
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": "Debug",
        "CMAKE_C_COMPILER": "cl",
        "CMAKE_CXX_COMPILER": "cl",
        "CMAKE_PREFIX_PATH": "D:/code/SDL3-3.4.16"
      }
    }

With this, I run e.g. cmake --preset windows-clang followed by cmake --build build to obtain build/f15se2.exe.

Running

After building, either drop the resulting binary into a directory with the game assets, use the --game command line option or the F15SE2_DIR environmental variable to set the assets' location. The game checks MD5 checksums on all asset files to make sure they are not corrupted, and will not start unless all files from the original game match up.

Releases

Prebuilt, self-contained packages for Linux, Windows and macOS are produced automatically for every version tag and attached to the corresponding GitHub Release:

• Linux: an .AppImage (portable — chmod +x and run) and a .tar.gz.
• Windows: a .zip with SDL3.dll and the compiler runtime DLLs bundled.
• macOS: a .tar.gz with libSDL3.dylib bundled.

Each package contains the engine and the optional HD asset overlays only. The original F-15 Strike Eagle 2 game data is not included (it is copyrighted) and must be supplied separately via --game <path> or the F15SE2_DIR environment variable, exactly as for a local build. The bundled SDL3 library is found automatically next to the executable (via RPATH on Linux/macOS, the executable directory on Windows), and the HD assets resolve relative to the executable regardless of the working directory.

To cut a release, push a tag of the form vX.Y.Z:

$ git tag v1.0.0
$ git push origin v1.0.0

This triggers the .github/workflows/release.yml workflow, which builds all three platforms, packages them, and publishes a GitHub Release with the artifacts attached. The release version string is derived from the tag via git describe.

Contributor policy

Contributions to this project are very welcome. However, contributors are expected to follow certain rules to keep the project manageable:

1. We don't discriminate contributors for any reason.
2. Keep politics and sensitive topics out of it, this is not the place for it.
3. No copyrighted content can ever be submitted into the project.
4. Even though this is already a different game than the reconstruction, we try to maintain some degree of compatibility. So, at least for the files which exist in both projects:
   1. Don't move routines around, keep the order as is.
   2. Don't refactor the code unless you are prepared to do it to the reconstruction also. This is actually encouraged, but make sure you plan for the extra work in such case.
   3. If you have a good reason to break compatibility, do so in the possibly least intrusive way. For example, don't add a huge block of code in the middle of a legacy routine, factor it out.
5. We don't discourage the usage of LLMs. However, all PRs must be possible to be reviewed by a human and the resulting code needs to be maintainable. Some practical suggestions to that end:
   1. Take on one task at a time.
   2. Keep changes small-ish.
   3. Test every change.
   4. Read the change and verify how it was implemented.
6. Keep the game's spirit and style intact. This is subjective, and we can always discuss specific cases, but the game should remain identifiable as F15 SE2 despite the fresh coat of paint. Whenever a change is implemented that changes the look and feel significantly, try to have it behind a toggle which lets the user flip it on or off at will.