Re: Time problem

[Josef Spillner <dr_maux@users.sourceforge.net>]

Boa-tarde!

On Saturday 14 June 2003 11:10, you wrote:
> I know the problem I will expose is classical, but I´m a newbie in these
> things. I´m coding a computer graphics work wich have a OpenGL doll made of
> spirals. This doll must do many movements. My problem is making this doll
> to be animated independent of machine clock. I mean, the animation must
> play at same speed in any machine.

There are two constraints involved here:
1. CPU speed
This is a hard constraint, and a very obvious one: If the CPU is too slow to 
calculate (and deliver) enough frames per second to meet your favorite speed, 
it won't work.
(For OpenGL, the same applies to the graphics board.)

2. Scheduling
I'm not sure about the other OS you mentioned, but at least Linux (the vanilla 
thingie from kernel.org) cannot guarantee any real-time performance, not even 
responsiveness.
So you'll either live with the fact that in case of disk activity or sudden 
process fubar, your animation will become terribly slow, or you take a look 
at realtime capable operating systems (and I've seen plenty of them doing 
fancy graphics already).

Theory aside, since you don't know the duration of the frame calculations in 
advance, you cannot use a simple sleep()-like algorithm, but rather one which 
takes the current time _before_ the frame calculation starts, and sleeps 
until, say, 40 milliseconds from then on (which results in 25 fps).

pseudocode:
void sleep_to(stamp){do{x = currenttime();}while(x < stamp);}
cur = currenttime();
calc_frame();
sleep_to(cur+40);

(Yes, you could sleep() for 40 minus the time used up by calc_frame(), but 
this wouldn't allow you to do other things in the meantime, at least in a 
single thread.)

The exact code depends on the functions which are available on all the OSes 
you want to consider; also keep in mind that timing with milliseconds can be 
inaccurate (there was a thread on this list about it already).

Josef