Not logged in, Join Here! or Log In Below:


Hello ppl! 

I fear that FPU calculations are incoherent across platforms, and especially compilers. 

Okay, exactly as I feared. 

You could store the position/velocity at each frame. Then to verify the replay, you can run the physics on the previous position, an comare the result with the next position, and if it meets some tolerance, like the values are within 99% of eachther 99% of the time, you can consider it valid. 

That COULD work. :) 

How about cutting all float values down by some precision ? Say you round all position and speed values to the next 0.25f after each calculation (both on the server and on the client)? I think quake 2 did something similiar in its networking code. This would probably diminish different floating point errors. 

I think a fixedpoint number class with overloaded operators could quickly drop in and replace float as a numeric type. I don't think it'd be much of a hassle to implement it. 

I think a fixedpoint number class with overloaded operators could quickly drop in and replace float as a numeric type. I don't think it'd be much of a hassle to implement it.
Dead wrong. Of course writing such a class is not much of a problem, but it is never a dropin replacement for floats. Most importantly, you'll absolutely never get around rewriting your calculations completely if you want any reasonable precision. Proper fixedpoint maths involves lots of different internal fixedpoint formats and precision considerations. Case in point: Vector normalization. With floats you'll probably have something like:
When you just naively replace that by 16.16 fixedpoint arithmetic, you'll have at least the following problems:  For x, y, z >= 181.019348 (0xb504f4 in 16.16 fixed point), the products x*x will overflow (assuming signed integer arithmetic).  For x, y, z 

That is perfectly clear to me; anyway, I think it's a nice summary of the different caveats of fixed point math. 

There was some talk on the ODE mailing list (yeah, I use ODE), about someone was trying to make a fixed point version of the library. Unfortunately the guy ran into a large pile of problems, so he abandoned the idea all together. As far as I can see, his main problem was to maintain precission in complicated calculations  in each and every place where something was calculated, he had to consider what happened to the precission, and take appropriate action. A hell of a mess I think. (Physics simulations are very sensitive to numerical errors; it's difficult to keep everything stable) 

Hi again, 

Wernaeh: 

If you decide to store the state  you don't need to store everything every frame. Either store things every tenth of a second or so, or else only store things when the state has changed by more than a certain amount. Then use interpolation during playback. So, I wouldn't have thought storage size would be a big deal. This doesn't address the cheating issue that you started with, though. Maybe you could store the control information as well, and use that to do some basic sanity checking of the state info... 

True, true, true. 

Ah ok, thanks for the explanation :D 
