Toggling vsync

[Andrew Davison]

Dear All,

In fullscreen mode, show() is tied to the vsync rate,
which can slow games down.

Is there a Java-based way of turning vsync on and
off?

I've heard that there's an OpenGL extension which
can do this, so perhaps JOGL may be be useful?

- Andrew

[swpalmer]

What happens when you have more than 2 buffers in you BufferStrategy ?
V-sync is usually desirable to avoid tearing - so long as you can keep up and not cause the frame rate to drop in half if your rendering takes a bit too long.

[Abuse]

It maybe possible through the
createBufferStrategy(int numBuffers, BufferCapabilities caps) method (though I dont think it is)

The only other way of turning vsync off in fullscreen, is to not use BufferStrategy at all, and use your own VolatileImage backbuffer. (this would be less efficient though, as you wouldn't be page flipping anymore)
Seems a waste to have to recode something like that though, just because no1 had the for-thought to include it in the BufferStrategy api :-/

Games published by our own members! Check 'em out!

[Orangy Tang]

Setting the  BufferCapabilities.FlipContents to something like COPIED will probably force a blit rather than a simple page flip/pointer swap. Whether this makes it no longer v-sync'ed is another matter.

But even on the worst displays you're going to be getting 60fps, is that really 'too slow'? If you're after a performance measure can't you just test it in windowed mode?

[princec]

I wish people would stop requesting to be able to turn off vsync. Nothing runs any faster with it on or off. It was a myth created by Quakeworld players due to a quirk in the design of Quakeworld.

Games without vsync look shit, period.

Cas

[kevglass]

To elaborate on this, I think what Cas is saying is don't tie your logic loop processing time to your rendering time. Fix you render loop at what ever FPS you want and only redraw that often. However, this doesn't negate you running your logic loop more often if you really feel you need to (although of course you won't see any changes on screen due to your logic resolution).

A useful thing would be to turn vsync on in windowed mode

Kev

[Abuse]

I wish people would stop requesting to be able to turn off vsync. Nothing runs any faster with it on or off. It was a myth created by Quakeworld players due to a quirk in the design of Quakeworld.

Games without vsync look shit, period.

Cas

I disagree, if your game running flat out gets ~50fps, on a 60hz vsync locked display, you are going to get alot less than 50fps. (somewhere in the region of 30fps)

In that scenario, it is alot better to turn vsync off, and get as much upto-date information to the screen as possible, 2/3rds of a screen update is better than no screen update.
Also, tearing in 3d games realy isn't that noticable.

[princec]

How can you say 2/3rds of a screen update is better than no update when it will be 1/3rd incorrect?

As I say - it is a Quake-player originated, developer-perpetuated illusion that 30fps on a 60Hz display is worse than 50fps on a 60Hz display. But I can't prove it to anyone You just have to do the experiments yourself.

Cas

[Abuse]

Setting the  BufferCapabilities.FlipContents to something like COPIED will probably force a blit rather than a simple page flip/pointer swap. Whether this makes it no longer v-sync'ed is another matter.

But even on the worst displays you're going to be getting 60fps, is that really 'too slow'? If you're after a performance measure can't you just test it in windowed mode?

To get a non-flipping strategy, you pass null in as the BufferCapabilities.FlipContents parameter. e.g.

1	createBufferStrategy(2, new BufferCapabilities(new ImageCapabilities(true),new ImageCapabilities(true), null));

I suppose the fundamental question is, can you use pageflipping and not have it vsynced?
If its impossible, then there is nothing wrong with the current API (in terms of not revealing necessary functionality).
If it is possible, then we need an extra parameter to the BufferCapabilities object, so we can specify vsync'ed or not.

[Abuse]

How can you say 2/3rds of a screen update is better than no update when it will be 1/3rd incorrect?

It won't be wrong as such, it will just be out of date.
But then, if no update occurs, ALL of it will be out of date.

Giving our brains partial information, and letting it correct for errors is far better than giving it no information.

As I say - it is a Quake-player originated, developer-perpetuated illusion that 30fps on a 60Hz display is worse than 50fps on a 60Hz display. But I can't prove it to anyone You just have to do the experiments yourself.

Cas

Indeed, self experiment time :p

vsync on, com_maxfps 30, spin around quickly.
vsync off, com_maxfps 50, spin around quickly.

I know which I prefer, and I know that I play with vsync off, com_maxfps 125

Games published by our own members! Check 'em out!

[kul_th_las]

When using vsync, it's your responsibility as a developer, to make sure your app is rendering on time. If your app is capable of 45fps, and you're displaying on a 60Hz display, you need to go with 30fps. If (through your own fault) your app isn't actually timing things correctly in order to hit that 1/30 second display timing each and every frame, then either (a) you're trying to do too much on a resource-limited machine, or (b) more likely you haven't properly tuned/timed your code to meet the 1/30 second mark.

I know Cas has said this a hundred times or more, but if you're rendering faster than the refresh rate (the maximum rate at which your display is going to update the information reaching your eyes) then you're absolutely wasting processor time that can be used by other things in your game (i.e. better AI, more visual effects, etc).

I don't understand why people are still not understanding this?! Just because your fps counter says you're getting 125fps, doesn't mean it's actually updating the screen 125 times per second! That may be how fast your rendering loop in running, but the screen (the device that actually displays the information) can only give you as many fps as the refresh rate. It's as  simple as that.

Again, if you're fps counter says 1,000,000 fps, but your refresh rate is 60Hz, then you're getting 60 frames per second. The fps counter ONLY measures how quickly the rendering loop is running, NOT how quickly the screen is being updated.

[kul_th_las]

In fullscreen mode, show() is tied to the vsync rate,
which can slow games down.

As was said before, the only reason vsync would slow your game down, is if your logic loop (how often you update the data in your world, i.e. player movement) is tied to how often you're updating the screen.

If the logic and display timing are tied together (i.e. one logic 'tick' for each frame rendered) then your game will run at totally different speeds depending on how fast the user's computer is. If your computer can run the game at 120fps and mine can only go 60fps, then the game will run at 1/2 the speed on my machine versus yours. And when I say speed, I don't mean rendering speed - I mean the movement of the characters, the visual effects, everything will run at 1/2 speed.

Logic and rendering timing must remain independent (a) because different system specs (so long as they are sufficiently high to play the game at all) should not affect how the game moves or feels to the player, and (b) because different people use different refresh rates (in the case of using vsync), and if your display AND logic are tied together, and your display is tied to vsync, then the refresh rate of their monitor will directly control the speed of the game.

[abies]

I'll state the obvious, but it hasn't been said already:

125fps on 60Hz display IS an important thing - just not for the gamer, for developer. Thanks to it, he will see that particular effect has reduced his framerate to 61 - a sure place for optimalization. Same holds true for comparing GPUs - fact that one GPU can run game in 50fps and second with 30fps means that first one can probably render it in better resolution without noticeable drop in speed (until it would go under 30 fps in this example).


As for the tearing, I have seen it few times and it was VERY noticeable - but it was with older card, maybe something has changed in meantime in the way GPU displays data.

[Abuse]

hmm,
125 was a bad example...
The reason I run Q3 at 125fps, is because Q3 makes a special case of it (75 & 125), due to a quirk in the the physics engine, running at said framerate allows you to move marginally faster.

Back to the issue at hand, if your rendering *on average* takes longer to execute than the time between vsync's, you will get stuttering.
(1 frame takes 2 vsyncs to render, the next only takes 1, etc etc)

There are 2 solutions.
1) Detect that you are droping frames, and switch to a framerate of refreshrate/2.
2) Disable vsync.

