upvote
There is an interesting technical reason why its a challenge (and they can't just swap in a supported library):

> What makes the “simulate inputs” approach work is that the engine takes utmost care to keep calculations identical on each client. This is not trivial because you still have to work with things that naturally differ on each client, such as mouse position or which units are selected - this is called the unsynced state. On top of that, there can be hardware differences that have to be worked around to get identical results - the huge effort involved is one of the reasons why Recoil is not available outside x86-64.

https://recoilengine.org/articles/netcode-overview/

reply
That notice is not worded in the best way and hasn't been updated for a while. However, progress has been made.

On the Recoil engine releases (https://github.com/beyond-all-reason/RecoilEngine/releases) page, we have had experimental Linux arm64 builds since March of this year.

Additionally, several people are trying to get the graphical pipeline and overall build working on Mac; you can follow their progress at https://github.com/beyond-all-reason/RecoilEngine/issues/936

The challenge with arm64 is that Recoil Engine does deterministic lockstep simulation using actual native floats for performance. Porting all of those operations (which were implemented using the mentioned library) to work on arm64 and produce the exact same bit-perfect results as on x86_64 has been challenging.

reply
It's great to hear, yeah I researched this topic a bit further and there are clearly some very determined people who want to bring BAR to more platforms, excited about the progress! Floats will be a big pain in the ass for sure and will cause countless desyncs, same story prevented playing supreme commander FAF on ARM processors, though a lot of attempts have been made
reply