Procedurally generating terrain in dead time before buffer swap

Question

I'm using OpenGL/C++ in Windows, and my main loop looks like this: GLboolean done = GL_FALSE; auto_ptr l_world(new World); l_world->Init();

while (!done) {
    if (PeekMessage(&msg,NULL,0,0,PM_REMOVE)) {
        if (msg.message==WM_QUIT) {
            done = GL_TRUE;
        } else {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    } else {
        if (!world->Iteration() || keys[VK_ESCAPE]) {
            done = GL_TRUE;
        } else {
            LocalContext.SwapBuff();
        }
    }  
}

where Iteration() is:

GLboolean World::Iteration() {
    DrawAll();
    MoveAll();
    CheckForCollisions();

    return GL_TRUE;
}

I've implemented the diamond-square algorithm to procedurally generate terrain, which I'm currently doing in World::Init(). Vertices, indices and textures are stored in buffers to be drawn every frame.

That's fine for a small area, but I want to make it much bigger if possible. To do that I'd like to generate on-the-fly as the camera moves, which would be done at the end of the iteration, after the drawing, moving and collision detection but before the buffer swap. It could be split over several frames, but I'd like to get as much done in a single frame as possible.

As I understand it, with vsync enabled SwapBuffers will block until the end of frame, so any time between the SwapBuffers call and the end of frame will be wasted. So that's my question: is there a way to tell how much time remains until the end of the frame, so I can keep generating terrain until the last possible instant but still maintain a consistent frame rate?

I've not found anything too helpful on the OpenGL Synchronisation page. I wondered if Triple Buffering might be the answer - if the other back buffer contains a completed frame, keep generating; if it's empty then SwapBuffers. It's not a great solution as it would make triple buffering mandatory, and how would you detect if one of the back buffers was free? Any better suggestions?

Answer 1

There is no such mechanism in OpenGL, unfortunately. On the other hand, with the multitasking systems we use, there's hardly any way to know what's going on anyway - it might be that your virus scanner just decides to start downloading updates at some point, and that messes up your timing and there's nothing you can do about it.. =)

It wasn't long ago when you couldn't even depend on the refresh rate on PCs. Currently the standard seems to be 60Hz, but even that may be changing with the 110Hz, 120Hz and 144Hz displays out there today.

So it's best to separate game logic from rendering (so rendering framerate may change while the game logic / physics will run at a stable rate), and do any terrain generation / preloading stuff on a separate thread.

If you're working on a platform where you have absolute control (or close to it), such as a game console, the situation is different.