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