Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
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  
  Java and hardware graphics acceleration  (Read 3661 times)
0 Members and 1 Guest are viewing this topic.
Offline Verbatim

Junior Newbie




Java games rock!


« Posted 2004-03-01 14:22:22 »

Does Java use hardware acceleration when drawing if it is available? If it doesn't normally, are there ways of accessing it?

I'd love to program my games in Java, and I think I can handle the slowdown of about 50% that Java is supposed to have vs. C++, in exchange for its being so much easier to code in and so much more portable...but if accellerated blending isn't available, that means a lot more than just 50% slowdown.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #1 - Posted 2004-03-01 15:10:32 »

It does on Windows in 1.4, and Linux in 1.5, and Mac in 1.3 but not 1.4...
All of this is behind the scenes.  The runtime will try to manage the images for you and do the right think most of the time.  In 1.4 it will do this as long as you make sure your image is a 'compatible' image.  Eg. after loading stamp the image into an image created with createCompatibleImage();

Quote
I think I can handle the slowdown of about 50% that Java is supposed to have vs. C++, in exchange for its being so much easier to code in and so much more portable...but if accellerated blending isn't available, that means a lot more than just 50% slowdown.


The slowdown in raw code is not near 50%.. depending on what you do and how you do it, the speed of Java code execution is generally on par with C. As you have guessed it is usually other limitations - such as the ability to accelerate images with hardware that make the difference for games.  software blits in Java will be slower than in C.. because of the Java safety checks like array bounds checking, inability to exploit pointer tricks, etc..  Also any sane software blit should be done with MMX/SSE/SSE2 or Altivec instructions, but I doubt the any current Java runtime does this.

Online princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2004-03-01 17:30:08 »

Scott is a hopeless optimist about performance Smiley Reckon on 50% being a good baseline for typical performance. Also reckon on hardware acceleration being a little primitive. If you want performance, stability, cross-platformity and reliability try LWJGL Smiley Tiny payload, mucho speedo.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #3 - Posted 2004-03-01 17:58:17 »

Quote
.but if accellerated blending isn't available, that means a lot more than just 50% slowdown.

It isn't. Or rather, it might be, if you just happen to be running the right combination of VM, OS, hardware and command line flags. But don't count on it.

Use LWJGL and be happy Smiley

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #4 - Posted 2004-03-01 22:59:32 »

Quote
Scott is a hopeless optimist about performance Smiley Reckon on 50% being a good baseline for typical performance.

Smiley  Well I'm serious about 50% being too low... I haven't seen many examples that go down as far as 50%.  Usually only special cases perform that bad.   It's been my experience that the graphics are the biggest factor.

No arguments about using an OpenGL binding to get past the graphics slowdowns though.  Keeping all the graphics bits just right so that the JRE acceleration works for you is a pain, and I don't claim that you can always get the speed you need just by making sure your images are accelerated by the JRE.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #5 - Posted 2004-03-02 01:51:25 »

Quote
Also any sane software blit should be done with MMX/SSE/SSE2 or Altivec instructions, but I doubt the any current Java runtime does this.


Not that it helps, but we do use VIS instructions on sparc.
Online princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2004-03-02 07:07:35 »

You see now the need for a SIMD instruction generator in the JVM now Wink ? Wrap the four major SIMD instruction sets up (MMX, SSE, SSE2, Altivec) and execute directly on a DirectByteBuffer.

Cas Smiley

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #7 - Posted 2004-03-02 10:08:14 »

Quote
Not that it helps, but we do use VIS instructions on sparc.


Heh, do you guys still do a Sparc JVM then? Tongue Grin

Hellomynameis Charlie Dobbie.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #8 - Posted 2004-03-02 11:57:35 »

Yeah, I doubt much blitting is happening on a Sparc server.  At least compared to games running on Intel or PPC.

I've whined about this to Sun on more than one occasion. The JPEG encode/decode should be done with tuned MMX/SSE/SSE2 instructions - you can get libraries from Intel for free* that already adapt to the processor and contain highly tuned code for this stuff.

http://developer.intel.com/software/products/perflib/ijl/

Basically the idea is that the if you have decided to go to native code for key pieces of the JRE (JPEG codec), then at least have a native implementation that doesn't suck (*cough* current Java JPEG codec *cough*) and is orders of magnitude slower than it could be if done properly.