I prefer the later solution (most of the time), as, IMHO a partially upto-date render is better than no render at all.
I say most of the time, because the game type also has to be considered, as to whether tearing is impairing visual quality significantly or not.

And just to clarify, this has nothing to do with tieing logic and rendering together.

I'd still like an answer to my earlier question :-

Can you page flip with vsync off?

My gut instinct is no, as I would expect the graphics card to cache the video pointer at the start of a frame.

[swpalmer]

Having vsync turned on will cause an objectional stutter in frame rate when your rendering time is slightly longer than the frame time.

The problem is that the frame rate will waver between the extremes of 100% and 50% of whatever the display sync is.  And that sometimes sucks more than the tearing that you get without vsync on.  Otherwise, absolutely you want vsync to avoid the tearing and regulate the frame rate.

[kul_th_las]

I'd still like an answer to my earlier question :-

Well, am I contributing to a thread jack? I apollogize.

125fps on 60Hz display IS an important thing - just not for the gamer, for developer. Thanks to it, he will see that particular effect has reduced his framerate to 61 - a sure place for optimalization.

Profiling your application will give you more accurate information on the effects of changing your code, no matter where you change it. Without having to rewrite your rendering code if/when you switch to vsync'ing.

The problem is that the frame rate will waver between the extremes of 100% and 50% of whatever the display sync is.

