#Supreme commander 2 desync 64 bits#
#Supreme commander 2 desync code#
#Supreme commander 2 desync license#

If your x87 implementation isnвЂ™t IEEE, itвЂ™s not x87.ДЄlso, you canвЂ™t use SSE or SSE2 for floating point, because itвЂ™s too under-specified to be deterministic. Furthermore, you have to check this after calls to external DLLs, because many DLLs (Direct3D, printer drivers, sound libraries, etc) will change the precision or rounding mode without setting it back.

#Supreme commander 2 desync 64 bits#

You have to make sure that the internal precision is set to 64 bits (not 80, because only Intel implements that), and that the rounding mode is consistent. The specifics vary by platform (i e, different between x86, ењ†4 and PPC).

#Supreme commander 2 desync license#

The technology we license to various customers is based on determinism of floating point (in 64-bit mode, even) and has worked that way since the year 2000.ДЄs long as you stick to a single compiler, and a single CPU instruction set, it is possible to make floating point fully deterministic. Here are the resources I have discovered in my search so farвЂ¦ Please contact me especially if you have managed to get binary exact results across different architectures and compilers in real world situations. If you would like to debate these points or add your own nuance, please contact me! I consider this question by no means settled and am very interested in other peoples experiences with deterministic floating point simulations and exactly reproducible floating point calculations. This typically results in significantly lower floating point performance. However with a good deal of work you may be able to coax exactly the same floating point results out of different compilers or different machine architectures by using your compilers вЂњstrictвЂќ IEEE 754 compliant mode and restricting the set of floating point operations you use.

#Supreme commander 2 desync code#

It is incredibly naive to write arbitrary floating point code in C or C++ and expect it to give exactly the same result across different compilers or architectures, or even the same results across debug and release builds. It is possible to get deterministic results for floating calculations across multiple computers provided you use an executable built with the same compiler, run on machines with the same architecture, and perform some platform-specific tricks. If your physics simulation is itself deterministic, with a bit of work you should be able to get it to play back a replay of recorded inputs on the same machine and get the exact same result. Unfortunately, the answer is not a simple вЂњyesвЂќ or вЂњnoвЂќ but вЂњyes, ifвЂ¦вЂќ What exactly is going on? Are floating point calculations deterministic or not? Other folks say that AMDs give different results to Intel machines, and that SSE results are different from x87.

People even report different results on the same machine from run to run, and between debug and release builds. Physics simulations use floating point calculations, and for one reason or another it is considered very difficult to get exactly the same result from floating point calculations on two different machines. It is clear that the only possible solution in this situation is to attempt a deterministic networking strategy.Д«ut we run into a problem. Perhaps you have a complex physics simulation with lots of rigid body state, or a cloth or soft body simulation which needs to stay perfectly in sync across two machines because it is gameplay affecting, but you cannot afford to send all the state.

In fact, this strategy has been used for many years in RTS games for precisely this reason with thousands and thousands of units on the map, they simply have too much state to send over the network. This is a very attractive synchronization strategy because the amount of network traffic depends on the size of the player inputs instead of the amount of physics state in the world. over the network, one could synchronize the simulation implicitly by sending just the player inputs. The basic idea is that instead of synchronizing the state of physics objects directly by sending the positions, orientations, velocities etc. Lately IвЂ™ve been doing some research into networking game physics simulations via deterministic lockstep methods. Hi, IвЂ™m Glenn Fiedler and welcome to Networking for Game Programmers.