Does Supcom work with windows 11?
-
Please focus only on the question that @soulgamer31 asked, which is if anyone is aware of any FAF bugs that are specific to Windows 11.
Is anyone aware of any bug, unwanted behavior, or significant performance decrease, that only happens when you run FAF in Windows 11, but not when you run FAF in Windows 10? If so, please report it here.
This isn't the right thread to talk about minor performance issues or performance optimization.
-
none at all
-
I have been running windows 11 for nearly month and developing the client and noticed no issues
-
Okay, thanks for the answers guys. I think im going to bite the bullet and try upgrading. I'll report back here if i encounter any problems. Cheers
-
@soulgamer31 Hey! Could you please share experience on how does FAF (and windows 11) working for you?
-
I have upgraded to Windows 11 and have found there is no issues with FAF client or Supreme Commander Forged Alliance. In fact I haven't seen any issues with any of my older games. Windows 11 does feel faster than Windows 10 so for me so worth the upgrade.
-
Does work on Windows11 on Mac M1 with the faf-client executable set on "Safe emulation"
https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-program-compat-troubleshooter -
@corsaire said in Does Supcom work with windows 11?:
Does work on Windows11 on Mac M1 with the faf-client executable set on "Safe emulation"
https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-program-compat-troubleshooterOne bit of advice however, it "works" but has a desynchonization problem.
See this topic https://forum.faforever.com/topic/2796/desync-on-all-replays-and-games-with-windows-11-arm-on-m1-max-apple/6 -
This is not necessarily an issue with Windows 11 but rather the hardware it is running on. If the hardware performs non deterministic calculations or gets different answers than other machines the game will desync.
Not much to do with windows 11 I believe -
@sheikah
Couldn't it be possible to reinforce the code for those calculations to make them really identical?
I mean having two computers giving different results for a same calculation is kind of, bad.Makes you remember the infamous Pentium processor floating point hardware bug...
Programs such as Matlab does tons of calculations and don't get throw out the windows whatever the processor or the OS that makes them run.
-
@corsaire said in Does Supcom work with windows 11?:
I mean having two computers giving different results for a same calculation is kind of, bad.
This happens all the time. Particularly floating point numbers (in comparison to doubles) is easy prey to giving different results. It may be small, but if it determines whether something got hit then suddenly you have a desync. You can read this article that scratches the surface of the issue.
-
@jip That's a nice article you got here.
Interestingly it points to a possible solution for the case we are facing. -
A solution if we had access to the source code of the engine - which we do not :sad_cowboy:
A work of art is never finished, merely abandoned
-
We would not be able to rip out floating points out of the egine even if we had source code access. Maths, graphics and physics libraries for games and even C++ compilers all usually are written explicitely for floating point numbers instead of simulating it with fixed point arithmetic. Switching away from floating point, if at all possible, would probably result in an engine too slow to be usable.
And for little reason, becasue the imprecision of floating point is not really the problem here. A problem only appears if the imprecision varies from machine to machine. If you use the exact same hardware/software, you will still have floating pint imprecision, but it will be the exact same imprecision on every machine, so the game will not desync.
However, when hardware is emulated you often run into problems where the emulation has to do things slightly different than real hardware for performance reasons.
Anyway that doesn't matter much because we still need engine source to find problems with the strictness of FP operations.
-
@katharsas said in Does Supcom work with windows 11?:
And for little reason, becasue the imprecision of floating point is not really the problem here. A problem only appears if the imprecision varies from machine to machine. If you use the exact same hardware/software, you will still have floating pint imprecision, but it will be the exact same imprecision on every machine, so the game will not desync.
I think this is incorrect.
In the CPU when processing floats they are processed using full precision instead of 32 bits. However, when the thread is taken off the processor the intermediate result is stored back into 32 bits (as it is a float and not a double). This can cause any computation to divert.
I think in FA they use double precision for everything. I know that at least Lua uses double precision by default.
-
I was thinking, it is probably a very naive thought but, can the calculation be done by another code, like a mod?
Or is it something that is done by a part that is untouchable? -
@jip said in Does Supcom work with windows 11?:
A solution if we had access to the source code of the engine - which we do not :sad_cowboy:
We do legit have access to alot of the games' code. While not helpful for above problem I do think it is worth stressing that we do have alot going for other games don't.
-
@dragun101 said in Does Supcom work with windows 11?:
We do legit have access to alot of the games' code. While not helpful for above problem I do think it is worth stressing that we do have alot going for other games don't.
hmmm, so you think that it would be possible to have a look into this matter?
-
No, Jip knows the code better than I do. I am just saying how lucky we are in general.
-
@jip said in Does Supcom work with windows 11?:
@katharsas said in Does Supcom work with windows 11?:
And for little reason, becasue the imprecision of floating point is not really the problem here. A problem only appears if the imprecision varies from machine to machine. If you use the exact same hardware/software, you will still have floating pint imprecision, but it will be the exact same imprecision on every machine, so the game will not desync.
I think this is incorrect.
In the CPU when processing floats they are processed using full precision instead of 32 bits. However, when the thread is taken off the processor the intermediate result is stored back into 32 bits (as it is a float and not a double). This can cause any computation to divert.
I think in FA they use double precision for everything. I know that at least Lua uses double precision by default.
I think you are talking about putting values into/out of registers, because speaking of threads does not make much sense in this context. If your CPU context switches your thread into/out of the hardware, it should also restore/backup any register values.
The only thing that your CPU is doing is executing instructions. If the same instruction does the same thing on every CPU that you want to support, you can safely use that instruction without ever running into problems. I am not sure why expanding a float to a double and back would change anything about that.
If you know to which instructions your code is compiled by your C++ compiler, you can probably make sure that only the ones are used that are consistent for every CPU that is relevant.
Here is an example of the amount of options you have on windows these days:
https://docs.microsoft.com/en-us/cpp/build/reference/fp-specify-floating-point-behavior?view=msvc-170I have no idea if those options are enough or if they result in code that is too slow, there are usually a ton of trafe-offs to consider here. For a usefull insight we would have to
- know which instructions create the problem for the emulator
- why and how often the game uses those instructions
- if those instructions can be replaced with an equivalent that does not run into the same problem
@Corsaire
In general nothing is really impossible, but you would need to do reverse engineering and answer all the questions stated above. And even if you know the exact problem it it might be unfeasable to patch (for example due to problematic instruction(s) being used everywhere in the code or the replacement instruction(s) being larger than the original instruction).
