Calculate the nanos, micros, millis, seconds, minutes, hours and days between two time intervals is easy. Just a simple subtraction and a simple divide by a constant will do. It get's complicated just for months and years interval, which is not what we are focusing.
Eg: How many millis we have between nanosecond values A and B?
Answer: (B - A) / 1000000
The inverse conversion (calendar to internal form) is very complicated indeed. Fortunately there is very few need and interest to do this. What we need is get a timestamp (al_current_value()) and measuring an interval (subtract and divide).
So, if we have a 64-bit nanosecond calendar time with some arbitary calendar time at zero-time (as many OS does). Converting that to a gregorian representation is not very hard. Anyway, in games we normally don't need the gregorian representation, just the internal one is enough.
However, about the conter reset, you are right. It would give a lot of headache.
Victor Williams Stafusa da Silva
Peter Wang <firstname.lastname@example.org> escreveu:
On 2007-12-29, Victor
> I agree, calendar time is almost useless for games. However some
> helper functions can easily get the number of
> nanos/micros/millis/years between two calendar times.
Which is backwards as all operating systems I know of provide high
precision micro/nanoseconds relative to some arbitrary offset, with
conversion functions into calendar time, not the other way around. Your
suggestion would have us do two (complicated) conversions for the common
> Ron Novy
escreveu: Why not use a counter that is
> reset every call instead of a timer. Use a function like
> al_get_counter or something and have it return a double or have
> multiple versions like al_get_counter (unsigned long) and
> al_get_counter_d (double)... This would give infinite resolution and
> make time relative to the app/game/thread using it...
That's horrible for multithreaded programs, unless the counter is
thread-local. Even then, it's horrible as soon as you have two time
intervals to track within the one OS thread. In any case, we use
al_current_time() for the time stamp in events. We need a global
reference for that.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.