# Movement stability using time

This topic is 1769 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Ok, I know that each machine runs at different speeds and will even process the exact same computations within the same machine within different amounts of time. This presents a problem if I want to have smooth (and consistent) movement. Here is how I have been doing it:

void Camera::UpdateTBF(){
newTime=clock();
fTBF=double(newTime-oldTime);

oldTime=newTime;
tbfFactor=fTBF/1000.0;

}



fTBF and tbfFactor are both doubles. newTime and oldTime are longs.

Whenever movement occurs, the amount of movement is multiplied by tbfFactor.

I thought this would work great, but every so often I see "jumps" in movement. So I arbitrarily set tbfFactor to 0.015 (that's about the average for my machine) and I get smooth, consistent movement all the time. What's the deal? I MUST be doing it wrong.....

##### Share on other sites

I've just take that from my project (uses Bullet Physics integration method)

int substeps = 0;
localTime += frameTime; //member variable

if(localTime >= dt) {
subSteps = int(localTime / dt);
localTime -= subSteps * dt;
}

if(substeps) {
subSteps = max(subSteps, maxSubSteps);

for(int i = 0; i < subSteps; ++i) {
world.update(dt); //fixed frame time
}
}

Edited by irlanrobson

##### Share on other sites

Also, L.Spiro's Fixed Timestep Implementation

This is something I should have STARTED my project with..... It may be too difficult to implement without starting fresh. Here is what I get from the article:

-Update the render each frame

-All movement is 33.3ms behind what is actually rendered

-Only do ACTUAL movement every 33.3ms

-For every frame between the 33.3, interpolate the matrix of EACH object rendered from an "old state" to a "new state"

If so, I may have a problem (maybe). I have certain instances where the player's ship is moving at 'relativistic' speeds and therefore from one frame to the next, objects could be moving (relative to the player) at millions of meters per frame. If the update happens every 33.3ms, then the actual distance traveled can be up to 33.3 times what it would be each frame. I could pass right through a planet without a scratch and the physics wouldn't know the difference....... There are ways around this problem, but that pulls me deeper down the rabbit hole.

##### Share on other sites

Another approach is to not use deltas, but instead decouple the logic update speed from the rendering speed.

https://github.com/TheComet93/game-of-life/blob/master/game-of-life/LoopTimer.cpp

https://github.com/TheComet93/game-of-life/blob/master/game-of-life/LoopTimer.hpp

Usage:

    // set up loop timer
LoopTimer loopTimer;
loopTimer.setFPS( 60 );

// run the program as long as the window is open
while( m_Window.isOpen() )
{
int maxUpdateLoops = 0;
while( loopTimer.isTimeToUpdate() )
{

// GAME LOGIC HERE

// limit amount of update loops allowed
// You can remove this f you are 100% certain that logic updates will always be faster than 1/fps.
if( ++maxUpdateLoops == 10 )
break;
}

// RENDER EVERYTHING HERE

}

The game logic update will be guaranteed to occur 60 times a second. The rendering speed will be uncapped, I suggest you enable vertical sync.

1. 1
2. 2
Rutin
18
3. 3
4. 4
5. 5

• 9
• 9
• 9
• 14
• 12
• ### Forum Statistics

• Total Topics
633300
• Total Posts
3011266
• ### Who's Online (See full list)

There are no registered users currently online

×