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

*To*: linuxgames@sunsite.dk*Subject*: Re: Time problem*From*: Gregor Mückl <GregorMueckl@gmx.de>*Date*: Sat, 14 Jun 2003 13:52:14 +0200*Delivered-to*: archiver@seul.org*Delivered-to*: mailing list linuxgames@sunsite.dk*Delivery-date*: Sat, 14 Jun 2003 07:46:29 -0400*In-reply-to*: <200306141310.35549.dr_maux@users.sourceforge.net>*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>*Reply-to*: linuxgames@sunsite.dk*User-agent*: KMail/1.5.2

-----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-----

**Follow-Ups**:**Re: Time problem***From:*Steve Baker <sjbaker1@airmail.net>

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

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

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