Type to search. Enter opens the first result.

    Started

    FAF-RE

    The Supreme Commander Forged Alliance engine rebuilt as C++ source that builds for x86 and x64 and plays real games checksum for checksum like the original. For the FAF community.

    ActiveEdit
    Source

    About the project

    Supreme Commander: Forged Alliance came out in 2007, and its Moho engine has been a frozen binary ever since. The Forged Alliance Forever community kept the game alive for years by patching that binary in place. FAF-RE is the engine written out again as readable C++20 that builds, runs and plays real games exactly like the retail ForgedAlliance.exe, so it can be maintained like any other code.

    The recovery is complete: every engine function the game uses is now source. The work left is making it better than the original.

    engine functions written as source, none outstanding
    40,617
    replays match every retail checksumcurrent FAF vault test set
    75 / 75
    less time than retail for x64 replaysfive replays with 8 sim workers, 4% to 33%
    19%
    retail, x86 and x64 builds in one game without a desyncAI-driven fighting, live multiplayer
    21 min

    What works

    WhatState
    Buildsx86 (main.exe) and x64 (main_x64.exe), CMake with clang-cl
    Rendersmain menu, cinematics, the game world; Direct3D 9 and 10 as shipped, plus Direct3D 11, Direct3D 12 and Vulkan added here
    Playsnative save and load on both architectures
    Replaysall 75 replays of the current vault test set match retail at every recorded checksum
    Multiplayerretail, rebuilt x86 and rebuilt x64 in one game: 21 minutes of AI fighting without a desync; retail and x64 alone ran 30 minutes, with and without sim worker threads
    Movies.sfd cinematics through FFmpeg, without the original’s Sofdec runtime

    How I know it matches

    A lockstep RTS is a strict judge. Every player runs the same simulation and compares checksums, so one wrong float in one tick shows up as a desync. That makes FAF’s replay vault the test suite: real games from stock and community maps, 1 to 12 human players, against the built-in AI and M28AI, played back on the rebuilt engine and compared with retail checksum by checksum.

    The faster x64 build follows the same rule. Simulation work moves to worker threads only where the result is provably the same as running it serially, and every such change has a switch that puts the original code back.

    Building it

    You need your own copy of the game: the repository holds no game binary, asset, map or script, and nothing derived from them. Then:

    1. Install Visual Studio 2022 with the C++ workload, LLVM (clang-cl and lld-link) and Git.

    2. Clone with submodules:

      Terminal window
      git clone --recursive https://github.com/Draiget/faf-re.git

    3. Build and copy the executable into the FAF run folder:

      Terminal window
      .\build.ps1              # x64 Release
      .\build.ps1 -Arch both   # x64 and x86

    Configuring fetches and builds every dependency from source at a pinned version: Wild Magic 3.8, wxWidgets 2.4.2, Boost 1.34.1, zlib 1.2.3, FFmpeg 7.1.3 and the rest. The full list and the options are in the README.

    faf-re on GitHubSource, build scripts, parity and performance notes.github.com SC:FA Moho engine sourcesThe announcement thread on the FAF forum.forum.faforever.com

    Thanks

    FAF-RE stands on many years of engine study by the Forged Alliance Forever community. Particular thanks to Hdt80bro and 4z0t.

    It is an independent preservation and interoperability effort, not affiliated with or endorsed by the game’s publisher or developer.

    Roadmap

    22 of 34 doneupdated

    Done22

    1. NetworkRobust against bad network data

      A malformed message from one player no longer crashes the lobby or ends the game. Damaged replays and saves are refused with the reason.

    2. Build and toolsCMake and clang-cl

      One CMake build with clang-cl for x86 and x64 replaces the Visual Studio project. Every library is fetched at a pinned version and built from source, FFmpeg included.

    3. RecoveryRecovery complete

      Every engine function the game uses is written as source: 40,617 functions, none outstanding.

    4. SimulationFAF engine patches in the source

      Engine fixes that FAF ships as patches to the original exe are ported into the source and follow the game version, up to 3840.

    5. PerformanceLua garbage collector on workers

      Mark and sweep run on sim workers with the same result as the serial collector. Collector time per game fell from 35.9 s to 9.3 s.

    6. PerformanceFaster than the original

      On five vault replays with 8 sim workers, the x64 build takes 19% less time than the original on average, 4% to 33%, with every checksum matching.

    Show 16 more
    1. RenderingIcons and fog drawn by the GPU

      Strategic icons, fog of war, selection brackets and projectile icons are drawn by the GPU on Direct3D 11, 12 and Vulkan. Each path turns on only after it passed a check against the original drawing.

    2. Platformsx64 without the 2 GB limit

      The x64 build uses full 64-bit addresses by default. x86 runs out of address space at about 60,000 units; x64 was still running at 90,000.

    3. PerformanceLighter main thread

      Replays compute up to 10 beats ahead of the screen, and icons, view culling, fog of war and unit updates run on worker threads. The look-ahead alone took a 41-minute 12-player replay from 37:33 to 20:46.

    4. RenderingDirect3D 11, 12 and Vulkan

      Direct3D 11, 12 and Vulkan join the original Direct3D 9 and 10, and the game picks the newest one that starts. The game's effects are translated at load time; DXC compiles all 339 entry points of the 11 effects for Direct3D 12 and Vulkan.

    5. Simulation76 of 76 replays

      Every game in the test set matches: 1 to 12 players, stock and community maps, games against the built-in AI and M28AI, 9 to 83 minutes long.

    6. NetworkOriginal, x86 and x64 in one game

      Three clients, the original game and both rebuilt builds, played 21 minutes of AI-driven fighting in one live game without a desync.

    7. PerformanceSim work on worker threads

      The first sim step moved to worker threads is the recon blip refresh per army. With 0 and with 8 workers a 12-player replay gave byte-identical results on all 6,814 beats checked.

    8. SimulationFirst replays match the original

      Nine real games from the FAF replay vault (8 to 12 players, 30 to 46 minutes) give the same checksum as the original game on every gameplay beat.

    9. Build and toolsCrash reports

      A crash writes one text report with every thread's stack, the Lua stacks with source lines, game state and the log tail, plus a minidump. Before, a crash froze the game with a cut-off log.

    10. SimulationSave and load

      Native save games write and load on both x86 and x64.

    11. RenderingOwn movie player

      The game's .sfd movies play through an independent player built on FFmpeg; the original video library is not used.

    12. Platformsx64 build

      main_x64.exe builds from the same source. A local multiplayer harness put it in one game with the x86 build: 1,250 beats in lockstep, no desync.

    13. RenderingIn game

      The commander spawns and is drawn on the terrain; unit selection and the in-game interface work.

    14. SimulationA skirmish map loads

      The map loads, the sim is built, blueprints are read and the armies are created.

    15. RenderingMain menu

      Menu textures load and the buttons respond to clicks.

    16. Build and toolsFirst build that links and starts

      The rebuilt source links into one executable, and it starts up to creating the graphics device without a fault.

    In progress3

    1. NetworkDedicated server

      An optional mode for tournaments: one Linux server with no graphics runs the only sim, and players connect to it, not to each other. Normal games stay peer-to-peer and unchanged.

    2. PlatformsSim on Linux

      The sim builds on Linux with clang and plays test replays to the end with the same checksums as on Windows. The full replay set is next.

    3. NetworkClient fed by the server

      The client shows the game from the server's data stream instead of running its own sim.

    Planned6

    1. PerformancePose and animation on workers

      Pose and animation take about 14% of sim time. They move to sim workers next, with results applied in the original order.

    2. PerformanceSim workers on by default

      Sim worker threads are off unless /simworkers is given. They become the default after checks with more worker counts and shuffled scheduling.

    3. RenderingDirect3D 12 in fast replays

      In a replay at full speed Direct3D 12 is still slower than Direct3D 9: 1032 s against 924 s on the same game.

    4. NetworkLinux server with Windows clients

      The server on Linux with Windows clients, first on a LAN, then over a relay. The replay the server writes must play back on Windows with the same checksums.

    5. NetworkTournament features

      A lobby hosted by the server, reconnect, a delayed feed for casters, admin pause and force start, and results reported by the server.

    6. RecoveryTyped pointer parameters

      962 functions take an untyped void* parameter, and 70 of them can take their real type. The rest are callbacks, type-erased by design, or dead code.

    Later3

    1. PlatformsWhole game on Linux

      The server work brings only the sim to Linux. Vulkan is already there; the window, input and sound still need a Linux path.

    2. PlatformsmacOS and arm64

      Clang builds for macOS on x86_64 and arm64 are in the long-term plan, but there is no Mac to build and test on yet.

    3. RenderingAlpha movies and subtitles

      Movies with alpha composition and subtitles are not supported yet; such movies are refused at open with a log line.

    The series

    No posts about this one yet.