[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Of time scaling and FPS
Gregor Mueckl wrote:
> > 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.
Yes - but it's still hard to test and debug - you can never be really
*sure* that your character will make that jump no matter the CPU and
> So it all boils down to trading speed for precision.
There is also an element of trading <whatever> for ease of coding and
(most importantly for amateur programmers) the ability to test on just
one PC and be reasonably confident that if it works there, it'll work
> 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.
I don't disagree with you in principle - I just think that as a practical
matter there are big benefits for the method I propose. (And lots of
commercial games work that way)
----------------------------- Steve Baker -------------------------------
Mail : <email@example.com> WorkMail: <firstname.lastname@example.org>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net