Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (515)
Games in Android Showcase (122)
games submitted by our members
Games in WIP (577)
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  
  Rendering and game loop method for optimal framerate  (Read 1393 times)
0 Members and 1 Guest are viewing this topic.
Offline Grimmov

Senior Newbie





« Posted 2013-10-11 18:22:17 »

I'm working on creating my first serious game in Java... right now, it is relatively simple, and merely displays a few hundred BufferedImages and shapes on the screen. I decided to test various combinations of rendering and game loop methods on each of my three computers...

Method one:
Exclusive fullscreen mode, using a BufferStrategy for page flipping, iterate over elements using an infinite loop with no delay.
Results:
My main desktop computer gets 145 FPS, powerful laptop gets 33 FPS, small laptop gets 11 FPS.

Method two:
Windowed mode, using javax.swing.Timer for timing, iterate over the elements with each expiration.
Results:
Main desktop gets 545 FPS, powerful laptop gets 33 FPS, small laptop gets 31 FPS (but looks laggy like 11 FPS).

Method three:
Windowed mode, using an infinite loop and System.nanoTime() for timing, call repaint() every interval.
Results:
Main desktop gets 850 FPS, powerful laptop gets 31 FPS, small laptop gets 31 FPS (but looks laggy like 11 FPS).


To summarize, my desktop computer gets vastly better performance than either of my laptops. But the larger laptop has its own nvidia graphics card and a CPU even faster than my desktop, so I see no reason there should be a performance disparity. (Yes, I did ensure that the laptops are on performance mode, not power saving mode.)

Furthermore, I am puzzled as to why (on the desktop) windowed modes are so much faster than dedicated fullscreen mode. I was under the impression that the advantage of fullscreen dedicated mode is superior performance.

Any insight into these issues would be appreciated.

Offline davedes
« Reply #1 - Posted 2013-10-11 18:51:58 »

If you care about performance and consistency across platforms, then don't use Java2D. Roll Eyes

LibGDX or another OpenGL-based framework would be a much better choice:
http://libgdx.badlogicgames.com/

Offline Savant

Junior Newbie





« Reply #2 - Posted 2013-10-11 19:03:07 »

We'll need more info on the computers for this question! The specific CPUs in question, operating systems, video cards, etc. all play their part in performance. That said.... yeah, Java2D isn't the quickest fish in the sea.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Grimmov

Senior Newbie





« Reply #3 - Posted 2013-10-11 19:07:42 »

I will try out LibJDX and see if it improves the consistency of performance... is the general conclusion simply that Java2D is shit and inconsistent for serious games?

By the way, all three of the laptops are runnings Windows 7 or 8 with i5 processors. The computer and the powerful laptop have similarly powerful nVidia graphics cards. I see no reason for the vast performance disparity unless there's just something very inconsistent happening at a low level.
Offline Savant

Junior Newbie





« Reply #4 - Posted 2013-10-11 19:19:27 »

i5's have a wide disparity of performance, especially in laptops. A lower-end laptop i5 is little better than an i3 for most applications, and a high-end i5 benchmarks within a few percentage points of an i7 when it comes to most game-related tasks. Also, a laptop i5 (or video card) is not at all the same as an equivalent desktop component. So, you may be experiencing some differences between laptop and desktop hardware here after all - wouldn't know without knowing the specifics.

Still, there's likely more going on - my uneducated guess is that you're doing a lot of work in the processor and not in the video card, which would make that video card relatively useless. If that i5's an i5-3317U, I could certainly see that issue happening.

Just a blind guess, though! Refactor out of Java2D and see where you are.
Offline xsvenson
« Reply #5 - Posted 2013-10-11 19:32:14 »

Perhaps those are the laptops that have a nvidia card for games and performance and the intergated intel card for non-graphics intense processing.
In that case, java is ranked as "non-graphics intense" and the nvidia card is not actually used.

Java2d is great for simple things. However for "serious" stuff, like games, not so well. You can do very much with it, of course, but performance and consistency and everything else plays a huge roll in making it bad.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Offline philfrei
« Reply #6 - Posted 2013-10-11 19:53:55 »

