I was having all sorts of TIME related bugs until I did this...

So the last few days I had an issue with schedules and behaviors not working on my iPad device. I traced the problem down to how time was being measure on the device and that fixed the scheduling and behaviors.

Then I started having a weird issue where the game became unresponsive, yet was not totally locked up. According to the debugger it was being put to sleep in Platform::sleep() for like thousands of seconds due to yet more bad numbers being returned from the time functions.

So as a temporary workaround I commented out the sleep function and the game stopped freezing.

Lastly I started working on a bug that I had been dealing with for a week or so now, where my game piece movement (done using MoveTo) was at times instantly moving to its destination instead of smoothly over time. After dealing with these time issues I started to think that maybe this was related as well, and sure enough it was. When the bug happened and the pieces moved instantly from one side of the board to the other it was because yet again bad numbers were coming from the time functions, and the sim was thinking a much longer period of time had elapsed than really had.

It all came down to Platform::getReallMilliseconds(). This function was the root of all these issues, but only on the new iPad. I started doing some research into mach_absolute_time(), and found a few code snippets on the web for using it to measure elapsed time. I then rewrote Platform::getRealMilliseconds() using what i'd learned.

Here is what I ended up with:

U32 Platform::getRealMilliseconds()
{
 	
    mach_timebase_info_data_t info;
    if (mach_timebase_info(&info) != KERN_SUCCESS) return -1.0;
    uint64_t absTime = mach_absolute_time();
    uint64_t nanos = absTime * info.numer / info.denom;    
    uint64_t durTime = nanos / 1000000;
    //Duration durTime = absTime * absolute_to_millis;
    U32 ret;
    ret = durTime;

    return ret;
}

Now i'm one of those programmers who ironically is good at their job yet absolutely horrible with math. However the funny thing is i'm pretty sure this is functionally identical to what the code did before, except the previous code tried to do it all in one line, whereas i'm doing it in pieces. My suspicion is that the all in one line version was overflowing and causing the value to be incorrect.

All I know for certain is since I did this, all of my previous bugs and errors have gone away and my game runs much better than it did before. All from that one change.

So bug or not in the engine, I thought i'd post this up for anyone in the future who might run into similar issues.