SC: FA (Moho) engine sources

[nomads]

It's my honor to see such a good post. Thank you all for your efforts and dedication.

[MayeulC]

Thank you very much for this quality work, and the pulic open source release!
I have been watching that other rewrite, but the source code isn't public yet. It is also true that LLMs have made decompilation efforts much more tractable than in the past, and we are seeing these projects proliferate, so in my opinion it is a good thing to make an early release to avoid duplicating effort.

This looks feature-complete, though. Which brings me to my main question: I have a bit of trouble understanding how much of a 100% faithful reimplementation this is. Given that your compiler is VS 2022, and looking at the libraries used, this does not look like a byte-compatible decompilation (where even the final binary checksum would match). Admittedly, this would be a very high bar to achieve.

And I see that you have included a few fixes already, so:

• how do you decide on what to keep close to the original vs what to change?
• Do you have a roadmap or guidelines for what kind of changes would be accepted?
  • lua engine modernization
  • network stack modernization
  • platform ports (Linux, mac, gcc/clang)
  • UI improvements: multiple viewports/windows, shortcuts, menu/artwork changes, etc
  • Gameplay interaction changes: unit orders, etc (I quite like PA's drag-circle to build metal extractors, for instance)

There is probably room for multiple similar projects, though, and if you go for a more faithful approach while the other project is more open to changes, that is perfectly fine by me too
We will probably see multiple forks and total conversion, with source code access, I imagine that you have fully anticipated this!

[Draiget]

@MayeulC said:

this does not look like a byte-compatible decompilation (where even the final binary checksum would match)

It won't be byte-to-byte for current binary, not possible, because compilers are different (I'm using clang, not MSVC) and I already did performance optimizations on top. Goal and idea of the project is to have byte-to-byte replay and simulation parity, including visuals - which is fully achieved today for whatever I did tested myself.

@MayeulC said:

how do you decide on what to keep close to the original vs what to change?

Everything is kept to original, nothing changed for sim or rendering that changes visual look from the original. I did changed things in terms of performance, which again - looks identical to original, but now works with modern DX12 and Vulkan (shader/data-driven rendering). If something are not behaving as original to me means a bug that I didn't found yet and I'm happy to fix it when such one reported.

@MayeulC said:

Do you have a roadmap or guidelines for what kind of changes would be accepted?

If you mean to the repo - I will accept changes that fixes bugs that doesn't affect simulation or any other PRs that fixes things I did missed to repeat original game behavior. Since that was AI-assisted there could be hallucinations during decompilation effort for sure. If you mean roadmap of this repo being part of FAF build - that's community and devs to decide, I can only keep simulation parity with original.

About my personal roadmap, there are features planned from my side to create tournament server-side simulation mode that wouldn't change any of the current simulation logic, only as additional flag\compiler definition so everyone can still play regular p2p games.
Testing Linux build also one of the TODOs, since compiler are clang it's possible but will require x87 math adjustments for the platform.

[kirovreporting]

So, you can update that .exe, and we can run it in MM as a custom option?

[zhanghm18]

@draiget Thanks a lot for your work, and I’m really glad to use this new release. I have two small requests:

1. I’ve submitted several PRs to the original FAF binary patches besides the particle pool limit one, including tracks/treads related fixes and memory optimizations. They may also be useful for your project.
2. I’ve noticed some visual differences compared to standard FAF. For example, ship wake trails appear much fainter than they are on the official FAF engine.

[Giebmasse]

Awesome work!

[Draiget]

@zhanghm18 thank you for reporting visual bug, I did found it now and will fix. Also glad that this decomp project helped to create more useful binary patches, I'm porting merged ones to my repo as well. Happy to fix all visual differences if there any more

[IndexLibrorum]

If I understand this correctly, with my limited knowledge of FAF dev, this is a pretty huge deal right?
What amazing work. Big props.

[MayeulC]

Thank you for your answers.

Goal and idea of the project is to have byte-to-byte replay and simulation parity, including visuals - which is fully achieved today for whatever I did tested myself.

I did see several mentions of MSVC in the repository readme, so I was a bit worried there, but it is good that the project can already be compiled with clang.

Everything is kept to original, nothing changed for sim or rendering that changes visual look from the original.

Gotcha. It should be possible to put test assets in the original, take a screen capture, and replay with the test assets in the CI to catch visual bugs, like what emulators do, if you really want to ensure 1:1 fidelity.

If you mean to the repo - I will accept changes that fixes bugs that doesn't affect simulation or any other PRs that fixes things I did missed to repeat original game behavior.

I really meant your repository. There are so many improvements I could think of, more or less user-visible. I listed some, but less-visible improvements could include multi-monitor improvements, steam input integration to make it easier to play on Steam Deck, Discord/Steam rich presence integration, better integration with FAF (integrated lobby, control it via IPC to avoid restarting the game, etc).

Testing Linux build also one of the TODOs, since compiler are clang it's possible but will require x87 math adjustments for the platform.

Yeaaah... I imagine that the game relies on system libraries? Probably not on the windows ucrt "universal c runtime" otherwise we would have seen desyncs on wine, but x87 definitely need some focus. It should be possible to load windows libraries (extracted from MSVC redist) with a small shim (or compiler options) to adjust the calling convention. That would not be my prefered approach though, as it makes it more complicated to support non-x86 platforms (arm) with native code. The other option is to link another controlled FP library, which behaves the same across platforms. This would break replays (the old library can still be embedded to read them on Windows, but new replays would be generated with the new one, unless additional trickery is performed). But you probably thought about all this already.

Something else came to my mind: It should even be possible to compile this to webassembly, and, with a few changes, have a replay player in the browser. The hard part is that assets are copyrighted and distributed with the game, but at least event (commander destruction, experimental unit built, game stats) can be extracted, and maybe a strategic view/minimap provided with custom assets? I am fairly new to FAF (not to supcom, but these decomp projects attracted me to FAF), but I imagine that the community would value that?

[IndexLibrorum]

@MayeulC said:

Something else came to my mind: It should even be possible to compile this to webassembly, and, with a few changes, have a replay player in the browser. The hard part is that assets are copyrighted and distributed with the game, but at least event (commander destruction, experimental unit built, game stats) can be extracted, and maybe a strategic view/minimap provided with custom assets? I am fairly new to FAF (not to supcom, but these decomp projects attracted me to FAF), but I imagine that the community would value that?

Some lightweight and fast replay tool would be much appreciated. I imagine that issues with copyright can be solved by simply not using any of the actual assets. A replayviewer with just strategic icons, for example, would already be very powerful.