>> Hi Physics blokes,
>> I am currently messing about with some rigid body stuff referenced
>> from Ruud's code (Richard Chaney), problem is that what I have been
>> doing so far is getting the timestep from the difference between the
>> last update and the current one. This seems to suggest that it is
>> better to have a constant timestep. How can I time this accurately so
>> that the physics is only updated after x millisecs? Also, how do i
>> make sure that there is useful work being done when it isnt time for
>> the physics to be updated.
> Here's roughly the way I've implemented a constant timestep simulation:
> timeStep = 0.002; // Or whatever you wish to use
> t = getTime();
> do
> {
> while (t < getTime())
> {
> updatePhysics(timeStep);
> t += timeStep;
> }
> drawFrame();
> } while (!done);
> In other words, run the simulation with a constant timestep until it
> catches up with real time, then draw your graphics, and repeat.
> This way, you get a constant timestep, the simulation will be in sync
> with real time when it's time to draw the frame, and you're always
> either updating the physics or drawing the graphics (and whatever else
> you add into the main loop). The only problem is if your physics
> calculations are too slow to be done in realtime, it'll get stuck into
> the physics loop, trying in vain to catch up to real time. But that's a
> problem with any fixed timestep simulation. Just check if the code
> stays too long inside the physics loop (like half a second), and handle
> that as you wish (like switch to a larger timestep, or throw an
> exception that tells the user it's time for a CPU upgrade ;-) ).
>> How should it be timed - the QueryperformanceCounter functions?
> Definitely!
> Petri Blomqvist
I would argue for varying step updates, meaning that physics
should be calculated as functional
F(t0, t1): {car1, ... carN, input1, ..., inputN } -> { car1~, ... carN~}
Here's why:
- it will make your physics more efficient, because otherwise
you might have had to call fixed step increment several times.
- more important this approach will give your calculation time
that is not proportional to the duration of the time passed.
This will protect you against hopelessly lagging behind whatever
computer (or rather Windows) did at the moment.
- this does not complicate the code, because in any case you
need to have your algorithms working using dt=t1-t0.
- in the network code you will need to be able to have this
functional to be able to recalculate cars position basing on
the received input from remote computer. In regular physics updates
you recalculate using input prediction algorithm instead of missing
part of the input, when you get input for the particular car,
you recalculate car position from the using that functional from
the last known state. This will prevent cheating as the server
will be responsible for physics handling.
If you're thinking about threads, from my experience threads
on Windows (especially Win9x) are not scheduled very good when
you have intensive processing going on. Though threads for
polling should be fine (polling controller input and posting it
for the main thread, same for polling for network events).
Alex.
