rec.autos.simulators

Although this project of mine is now finished, I am still tinkering around
with it

I hear a lot of mention about changing the physics frequency to 5 hz or 1 hz
or whatever

What exactly does this mean? In my sim, the time step is calculated as the
time difference between program cycles, not given as a constant time.

It performs the physics using the calculated timestep, draws the screen,
calculates a new time step, does the physics, draws the screen.... etc.

So how is a fixed timestep implementable without making the game run in slow
mo as it would if I put the timestep to 1 hz (effectively making it run at a
1000th of a second each frame

Alex Smith

Now THAT would be slow! :-)

Quite simply, it means how many times per second (1 Hz = once per second)
you update the physics. For arcade physics, a few dozen Hz might do, but for
a real physics simulation it needs to be in the hundreds to maintain stable
(= cars not launching to Jupiter & beyond) and accurate simulation. With
special integration techniques like implicit integration (which I haven't
tried) it's possible to use less. In my sim, I use 250 Hz.

The way you're doing it, your physics are dependent on your graphics refresh
rate - if you get 100 fps, your physics are also updated at 100 Hz which
might be enough - but if your graphics slow down due to a lot of alpha
blending or other stuff, your physics calculations will slow down also,
which could lead to stability problems. In my view, it's best to keep
graphics and physics updates separate, especially if you intend to implement
some sort of replay mode.

You shouldn't have much trouble modifying your existing code to do the
following:
Loop physics calculations with a fixed timestep until it catches up with
realtime, draw the screen, loop physics again, draw the screen...

Petri Blomqvist

This is ripped out of the Quake 2 source code as an example, this is done in
WinMain.

oldtime = Sys_Milliseconds ();
while (1)
{
    do
    {
        newtime = Sys_Milliseconds ();
        time = newtime - oldtime;
    } while (time < 1);

    Qcommon_Frame (time);

    oldtime = newtime;

Hope that helps,

Nick.

In other words, do the physics simulation twice then update the
screen, then repeat... is this how everyone else is doing it? or am I
missing something?

...

 Yep, but I do it a lot more than twice per graphics frame usually.  

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm

so is this a solution???

// Physics frequency in ms
fixedTimeStep = 0.002;

// Counter for how much time has passed in the physics world
 physicsTimeElapsed = 0.0;

// Actual system time elapsed between frames
realTimeElapsed = thisFrameTime - lastFrameTime (from system clock)

// While the physics is not in sync with system time
while (physicsTimeElapsed < realTimeElapsed
{
    do_physics
    physicsTimeElapsed+=fixedTimeStep

This is just off the top of my head, so I might have the wrong end of the
physics stick :)

Though sometimes I run at 250Hz and the framerate at certain simple
tracks is catching up with the physics! I think it draws the same
frame twice in that case, hm. Wow. :)

I'll move to 500Hz/1000Hz anyway. Gotta keep ahead of those gfx
boards! ;-)

Ruud van Gaal
Free car sim: http://www.racer.nl/
Pencil art  : http://www.marketgraph.nl/gallery/

Thanks for the input guys!