Viability of Java For Video Games

Started by
17 comments, last by NewBreed117 10 years, 4 months ago

Is Java viable for graphic intensive video games. More specifically could I recreate a game like Halo or Call of Duty where you need to have quick

input and output? Thanks in advance to your answers smile.png

Advertisement


Is Java viable for graphic intensive video games.

Yes.


More specifically could I recreate a game like Halo or Call of Duty

Doubt it. (Not that that has nothing to do with Java)


where you need to have quick input and output?

Yes.

Is Java viable for graphic intensive video games. More specifically could I recreate a game like Halo or Call of Duty where you need to have quick

input and output? Thanks in advance to your answers smile.png

The language choice is mostly irrelevant on the PC, especially if you aim to create something similar to old games like Halo or CoD (a modern PC is significantly faster than the previous console generation and even the current generation (PS4/XBOne), Graphics are primarily handled by the GPU and most of the fancy special effects will be written using GLSL or HLSL regardless of what language you use for your game logic.

That said however, Java has quite many issues that you will have to work around(The Java standard library is pretty awful for games so you will have to rely on third party libraries quite a lot) and it doesn't really provide any tools for fine tuning the lower level details nor is it expressive enough to make it easy for the VM to optimize things for you (You pretty much have to choose between high performance with a slow startup(server VM) or far from optimal performance and fast startup(client VM), i'd highly recommend going with C# instead. (its very similar but provides a saner way to interface with native code if it becomes necessary)

[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
It's viable but a lot of things are "viable" doesn't mean its a good idea. Notably C# has every advantage over Java when it comes to games(well, most things.) The language only matters depending on what you're doing, it's pretty rare to be making a game that say, has to be fancy enough to -require- a language like C++.


The Java standard library is pretty awful for games so you will have to rely on third party libraries quite a lot
What do you mean with that?

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

The Java standard library is pretty awful for games so you will have to rely on third party libraries quite a lot

What do you mean with that?
The built-in Java libraries for graphics are based on the lowest common denominator. They were written with completeness and portability in mind. They were not designed around hardware acceleration.

Even when they do take advantage of it, the results are very inconsistent. It is well documented that graphics performance can dramatically change mid-execution. In one of many well-known examples, simply calling drawImage() with a BufferedImage can use DirectDraw for blitting giving you an incredible framerate, but then after resizing or even moving the window Java may suddenly decide to switch to CPU based rendering dropping you to just five or ten frames per second. There is no notice given to your app, just suddenly there is a performance drop as it switches to CPU-based rendering.

That may be fine for a turn-based game that isn't animated. If your Chess game drops to 5 frames per second nobody will care.

High performance games that use Java tend to use JOGL (Java OpenGL wrapper) or similar libraries that provide access to proper hardware acceleration.

Ohh I see, I asked because "Java for games" in my mind is Java + LWJGL, not Java2D precisely. By "standard libraries" I thought he was referring to the usual collections, networking, threading, and so on.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

Ohh I see, I asked because "Java for games" in my mind is Java + LWJGL, not Java2D precisely. By "standard libraries" I thought he was referring to the usual collections, networking, threading, and so on.

networking, threading, etc are included in the java standard library, LWJGL and JOGL are not. (They are third party wrappers around native, platform specific libraries).

Neither LWJGL nor JOGL are really optimal choices due to the JNI overhead (a proper engine will allow you to minimize the number of calls made through the JNI) but they are still significantly better than the Graphics classes provided by Java.

[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!


networking, threading, etc are included in the java standard library, LWJGL and JOGL are not. (They are third party wrappers around native, platform specific libraries).

But then OpenGL and DirectX are not part of the C++ standard library either and are also third party wrappers around native platform specific code.

I get what you are saying about the JNI overhead but then this isn't really a performance bottleneck that would prevent somebody writing a game like HALO or COD which are several years old and when released ran on much slower PCs than the average budget Dell that somebody can buy nowadays.

I have some experience of using Java / OpenGL for Android development. It was fast enough but since the Java garbage collector does not extend to the graphics card buffers, I found it to be really fiddly to manage the memory manually.

C++ has RAII for memory management which works great with vertex buffers, textures etc.. whereas I found the Java code needed to be spammed with try catches. Java was not great here.

All in all, I suggest that unless you know that you have all the Java wrappers required to do your project, Java is fine. If you feel you may need to wrap native libraries, not only will you need to write the native side of the Jni layer in C/C++ anyway but you will be spending time writing bindings rather than games.

I recommend Java shim and the rest in C++ any day of the week smile.png
http://tinyurl.com/shewonyay - Thanks so much for those who voted on my GF's Competition Cosplay Entry for Cosplayzine. She won! I owe you all beers :)

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.

This topic is closed to new replies.

Advertisement