Before totally ruling out Java2D, it might be worth checking if you are following suggestions posted in this thread on efficient Java2D methods. If you are, you will have a better chance of gauging tradeoffs.

http://www.java-gaming.org/topics/java2d-clearing-up-the-air/27506/msg/0/view/topicseen.html#new

Also, the Swing.timer is known to perform significantly worse than the util.timer. "Killer Game Programming in Java" does a comparison of performance of game loops vs the two timers. The swing timer does very poorly, but the util time is pretty much matches the game loop technique.

I'm just starting to learn about BufferStrategy and taking the path of matching the screen refresh rate. Based on what I'm reading in Brackeen's "Developing Games in Java", a timer-based approach wouldn't work for this.

"It's after the end of the world! Don't you know that yet?"
Offline Grimmov

Senior Newbie





« Reply #7 - Posted 2013-10-11 20:23:06 »

philfrei, I do happen to be following all of those suggestions... it seems that I am actually using Java2D correctly, it is just slow.

So, here's an update for anyone with similar issues: it turns out that the laptops were refusing to use video acceleration, I think. As an experiment, I set the following flags at the start of the program:

System.setProperty("sun.java2d.d3d", "false");
System.setProperty("sun.java2d.noddraw", "true");
System.setProperty("sun.java2d.opengl", "true");

This caused the laptops to freeze when the program was launched outside of fullscreen exclusive mode (they most likely cannot use OpenGL in windowed mode), but once I also enabled fullscreen, they started running quite well.

I was able to achieve 143 frames per second on the powerful laptop, and about 57 frames per second on the smaller laptop with integrated graphics (and it actually displayed about that many frames, unlike before).

So, here are my current questions:

1) How the heck can I get the laptops to utilize acceleration under D3D? Is it possible, or even desirable?
2) Why does my desktop render so much faster in windowed mode rather than fullscreen dedicated mode?
3) LibGDX or Slick (or something else)? I have read about the differences, but more opinions are nice.


Offline davedes
« Reply #8 - Posted 2013-10-11 21:24:50 »

Don't rely on the flags. They are unpredictable and generally Java2D should be picking the best options for you. On some systems they will have no effect.

1) You can only hope that Java2D will do things the best way. You can't always count on it.

2) Not sure. Generally you shouldn't measure performance differences if you aren't rendering anything, since it doesn't really give you "real-world" information. If you are rendering a scene and seeing significant differences between fullscreen and windowed mode, it may be due to fill-rate.

It could also be the computer choosing some strange GPU settings. For example, when unplugged, some laptops might perform really poorly in full-screen if "battery saving" modes are enabled. Or something to do with the run mode, like xsvenson mentioned.

3) Slick is outdated and no longer actively maintained. The website is hosting docs and JARs for an outdated version. The wiki is down and the forums are pretty inactive. LibGDX is much more powerful, more flexible, better documented, better maintained, ports to more platforms, includes better tools, etc...

Offline philfrei
« Reply #9 - Posted 2013-10-11 21:54:09 »

Cool, re, applying the Java2D "best practices". You are probably well ahead of me.  Smiley

Poking around (was curious about the flags you were setting, trying to learn more about them), I just found this document online, seems to be a wealth of information. I don't know how applicable this is, since your laptops are probably working as designed. But there might be some interesting tools and insights.

http://www.oracle.com/technetwork/java/javase/java2d-142140.html#gcrtt

I'd scroll back a small bit and start perusing from 3.2 Generic Performance Issues. There's a set of links from there, heading in various directions.

I didn't check for a Java 7 SE version of the doc.

"It's after the end of the world! Don't you know that yet?"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #10 - Posted 2013-10-12 02:54:55 »

I'd examine your code, in particular how you are measuring your framerate.
At the same resolution, windowed mode should never outperform fullscreen exclusive mode.

