[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: linuxgames@sunsite.dk*Subject*: Re: Of time scaling and FPS*From*: Gregor Mueckl <GregorMueckl@gmx.de>*Date*: Sat, 11 May 2002 18:30:26 +0200*Delivered-To*: archiver@seul.org*Delivered-To*: mailing list linuxgames@sunsite.dk*Delivery-Date*: Sat, 11 May 2002 13:30:25 -0400*Mailing-List*: contact linuxgames-help@sunsite.dk; run by ezmlm*References*: <20020428125612.990A71036@gate.home.lan> <3CD9FA87.C021E6EC@gbl.com.br> <3CDC4D43.64A0EBB9@airmail.net>*Reply-To*: linuxgames@sunsite.dk*User-Agent*: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221

Steve Baker wrote: > "Miguel A. Osorio" wrote: > >>Hey people, >> >> I have some matters about time scaling and a little FPS problem I'm >>having on my project to discuss. About time scaling, just to make sure, >>the correct way to calculate one frame time could be: >> >>// Main loop - no time scaling >>while(true) >>{ >> get_input() >> update_states_and_variables() >> render() >>} >> >> The calculation I'm talking about would be something like: >> >>// Main loop >>while(true) >>{ >> tf = gettime() >> delta = tf - ti >> ti = gettime() >> >> get_input() >> update_states_and_variables() // Use delta here on time dependent >>variables >> render() >>} >> >> Is this one right way to do it? >> > > That's one way...so all of your equations for motion say things like: > > position += speed * delta ; > (a lot of text cut out here) > However, for some genre's of game, this is the way to go because as the > programmer, you have better control. For example, if you have a character > that jumps - then with the first approach, the *exact* maximum height > he'll reach will depend to some slight degree on the update rate of your > graphics...not by much - but enough that if you've *carefully* designed the > scene so that he has to jump *just* right to land on some platform - then > on some computers the jump will be easy and others it'll be impossible. > Without a boatload of testing and annoying tweaking of initial accellerations > and stuff, it'll be a pain. > You could heavily decrease that error with a little mathematical sophistication. The point is that you are numerically integrating a differential equation (although it's a simple one). That does give you errors in any case. But the error you get heavily depends on the method you chose to integrate. The method you presented above is the Euler-Couchy method which is easy to understand and actually very poor. It may not even be the fastest out there, but that's just my guess right now. One of the more sophisticated methods to do the job is Runge-Kutta. It's still rather simple and comes in several dozens of variants which vary a little bit in their calculation effort and precision. Best thing would be that you get a good book on numerical mathematics before you try that. One that's currently in my bookshelf is William H. Press et al., "Numerical Recipies in C", but one thing I don't like about it is that the code examples are very obfuscated in fact. You can also have a look at their website: http://www.nr.com Basically Runge-Kutta may look as being more expensive, but you can savely play some tricks on them like adaptive step size without having to loose precision (in fact adaptive step size is used to *gain* precission, but to small a stepsize will kill too much performance). And besides, if you integrate using a different step size than you have in your rendering loop you will need an additional interpolation step, though. In terms of efficiency that's comparable to Euler-Cauchy. So it all boils down to trading speed for precision. But that's not to far off reality in game programming. Just have a glance at what ODE does, and simulations like that run in realtime even in games. I'm mentioning that example only because it shows that the calculation time can be there if it is done right. > My TuxKart game works the first way - and on slow machines, I get bad > problems with collision detection and the way one object richochets > off another - Karts keep driving through walls and stuff like that. > It's a real pain to fix it. I wish I'd implemented it the second way. > It's very tricky to get right indeed. The point is that you *never* (even with fixed step sizes) get the exact moment in time when the the objects start to touch each other. Normally you'll first get a hint of the collision when the objects already interpenetrated each other. And that's where the trouble starts because you have to correct that in your simulation. You might even totally miss collisions (like it seems to happen with the karts that go through walls). That happens with a step size that's far too big meaning that you will get positions of your objects before and after the collisision at times they are totally seperated from one another. So the simulation has no hint that the collision has taken place. The normal way to handle that is to limit the step size to do the integration with (yes, we're still talking about the same thing as above) to a value that guarantees that you won't miss any collisions. That value of course depends on the speed your objects are traveling with and their size (you even might determine that value dynamically to avoid wasting time with making small steps when they aren't needed). > There is a third way - pick an update rate that all reasonable computers > can manage - and slow all faster machines to that rate. Anything that > can't make your minimal performance is declared "too slow to run this > program". Now you don't need any time code at all - everything can > just be hard coded. My original TuxAQFH game works that way - and it's > great! You don't get 200Hz frame rate on a GeForce-4 ti 4600 - in fact > you get the exact same speed as you get on a Voodoo-2 - but it's plenty > fast enough to be playable - and it's a lot easier to write - so why would > you care? In fact, you could even adjust the amount of detail you render > to keep the frame rate around your nominal rate so that you'd get nicer > graphics on a fancy modern card. > Seen from a mathematical point of view this one is very similar to the second method you proposed. The only thing here is that you also couple rendering with your simulation. One pitfall here is that the simulation might become inacurate if you are choosing to large a step size (steps of 10ms+ are large steps). Gregor PS: Before you tear me apart: I know that I'm not that wrong except for the parts in which I mention things about calculation costs. So, if you feel like attacking anything, try that first :) [hm... maybe I shouldn't provoke you like I managed to do the last time on that dl* stuff - sorry for that!] -- ***************************************************** * Gregor Mueckl GregorMueckl@gmx.de * * * * The ChallengeOS project: * * http://challengeos.sourceforge.net * ***************************************************** * Math problems? * * Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x]. * *****************************************************

**Follow-Ups**:**Re: Of time scaling and FPS***From:*Steve Baker <sjbaker1@airmail.net>

**References**:**Of time scaling and FPS***From:*"Miguel A. Osorio" <maos@gbl.com.br>

**Re: Of time scaling and FPS***From:*Steve Baker <sjbaker1@airmail.net>

- Prev by Date:
**Re: Video Card** - Next by Date:
**Re: Of time scaling and FPS** - Prev by thread:
**Re: Of time scaling and FPS** - Next by thread:
**Re: Of time scaling and FPS** - Index(es):