For something like blitting in general it is never possible to make it 'fast enough' the best you can get is 'as fast as is possible'.

Offline Jeff

JGO Coder




Got any cats?


« Reply #9 - Posted 2004-03-03 02:48:55 »

Quote
Scott is a hopeless optimist about performance Smiley Reckon on 50% being a good baseline for typical performance.


PC is a hopeless pessimist. Reckon on 90%+ if you are willing to properly tune your code and aren't doing things thatbvery specifically hit Java's weakest areas.

(IE if you absolutely HAVE to psend 90% of your processing time doing array buble sorts then I'd buy 50%).

Isnt it nice how we all have our opinions? AND we all have data to back it up.  Smiley   In particular, I'd guess Cas's experience probably has a LOT to do with arrays as he's a 3D juggler.   My expreience has to do with a sort of average of a braod range of problems because I spent about 2 years on the JDK tuning team doing both JDK APis and outside customers' code.

In the end, give it a chance, learn how to do Java right and tune Java right, and then you TOO will have an opinion Wink


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #10 - Posted 2004-03-03 02:52:35 »

Quote
Basically the idea is that the if you have decided to go to native code for key pieces of the JRE (JPEG codec), then at least have a native implementation that doesn't suck (*cough* current Java JPEG codec *cough*) and is orders of magnitude slower than it could be if done properly.
.


Question, can't you plug-in your own codec into the imageio framework? I bet if you did an example that was lots faster and justa s high quality as the one in the JDK and sent it in to thsoe guys it woudl geta lot of attention....



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #11 - Posted 2004-03-03 03:59:56 »

.. or, you can use the jpeg imageio codec from JAI, it's highly optimized native code, as I understand. See if it helps.


Online princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2004-03-03 07:04:29 »

You can get 90-100% of C++ speed using the server VM Smiley Trouble is, no-one has it - and the client VM is typically around 50% across the board of a like-for-like real world C++ application with no other obvious bottlenecks.

Jeff, please please please start nagging those VM guys to merge the VMs!

Cas Smiley

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #13 - Posted 2004-03-03 11:39:43 »

Quote
.. or, you can use the jpeg imageio codec from JAI, it's highly optimized native code, as I understand. See if it helps.

[rant]Could someone explain why Sun has more than one JPEG codec?[/rant]

I can't use ImageIO in my application because:
A) It has a memory leak if I reuse the image reader
(fixed in Tiger yay!: http://developer.java.sun.com/developer/bugParade/bugs/4868479.html)
B) If I don't reuse the image reader OR I call certain reset methods that work around the leak, it's performance plummets and it generates massive garbage. (See workarounds and evaluation for above bug)

That has forced me to go back to the awt toolkit image loader with it's abysmal performance.

[rant]Here we complain about JRE size, and it is full of this bloat, with redundant implementations of image loaders. Replace the old loaders with calls to ImageIO behind the scenes.. maybe then the ImageIO bugs will be important enough to fix and everyone will be happy!  Maybe this has been done for Tiger?[/rant]

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #14 - Posted 2004-03-04 02:03:33 »

Quote
Replace the old loaders with calls to ImageIO behind the scenes.. maybe then the ImageIO bugs will be important enough to fix and everyone will be happy!  Maybe this has been done for Tiger?


Funny you should say that.
It was attempted to be done for tiger, but, unfortunately, we found that
 - it's not easy due to asynchronous nature of toolkit image loading implementation (try doing animated images in imageio correctly)
 - it was slower, both footprint and startup time increased

So, due to the time constrants we had to abandon this idea for tiger, and instead clean up imageio implementation first and try again in the future release..
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #15 - Posted 2004-03-04 02:50:20 »

Yes, I can see that it might matter for a huge animated GIF, but I bet it would solve more problems than it caused if image loading was simply not asynchronous.  It should never have been asynchronous in the first place really.  The few that want it that way could start their own thread and managed it in their code.  Then for the majority they could avoid all the pain with media trackers, etc.
Thanks for trying though Smiley
It is nice to see ImageIO cleaned up.

Offline Verbatim

Junior Newbie




Java games rock!


« Reply #16 - Posted 2004-03-04 18:38:25 »

