irresistible force wrote:
Hi ColacX. This is some tricky stuff - I expect the lack of replies is only because you are doing this already, which actually makes you one of the leading authorities on the subject
I did some similar stuff a long time ago in 3D with the ODE engine and it was no picnic. As long as you give the same inputs to all simulations, theoretically they should run the same (although there are of course plenty of other problems from floating point precision on different architectures etc). As long as you add the new body in the same time step, theoretically the outcome should be the same. So for example, if the server adds the new body between the 135th and 136th time steps, the client should too. This pretty much means that the two simulations need to progress in lock-step, as fast as the slowest among them can go.
It sounds like you already have a good system for checking if things get out of sync, maybe you could apply similar checks to all the data going into
each simulation as well to make sure they are the same.
hey thanks for the reply. feels good to know I'm on top of things
Yeah if the client and server starts the simulation on the same frame it works really well. However the problem is when the client joins mid-game all existing bodies needs to be recreated on the client side and that is when the internal-state of the b2world differs. Joining-mid game is a really wanted feature as we want up to 8 players to join and leave as they wish.
As you said I already am running the simulations in lock-step, that does make the outcome exactly the same. Except for the problem described above.
Currently I'm testing on the same computer so I wont have to worry about floating-pointers just yet.
I'm using a checksum of all bodies property values to determine if they are in-sync or not, currently the solution right now is to simply resync any body that is off-sync which causes a snapping of the position every 60th frame or so, which looks a bit bad for the user.
The input data are in sync, I've tested that. But it's easy to just add a checksum for that too so why not.