Re: DT in BGT
You don't need to worry about clock::update. It's hard to think of a good reason someone would need it, but it didn't seem impossible, so I included it just to be safe.
If you use the amount of realtime that elapses for dt, you'd probably get more accurate physics on one machine, but you would be right back where you started with multiplayer being a mess. In theory, you could do it that way, but it's much easier to sync frames than realtime. You're going to get inconsistent delays, no matter what, due to the differences in computers, delays over the network, etc. The slight differences in realtime that pass between calls to move will add up, and you'd basically have to have the server control everything and send that constantly.
Using a constant frame delay for dt has it so that, even if there is some lag, you know that in 100 frames after the ball was hit, it will be in the same place for both players, which you could not say for 1.7s. The players won't be in the same frame at the same time, but outside of extreme situations, they'll be close enough that you can account for the difference without relying on the server to do everything.
The thing about realtime calculations is that you would need to track every force and when it was applied to remain deterministic. You'd basically be calculating everything that happened since the last input, and then you'd still need to worry about overpenetration, etc. Frames allow you to calculate what happened in the past frame, without there being as much room for error. It's basically a tradeoff between millisecond accuracy and determinism, due to never being able to predict for sure what millisecond the calculations will be performed in. The purpose of the clock is to keep dt as close to constant as possible, and the errors should mostly average out on the scale of seconds.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
