Re: [AD] use double for al_current_time and al_rest?

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2007-12-28, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> On Fri, 2007-12-28 at 14:53 +0100, Andrei Ellman wrote:
> >  > If we want nanoseconds instead of milliseconds, a 32-bit integer would
> >  > not work though for al_get_current_time, as it would overflow pretty
> >  > fast (after 4 seconds) - but both Linux and Windows timers would provide
> >  > us with that precision nowadays so seems a pity just rounding it down.
> > 
> > Why not just use a 64-bit integer internally for representing the time. 
> > While floating point numbers have a greater dynamic range, they are 
> > prone to undeflow when the exponent becomes too large. A 64 bit integer 
> > is equally as long as a 64 bit double.
> > 
> > Internally, all calculations involving the timer will be done using 64 
> > bit integers. The user-level functions that access and manipulate the 
> > timer will use doubles. The double will be converted to a 64-bit integer 
> > before it is used in timer-calculation. Likewise, functions for 
> > retrieving the timer value will convert the result to doubles. As well 
> > as doubles, the timer can be set/accessed using Allegro's 'fixed' type 
> > if anyone wants to set the timer using fixed's. If speed of timer 
> > access/manipulation really is reqired, another set of functions can be 
> > written that uses the native timer-format (64-bit integer) to avoid the 
> > overhead of conversion, but the docs will recommend using a 'double' 
> > number of seconds for ease of use.
> 
> Makes sense. I still think it might be overkill (as I said, for 90 days
> of continuous time, the precision would stay below nanoseconds with
> seconds expressed as double) - but if we would have more time related
> functions like something to get the unix time and not just the time
> since Allegro was initialized, this solution would combine the
> advantages of both.

In that case there's no point using 'time since Allegro was initialised'
so might as well use 'time since arbitrary start', i.e. whatever the OS
gives.

Peter