@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:
I 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
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).