Accurate Physics timing

I understand that NSTimer works by specifying the interval at which it will call the specified method.

I can see that time based movement would be regulated as you would expect time based movement to behave with this method.
_
Okay, the interval is 1/60, which equates to 0.016666.

So, if it takes longer than that to process a frame, what happens? Certainly, the framerate would suffer, however, movement will still be processed as though it hadn't.

Normally, you multiply the acceleration, translation, rotation or whatever physical calculation by the time between frames. With this system, even if the framerate is less than 60, it still would be multiplied by 1/60, unless you calculate the framerate and multiply by the inverse. So, this is one way to do it but isn't there another way that is the more traditional way with a regular timer that counts time between frames?

To summarize, how do I measure timing on the iPhone at a low level?

The documentation for NSTimeInterval says:

Quote: NSTimeInterval is always specified in seconds; it yields sub-millisecond precision over a range of 10,000 years.

Quote:NSTimeInterval is always specified in seconds; it yields sub-millisecond precision over a range of 10,000 years.

What? Seconds or sub-miliseconds? 10k years? Huh?

All that says is how precise the NSTimeInterval data type is. NSTimeInterval is a floating point number representing seconds. The data type (a double) is large enough to offer precision past milliseconds, for a value representing a time of 10,000 years. In other words, it is precise enough to represent a time specified in seconds: 10,000 years x 365 days x 24 hours x 60 minutes x 60 seconds on the left hand side of the decimal point and 0.001... on the right side.

This is what I need to implement. I know how to do it, I've done it before, just not on the iPhone.

Code:

GetCurrentTime();

This function accesses the hardware to count processor cycles, which is translated into milliseconds with some math. The milliseconds are stored and this is how the time intervals are calculated. Is there no equivalent to the above functionality and the functionality that you referred me to?

I am using 3D geometry (which has nothing to do with this) and accurate physics timing too (constant 60 ticks per second on iPhone and 110 ticks on Mac). I am skeptical you fully understood the page I linked to.

bmantzey Wrote:That's a standard way of doing business. Update separate from draw but I'm dealing with 3D geometry. Also, more accurate physics requires a timer.

No, more accurate physics requires small delta steps. If a timer does not fire for 5 seconds, and you simply calculation positions using a delta of 5 seconds, you're going to run through walls and have all kinds of trouble. Everything will be entirely wrong.

The point is regardless of *WHEN* your timer is called, you should *ALWAYS* calculate physics on a known fixed time interval. For example, if you used, 1/100th of a second, then when your timer gets called after 5 seconds of not being called, there would be 500 iterations of physics updates, each using delta of 1/100th of a second, that way all collisions and object interactions are handled appropriately.

bmantzey Wrote:Is there no equivalent to the above functionality and the functionality that you referred me to?

You don't need to use another timer. Just do the same thing on iPhone that you've been doing -- which is actually what I was talking about, and that link too. You're technique will work perfectly on iPhone. That's what I use. In fact, that code looks mighty darn familiar

// If this is the first time we've run, get the timebase.
// We can use denom == 0 to indicate that sTimebaseInfo is
// uninitialised because it makes no sense to have a zero
// denominator is a fraction.
if ( sTimebaseInfo.denom == 0 ) {
(void) mach_timebase_info(&sTimebaseInfo);
}

// Do the maths. We hope that the multiplication doesn't
// overflow; the price you pay for working in fixed point.
nanos = time * sTimebaseInfo.numer / sTimebaseInfo.denom;
return ((double)nanos / 1000000000.0);
}

You should avoid [NSDate timeIntervalSinceReferenceDate] and other methods because they're not accurate. If the clock is changed when your game is running, for example, you'll get wacky results.

AnotherJake Wrote:I am using 3D geometry (which has nothing to do with this) and accurate physics timing too (constant 60 ticks per second on iPhone and 110 ticks on Mac). I am skeptical you fully understood the page I linked to.

No, I do understand it. I'm trying to achieve time based motion. If I translate my geometry (which is 3D) by, say, 5.0f, that may appear slower or faster based on frame rate. That's why you're supposed to multiply the translation by the time between each frame. I understand that the draw function is only being called every 1/60 IF the frame rate is sustained at 60. If you don't multiply your translations and rotations by the time between each frame, you may have slowed down animation, because it's frame based.

FreakSoftware Wrote:No, more accurate physics requires small delta steps. If a timer does not fire for 5 seconds, and you simply calculation positions using a delta of 5 seconds, you're going to run through walls and have all kinds of trouble. Everything will be entirely wrong.

The point is regardless of *WHEN* your timer is called, you should *ALWAYS* calculate physics on a known fixed time interval. For example, if you used, 1/100th of a second, then when your timer gets called after 5 seconds of not being called, there would be 500 iterations of physics updates, each using delta of 1/100th of a second, that way all collisions and object interactions are handled appropriately.

I agree, that's what the Variable interval time-based physics solves. I'm asking about a timer.