if your rendering *on average* takes longer to execute than the time between vsync's, you will get stuttering.
(1 frame takes 2 vsyncs to render, the next only takes 1, etc etc)

Not if you time your application for the lower frame rate. This is why publishing minimum system spec for your app is important - if the system meets the system specs, then you can expect it to hit the render timing consistently.

I should point out that Alien Flux has an option for toggling 60/30fps render speeds, which is quite an intelligent option, given what a wide range of machines that game runs on.

Besides "scalability" is something we all ought to do when writing games - every major game does it nowadays (i.e. being able to turn on/off certain effect that directly affect the user's framerate). It IS possible to have smooth animation, AND zero tearing. They're not mutually exclusive.

[oNyx]

hmm,
125 was a bad example...
The reason I run Q3 at 125fps, is because Q3 makes a special case of it (75 & 125), due to a quirk in the the physics engine, running at said framerate allows you to move marginally faster.
[...]

"Play more promode"

CPMA's physics are framerate independant (since 1.0 iirc). And that without the strange sideeffects of pmove. I'm still wondering how arQon did that

Btw if your monitor is able to use 140hz (in your choosen resolution) you can just create a new mode wich supports 125hz. Either with registry hacking or with programms like power strip.

(Sorry for beein OT )

[Abuse]

Not if you time your application for the lower frame rate. This is why publishing minimum system spec for your app is important - if the system meets the system specs, then you can expect it to hit the render timing consistently.

true, min. system specs do serve a purpose, though more often than not, it is so people don't take games back to the shop saying 'this game is unplayable blah blah blah' (and if they do, the shop has something to fall back on, like 'you read the requirements... etc etc')

Also, due to the abstractness (is that a word? ^_^) of Java, it is obviously far harder to give accurate min. requirments.

I should point out that Alien Flux has an option for toggling 60/30fps render speeds, which is quite an intelligent option, given what a wide range of machines that game runs on.

yep, and as cas and others have argued in many previous Threads, for 2D animation to appear smooth, it has to be done at a constant FPS.

However, take the vast number of 3d shooters/flight sims/rpgs etc etc out there.
None use fixed 'multiple of refreshrate' framerates, simply because it isn't necessary for 3D games.

Besides "scalability" is something we all ought to do when writing games - every major game does it nowadays (i.e. being able to turn on/off certain effect that directly affect the user's framerate). It IS possible to have smooth animation, AND zero tearing. They're not mutually exclusive.

true, it is.

However, Unless you have dynamic detail alteration (very very few games do), or you have levels/maps that have been expertly crafted for consistent processing load, you will always get fluctuations in framerate.

Running with Vsync off, your rendering will always be more tollerant to load flucuation.

for example :-

VSync ON, Your machine is running at 90%, and attaining the max. 60fps.
You then have an event that causes an increase in load to 110% (lets say, an explosion occurs very close to the camera, and the fillrate takes a hammering)
While you are running at 110%, all your frames are taking 2 vsyncs to render, so your framerate has dropped from 60fps to 30fps.
Ofcourse, in a real-life example the 110% load would be for only a few frames. However, in many ways this is far worse, as your framerate will be 1-2-1-1-2-2-2-1 (vsyncs) aka stuttering.

Now, the VSync OFF scenario as you can imagine will not suffer from the same problems, the framerate will be directly proportional to the cpu load.
So, a 110% load will cause the framerate to drop to 1/1.1 * 60 = 54fps.

So, as i see it vsync off gives more stable framerates, at the expense of tearing.
And tearing in 3D games is not [very] noticable.

[Andrew Davison]

Part of the problem with the discussion is the meaning
of FPS, which should refer only to rendering rate.

A separate measure, which I call updates/sec (UPS), is
the frequency of updates to the game state.

There's no point having a FPS in your code which
exceeds the refresh rate. But, UPS can be anything.

Let's say we have 80 FPS, and the refresh rate is 85Hz.
Is everything fine? Perhaps not.

80 FPS means that our program calls the rendering
code 80 times/second, but how long does the
rendering code take? If it takes longer than 1/85 sec
(the time for a single refresh) then the rendering will
not be seen until the end of the 2nd refresh.

We have a few choices:

• profile our code to prevent rendering time from
  ever exceeding the time for a refresh;
  
• allow the occasional 2 cycle refresh, which may
  look like stuttering on-screen;
  
• disable vsync, and get tearing on-screen instead
  of stuttering.
  

- Andrew

[princec]

It is worth mentioning that triple buffering can give you a fairly hefty increase in consistent frame rate in certain situations.

Mind you it's also worth agreeing that tearing is far less noticeable in 3D scenes...

Cas

[shawnkendall]

Classic link.
30 Frames per Second vs. 60 Frames per Second
http://www.daniele.ch/school/30vs60/30vs60_1.html

Maybe this article will explain why faster is always better PrinceC...
I think your religion is too strong though... :-)

[kul_th_las]

Look, this is pointless. This has turned into a tearing vs. no tearing discussion. That's really the bottom line here. We don't all seem to be working off of the same definitions of "smoothness" or "quality". These seem to be subjective terms in this thread.

Different rendering philosophies are going to persist because ultimately, even if we all understand the subject at hand perfectly well, some of us are willing to put up with visual tearing, and some of us aren't.

BTW, when was this article written? 3dfx went out of business years ago! This article is so poorly written, and even less well supported by technical information, that the reader is forced to take the author's word for it. The issues brought up in it (due to its lack of solid technical and logical backing) are absolutely debatable. It's no more valid or invalid than the opinions raised in this thread by anyone.

Some of you will be glad to hear that this is definitely my last post on this thread. Nothing's being accomplished.

Make better games, damnit! However the hell you decide do it!

[oNyx]

Classic link.
30 Frames per Second vs. 60 Frames per Second
http://www.daniele.ch/school/30vs60/30vs60_1.html

Maybe this article will explain why faster is always better PrinceC...
I think your religion is too strong though... :-)

