Jump to content
  • Advertisement
Sign in to follow this  

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.

If you intended to correct an error in the post then please contact us.

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(){



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 this post

Link to post
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 this post

Link to post
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"


Is that about right?


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 this post

Link to post
Share on other sites

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






    // 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 )



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.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!