Which API/Engine to use for what, strength weaknesses, ease of use, speed?

Newbie & Debugging Questions
#1

Could somebody help me figure out which API/Engine to use for developing java games:

Q1. Which one is good for what kind of game 2d or 3d?
Q2. What is its respective strengths and weaknesses
Q3. Is it easier/more difficult to use compared to the other API/Engines ?
Q4. Is it speedier/slower compared to the other API/Engines?
Q5. Is the API/Engine aimed for a special platform, eg MobilePhone/PC/Gaming Devices like PSP etc ?
Q6. Is the API/Engine commonly used, so there is easy to get support/advice from forums etc ?
Q7. What kind of license does the API/Engine have if any ?
Q8. Does the API/Engine have support for networked GamePlay ?
Q9. Does the API/Engine have support for Open GL or Direct X ?
Q10. Which java versions does the API/Engine require and support ?
Q11. Which API/Engine have the best device input support ?
Q12. Which API/Engine has the best sound support?

I am sure there is lots of questions that I have forgotten to ask and will ask in the future,
but I hope these questions will at least point me in the right direction,
so I don’t spend a lot of time trying to use one API/Engine or
a combination of API/Engines and find me “limited” by the choosen API/Engines.

Kind regards
Erudite

#2

There is no binding to use DirectX through Java and DirectX doesn’t work fine under non-Windows OS. Therefore, I advice you to forget this possibility if you are interested in Java. Nevertheless, early updates of Java 1.6 use Direct3D pipelines under Windows.

#3

Thats a lot of questions :slight_smile:

I would recommend you look at Slick its a 2D game library and has a very nice api http://slick.cokeandcode.com/
It does hardware accelerated graphics through OpenGL and sound through OpenAL, works on all 3 major platforms (windows, linux, mac), has support for controllers through JInput.

for 3d games I’d recommend http://www.jmonkeyengine.com/

Both of the above are based on the LWJGL binding which you can have a look at if you need more direct access to the OpenGL and OpenAl api’s at http://www.lwjgl.org

most of the answers to your questions can be found through the doc’s on those sites.

#4

You could also do pretty much all those things without any API at all. Java on its own can do pretty much everything – it may not be the fastest way possible to do so, but it’s always fairly accessible and quite powerful.

#5

Thank you all, at least it gives me somethinging to look into.
/Erudite

#6

I disagree with you. For 3D games, it is absolutely necessary to use an API. My game used only Java in October 2006 and I got often… 1 FPS. Now, by using another Java binding of OpenGL called JOGL, I get between 8 and 400 FPS even without any spatial subdivision!!!

Not using an API for 3D games forces you to rewrite a software renderer. The only game I know that uses software rendering and that is quite fast is “ancient arenas” but I suspect that the author activated OpenGL through GL4J for the sequel of this game. Some engines like JPCT can give impressive results. Bloodridge uses JPCT as far as I know.

LWJGL is not the only Java binding for OpenGL. JInput is really required only if you want to handle something other than a keyboard and a mouse. LWJGL is interesting as a all-in-one solution as it includes a lot of very useful libraries and is independent of AWT which is fine if you wish to use a private VM whereas JOGL is only an OpenGL binding but extremely reliable, supported by Sun, that works under Solaris too (under some other Unix if you are patient and motivated) and that works good with Swing components. Personally, I don’t really need to use all the included libraries of LWJGL, I prefer using JOGL with JOGG and JORBIS. I hope what I wrote may help you.

#7

Well that’s definitely true, but I did mention that Java can do anything, just it won’t be the fastest way. Maybe I should have emphasized that it often crawls.

In 2D games I have made switching to OpenGL goes from 12 fps to over 150 in some cases.

#8

2D games are not a good example to show the increase of performance.

#9

Can you explain these two points a bit more? I don’t see any reason to be forced to use private JVM with LWJGL. I also don’t know about any reliability problems with LWJGL. And from what I read it was more reliable than JOGL with fullscreen support on linux for <1.6 JVMs.

EDIT: I’m sorry, it seems I misunderstood the meaning of your sentence.

#10

It’s true JOGL is not more reliable than LWJGL.

Without a dependency to AWT, you could ship your game with a private JVM without AWT (leaving out AWT saves a lot in download size). Distributing a game with a private JVM will make it practically immune to JVM compatibility problems.

#11

Remember that with Jogl if you want fullscreen you’re forced to use the standard library fullscreen-exclusive mode - which has, historically, been very buggy (especially if you want to change resolution) and poorly supported on non-windows platforms. LWJGL has built-in fullscreen support which means it actually works reliably (and if it fails it’ll fail with a nice catchable exception rather than an uncatchable seg-fault.

#12

Hmm, I’d be very interested to know how you can do that.

#13

Delete all the dlls one by one in the JVM until your game stops working. Then using Winzip or something, delete entire packages from rt.jar one by one until your game stops working, using -verbose:class on the commandline to see what classes it’s picking up. Then delete any other odds and sods lying around you think you won’t need, including java.exe etc, and make your own stub launcher that only runs your game. You can get the 1.4 VM down to about 2.5MB compressed using this technique. That worked for me for the last 5 years but now I’m shipping the entire 1.6 JVM with no mods in it because everyone with money and who wants to buy games generally has broadband and has to put up with everything else being massive anyway.

Cas :slight_smile: