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

[Andrei Ellman <ae-a-alleg@xxxxxxxxxx>]

> Yes, but who will let their program run for a year? :P Anyway, maybe we
> can add a function: al_set_current_time(double t) which resets the value
> (might also be useful if we keep an integer value) - to better allow
> handling overflow. I.e. the user could then simply reset each day
> instead of having to deal with the 50 or how many days, depending on
> what type is used.

Making the user to reset the timer once a day is just another thing 
added to the user's TODO list. If they don't run their app for more than 
a day, they won't notice, but once someone else does, they will notice a 
problem. If they don't bother to mention that the problem only occured 
after running the app for more than a day, the original programmer will 
have trouble tracking down the bug.


> 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.


> > Plus, with doubles being 64-bit, on 32-bit compilers (GCC at least), they'll 
> > be passed through memory by a hidden reference (unlike 32-bit floats that can 
> > be passed on the stack/in registers).

Usually, setting the timer, reading from it or updating it is not 
something that is done repeatedly inside a speed-critical piece of code, 
so I don't think that matters.


AE.