[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

*To*: linuxgames@sunsite.dk*Subject*: Re: Time problem*From*: Steve Baker <sjbaker1@airmail.net>*Date*: Sat, 14 Jun 2003 12:44:24 -0500*Delivered-to*: archiver@seul.org*Delivered-to*: mailing list linuxgames@sunsite.dk*Delivery-date*: Sat, 14 Jun 2003 13:43:25 -0400*In-reply-to*: <200306141352.17369.GregorMueckl@gmx.de>*Mailing-list*: contact linuxgames-help@sunsite.dk; run by ezmlm*References*: <20030202143627.71FA3E43A@whouse.4orsi.it> <00d601c33254$da8cad40$0100000a@knight> <200306141310.35549.dr_maux@users.sourceforge.net> <200306141352.17369.GregorMueckl@gmx.de>*Reply-to*: linuxgames@sunsite.dk*User-agent*: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030507

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.

The best approach is to measure the time at the return from 'swapbuffers' using gettimeofday() - it's easiest and quite accurate under Linux. Subtracting the time at the start of the previous frame from the time now gives you the amount of time the previous frame took to calculate - which is a REASONABLE estimate for how long this one will take. Now, you need to know the speed (and perhaps accelleration) for each moving object in each translational and rotational axis (X,Y,Z,H,P,R). Now, multiply the speed (in - say - meters per second or degrees per second) by the time we expect this frame to take to compute - and add that on to the current position to give the new position that your models will be in when you've finished computing and displaying. The simple Newtonian equations of motion normally suffice: s = u * t + 0.5 * a * t * t v = u + a * t Where: t -- the time step s -- the distance moved in time 't' u -- the velocity at start of frame v -- the velocity at the start of the NEXT frame a -- the accelleration throughout the frame This can be computed separately for each of X, Y and Z - and also works for heading, pitch and roll angles so long as you are careful to account for the wrap-around at 360 degrees and you know about the 'gymbal lock' problem assocoated with animating rotations. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK-----

**References**:**Time problem***From:*Igor Cabral Corrêa <imortis@uol.com.br>

**Re: Time problem***From:*Josef Spillner <dr_maux@users.sourceforge.net>

**Re: Time problem***From:*Gregor Mückl <GregorMueckl@gmx.de>

- Prev by Author:
**Re: Time problem** - Previous by thread:
**Re: Time problem** - Index(es):