On a second thought, might also be this assert that fails the first tick:

gpAssert( (_controlfp(0, 0) & _MCW_PC) == _PC_24 );

Since setting the _PC_24 flag does not do anything on ARM, when checking the flags, that will be unchanged. First thought - could we disable one of these asserts with a patch? Or somehow pretend the flags are always set as expected on Apple Silicon with _PC_24 set (or redefine _MCW_PC)?

However, two more interesting bits of information I found, comparing Intel and Apple Silicon, which seems to hint at calculations using binary64 (double) match but binary32 (single float / 32 bit (24 bit precision)) don't match:

https://stackoverflow.com/questions/71441137/np-float32-floating-point-differences-between-intel-macbook-and-m1

https://eclecticlight.co/2021/04/22/can-you-trust-floating-point-arithmetic-on-apple-silicon/

If so, that would mean the proper fix would be to replace all single floats in the game with double floats.

From the first link these two function calls are important to ensure deterministic floating point calculations across different systems (such as Intel and AMD):

_controlfp(_PC_24, _MCW_PC)
_controlfp(_RC_NEAR, _MCW_RC)

The first is Precision Control, the second is Rounding Control. According to the microsoft documentation linked for controlfp - setting the Precision Control to 24 bits is not supported on ARM. Making this call on ARM will simply not change anything. The Rounding Control to NEAR seems to be ok.

(Precision Control is not supported for x64 either, but supreme commander FA is 32-bit application I think)

@Eyvind Great find! Even without source code, perhaps it could be possible patch? (or if Microsoft needs to do something?)

It would be interesting to compare with Qualcomm ARM based Windows 11 laptop, if anyone have access to one of those?

Tried again now with latest parallels and windows updates:

Edition Windows 11 Pro Insider Preview
Version 22H2
Installed on ‎6/‎12/‎2022
OS build 25136.1000
Experience Windows Feature Experience Pack 1000.25136.1000.0

Same issue still, i.e. immediate desync on replay playback (but the replay continues fine). Single player works.

Maybe with Metal 3 with MacOS Ventura and new DX12 support in Parallels later this fall it will be improved? Will try again in a few months.

Hi,

I'm running SupCom FA & FAF on Windows 11 ARM on Apple MacbookPro M1 Max in Parallels 17.1. The game runs good (298 cpu score, ~90 fps), but I've noticed that all replays I've tried desync the first second after game starts. This happens also if I join a PVP game. The full game can be viewed on FAF replay, I'm user "malu5531": https://replay.faforever.com/15627000 (needles to say, the game probably looks quite different when others view it compared to when I played it).

I've tried to adjust emulation settings, parallel settings, etc, but not closer to a solution. I'm running Windows 11 Arm release 22489 with FAF Arm emulation setting set to "Safe Emulation".

I've posted a video of the game running on youtube:
https://www.youtube.com/watch?v=ukKOy20BwBk

I attach client.log and game_11612043.log with details on the error when I try to view the following replay: https://replay.faforever.com/11612043

I guess the issue may be some patch / mod not loading correctly since the desync happens immediately. Any ideas what I can try to fix this and/or is there any more information or detailed logs needed for troubleshooting?

Attachments: game_11612043.log client.log