Allegro game programming library

On Sat, 2007-12-29 at 18:28 +1100, Peter Wang wrote:
> modules.lst is a static file.  At initialisation time Allegro tries to
> load every module in the list and just ignores if it fails.  Actually,
> the only reason it exists is that I thought it's somehow more secure
> than loading any module that exists in the module directory.  That, and
> it allows the system administrator to prevent unwanted modules without
> actually deleting them.  I don't think either are very good or useful
> reasons though, so if someone can be bothered changing it...
> 

Yeah, I guess nothing would be lost if we just hardcode the list - the
only important thing is the ALLEGRO_MODULES environment variable.

Oh, and somewhat related, right now scons (and also cmake I think) put
liba5_font.so into the <prefix>/lib/allegro/<version>/ - i.e. along with
the modules. That wasn't done with any special reason behind it though,
so maybe it should be changed to just install it as
<prefix>/lib/liba5_font.so (or some other name if we don't want the
liba5_ prefix), so no second -L has to be output by allegro-config and
it also would be consistent with how it works in Windows.

-- 
Elias Pschernig <elias@...>

IMHO the better definition of "current time" is not a long, fixed, int or double. It is some sort of structure containing day, month, year, hour, minute, second and milli-micro-or-nanoseconds.
To measure the amount of time betewwen two different times, some helper functions can do it easily.

Victor Williams Stafusa da Silva

Peter Wang <novalazy@...> escreveu: On 2007-12-28, Elias Pschernig  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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-- 
https://lists.sourceforge.net/lists/listinfo/alleg-developers


       
---------------------------------
Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!

On 2007-12-28, Victor <vwss1984@...> wrote:
> IMHO the better definition of "current time" is not a long, fixed, int or double. It is some sort of structure containing day, month, year, hour, minute, second and milli-micro-or-nanoseconds.
> To measure the amount of time betewwen two different times, some helper functions can do it easily.

Calendar time is pretty useless for most game situations (and there are
standard C functions for that, albeit only with second granularity).
What most games need is the interval between two points in time, e.g.
between two frames, in a single unit if possible.

Peter

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...  You could also keep al_current_time as a count of total time but the user could also do this by adding all the calls to al_get_counter together in there own code...


/* Simple example where al_counter is incremented elsewhere */
static unsigned long al_counter = 0;
static unsigned long al_count_per_second = 60; /* Example */
unsigned long al_get_counter(void)
{
   unsigned long ret = al_counter;
   al_counter = 0;
   return ret;
}

double al_get_counter_d(void)
{
   double ret = (double)al_counter / (double)al_count_per_second;
   al_counter = 0;
   return ret;
}

Peter Wang <novalazy@...> wrote: On 2007-12-28, Victor  wrote:
> IMHO the better definition of "current time" is not a long, fixed, int or double. It is some sort of structure containing day, month, year, hour, minute, second and milli-micro-or-nanoseconds.
> To measure the amount of time betewwen two different times, some helper functions can do it easily.

Calendar time is pretty useless for most game situations (and there are
standard C functions for that, albeit only with second granularity).
What most games need is the interval between two points in time, e.g.
between two frames, in a single unit if possible.

Peter


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-- 
https://lists.sourceforge.net/lists/listinfo/alleg-developers


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.

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.

Anyway, making some calculations I saw that a 64 bit-integer is big enough to have nanosecond precision for more than 1000 years without overflow. So this would be a nice representation for internal time and is a good return value for al_get_current_time. Some helper functions could convert this to a gregorian calendar time value easily.

As explained by Ron, the current time is not very useful, the time interval is better. But an interval could be calculated easily by subtraction of two calendar times.

Victor Williams Stafusa da Silva

Ron Novy <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...  You could also keep al_current_time as a count of total time but the user could also do this by adding all the calls to al_get_counter together in there own code...


/* Simple example where al_counter is incremented elsewhere */
static unsigned long al_counter = 0;
static unsigned long al_count_per_second = 60; /* Example */
unsigned long al_get_counter(void)
{
   unsigned long ret = al_counter;
   al_counter = 0;
   return ret;
}

double al_get_counter_d(void)
{
   double ret = (double)al_counter / (double)al_count_per_second;
    al_counter = 0;
   return ret;
}

Peter Wang <novalazy@...> wrote: On 2007-12-28, Victor  wrote:
> IMHO the better definition of "current time" is not a long, fixed, int or double. It is some sort of structure containing day, month, year, hour, minute, second and milli-micro-or-nanoseconds.
> To measure the amount of time betewwen two different times, some helper functions can do it easily.

Calendar time is pretty useless for most game situations (and there are
standard C functions for that, albeit only with second granularity).
What most games need is the interval between two points in time, e.g.
between two frames, in a single unit if possible.

Peter


-------------------------------------------------------------------------
This SF.net email  is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-- 
https://lists.sourceforge.net/lists/listinfo/alleg-developers

         

---------------------------------
Never miss a thing.   Make Yahoo your homepage.  -------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/-- 
https://lists.sourceforge.net/lists/listinfo/alleg-developers

       
---------------------------------
Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!

On 2007-12-29, Victor <vwss1984@...> wrote:
> 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
case.

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

Peter

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 <novalazy@...> escreveu: On 2007-12-29, Victor  wrote:
> 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
case.

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

Peter


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-- 
https://lists.sourceforge.net/lists/listinfo/alleg-developers


       
---------------------------------
Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!

http://msdn2.microsoft.com/en-us/library/hskdteyh.aspx

contains a CPUID intrinsic (no need for asm)

there is lots of useful source code there too.

this at least might be useful for MSVC versions, possibly mingw too.


aj.



Evert Glebbeek wrote:
> On Dec 28, 2007, at 11:05 PM, Milan Mimica wrote:
>   
>> This will break the watcom build as it doesn't support  
>> ALLEGRO_USE_C, if anyone cares.
>>     
>
> Probably not. If someone comes along and does they can fix it. ;)
>
>   
>> Also, I assume that non-ASM version is generally less tested  
>> becasue it wasn't a default choice, so this change might have  
>> impact on allegro stability on some platforms.
>>     
>
> Probably not too much. When build in 64-bit mode Allegro doesn't use  
> the inline asm code except to query the CPU capabilities flag with  
> CPUID, which reminds me, we may want to keep that information and  
> related information at hand. Having a single function that calls  
> CPUID isn't quite the same as using ASM code all over the code.
> The MacOS X port also uses the C only version.
>
> Evert
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>