What sort of performance do you get out of my Balls.jar benchmark?
It's old and somewhat outdated (it was written back when the various experimental opengl & d3d pipelines were first introduced[Java1.4]), but it still gives a fairly good indication of expected performance from java2d.

My desktop machine (Windows 7, phenom II x6 @ 3.5GHz,HD 5870) can hit just over 21k blits in 1920x1080 fullscreen exclusive mode, with AlphaComposite enabled. (all image types)
Obviously this isn't representative of real world performance, as drawing the same image over & over is very much the optimal use case (ideal for pipeline caching of instructions & such), but it does give an indication as to whether the rendering pipeline is performing 'correctly'.

Oddly on my machine the performance of the various image types is all over the place in windowed mode; though as I said, it's old code & might not be doing everything correctly.

Incidentally the 'image types' are all old terminology, back when the acceleratability of BufferedImages varied wildly on how you created them.
You'll notice there's no translucent VolatileImage; that's because GraphicsConfiguration#createCompatibleVolatileImage(with,height,transparency) didn't exist in Java 1.4.

I've long since forgotten what exactly the image types mean; you'll have to examine the source to find out.
Though in any modern Java runtime they should all perform much the same. (which again makes me wonder WTF is going on with windowed mode, as I'm seeing vast performance differences between the image types.)

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

Senior Newbie





« Reply #11 - Posted 2013-10-12 05:42:21 »

I tried out your benchmarking program, and the results were confusing.

While in fullscreen mode, I was unable to make my framerate drop below 60 no matter which settings I used. The balls stopped appearing once I reached ~7000.

While in windowed mode, my framerate was initially 400, and it took 22,000 balls before my framerate was reduced to 60.

If I set the the number of buffers to 2 rather than 3, I still had 120 FPS with over 32,000 balls, so I gave up waiting for it to get slower.

So again, my performance seemed superior in windowed mode. This mirrors the behavior I experienced with my own program.
Offline davedes
« Reply #12 - Posted 2013-10-12 16:58:39 »

Here's my results...
OSX 10.8.5, 2.66 GHz Intel Core i7, 8 GB RAM, NVIDIA GeForce GT 330M

--

AutoImage - @ 30 FPS, 1920x1200, alpha composite on, 2 buffers
1600 particles  - windowed
750 particles  - fullscreen

"FullAlpha AutoImage" gives me 3300+ particles in windowed mode.

Just FYI, a more "real-world" benchmark would use multiple different images to include some texture switches and possible batch flushing (depending on how the backend is implemented).

Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #13 - Posted 2013-10-12 17:33:51 »

I suppose it's worth mentioning that my confidence in the performance of java2d on anything but Windows is near zero.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline StumpyStrust
« Reply #14 - Posted 2013-10-13 08:43:43 »

Java2D can handle basic sprite based games very easily and remain fast on most platforms as long as all you are really doing is g2d.drawimage stuff. At around 5-10k draw calls and integrate GPUs die. Fancy stuff can be done and remain somewhat fast but it is an absolute pain in the ass and requires hacks out the wazu. Don't listen to the constant java2D sucks suff because it is true in some cases but most people try things that java2D does not accelerate.

If you are serious about game dev, use Libgdx or your own stuff through opengl bindings. Libgdx can have a larger learning curve and anyone who says it doesn't, has already mastered it somewhat. It is worth it to skip java2D though as you will need to learn things like XML/json/what-is-going-on-graphics-wise-under-the-hood eventually.

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.

TehJavaDev (30 views)
2014-10-27 03:28:38

TehJavaDev (26 views)
2014-10-27 03:27:51

DarkCart (39 views)
2014-10-26 19:37:11

Luminem (21 views)
2014-10-26 10:17:50

Luminem (25 views)
2014-10-26 10:14:04

theagentd (31 views)
2014-10-25 15:46:29

Longarmx (61 views)
2014-10-17 03:59:02

Norakomi (57 views)
2014-10-16 15:22:06

Norakomi (46 views)
2014-10-16 15:20:20

lcass (43 views)
2014-10-15 16:18:58
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!