AnotherJake Wrote:This works on iPhone too:

Code:

#import <sys/time.h>
double GetCurrentTime(void)
{
    struct timeval time;
    
    gettimeofday(&time, nil);
    return (double)time.tv_sec + (0.000001 * (double)time.tv_usec);
}

It will not, for the same reasons I stated above. It's not guaranteed to be accurate. What I wrote is the most accurate method you can use.

bmantzey Wrote:No, I do understand it.

No you do not.

If you pay close attention to what he's doing, he's compensating for when the framerate goes low. e.g. If framerate is 30 and you want 60 ticks, it inserts another update each frame.

@Najdorf: if your physics is the bottleneck, then you got problems!

@FreakSoftware: Accuracy may be debatable, but it works just fine.

bmantzey Wrote:I agree, that's what the Variable interval time-based physics solves.

No, that's completely contradictory. If it's a variable delta for the physics, you end up with the problem I already explained. You can have inaccurate physics results. It really seems you're fundamentally misunderstanding that point.


@AnotherJake: Yes, you're right re: accurate vs works. But you might as well use the one that's guaranteed always correct.

AnotherJake: it doesn't work fine.

gettimeofday, [NSDate timeIntervalSinceReferenceDate] and others are based on *wall clock time*. That means that if the time is adjusted by a large amount (eg. the user pokes around in system prefs) the values returned will be discontinuous. If the time is adjusted by a small amount (eg. NTP synchronization calls adjtime()), the value returned will not increase at a rate of one second per second.

mach_absolute_time and other fronts for it don't suffer this problem; they're based on absolute elapsed time delta since boot.

Looks like Mach is what I need to be looking closely at. Are you sure it works on iPhone?

bmantzey Wrote:Looks like Mach is what I need to be looking closely at. Are you sure it works on iPhone?

I didn't paste it for no reason.

OneSadCookie Wrote:AnotherJake: it doesn't work fine.

Okay, okay, I'm sold. I hadn't really considered how much havoc it might cause if the clock changed...

FreakSoftware Wrote:I didn't paste it for no reason.

Well, I got mach in there and it appeared to work beautifully in the simulator. However, when we put it into the iPhone, it made it crawl. We know it was the timer because when we took it out, it made a huge difference. Have you tested this on the actual phone? Maybe I'm doing something wrong. I had one question, what's


do?

The Apple documentation said that it should be called many times and averaged, for more accuracy, but how? I can see that it returns an integer but the example given only called it and didn't actually do anything with the returned integer.

Okay, obviously, divide the number of times it was called by the sum attained from those calls is how to get the average, but what do I do with it after I get that average?

As I have it now, it's only calling that function, just as Apple does and it's called every frame.

Quote:Have you tested this on the actual phone?

Sadly, I *couldn't* actually test it on the phone because my application was all screwed up. That's all taken care of now, (as of a day or two ago), but I haven't had the time/need to setup testing on the phone yet.

At any rate, I'm highly skeptical that it would be slow. I could certainly be wrong, but it's such a low-level low-overhead thing that it shouldn't be an issue.

-

getpid just gets the id of the process (your game).

The use of getpid in Apple code you're looking at has nothing to do with timing. Apple is purely using it at as an example to show that using mach to get timing information is so precise that you can time a single function like getpid which returns practically immediately. It has absolutely no usefulness to you at all in any way shape or form. You should not be calling it, using, or anything.

bmantzey Wrote:Have you tested this on the actual phone?

I have been using it on an actual device and it works as advertised, and it's not slow by any remote stretch of the imagination, so you must be doing something else incorrectly.

AnotherJake Wrote:I have been using it on an actual device and it works as advertised, and it's not slow by any remote stretch of the imagination, so you must be doing something else incorrectly.

I can accept that. Should I wrap any use of NSLog in #if TARGET_IPHONE_SIMULATOR ?

That's the only other thing I can think might cause this problem.

Oh, I'm using doubles instead of floats if that matters at all.

NSLog and doubles matter not.

What you should do is profile your program to see precisely what the problem is.

How do I profile it?

/Developer/Applications/Performance Tools/Shark

To use it for iPhone you need to go to Sampling->Network/iPhone Profiling...

Then once you've launched your app on the iPhone you can select it as a target. It's not the most reliable tool on iPhone, as I have had it crash/hang numerous times, and it takes *forever* to analyze, but when you do finally get some data it'll nail down trouble right away. Probably don't want to sample for more than a few seconds at a time because of how much it chokes on the iPhone, but it's worth the hassle.

Sweet, thanks again.