Accurate Physics timing

⌘-R in Chief
Posts: 1,254
Joined: 2002.05
Post: #16
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.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #17
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! Wink

@FreakSoftware: Accuracy may be debatable, but it works just fine.
Quote this message in a reply
⌘-R in Chief
Posts: 1,254
Joined: 2002.05
Post: #18
bmantzey Wrote:I agree, that's what the Variable interval time-based physics solves. Rasp

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. Smile
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #19
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.
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #20
Looks like Mach is what I need to be looking closely at. Are you sure it works on iPhone?
Quote this message in a reply
⌘-R in Chief
Posts: 1,254
Joined: 2002.05
Post: #21
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. Smile
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #22
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...
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #23
FreakSoftware Wrote:I didn't paste it for no reason. Smile


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

Code:
    getpid();

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 this message in a reply
⌘-R in Chief
Posts: 1,254
Joined: 2002.05
Post: #24
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.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #25
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.
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #26
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.
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #27
NSLog and doubles matter not.

What you should do is profile your program to see precisely what the problem is.
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #28
How do I profile it?
Quote this message in a reply
Moderator
Posts: 3,572
Joined: 2003.06
Post: #29
/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.
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #30
Sweet, thanks again.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Timing issues markhula 8 4,753 Sep 29, 2010 07:56 AM
Last Post: mariocaprino
  Raster timing bars markhula 23 7,070 Sep 28, 2010 12:56 PM
Last Post: markhula