• Create Account

We're offering banner ads on our site from just \$5!

### #Actualhplus0603

Posted 14 December 2012 - 12:15 PM

you still have to do the transition from time to ticks at some point on the client if you want to update the client time with the internal clock

Yes, but that's the only place you need to do it. Basically, there is one place in your code where you do:

targetTick = (currentTime() + serverOffset) * ticksPerSecond;

And you only do this at the beginning of a step (or, even, when detecting whether steps need to be done.)

And, you could measure serverOffset in ticks, rather than time -- you don't necessarily need better precision than that. Thus, the math could just as easily be:

targetTick = currentTime() * ticksPerSecond + serverOffset;

There's really very little reason to use resolution of fractional ticks in physics or simulation or networking.

For presentation, if you run graphics faster than physics, you may want it, to do presentation extrapolation. But try to keep that from leaking into simulation.

: fix tags

### #3hplus0603

Posted 14 December 2012 - 12:15 PM

you still have to do the transition from time to ticks at some point on the client if you want to update the client time with the internal clock

Yes, but that's the only place you need to do it. Basically, there is one place in your code where you do:

targetTick = (currentTime() + serverOffset) * ticksPerSecond;

And you only do this at the beginning of a step (or, even, when detecting whether steps need to be done.)

And, you could measure serverOffset in ticks, rather than time -- you don't necessarily need better precision than that. Thus, the math could just as easily be:

targetTick = currentTime() * ticksPerSecond + serverOffset;

There's really very little reason to use resolution of fractional ticks in physics or simulation or networking.

For presentation, if you run graphics faster than physics, you may want it, to do presentation extrapolation. But try to keep that from leaking into simulation.

### #2hplus0603

Posted 14 December 2012 - 12:14 PM

you still have to do the transition from time to ticks at some point on the client if you want to update the client time with the internal clock

Yes, but that's the only place you need to do it. Basically, there is one place in your code where you do:

targetTick = (currentTime() + serverOffset) * ticksPerSecond;

And you only do this at the beginning of a step (or, even, when detecting whether steps need to be done.)

And, you could measure serverOffset in ticks, rather than time -- you don't necessarily need better precision than that. Thus, the math could just as easily be:

targetTick = currentTime() * ticksPerSecond + serverOffset;

There's really very little reason to use resolution of fractional ticks in physics or simulation or networking.

For presentation, if you run graphics faster than physics, you may want it, to do presentation extrapolation. But try to keep that from leaking into simulation.

### #1hplus0603

Posted 14 December 2012 - 12:14 PM

you still have to do the transition from time to ticks at some point on the client if you want to update the client time with the internal clock

Yes, but that's the only place you need to do it. Basically, there is one place in your code where you do:

targetTick = (currentTime() + serverOffset) * ticksPerSecond;[/quote]

And you only do this at the beginning of a step (or, even, when detecting whether steps need to be done.)

And, you could measure serverOffset in ticks, rather than time -- you don't necessarily need better precision than that. Thus, the math could just as easily be:

[code]targetTick = currentTime() * ticksPerSecond + serverOffset;

There's really very little reason to use resolution of fractional ticks in physics or simulation or networking.

For presentation, if you run graphics faster than physics, you may want it, to do presentation extrapolation. But try to keep that from leaking into simulation.

PARTNERS