Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (553)
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  
  Why Java games look choppy: Vertical Retrace  (Read 6709 times)
0 Members and 1 Guest are viewing this topic.
Offline CommanderKeith
« Posted 2006-08-17 05:45:12 »

This is a pointless thread that I wanted to start to let other newbs like myself know why their animations look terrible. 

I've always wondered why many java games look so crap, including mine.  The animation isn't smooth even when running on state-of-the-art computers.  At first I blamed the garbage collector since it pauses all threads and it's uncontrollable.  But GC pauses are usually insignificantly small.

The real problem is the vertical screen retrace (the monitor refresh rate).  Chet Haase showed the problem is his blog entry: <a href="http://weblogs.java.net/blog/chet/archive/2006/02/make_your_anima.html">Make Your Animations Less Ch-Ch-Choppy</a>.

Vertical retrace is a massive problem because it can cause your images to be displayed up to 16.6 milliseconds late if the screen refreshes at 60Hz.  This is noticable to the human eye.

The other problem is that it causes your animations to become 'torn' when a new image is drawn half-way through the vertical retrace, so the top half of the old screen image remains but the new one takes up the bottom half.  This looks fugly to say the least.

As Chet said in his follow-up blog,
<a href="http://today.java.net/pub/a/today/2006/02/23/smooth-moves-solutions.html#handling-vertical-retrace.html">Smooth Moves</a>:

"The fix is easy for anyone writing a fullscreen Java application; applications that use the FlipBufferStrategy get this for free. When that buffer strategy copies its contents to the screen from the back buffer, it specifically waits for the vertical blank interface, and thus avoids tearing completely.

The fix is not as easy for typical windowed (non-fullscreen) applications, because there is currently no way to tell Java to wait for this interval, and there is no way for your code to know when it is a good time to go ahead with the copy. We hope to address this in a future release (I just filed a bug on it last week!), but in the meantime there is no way to get this behavior."


Anyway, i think this is one of the last things Java 2D needs to make our apps look decent, so if someone can help me find that bug & vote for it, (and politely hassle Sun's J2D team to work it out  Wink), all the better for us.

PS: Interestingly, on my computer with the OGL pipeline enabled I get v-syncing when my BufferStrategy uses 2 buffers, but with 3 or more I lose the v-syncing.

Offline CommanderKeith
« Reply #1 - Posted 2006-08-17 06:13:09 »

Here's the bug Chet Haase reported, and I've cast my 2 lousy votes against it, join in!

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378181

Offline kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #2 - Posted 2006-08-17 16:34:52 »

Not sure if this would help, but I wrapped this up for vsync in Java2D windows in the Mini Adventure days:

http://www.newdawnsoftware.com/resources/pxsync/

It's a small native library that allows you to get vsync in a window on Windows. On other platforms v-sync is the default anyway.

Probably doesn't work for OpenGL pipeline of course Sad

Kev

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CommanderKeith
« Reply #3 - Posted 2006-08-18 09:37:16 »

Awesome, JGO power all the way  Cheesy, 0 -> 8 votes in 24hrs.  At this rate it should be in the top 25 RFE's by the end of the month  Wink

Not sure if this would help, but I wrapped this up for vsync in Java2D windows in the Mini Adventure days:

http://www.newdawnsoftware.com/resources/pxsync/

It's a small native library that allows you to get vsync in a window on Windows. On other platforms v-sync is the default anyway.


Thanks for the code!  I'm going to give it a try & compare performance since Chet did something similar & the app ate ~100% of CPU power.

When you say on other platforms it is the default, do you mean that all painting is sync'ed?  Is that a rule for all Linux & Macs?

Keith

Offline kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #4 - Posted 2006-08-18 14:29:39 »

Last time I check windows using X dispaly are vsynced by default yes. So that covers Linux and MacOS X.

Kev

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #5 - Posted 2006-08-18 17:47:43 »

Here's the bug Chet Haase reported, and I've cast my 2 lousy votes against it, join in!

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378181

We do intend to fix this in upcoming release. Didn't make it into JDK 6, unfortunately.
So save your votes for bugs we don't intend to fix =)

Dmitri
Offline CommanderKeith
« Reply #6 - Posted 2006-08-19 02:59:26 »

Cool, can't wait for JDK 7 then.  That fix will be the best thing for percieved performance.

Its great to have you & Chris Campbell keeping us informed here. 

Keith

Offline whome

Junior Member




Carte Noir Java


« Reply #7 - Posted 2006-08-24 06:56:39 »

http://koti.mbnet.fi/akini/java/vsync/
I did a small test program with vsync library (with and without vsync).

BufferedFrame (without vsync):
* eat only 1-2% CPU
* targetFPS=100, run at constant 99-100 fps, use System.currentTimemillis() + Thread.sleep for fps capping

BufferedFrameVSYNC (with vsync):
* eat 99-100% CPU if I remove Thread.sleep() method call at the end of mainloop
* run at 61-62 fps with vsync library, I tested it on laptop lcd screen

Animation:
text is animated based on delta time and drawn to a new position. Both versions suffer occassional few pixels hops, but probably due to my doMainLoop implementation(??).

Final conclusion:
You still need an accurate sleep method to consume less CPU. Eating all cpus on windowed (small) game is not nice.
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.

CopyableCougar4 (24 views)
2014-08-22 19:31:30

atombrot (34 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (28 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (27 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (33 views)
2014-08-08 02:01:56

Norakomi (42 views)
2014-08-06 19:49:38
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!