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?
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.
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 :-/
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?
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 
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
[quote]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
[/quote]
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.
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
[quote]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?
[/quote]
To get a non-flipping strategy, you pass null in as the BufferCapabilities.FlipContents parameter. e.g.
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.
[quote]How can you say 2/3rds of a screen update is better than no update when it will be 1/3rd incorrect?[quote]
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.
Indeed, self experiment time 
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
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.
[quote]In fullscreen mode, show() is tied to the vsync rate,
which can slow games down.
[/quote]
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.
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.
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.
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.
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.
[quote]I’d still like an answer to my earlier question :-
[/quote]
Well, am I contributing to a thread jack? I apollogize.
[quote]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.
[/quote]
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.
[quote]The problem is that the frame rate will waver between the extremes of 100% and 50% of whatever the display sync is.
[/quote]
[quote]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)
[/quote]
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.
[quote]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.
[…]
[/quote]
“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 :-X)
[quote]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.
[/quote]
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.
[quote]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.
[/quote]
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.
[quote]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.
[/quote]
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.
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.
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