Blog

Archive
| All posts |
  • The case of the strange shaking screensaver effects

    published on 4/11/2008 4:59 PM
    I have had a long standing issue with the screensaver that I just couldn't figure out. The problem manifested itself in that the timing was off in the main loop. So all animations where jumpy and uneven. This was very noticeable in the pingpong and asteroids scenes where the ball seemed to jump back and forward by a few pixels. Other scenes like planestate and matrixtrails didn't seem to be affected.

    Seeing as things jumped it had to be two things. Either I was using too much system resources or the deltatime used was off.
    Seeing as the cpu usage was quite high for what it should be I suspected it was the first option. But after checking the delta times I noticed they where off too. Seeing as a game of ping pong just can't consume 80% of the cpu on a dual core machine I started by tweaking the main loop in every way I could think of. Smoothing the delta time, disconnecting the update and render part so they could run independently and so forth but nothing helped.
    Checking the forums wasn't much of a help either since no one seemed to have this problem. Same was with opengl tutorials from nehe and the like. My mainloop was also basically what they used except I used more exact timing.

    Eventually I came to the conclusion that it just couldn't be the mainloop so what could it be? The only way to find out was to remove part of the code. So in the end I removed everything except one thing. Two calls to SwapBuffer. In OpenGl this is the call that shows the next frame. The reason there was two is that I'm on a dual monitor system.

    So to put it simply there are two buffers. One for each monitor. I render to both of them and when I'm done I call 'SwapBuffer' to show the new frame I just rendered.

    So the question remained as to how can they take so much cpu and make everything uneven. Well it turns out that vsync was enabled by default on the computers I have tested and it works by waiting for a vsync for each call to SwapBuffer. It doesn't care that they are on different monitors. This was the cause for all my problems since the first swapbuffer call made him busy wait for a vsync. Then the next swapbuffer call came in and this made the frame time vary between 1/30 & 1/15 of second per frame deepening on what happened on that frame.

    So by forcing vsync off not only did the cpu usage get a lot lower (Down to 10-20%). All animations are a lot smoother. This includes the planestate one even though you though it was good before. Now it's simply amazing to look at and completely mesmerizing.

    Well I hope I don't get any more bugs like this in the future.

    Not that you can see this in a picture but here is one never the less.

Comments

You need to Log in/register to add comments