Nothing new... well some of the explainations are a bit vague.

Motion blur is a sideeffect generated by the way we receive data - it's asynchronous. We don't see complete frames... instead it's like updating random "pixels" at 7-15hz. It's like having a back buffer and the new image-information is sprayed over it - therefore fast moving objects appear to be blurred (because not all "pixels" have been updated).

Another "funny" thing is that a quite huge part of the image we currently see is based on old data

If something moves within our ~170° fov we look at it (we are drilled to do so - it could be something dangerous)... so we look at it and our back buffer gets updated information about that area... we look back... and as long as there isn't any motion our brain just asumes that everything in that area hasn't changed. For that reason we hardly notice when our eyesight degenerates and it's also the reason for the "tunnel view" effect (smaller fov) if you move at high speeds.

[shawnkendall]

The article is definitely soft but it helps explain the complexities that arise with different display mediums.

The illusion (or real effect?) of motion blur is creatable by "static" computer graphics scenes if the update is fast enough.
We have done tests with 120 hz updates and motion blur begins to be percieved even though we know the individual frames are clear and sharp just like objects in reality.

However, actual technical studies would be much better if anyone knows off any, I think I am of to Google :-)

[MGodehardt]

Dear All,

In fullscreen mode, show() is tied to the vsync rate,
which can slow games down.

- Andrew

Are you serious ? Do you understand the meaning of your sentence ?

Your Monitor has a refresh rate ( for e.g. 60 Hz ), Hz means s ** -1, means every 1/60 second the beam of the CRT has finished drawing one screen.

In one second it will draw 60 screens, its your MONITOR which is slowing down your app.

"Do not ask what the app can do for you, ask what u can do for the app."

Its like lightspeed, u cant go faster than light ( but it would be funny to follow the beam of a flashlight )