CODEWITHSUNDEEP
copengl
gobien
gobien

Reputation: 537

Flowing animation with timing (OpenGL)

i'm programming a little game with opengl and C. I've encountered an issue: due to clipping... my animation (actually based on glutTimerFunc) haven't a constant fps. A variable fps isn't a problem, but the animation is affected, so it don't correspond to the timing, then: fps1,pos1; fps2,pos2; fps3,pos3... But if the fps isn't regular, so animation doesn't. I would implement it like: fps1,pos1;(if fps1 isn't drawed) fps2,pos1; (fps1 drawing ended, so now, because i skipped a frame) fps3,pos3.

how can i do it? i would use the clock() function, but it gives always 0

ps: howto force v-sync in opengl?

Upvotes: 2

Views: 1502

Answers (1)

Tommy
Tommy

Reputation: 100632

Whether OpenGL updates are synchronised with the vertical retrace will be communicated in an platform-specific manner since it's related to however your platform has tied OpenGL into itself. So it's a tick box in the interface designer on the Mac, there's a WGL extension called WGL_EXT_swap_control over on Windows and a GLX extension in X11.

Assuming you have some means of installing a callback that is triggered upon vertical retrace (such as via a CVDisplayLink on the Mac; sadly I'm not up on the Windows/Linux equivalents), and you want your physics to run at a constant number of steps per second, you could write something like:

void myRetraceFunction()
{
    static unsigned int timeError = 0;
    static unsigned int timeOfLastFrame = 0;

    unsigned int timeNow = getTimeNow(); // assume this returns in ms

    // Get time since last frame.
    // Since we ignore overflow here, we don't care that the result of
    // getTimeNow presumably overflows.
    unsigned int timeSinceLastFrame = timeNow - timeOfLastFrame;

    // Store this so that we get correct results next time around.
    timeOfLastFrame = timeNow;

    // Establish the number of times to update physics per second, as the
    // name says. So supposing it has been 0.5 of a second since we last
    // drew, we'd want to perform 0.5*200 physics updates
    const unsigned int numberOfTimesToUpdatePhysicsPerSecond = 200;

    // calculate updates as (updatesPerSecond * timeSinceLastFrame / 1000),
    // because we're assuming time is in milliseconds and there are 1000
    // of them in a second. What we'll do though is preserve any amount we'd
    // lose by dividing here, so that errors balance themselves.
    //
    // We assume that timeSinceLastFrame will be small enough that we won't
    // overflow here.
    unsigned int timeSinceLastFrameNumerator =
          timeSinceLastFrame * numberOfTimesToUpdatePhysicsPerSecond
          + timeError;

    // calculate how much of the numerator we're going to lose to
    // truncation, so that we add it next frame and don't lose time
    timeError = timeSinceLastFrameNumerator % 1000;

    // calculate how many physics updates to perform
    unsigned int physicsUpdatesToPerform = timeSinceLastFrameNumerator / 1000;

    // do the physics work...
    while(physicsUpdatesToPerform--)
       updatePhysics();

    // ... and draw a frame
    drawFrame();
}

That timeError stuff is to regulate against rounding problems. E.g. suppose you were running at a constant 70 frames a second and wanted physics updates 60 times a second. If you ignored the error that accumulates then you'd actually run zero physics updates a second since at each instant the code would come to the conclusion that the amount of time since the last frame draw wasn't long enough for a physics update to have been required. And you'd also otherwise get aliasing problems if you went the other way, with any frame rate that isn't an integer divisor of the physics update rate.

If you don't have an explicit retrace function but instead a perpetual loop that pushes out frames but blocks on vertical retrace then you'd write the same sort of thing.

If you have no way to block on vertical retrace at all, you might install a timer at a target frame rate and pretend that's a vertical retrace sync. You could just push frames out as fast as possible but you'll likely get complaints with anyone with a laptop or other machine where it's pretty obvious when the fans are coming on.

Upvotes: 1

Related Questions