LWJGL Forum

Programming => Lightweight Java Gaming Library => Topic started by: vitalir on October 29, 2007, 14:09:03

Title: Timing, Vsync, CPU
Post by: vitalir on October 29, 2007, 14:09:03
Hi All!
I am just starting with lwjgl, first of all - great thanks for the library! Clearly java needed one for a long time!

While playing with lwjgl I noted a few things:

- Using Display.sync(60) gives quite smooth and totally satisfying animation quality (thanks! i always thought java=jerky), however Display.sync(30) gives floating speed, i.e. occasional slow-downs, so animation is not smooth. Is that how it should be?
- With Display.setVSyncEnabled(true) the CPU is 100% utilized.. hm.. is vertical synchronisation that intense? no way to imrove? or is it only on my laptop?
- Occasionally, at the top of the screen, I still get an invisible line which breaks my moving polygon (as if vsync is off).

Would be great to hear any opinions. Wanted to add that those issues are minor and overally lwjgl feels great!
Title: Re: Timing, Vsync, CPU
Post by: princec on October 29, 2007, 15:35:11
The 100% CPU is down to a fairly crappy driver implementation that appears to be bugging Windows and Nvidia at the moment. sync(30) should be as smooth as sync(60) though.

If you're getting a break at the top of the screen it must be because vsync is not in fact turned on after all.

Cas :)
Title: Re: Timing, Vsync, CPU
Post by: oNyx on October 29, 2007, 16:10:26
You may see a fixed tear line on some systems in windowed mode. If you move the window around that break will stay in place (relative to the screen). It's a pretty rare glitch (try newer drivers) and there is nothing you can do about it on the software side.

30fps is too slow for most genres anyways. It's ok for 2D RGPs for example, but for everything else you want at least 60fps. And fast paced first person shooters already need about 120fps.
Title: Re: Timing, Vsync, CPU
Post by: vitalir on October 29, 2007, 19:12:55
Quote from: oNyx on October 29, 2007, 16:10:26
You may see a fixed tear line on some systems in windowed mode. If you move the window around that break will stay in place (relative to the screen). It's a pretty rare glitch (try newer drivers) and there is nothing you can do about it on the software side.

Thanks for suggestion - it does stay on the same place relative to the screen! Clearly a driver bug then. BTW its visible in fullscreen as well, and appears about 3 times out of 5 runs.
Title: Re: Timing, Vsync, CPU
Post by: Fool Running on November 04, 2007, 21:46:18
QuoteAnd fast paced first person shooters already need about 120fps.
Most users run at 60hz (even with CRTs) and flat panels don't even update higher then 60hz  :-\
Title: Re: Timing, Vsync, CPU
Post by: Graeme on November 05, 2007, 23:14:06
Quote from: Fool Running on November 04, 2007, 21:46:18
QuoteAnd fast paced first person shooters already need about 120fps.
Most users run at 60hz (even with CRTs) and flat panels don't even update higher then 60hz  :-\

Maybe he is confusing the rate at which game logic is performed with the rate at which the scene is rendered ??
Sometimes games are written to run the logic as often as possible, but they only bother to redraw everything 30-60 times per second.
Title: Re: Timing, Vsync, CPU
Post by: oNyx on November 05, 2007, 23:43:29
Quote from: Graeme on November 05, 2007, 23:14:06
Quote from: Fool Running on November 04, 2007, 21:46:18
QuoteAnd fast paced first person shooters already need about 120fps.
Most users run at 60hz (even with CRTs) and flat panels don't even update higher then 60hz  :-\

Maybe he is confusing the rate at which game logic is performed with the rate at which the scene is rendered ??
Sometimes games are written to run the logic as often as possible, but they only bother to redraw everything 30-60 times per second.
No, I do mean 120fps. The reason for this is the lack of motion blur. That's why you need to spit out this many fps if the changes from one frame to the next are pretty drastic.

Movies for example contain massive amounts of motion blur, which is the reason why they look sort of smooth. Short exposure or speed cam scenes don't look smooth at all. A famous example for this are the fight scenes in Gladiator. It looks like stop motion... just like a video game.
Title: Re: Timing, Vsync, CPU
Post by: Graeme on November 06, 2007, 00:02:05
Huh, I always assumed that most high end games are way too demanding on the system to be able to run at 120 fps.  I wonder if it's noticeable when a game drops from 120 to 60 (or something).
Title: Re: Timing, Vsync, CPU
Post by: oNyx on November 06, 2007, 00:58:38
Of course they are too demanding initially. But for the most part they are playable if you get at least 30fps. A drop from 120 to 60 is noticeable, but less annoying then a drop from 60 to 45 for example.

Also with >= 85fps other things become more important than more and more frames. Quake3 for example had a slightly broken rounding routine for the jump arc. With the corrected routine @85fps (@85hz) it felt a lot smoother then with the broken one @120fps (@120hz). Just because the position was more accurate during jumping... weird huh?
Title: Re: Timing, Vsync, CPU
Post by: princec on November 07, 2007, 12:52:21
Doom3 engined games are capped at 60Hz. I think really that's as fast as you realistically need to go.

