frob: Now I realise I had made an assumption which I may not have made clear enough - I was referring to 'floating point' as just the bits covered by the IEEE 754 standard. I accept that everything outside it (like sin, inv sqrt etc) may not always give the same result across all processors.
Good luck performing 3D world operations and physics manipulations without them.
Going back to the OP, I'd recommend doing the following to get the replay system robust:
* Do a binary save after every single step of the simulation.
* After each step, load the previous step's save, and apply the input again.
* Compare the CRC of the two states
* If there's a difference, then compare a binary save of the original step against a binary save from the repeated step
* Find out which byte of the binary saves is the first one that's different.
* Load one of the binary saves, but this time assert when you get to the different byte
* You should have a callstack that indicates which member of which entity has diverged which should give you a pretty strong clue about where you went wrong.
Do this all the time in your debug builds so you catch any new bugs immediately, and not just when you're explicitly trying to test your replay system.
I recently wrote an article which covers some relevant stuff (in the context of lockstep multiplayer): http://www.tundragames.com/minimizing-the-pain-of-lockstep-multiplayer/
frob: Now I realise I had made an assumption which I may not have made clear enough - I was referring to 'floating point' as just the bits covered by the IEEE 754 standard. I accept that everything outside it (like sin, inv sqrt etc) may not always give the same result across all processors.Good luck performing 3D world operations and physics manipulations without them.
You don't have to. You only need to provide your own versions (which could also be "fast approxiate" versions, depending on your needs) that don't use processor intrinsics like fsin/fcos.
Going back to the OP, I'd recommend doing the following to get the replay system robust:
* Do a binary save after every single step of the simulation.
* After each step, load the previous step's save, and apply the input again.
* Compare the CRC of the two states
* If there's a difference, then compare a binary save of the original step against a binary save from the repeated step
* Find out which byte of the binary saves is the first one that's different.
* Load one of the binary saves, but this time assert when you get to the different byte
* You should have a callstack that indicates which member of which entity has diverged which should give you a pretty strong clue about where you went wrong.
Do this all the time in your debug builds so you catch any new bugs immediately, and not just when you're explicitly trying to test your replay system.
I recently wrote an article which covers some relevant stuff (in the context of lockstep multiplayer): http://www.tundragames.com/minimizing-the-pain-of-lockstep-multiplayer/
This approach looks like it would work without having to add logging in 1000s of places.
But with save times approaching 1 min, saving each frame seems extreme...
Going back to the OP, I'd recommend doing the following to get the replay system robust:
* Do a binary save after every single step of the simulation.
* After each step, load the previous step's save, and apply the input again.
* Compare the CRC of the two states
* If there's a difference, then compare a binary save of the original step against a binary save from the repeated step
* Find out which byte of the binary saves is the first one that's different.
* Load one of the binary saves, but this time assert when you get to the different byte
* You should have a callstack that indicates which member of which entity has diverged which should give you a pretty strong clue about where you went wrong.
Do this all the time in your debug builds so you catch any new bugs immediately, and not just when you're explicitly trying to test your replay system.
I recently wrote an article which covers some relevant stuff (in the context of lockstep multiplayer): http://www.tundragames.com/minimizing-the-pain-of-lockstep-multiplayer/
This approach looks like it would work without having to add logging in 1000s of places.
But with save times approaching 1 min, saving each frame seems extreme...
1 minute sounds like a very long save time! I'd have expected something closer to a couple of milliseconds even in a debug build on a dev PC. That said, my game's state is very minimal.
Could it be improved if you made your binary saves into a block of memory rather than to disk?
It might be. Uncompressed save files are around 200 mb, compressed they take up 14 mb.
