Author Topic: OpenGL - the timing/vsync problem.  (Read 4836 times)

0 Members and 1 Guest are viewing this topic.

Offline Knurz

  • Atari ST
  • ***
  • Posts: 121
  • Karma: 25
    • View Profile
    • GitHub Repository
OpenGL - the timing/vsync problem.
« on: December 31, 2011 »
Hi!

I'm new to OpenGL and to intro coding and I tried to do a simple scroll effect... which drives me a little crazy :P

To set the vsync setting in the GL I'm using:
Code: [Select]
wglSwapIntervalEXT = wglGetProcAddress("wglSwapIntervalEXT");

if (wglSwapIntervalEXT)
wglSwapIntervalEXT(1);

But this is useless if someone has forced his vsync setting to off using his driver. My next thought was to calculate the framerate by myself ( where I found this forum with google... ) and I followed some threads where the guys are talking about a delta-timer which guarantees a solid FPS. So my next thought was about taking a highprecision timer, store the last taken time in a var and sub/compare it with a time taken right now:

Code: [Select]
GetSystemTimeAsFileTime (&ftCurrent);
liconvert.LowPart = ftCurrent.dwLowDateTime;
liconvert.HighPart = ftCurrent.dwHighDateTime;
liCurrent = (double)liconvert.QuadPart/10000;
if (liCurrent - li_oldTime > 16) {
                                        ..... do stuff .....
glClearColor(0.1568f,0.2705f,0.71764f,1.0f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); // Clear Screen And Depth Buffer
glLoadIdentity();
DrawGLScene();
glFlush();
SwapBuffers(hDC);
glFinish();
li_oldTime = liCurrent;

The situation right now is that the scrolltext flickers .... a little less if vsync is on, a little more if vsync is off. I've tried comparing the "100-nanosecond intervals" from GettSystemTimeAsFileTime but it still flickers.

It seems that my problem is that the program renders sometimes more, sometimes less frames than the Adapter is displaying. Is there any way how I can fix that ? I've checked the dependencies of several intros to see if they are based on OpenGL too, and played around with vsync settings and I never noticed a flicker on effects. So..what am I doing wrong ?

Thanks for your help :).

Bye

PS.: I've attached the executable, so you can see my problem. If you are unsure to run it, it's packed with UPX, so just unpack it and you can inspect/check it for safety.
Remember what the dormouse said: Feed your head

Offline Raizor

  • Founder Member
  • Pentium
  • ********
  • Posts: 1154
  • Karma: 175
    • View Profile
Re: OpenGL - the timing/vsync problem.
« Reply #1 on: December 31, 2011 »
Hi Knurz. I've run it here and it doesn't flicker. I get some slight jerkiness when vsync is forced on, not so much when it's forced off. I'm on Win7 x64 using a GTX850 for reference.

The way you're doing delta timing is slightly different to how I do it in GL for scrollers. Looks like you're checking that 16 milliseconds has elapsed before doing an update. You might want to try drawing no matter how much time has elapsed, and only update your scroll positions every 16 ms. So it redraws as often as possible but doesn't move the objects until 16 ms has passed since it last moved them. That may give you better results.

Personally, I do constant updates and use the current time to calculate the offset for the scroller (or whatever I'm moving). You might want to try that method too. If you check the code for Here comes the Sun in the competitions forum, that does exactly that for the scroller so may be a useful reference.
raizor

Challenge Trophies Won:

Offline Shockwave

  • good/evil
  • Founder Member
  • DBF Aficionado
  • ********
  • Posts: 17409
  • Karma: 498
  • evil/good
    • View Profile
    • My Homepage
Re: OpenGL - the timing/vsync problem.
« Reply #2 on: December 31, 2011 »
Same as Raizor here, no flickering at all only a very slightly jerky movement every few moments (I wouldn't even notice if I wasn't looking for it since I have a shitty monitor).

I used to take the same kind of approach as you are doing, but these days I use the same method as Raizor, ie let the updates take care of themselves, sleep for a millisecond or two at the end of the loop before I swap the buffers, take a timer reading and calculate the delta for the next frame.
Shockwave ^ Codigos
Challenge Trophies Won:

Offline Knurz

  • Atari ST
  • ***
  • Posts: 121
  • Karma: 25
    • View Profile
    • GitHub Repository
Re: OpenGL - the timing/vsync problem.
« Reply #3 on: January 02, 2012 »
Hi!

Thanks for your time and thanks for testing!

I used to take the same kind of approach as you are doing, but these days I use the same method as Raizor, ie let the updates take care of themselves, sleep for a millisecond or two at the end of the loop before I swap the buffers, take a timer reading and calculate the delta for the next frame.

This is what I finally did to achieve a smooth timing.

Thanks again!

Bye.
Remember what the dormouse said: Feed your head

Offline Shockwave

  • good/evil
  • Founder Member
  • DBF Aficionado
  • ********
  • Posts: 17409
  • Karma: 498
  • evil/good
    • View Profile
    • My Homepage
Re: OpenGL - the timing/vsync problem.
« Reply #4 on: January 02, 2012 »
Excellent, glad that's sorted for you.
Shockwave ^ Codigos
Challenge Trophies Won: