Re: [AD] Add timeBeginPeriod(1) to wtimer.c

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Fri, 2005-02-18 at 01:59 +1100, AJ wrote:
> > Ideally, we would either find a document describing the implications of
> > timeBeginPeriod(1), or have some more test results.
> 
> 
> all my net research has not found a single thing that mentions adverse 
> effects.
> 

Yes, same for me.. but I wasn't actually able to find anywhere what it
does. If newer windoses run with a 1ms scheduler anyway, then it should
be no problem at all - Allegro apps just get some sort of higher
priority, and it would be best to call it once in allegro_init.


> > I suspect (may be wrong though), that timeBeginPeriod(1) causes the
> > windows scheduler to be called 1000 times / second instead of just 100
> 
> i dont think the overhead is all that much.
> its a cost worth paying, if its going to give us 1ms accuracy.

Not sure how high the cost would be, even in case it would work like I
think. I only know the linux scheduler has 10ms tickss, and uses every
2nd tick to do scheduling (or something like that, didn't pay enough
attention in lectures :P) - and there must be a reason they don't use
1ms ticks.

> id like to see a really basic test app that i can try on my machine.

Yes, me too. If 3 or 4 people here can test it, and see that accuracy is
improved, with CPU usage only rising insignificantly - there's no
question we should add it.

> so now i think we all agree its a good thing, last thing to test
> is if to put it once globally, or inside the al_rest().
> 

To me, just adding it inside al_rest seems not a good idea. Look at code
like this:

while(1)
{
    if (ticks < logic_frames) { handle_game_logic(); }
    if (gfx_frames < logic_frames) { draw_drame(); }
    else rest(1);
}

With the current polling-based nature of allegro, this is how you get
<100% CPU in a fixed-FPS game. Now if rest(1) actually waits only one
second, then timeBeginPeriod(1) is called 1000 times / second - and to
me it seems that can't have less overhead than just calling it once in
allegro_init(). All just guessing though.

> if we find its slow on a 300mhz machine, yet is fast on a 3ghz machine.. 
>   do we go with it or not?   personally im <rant> sick of pandering to 
> almost obsolete archetectures</rant> and  propose that if it doesn't get 
> included because of slower archectures, that it gets included inside a 
> some type of  #ifdef INCLUDE_PERFORMANCE_CODE
> 

True, we can always make it a configure option - but let's just see if
we can do some testing first.

-- 
Elias Pschernig





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/