Hello, is there a "good way" to update physics in the game loop ? I've heard about framerate dependent/independent methods, and honestly i'm a little lost. For example :

//Main 

    DWORD time1, time2;
    float deltaTime;
    time1 = g_timer->getTickCount();

    while(message.message != WM_QUIT )
    {
	time2 = g_timer->getTickCount();


	gameLoop((float)(time2 - time1) / 1000);
			
        time1 = time2;
     }

In gameLoop I call updatePhysics(elapsedTime) every time. Of course elapsedTime = (float)(time2 - time1) / 1000 In updatePhysics a rotation look like that :

//rotate tt 25 radians

tt->setPitch(tt->getPitch() - 25.0f * elapsedTime);

For every physic calculation I'll use elapsedTime. Is it the good way to go ? Thanks, I must know before writing too much code in a wrong way.

Why is this in "Graphics Programming and Theory"?

Look under in "Game Programming" (http://www.gamedev.net/community/forums/forum.asp?forum_id=11)

You will find this question is asked quite often.

Here's my opinion.

Basically, if you want to avoid problems, you want physics to be updated at a roughly constant rate - say every 30ms. If you physics runs too fast (elapsedTime too small), you might run into numerical problems; some numbers being too small to be added or to be use as denominators. On the other hand, if physics runs too slow, then you will have consistency issues, such has objects going through walls, or imprecise collisions.

There are more elegant designs, but as a simple solution:

If elapsed time is too small, keep adding it up and continue with your game loop (rendering, networking, etc). Update physics when the accumulated time stamp is big enough. If its too large, you want to run the physics several times in that single loop. Think of physics as a space-time window with a determined timestamp, and let the rendering framerate vary instead.

By the way, 99.9% of your code, if well written, should be completely independant from this. Whatever you choose, its best not to start spreading "elapsed time" everywhere :)

Quote:Original post by Steadtler
Basically, if you want to avoid problems, you want physics to be updated at a roughly constant rate - say every 30ms. If you physics runs too fast (elapsedTime too small), you might run into numerical problems; some numbers being too small to be added or to be use as denominators. On the other hand, if physics runs too slow, then you will have consistency issues, such has objects going through walls, or imprecise collisions.

Not necessarily true (about long elapsedTime) if your collision detection algorithms are testing a ray from the starting position to the ending position.