Thanks for all the info...I'll take it I can expect a Java program to run somewhere between 90% and 50% of the speed of C++, and I'll be sure to get the latest version of LWJGL when I'm ready to get started coding...I still have a fair bit to learn before I'll really be ready to take on coding my side-scroller, but it's good to hear I'll be able to write a game with little noticable slowdown outside of the attrocious loading time everything Java seems to have...I may actually be able to use what I'm learning, rather than just using it as a stepping-stone to C++.

Of course, it's possible the horrible loading times I'm getting is because Eclipse is so bloated...bloated with truly useful features, but still bloated...whatever the cause, it sometimes takes two minutes for one of my console programs to start running...once it runs, it finishes instantly, but it's a pain to wait two whole minutes while the VM loads.
Offline rreyelts

Junior Member




There is nothing Nu under the sun


« Reply #17 - Posted 2004-03-04 19:09:09 »

Quote
it sometimes takes two minutes for one of my console programs to start running...

Something is broken on your machine. I load entire application servers (i.e. Weblogic) in less than 60 seconds.

God bless,
-Toby Reyelts

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Online princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2004-03-05 06:56:36 »

Probably not broken... Eclipse is very big... and it might be configured to refresh and rebuild the workspace on startup too.

Hey, by the way, loading time in 1.5 is really much, much faster than 1.4 now! I'm very pleased to see progress in this area. There's also a 10mb saving per VM instance Smiley

Cas Smiley

Offline Jeff

JGO Coder




Got any cats?


« Reply #19 - Posted 2004-03-05 07:28:24 »

Likely Eclipse is eating all your memory and youa re swapping trying to run your app.

Swapping in general really hurts Java performance and it absolutely kills it dead under Winblows.

A hint, watch for that tell tale red drive light.  If its glowing like a stop light then you are likely swapping.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #20 - Posted 2004-03-06 04:22:26 »

Quote
Yes, I can see that it might matter for a huge animated GIF, but I bet it would solve more problems than it caused if image loading was simply not asynchronous.


Those apis were developed a long, long time ago (in a galaxy far, far away).

Also, there are advantages to async image loading, for cases when you load your images from a url on a remote server - you don't want your call blocked. Or, imagine some service which generates gif frames (like a streaming movie). A sync call will never be complete.

So, obviously, for backward compatibility reasons, the imageio based implementation will have to be async.

Then, there's my favorite ImageProducer/Consumer stuff. Don't get me started..

But I agree, I'd very much like to see toolkit image loading to be implemented on top of imageio. For one, it'll support more image formats, less code to support, etc.

Online Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #21 - Posted 2004-03-06 09:10:40 »

Are the 2 always going to be seperate though?

I realy don't see the logic in having Image loading methods in java.awt.Toolkit, javax.imageio.ImageIO, java.awt.Component, etc etc etc etc.

Why not have a class that encapsulates all 'loading of Images from datasource', rather than half a dozen methods, liberally spread among totally unrelated classes across the entire AWT :-/
At the moment, the API looks like Images in AWT were an afterthought :-/

Quote

Those apis were developed a long, long time ago (in a galaxy far, far away).

ah the confession Tongue
AWT was designed by chimps, who were miles-away at the time.

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

Senior Member




If only I knew what I'm talking about!


« Reply #22 - Posted 2004-03-06 17:25:32 »

Quote
I realy don't see the logic in having Image loading methods in java.awt.Toolkit, javax.imageio.ImageIO, java.awt.Component, etc etc etc etc.


Neither do I, but we can't remove Toolkit/Component ones for obvious compatibility reasons. All we can do is implement them using imageio, and encourage people to use imageio directly..

Online Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #23 - Posted 2004-03-07 07:05:15 »

Quote


Neither do I, but we can't remove Toolkit/Component ones for obvious compatibility reasons. All we can do is implement them using imageio, and encourage people to use imageio directly..



I'd be great to see them deprecated in 1.5.....1.6 :p

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

Senior Member




Giving Java a second chance after ludumdare fiasco


« Reply #24 - Posted 2004-03-07 12:41:40 »

Quote
Swapping in general really hurts Java performance and it absolutely kills it dead under Winblows.


Grin When I first read that I thought it was a typo,  but Jeff isn't usually that far off, he usually has the correct letters but in the wrong order....
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 (20 views)
2014-09-12 09:08:26

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

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

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

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

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

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

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

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

mitcheeb (36 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!