Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (495)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Work-around for no Vsync in windowed mode?  (Read 7093 times)
0 Members and 1 Guest are viewing this topic.
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Posted 2009-08-24 15:00:50 »

I've been experimenting with determining the phase & period of the vsync signal (by timing a tight redraw loop in fullscreen exclusive mode),
with the idea of using this information to accurately time repaints in windowed mode to minimize or even eliminate tearing.

Timing the phase & period of the vsync has been easy enough, but... (yes, the inevitable but... Smiley
The actual refresh rates i'm measuring do not (quite) correspond with the refresh-rate the display is supposed to be operating at (according to Windows).

I'm using an hdtv as my monitor, and these are the values i'm observing for the different refresh rates my screen supports.

1  
2  
3  
4  
5  
6  
Reported : Observed
24Hz       : 23.974257Hz -> 23.97Hz ?
25Hz       : 24.99952Hz -> 25Hz
30Hz       : Barfs
50Hz       : 49.99325Hz -> 50Hz
60Hz       : 59.93889Hz -> 59.94Hz ?


I realize that the way in which i'm collecting the timings (System.nanoTime()) has it's own error margins involved.
However, the results clearly point to the fact that for 24Hz & 60Hz the drivers are reporting my refresh rate to be one value - where-as in reality it is something different.

Another problem is that i'm observing drift in the results, now my understanding of the vsync signal is that it's regular as clockwork. Is this a false assumption?
Or is it, as I suspect System.nanoTime() that is drifting. (though, it could be something wrong with my code too.....)


It's really the drift that's stopping this experiment from getting any further; but the false reporting of the refresh-rate intrigued me enough
to see if anyone else had encountered, or even considered that the OS might be lying to you!  Grin

:EDIT:

I might hook up one of my 19" monitors & see what that reports for '60Hz'.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #1 - Posted 2009-08-24 21:07:44 »

I might hook up one of my 19" monitors & see what that reports for '60Hz'.

Here's what I get when analysing my 19" monitor:

1  
2  
3  
4  
@60 -> 60.015537Hz
@72 -> 71.99875Hz
@75 -> 75.020294Hz
@76 -> 75.95719Hz


It doesn't appear to be any great revelation that the refresh rates reported by the OS are only approximations; but isn't it then wrong to base game logic at a rate that does not match the display rate?

You see many games dropping into resolution X by Y @ 60Hz, and then running their game logic @ exactly 60Hz - expecting the two to stay in-sync.
If using v-sync to throttle the game, the game speed will vary +/-0.5% depending upon the actual refresh rate being used by the game.
If not using v-sync, then you'll get 1 duplicate or dropped frame once every ~200 seconds.

I'm aware this issue is particularly important in decoding & syncing audio & video streams (the whole 24p/100Hz/2:3 pulldown etc etc),
but hadn't considered that it also effects games to some degree too.

Basically, fixed frame time really is flawed even for 2D - because refresh rates cannot be relied upon as being precise.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #2 - Posted 2009-08-24 21:16:32 »

Also, for games that use DirectX, have a fixed time step & rely upon v-sync to throttle the game speed - there appears to be a really interesting way of cheating.

start->run->dxdiag->'more help' tab->'override...' button-> force refresh rate->40Hz

It'll be like playing the game @ 2/3 speed =)

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CommanderKeith
« Reply #3 - Posted 2009-08-25 01:15:22 »

Weird results!

There's a bug about the lack of v-sync here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378181

Dmitri Trembovetski of java2D fame has promised to make a fix in time for java7.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #4 - Posted 2009-09-03 16:37:09 »

Unfortunately this still haven't happened as I'm on the JavaFX gfx team pretty much 100% of my time =(

There's already vsync support in the jdk (as of 6u10 or so), but only signed apps will be able to use it (it involves the use of a private BufferCapabilities subclass): http://hg.openjdk.java.net/jdk7/2d/jdk/file/a389af17df10/src/share/classes/sun/java2d/pipe/hw/ExtendedBufferCapabilities.java

Dmitri
Offline skinny boy

Junior Member





« Reply #5 - Posted 2009-09-03 18:08:47 »

this is a noob question

but why isn't the BufferStrategy capable  of eliminating tearing in Window Mode as is in FSEM?

in the docs ( http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html ) it doesnt say anything about using it only in FSEM (though there is an example along the FSEM tutorial link: http://java.sun.com/docs/books/tutorial/extra/fullscreen/index.html )
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #6 - Posted 2009-09-04 02:35:08 »

In full screen mode, if the Direct3D pipeline is enabled, BufferStrategy defaults to vsync-ed mode because it is assumed that most full screen apps are games or apps which need smooth user experience. In windowed mode typically responsiveness is more important, which is why BS is not v-synced by default for windowed apps (which includes swing since it uses buffer strategy for double buffering).

So yes, buffer strategy is capable of being v-sync-ed in windowed mode (providing a hw accelerated pipeline is used), but by default it isn't v-synced.

Dmitri
Offline skinny boy

Junior Member





« Reply #7 - Posted 2009-09-04 12:49:36 »

all this talk about "default" gave me the impression that the programmer can use the BS class the way he wants to -for example, not v-sync while in FSEM or v-sync while in window mode (by calling methods of the BS class perhaps?)

or is the default behavior the only behavior possible provided by Java??

thank you for your time Dmiitri
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #8 - Posted 2009-09-04 17:30:32 »

Right now "default" means that if you create a BS in FSEM mode, it'll be v-synced, in windowed mode - non-vsynced.

In jdk7 the intention was to add a new API (specifically, a BufferCapability variant which specifies what kind of BufferStrategy to create) which would allow to override the default behavior and request vsync-ed or non-vsync-ed strategy.

Dmitri
Offline skinny boy

Junior Member





« Reply #9 - Posted 2009-09-04 19:20:37 »

thank you very much for your time

i think i got it now...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CommanderKeith
« Reply #10 - Posted 2009-09-08 04:25:32 »

Unfortunately this still haven't happened as I'm on the JavaFX gfx team pretty much 100% of my time =(

There's already vsync support in the jdk (as of 6u10 or so), but only signed apps will be able to use it (it involves the use of a private BufferCapabilities subclass): http://hg.openjdk.java.net/jdk7/2d/jdk/file/a389af17df10/src/share/classes/sun/java2d/pipe/hw/ExtendedBufferCapabilities.java

Dmitri


This looks great, nice work solving it with this new class. It would be great to get it included in java7. Could you justify working on it since javaFX relies on the java2D API? Thanks for keeping us informed!

Cheers,
Keith

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #11 - Posted 2009-09-09 01:07:40 »

This looks great, nice work solving it with this new class. It would be great to get it included in java7. Could you justify working on it since javaFX relies on the java2D API? Thanks for keeping us informed!


Well, the FX runtime can use this private API anyway (since the java fx runtime is signed). It was in fact added for this very purpose (FX support), so it will be hard to justify spending more time on it to make it a public API.

The main issue with making this a public API is not in coding but clarifying all sorts of "ifs and buts" etc since we can't guarantee that it can be  enabled in all cases (so that apps start relying on it for say driving their animation etc). Also, there are some restrictions on how this can be used in applets - with the current AWT/2D model it's hard to make it such that vsync-ed applets within same app don't affect each other's framerate (they'll basically get half of the frame rate if two of them running on a page).

Dmitri


Offline CommanderKeith
« Reply #12 - Posted 2009-09-09 02:37:05 »

That's a pity, but at least it's in there as a private API.

Thanks Dmitri

Offline whome

Junior Member




Carte Noir Java


« Reply #13 - Posted 2009-09-26 22:10:14 »

There's already vsync support in the jdk (as of 6u10 or so), but only signed apps will be able to use it (it involves the use of a private BufferCapabilities subclass): http://hg.openjdk.java.net/jdk7/2d/jdk/file/a389af17df10/src/share/classes/sun/java2d/pipe/hw/ExtendedBufferCapabilities.java
Do a singed application apply to applets/webstart apps only? Or do I must sign a standalone applications as well, I think its not necessary right?

What comes to the to-be-or-not public api debate. Well is it so much a problem if some systems cannot use it. Graphics and game developers are used to it anyway each gfx cards have own issues to tackle. Publish it with a disclaimer it may not work so check for capability mode after setting it.

I had a need to program a silk smooth image scroller, from right to left, in windowed application and eating <5% cpu. It was a mission impossible in Java, cpu was ok but animation was not even close to an acceptable level. In the end had to use Delphi and directx application :-(

Maybe this private api could have helped me. I must take time create a test program someday and see if there is still hope in Java.

thx.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2009-09-26 23:12:13 »

Standalone apps run with all permissions.

Cas Smiley

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #15 - Posted 2009-09-27 00:24:08 »


I had a need to program a silk smooth image scroller, from right to left, in windowed application and eating <5% cpu. It was a mission impossible in Java, cpu was ok but animation was not even close to an acceptable level. In the end had to use Delphi and directx application :-(


You could have just used one of the many Java OpenGL bindings or libraries, like LWJGL, JOGL, Slick and just got vsync and super smoothness that way.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (24 views)
2014-09-12 09:08:26

Norakomi (56 views)
2014-09-10 13:57:51

TehJavaDev (69 views)
2014-09-10 06:39:09

Tekkerue (35 views)
2014-09-09 02:24:56

mitcheeb (56 views)
2014-09-08 06:06:29

BurntPizza (40 views)
2014-09-07 01:13:42

Longarmx (26 views)
2014-09-07 01:12:14

Longarmx (33 views)
2014-09-07 01:11:22

Longarmx (31 views)
2014-09-07 01:10:19

mitcheeb (39 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!