Hello Guest

Display.sync() methods

  • 11 Replies
  • 19841 Views
*

Offline Qudus

  • ***
  • 123
Display.sync() methods
« on: January 12, 2008, 17:38:30 »
I have some questions about the Display.sync() methods. The sync() method causes the rendering to judder. I have called the method with 128 as the parameter and the resulting FPS is 128 indeed. But animations are juddering, if they are computed from the current game-time, which makes it quite unusable. The sync2() method causes the same juddering and doesn't even result i the correct FPS, but in something lower. The sync3() method doesn't cause any juddering, but doesn't limit the FPS at all.

Is this a known problem? Could it get fixed? I tried to implement my own FPS limitation code without any better success than the Display.sync*() methods. I guess, you have also realized, that the sleep() method cannot be used, since it causes this juddering. Unfortunately using a loop with only the yield() method in it doesn't prevent the CPU from being comsumed 100%. This this topic still a current one? Is anyone working on this?

Thanks.

Marvin

*

Offline bobjob

  • ****
  • 394
  • LWJGL: WOW SO GOOD
Re: Display.sync() methods
« Reply #1 on: January 12, 2008, 18:14:39 »
a reasonable sync time is 60. so your app is going twice as slow as most visual apps.

also if you notice that bars accross the screen dont seem to be in sync, you may want to try enable vsync.

*

Offline Qudus

  • ***
  • 123
Re: Display.sync() methods
« Reply #2 on: January 12, 2008, 18:52:40 »
Thanks for the reply.

also if you notice that bars accross the screen dont seem to be in sync...

What bars?

...you may want to try enable vsync.

I know, that vsync provides a very reliable, stable and smooth FPS limitation as a side-product. But can't this behavior be achieved by a software limitation?

Marvin

*

Offline bobjob

  • ****
  • 394
  • LWJGL: WOW SO GOOD
Re: Display.sync() methods
« Reply #3 on: January 12, 2008, 19:41:24 »
as well as making the fps smooth, what vsync also does is make a verticle sync, so that the whole screen or opengl context window will be in sync. run ur app on high resolution without any sync (to make the bars more noticable) and you should be able to notice that there seems to be delayed bars on the screen when you move around. thats what vsync is good for, but im not sure if all cards support vsyc, therefore its good to initialize vsync at startup, and put a .sync(60) in the main loop just in case.

*

Offline bobjob

  • ****
  • 394
  • LWJGL: WOW SO GOOD
Re: Display.sync() methods
« Reply #4 on: January 12, 2008, 19:48:44 »
oh SNAP!
you said 120 thats means it should be running twice as fast. lol, sry

*

Offline bobjob

  • ****
  • 394
  • LWJGL: WOW SO GOOD
Re: Display.sync() methods
« Reply #5 on: January 12, 2008, 19:51:25 »
something to note abbout chuggy graphics, if your using a radeon, dont use display lists, for some reason there is a memory leek on some cards(i used to think it was a problem with garbage collection but i was wrong), vbo's work just fine though.

*

Offline Qudus

  • ***
  • 123
Re: Display.sync() methods
« Reply #6 on: January 12, 2008, 19:54:30 »
Yes, I know these bars. Well, I would't have called them bars ;). Of course running a game with vsync enabled is best. I just wondered, why it doesn't seem to be possible to limit FPS from software side.

128 was just an example value. You can see the odd behavior at any limiting value. Just create a small scene, where a shape is constantly rotated over the screen. If you use a sleep() with any value in the main loop to prevent the CPU from being used at 100% you will notice the shape juddering. That's what I am talking about.

Of course this can be avoided using vsync. But that's not my point.

Marvin

*

Offline Qudus

  • ***
  • 123
Re: Display.sync() methods
« Reply #7 on: January 12, 2008, 19:55:33 »
something to note abbout chuggy graphics, if your using a radeon, dont use display lists, for some reason there is a memory leek on some cards(i used to think it was a problem with garbage collection but i was wrong), vbo's work just fine though.

I'm using an NVIDIA card. And no DisplayLists currently.

*

Offline bobjob

  • ****
  • 394
  • LWJGL: WOW SO GOOD
Re: Display.sync() methods
« Reply #8 on: January 12, 2008, 19:59:59 »
lol, cool i think i get what ur asking now  ::)

*

Offline oNyx

  • ***
  • 177
  • 弾幕
Re: Display.sync() methods
« Reply #9 on: January 12, 2008, 23:37:20 »
[...]
128 was just an example value. You can see the odd behavior at any limiting value. Just create a small scene, where a shape is constantly rotated over the screen. If you use a sleep() with any value in the main loop to prevent the CPU from being used at 100% you will notice the shape juddering. That's what I am talking about.
[...]

That's tearing. You get that if vsync is disabled.

*

Offline Qudus

  • ***
  • 123
Re: Display.sync() methods
« Reply #10 on: January 12, 2008, 23:45:49 »
That's tearing. You get that if vsync is disabled.

If vsync is disabled and no software limitation is used, the CPU will be used at 100%, which should be avoided, to have time for other calculations, that might run in another thread. And maybe there are other reasons.

Say, your computer is quite weak and therefore you want to limit the FPS to 30, since your game might run smooth at this level. Then you cannot use vsync to limit to that FPS. You can only limit to the vertical refresh rate, that your display system is running at. This might be 60 for most TFT displays (or 75 for some) or even 100 or 120 or more for CRT systems.

Got my point?

Marvin

*

Offline oNyx

  • ***
  • 177
  • 弾幕
Re: Display.sync() methods
« Reply #11 on: January 13, 2008, 00:12:07 »
You either use vsync or it won't be smooth. Disabled vsync is for benchmarking purposes only.

>Then you cannot use vsync to limit to that FPS.

You can if hz is a multiple of the desired frame rate and if an Nvidia card is used. Eg if the desired frame rate is 30 and hz is 120, you can use swapinterval 4.

Alternatively you can show each frame several times or use a frame capping method, which yields similar results (the intervals aren't as strict, but it's more flexible).

>Got my point?

There is no point for me to get. I know all the ins n outs of that topic.