Re: Time problem

[Gregor Mückl <GregorMueckl@gmx.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I don't really like this solution. It's kludgy. If you know the movements of 
the doll in advance (which is ususally the case) then you can do the 
following:

- - Rewrite the math describing the doll animation as a function of time. If you 
have discreet key frames then you should use an interpolation mechanism in 
between (linear interpolation being the simplest).

- - Rewrite your animation code so that it can recalculate the the current pose 
of the doll as a function of the two keyframes involved and the percentage of 
the the transition that's already past.

- - In your main loop you do roughly the following:

percentage=(current_time()-start_time)/(end_time-start_time)
interpolate(start_key, end_key, percentage);

where interpolate() is the function you wrote in the last step. percentage is 
a floating point value that changes gradually from 0 to 1.

This method may seem tedious but has its benefits:

- - smooth animations
- - no artificial slow-down in your main loop neccessary
- - works even when rendering is much slower than expected

Regards,
Gregor

Am Samstag, 14. Juni 2003 13:12 schrieben Sie:
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+6wxwTN1O8kLyTwsRAvahAKCT42vF8BhfEKxL7vHim4RU6w/zcACggzP3
I7T+0/UB4PgNkEMYZoNX6mk=
=NCsH
-----END PGP SIGNATURE-----