SC: FA (Moho) engine sources

[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.

[Tokyto_]

This is really cool work! I wanted to see what could be possible with this, so I experimented a little bit

Since I was mapping in the past and fixed water to a single level was quite a frustrating limitation, I made it so it's possible to create water height at different levels / regions.

I now have a small proof of concept with polygon-shaped lakes at different elevations. Ships, submarines, torpedoes and naval factories seem to work in my tests. I also tried AI games and a short two-PC LAN game without a desync, although there’s still a lot more testing to do.

Video: https://www.youtube.com/watch?v=UmmmxQOOND8
Code: https://github.com/Tokyto/faf-re/tree/regional-water
Editor + Explanation: https://github.com/Tokyto/faf-re/tree/regional-water/regional-water-demo

Also had to make a small tool that allows you to make water / lakes regional for said map (saves as EXAMPLEMAP.v0001.scmap.regionalwater alongside the actual map):

A few technical details:

• The engine loads polygon regions and their water heights from the map’s sidecar file.
• Water height queries use the local region at a given position. This needed changes in several places, including unit movement, projectile collisions, building placement and some AI queries.
• The renderer creates separate water surfaces for the regions. So far I’ve tested this with D3D9.
• In my tests, ships could navigate along the shores, submarines could dive, torpedoes and torpedo bombers worked, and AI built a naval factory and ships. Transports could also unload units in the raised water.
• The LAN test was done with the same modified engine and map files on both PCs. It’s a promising start, but definitely not proof that longer multiplayer games are desync-free.

This is an experimental demo, not a finished FAF feature. Big thanks to Draiget and everyone who worked on reconstructing the engine — I hope this shows some of the interesting possibilities and encourages more experiments!

Feel free to use my vibe coding as you see fit

[Nooby]

@IndexLibrorum

This would really speed up my work with

https://forum.faforever.com/topic/7746/unit-logger-mod?_=1793094473252

I currently have a 169 GB postgres database of unit information through time every few ticks of thousands of replays and the game result. I am sure some interesting strategy and balance information could be extracted from this. Currently it is run on a Linux machine through wine but it does have issues with black-screens and removing the graphics entirely would make it much smoother and faster.

[IndexLibrorum]

@Tokyto_ said:

I now have a small proof of concept with polygon-shaped lakes at different elevations. Ships, submarines, torpedoes and naval factories seem to work in my tests. I also tried AI games and a short two-PC LAN game without a desync, although there’s still a lot more testing to do.

Very cool. If you're looking for another related concept, mapmakers have been complaining for years that there is no kind of terrain or option to allow both naval and land units to cross the same spot. Think something like bridges, or 'shallows' like AoE has.

Something like that would be really interesting for us mappers.