Cas :)
Title: Re: Timing, Vsync, CPU
Post by: elias4444 on November 07, 2007, 15:35:06
I think where some games make the mistake of "needing" to go to 120fps (or more than the screen refresh rate) is when their controls responsiveness is tied to the framerate. Just make sure you're using a good timer with all of your controls and you should be fine. If the screen is only drawing 60fps, then it's not going to matter however many frames per second more the graphic card is drawing... what good does it do you to draw the frame twice per screen refresh if the user can only see the last one anyway?

Title: Re: Timing, Vsync, CPU
Post by: oNyx on November 08, 2007, 03:00:49
Vsync is a given. How can there be any smoothness if there is no vsync?

Note that I wrote "120fps (@120hz)". 120hz or even 160hz are possible with CRTs. At 1024x768 mine only goes up to 100hz tho.

>Doom3 engined games are capped at 60Hz. I think really that's as fast as you realistically need to go.

Ye, there was quite some uproar back then. And well, I disagree. 60fps is alright for 2D, but a tad more is nice for first person 3D games. Sure it's the point of diminishing returns, but up to 100-120fps there are visible improvements. Ideally everything is in sync; fps, hz and mouse polling rate (USB mice use 125hz by default, PS/2 can be configured to use 100hz).
Title: Re: Timing, Vsync, CPU
Post by: bobjob on November 09, 2007, 21:53:23
Quote
A famous example for this are the fight scenes in Gladiator. It looks like stop motion... just like a video game.
i think the effects in gladiator are due to the lense size, and fov, not the frame rate. Also used in war movies during action to make the scene seem more intense.

I honestly have never seen a game that requires more than 60fps, the human eye cant even pic up much more than that anyway. The only way you can detect if a CRT monitor is set to 60hz is buy looking at the screen from the side of your eye (you may get a black bar for a mini-second, this isnt possible on flat screens), any higher that that is impossible to detect (with the human eye).

Movies genereally have a frame rate of either (PAL) 25, or (NTSC) 24.

so i really dont think fps is an issue. VITALIR i think you should stick with a good 60fps.

something else that interesting is that anime is generally animated at 14 fps.


Anyway correct me if im wrong.
Title: Re: Timing, Vsync, CPU
Post by: princec on November 10, 2007, 13:32:31
And of course there will ne NO CRTS in use in the very near future. They haven't even been on sale here for several years now. There are a very few diehards that are sticking with them but it'll only be another year or two. They are already a tiny minority anyway.

Cas :)
Title: Re: Timing, Vsync, CPU
Post by: elias4444 on November 10, 2007, 17:24:06
Considering I could barely even give away my last CRT, you're more right than you know!  :P
Title: Re: Timing, Vsync, CPU
Post by: oNyx on November 12, 2007, 02:06:45
>i think the effects in gladiator are due to the lense size, and fov, not the frame rate.

It's short exposure. Hence no (well, less) motion blur. The framerate is the same.

>I honestly have never seen a game that requires more than 60fps, the human eye cant even pic
>up much more than that anyway.

The human eye is asynchronous. Each "pixel" is asynchronously polled every ~7hz. Basically... the new scene is sprayed over the old. That's how real life motion blur works. The quality of the eye-generated blur depends on the source material. Infinite frames (the real world) yield better blur than 60 frames for example.

Now imagine you're doing a 180° turn in 0.5 sec. With 60fps you get 30 frames in that time... 180/30=6. So, each frame has a 6° step. A quick 180° turn is more than 2 times faster, leaving you with 12 or more degrees per frame.

>Movies genereally have a frame rate of either (PAL) 25, or (NTSC) 24.

However, movies already contain excessive amounts of motion blur (unless short exposure times are used). Just press pause and you'll see. In the cinema they usually put some extra blur on top during cam turns, because it wouldn't look smooth otherwise (it still looks a tad jerky).

Btw NTSC uses 30 (interlaced - 60 progressive). 24 is cinema.

>And of course there will ne NO CRTS in use in the very near future.

Yes. However, displays will most likely allow more hz in the future. OLEDs for example can switch a lot faster.

---

Well, it's a pretty complicated topic. The perceived smoothness depends on several factors. Eg the extreme contrast levels of the usual "white rect on black background" test case usually aren't reached. With real art in place everything is magically smoother. Or things don't move fast enough to make a difference (that's why 2d is usually more than fine with 60fps). Or you can cheat like movies do with a bit of generated motion blur.

Example:
(http://kaioa.com/k/woosh.png)
The bunny does a cell size (32px) step @ 60fps, but it looks like it does a super fluid sweep. The excessive amount of blur isn't obvious to the player, but is clearly visible in screenshots.