Yes, a high-quality physics engine would aim for consistency. However, you can do drag with variable timesteps pretty easily as well, if not exactly correct, then good to second order in dt. Complicated things like orbital motion are difficult, and I can definitely see using a fixed timestep when you need good simulations.
On the other hand, despite having programmed plenty of physics simulations, I've never needed to use it in a game. Of course it depends on the type of game, but I certainly would not jump to a fixed timestep as my first solution. I also find it very annoying when a game prohibits me from running it faster than 20fps, no matter how fast my computer is capable of running it. Just my opinion, though. -Christopher On Fri, Aug 27, 2010 at 12:22 PM, Brian Fisher <br...@hamsterrepublic.com>wrote: > On Fri, Aug 27, 2010 at 9:10 AM, Christopher Night <cosmologi...@gmail.com > > wrote: > >> Sure. But of course, it's extremely easy to do constant-acceleration >> motion as well: >> >> y += vy * dt + 0.5 * g * dt ** 2 >> vy += g * dt >> >> Sure, that explicit integration technique works fine if you can write an > explicit integration function - I've used that same technique even with > fixed time-steps because it's more accurate. But now how about if you have > acceleration and friction for a car driving on a surface - can you write a > single dt based function for that? now how about something that is > accelerating away with a spring on it? or maybe something falling while > accelerating off axis with a spring attached? It very quickly gets beyond > your ability to write such functions if you try and do really interesting > stuff. > > While consistent timesteps on the other hand, make it so the thing is > always consistent and repeatable, even with simple update functions. Don't > you want your game to behave the same regardless of frame rate? If you do, > then fixed timestep simulation loops is a simple elegant widely used > solution. >
