need unbiased help on library choice

General Discussions
#1

Hi everyone,

I am new to Java Game Development, though not new to Java at all.

At the moment I am diving into Game Development with Java (and…which is the best thing about it: for pure fun!).

A friend of mine is a pro Graphics Designer and we decided to take it slow and try to design a simple 2D game first.

I am convinced this shouldn’t prove too hard at all - because I bought a terrific book about game Development by David Brackeen… think many of you might know it.

However,

when we did a first brainstorming about what we could need in order to start a 3D Game later sometime this year I started research and am quite confused by now.

I had read about Java3D (I tend to read a lot before I start doing things) and was sort of concerned when I read about all this Java3DIsDead type of stuff.

This seems not to be the case anymore, but in the course of my search I stumbled over Xith3D, LWJGL and JME.

So, finally, here are my questions:

  • which of the above mentioned is the most advanced library in terms of features ?

(e.g. the JME feature list seemed a little more comprehensive to me than the Xith3D one…but i’m a noob, so…)

  • which library is the most advanced in terms of stability?

  • why should you not attempt to develop your 3D game with Java3D (using OpenGL) and e.g. odejava?

(some of the libs seem to bring their own physics library along which complicates comparison)

  • Does any of the pure gamingLibs (Xith3D,LWJGL,JME) focus on a special type of game?

  • is LWJGL the only one with built-in support for controllers and GUIs?

(seemed to be two critical points)

  • Generally (nonJava) speaking: what is DirectX 9.x capable of in contrast to OpenGL? Are there any feature differences at all?

I hope there are some unbiased experts out there (it sounds contradictory now i write it down…) ;).

Hope I did not ask something that was asked here before.

I read this forums quite a lot before I started to post (I told you i read a lot before I actually do things…)

Of course, in the end, learning one scenegraph helps with learning other scenegraphs later on, but I need to make a decision anyway.

thanks folks

Murat Kayi

P.S.: oh, and I did not include JOGL because I am not a low level lover. I avoid these things as long as possible…

#2

[quote]Hi everyone,
I am new to Java Game Development, though not new to Java at all.
At the moment I am diving into Game Development with Java (and…which is the best thing about it: for pure fun!).
A friend of mine is a pro Graphics Designer and we decided to take it slow and try to design a simple 2D game first.
[/quote]
It’s simple to do a basic frame for that. I didn’t knew anything about input in Java, but it took me just 3 hours to make it, then another 4 hours to polish it and make more versions for testing purposes. (It’s simple even with just a documentation for the standard library)

Xith3D is working on top of the JOGL, or LWJGL. So it depends on your definition of advanced.
Invader Zim anyone?

Java3D was scenegraph that was supposed to be used for visualization of a 3D scenes, not someting heavily optimalized for games.
Java3D hides a lot from you, and it doesn’t support AFIAK vertex/pixel shaders.

So first at all.
Java3D and Xith3D are scenegraphs, not a game libraries (in a meaning “standard library”).
JOGL and LWJGL are libraries for connecting a game to OpenGL and direct fast talking with GFX hardware, prefferably batched to simplify in drivers optimalizations.
JOGL doesn’t have a input API, because it was designed as a pure OpenGL binding library. Sound API that is supposed to be used with JOGL, or any other library, is called JOAL, input JInput.
LWJGL was designed to have all of this in one place so it has not only API for OpenGL, but also for input, sound, and has a timer inside.
Other timers are:
Timer in Java1.5.0+ (Java5.0 in Linux naming convention.).
GAGE timer.
[/quote]

As someone that attempted to write a library for connection to DirectX in assembly for input, I could tell you: It’s a shit.
Mickerosoft is crazy they designed it this way and people that worked with it longer are saying that 5.0 was a big improvement from previous, and that 9.0 isn’t as bad as 5.0. But I dislike DirectX 10. So if they would add that ugly features it could be nasty to work with.
Also OpenGL is better backward compatible.
As for feature differences. DirectX has poor support on Linux, and don’t forget on MAC.
Some games use OpenGL for graphic, and DirectX for sound and input, so you could use both.

[quote]oh, and I did not include JOGL because I am not a low level lover. I avoid these things as long as possible…
[/quote]
This make me laught. You included LWJGL, but thinks JOGL is too much low level.
If you’d like to learn a 3D programming you’d need to learn how it would look inside of a GFX card, and its pipeline. You might also need to learn a lot of 3D math
You’d also need a 3D modeling program, models, textures, loaders for output of the modeling program, GIMP, Buzz, brain, and a reasonable GFX card.

#3

You seem to have forgotten a comparison on jME there Raghar :wink:

jME is a game API, so its centred on gaming essentially. Then visualisation next (i know a few people doing that actually).

Personally, I am the lead developer in a project to get physics to jme; hence, my advice here is probably biased.

jME is very feature rich, from a particle system to cloth to renderqueues (you will know how valuable these become when you start programming in 3d!) to sound (OpenAL) to Input to Camera Controls to Model Loaders and Joints.

There is also a crude Entity class too, so you can definetly start making games start away.

JOGL is the same as LWJGL, they both are bindings to OpenGL. LWJGL tends to be more stable with the whole nVidia/ATI thing, but it seems that JOGL have fixed that issue now, not sure.

I guess the best thing to do is make a little hello world application (model loading perhaps?) in each different API (Java3D, Jme and Xith) and see which you feel more comfortable with…

Thats as unbiased as i can be really :-/

DP

#4

I disagree with your view of Xith3D.

Java3D is primarily used for scientific visualisation, although there have been some excellent games created with it. It supports multi-threaded access to the scenegrpah data structures (this comes with a hefty performance penalty). It was a very well designed scenegraph but its performance was not really up to scratch for games.

Xith3D uses some of the excellent scenegraph design ideas from Java3D but was engineered expressly with games in mind. It does not support multi-threaded access to the scenegraph data and has various other improvements. One of Xith3D’s important features is abstraction from the underlying rendering API. Not only can you can pick between JOGL and LWJGL for your project, but if either of those API’s were to cease development you would be safe.

Xith3D is a game library.

Cheers,

Will (a Xith3D developer)

#5

Hi and thanks for the answers first of all…

[quote]This make me laught. You included LWJGL, but thinks JOGL is too much low level.
[/quote]
Well, i did not realize LWJGL is on the same level as JOGL.
Avoiding Lowlevel stems from my dislike of inventing existing technologies. In the book I bought, 3d is handled by creating a (naturally slow) software 3D renderer from scratch, explaining all the 3D basics along the way.

That’s fascinating and will help me understand any lib that deals with 3D… so it’s the most natural thing to look for a lib that does not bother me with things other people already found solutions for.

[quote]If you’d like to learn a 3D programming you’d need to learn how it would look inside of a GFX card, and its pipeline. You might also need to learn a lot of 3D math
[/quote]
Thats what i will be doing (see above), but I would prefer a clean comprehensive highlevel api once i grasped the idea behind 3D rendering.

[quote]You’d also need a 3D modeling program, models, textures, loaders for output of the modeling program, GIMP, Buzz, brain, and a reasonable GFX card.
[/quote]
yep. Well, I’ve got Blender, Gimp, a good video card and my friends reassure me that there might be some brain somewhere within me.
But I learn these Things merely in order to be able to understand what this friend of mine (who is going to be the one doing graphic ressources like textures, models) is actually doing and what I need to implement. (he uses 3dsMax, though…)

My art skills are non-existant…

sounds like an excellent idea :smiley:

-Is this true for JME also?

there’s one other thing I forgot to ask:

this friend of mine is rather fond of cartoon atmosphere. He told me he was creating cartoon effects with cellshading.

  • is cellshading achieved through a sort of discrete shading in the lighting of a scene?

  • do the models have to carry certain features when loading them into a scene?

  • I saw an example of a cellshaded model (I think it was on the JME site, but don’t chop my head off in case it wasn’t). Is that kind of rendering done “manually” or is it an OpenGL feature? I don’t need an in depth explanation… I just want to know if it could influence my choice - as an art-idiot I want to keep my Graphic-Hero happy…

thanks so far for all the input.

#6

jMe only uses LWJGL to the best of my knowledge.

Java Cool Dude ported the NeHe cell shading demo to Xith3D. His demo is listed here http://xith.org/demo/JavaCoolDude.php along with a bunch of other neat stuff he created.

The source for that demo is here: http://users.xith.org/JavaCoolDude/showsrc/celshading.php he created a thread with info about his demos here: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1071038323

Cheers,

Will.

#7

Hi ,

again, I’d like to say thank you, cause your input made me understand that my way of regarding this topic as a matter of “either…/or…” was sort of shortsighted. (“omg, which library is the right one?”, like in a quiz show :P)

I did not even realize there’s more (LWJGL) than one(JOGL) way to “connect” to the OpenGL library.

Also, by the way the various scenegraph APIs have common features and make use of both low-level APIs, I can tell now it’s not a choice which by all means will last “forever”.

So, I will definitely try the “getting Started”-examples provided with each lib and go on from there (except of Java3D which seems to be lagging behind at the moment - but they have roadmap for a major revision, don’t they?)

To put it in a nutshell:

It’s good to know that I can tell my friend to not worry about features or technology (he kept bugging me about “you sure it’s possible to do xyz in Java?”).

til soon (really, i tend to ask as much as I read, lol)

Murat Kayi

#8

LWJGL is a step ahead of JOGL in that it also incorporates OpenAL, FMOD (optional), and DevIL (optional) and in input layer in an easy to use package. LWJGL also has its own superlightweight context management which you can use to entirely bypass AWT if you wish.

LWJGL no longer has controller support as the code we had was not crossplatform, so we ditched it. Sorry :frowning:

Cas :slight_smile:

#9

[quote]has its own superlightweight context management which you can use to entirely bypass AWT if you wish.
[/quote]
thats the part which is important for non3D GUIs in the foreground, isn’t it (cause at least Java3D uses an AWT component to display the scene which makes lightweight GUI components on top of that hard)?

[quote]LWJGL no longer has controller support
[/quote]
Standalone Input APIs I know of are JInput and JXInput - any others you would hint at?

#10

Methinks Cas means ‘superlightweight’ as in ‘tiny and easy’ rather than the more techincal Swing term ‘lightweight’. None of the 3D libs actually support lightweight 3d components*

This is actually less of an issue than you first expect. Tool-tips and JMenus have a flag to force them to be heavyweight, and most other controls don’t needs to overlap. The only problematic component is the split panes, but I don’t really see much use for them in this context.

If you really want GUI widgets over a 3d display, the Spaghetti library does totally OpenGL rendered widgets, and I belive Xith3D has some fancy rendering of swing controls onto a 3d texture.

*Cavet: Jogl has a lightweight GL component, but because of the hoops it has to jump though to make it work, its so slow to be totally impractical.

#11

Incidentally, are there any plans to bring back LWJGL input before v1.0? JInput is horrible to work with, and I’m unsure as to how reliable it is.

#12

[quote]If you really want GUI widgets over a 3d display
[/quote]
well right now it’s just a matter of becoming aware of possible problems - but most 3dGames use some sort of 2Dlayer for a GUI, so…

[quote], the Spaghetti library does totally OpenGL rendered widgets,
[/quote]
erm…what? :ospaghetti? as in pasta? ???

[quote] and I belive Xith3D has some fancy rendering of swing controls onto a 3d texture.
[/quote]
some of the posts over in the xith3d forum say it’s not working as they would like it to…

#13

The library is abstracted away from the renderer. Currently the “official” library is LWJGL, but Badmi from the jme camp (not a developer, but a user) has managed to create a JOGL binding to it too.

So really, both are available, but only LWJGL is currently supported.

DP

#14

Yes, but usually the regular AWT/Swing look and feel is totally inappropriate for a game, and you usually only need some very simple controls (buttons, maybe checkboxes, maybe lists). Its often easier just to do a really simple GUI with your own look and feel.

[quote]erm…what? :ospaghetti? as in pasta? ???
[/quote]
Spaghetti is a GUI library for LWJGL written by Cas. I’ve been (ab)using it for a while now, mainly for tools stuff but also for in-game menus. Its perpetually in a state of flux though, as I keep tweeking and adding to it, and I think Cas just uses hardcoded stuff now.

#15

[quote]erm…what? :ospaghetti? as in pasta? ???
[/quote]
I think it originally was as in spaghetti code :smiley: Also goes under SPGL.
http://www.puppygames.net/forums/viewforum.php?f=7&sid=a30b0aa4e70e35c783f091310b4f3d0c


I think it is a UI-tool for games (+more helper/high level stuff. Have not used it, just know about it) Think v2 is on its way. Cas will tell you exactly what it is.

Very good Qs. I was about to ask roughly the same things, but didn’t have to :slight_smile: Really great info, but I still have no clue to what lib to use. I am leaning towards jME or xith3D, since I don’t want to reinvent the wheel. They seem to be the highest level game libs with performance.

Does anyone know how they compare performancewise?

And are there any full games that have used these libs?

I saw Marble fun and Dirt in the GDC demo clip, but cant find the games anywhere :frowning:

#16

I didn’t forget to mention a jME. I simply didn’t like to talk about things that I never used. I also thought that a jME developer could be somewhere on this board and will add its comments.

Re William Denniss

Note I said in a standard library meaning. Xith3D is simply library build around a scenegraph that is providing an abstraction from undelying API, and has a few additional support packages around.

It lacks map class, a primitive linked list implementation, Mersene Twister (I like that BSD implementation / conversion from Kent Paul Dolan.), that nasty library for data conversion that I worked on for 3 months, DCT, image filters, support for Ogg Vorbis conversions (At least support for Vorbis, ogg support isn’t really needed.), I didn’t seen a patchfinding classes like A* and DASH, classes for conversion between different packed formats…

BTW does it support a multithreaded reading from scenegraph, or is it strictly access it just from one thread implementation?

#17

Raghar,

We must be on different wavelengths or something, Xith3D is a lot more than simply an abstract way to access OpenGL! The abstraction from the rendering API is but one feature. Personally I think Xith3D is quite well set up for games. There is sound support (Ogg Vorbis), a whole bunch of model loaders, texture loaders, physics (though Odejava), XML serialization, HUD support, SkyBox’s, primitive objects and the list goes on.

There is no synchronization at all, so it isn’t supported (although there is nothing to physically stop you…). Writing to the scenegraph while rendering is not recommended and some checks are in place to prevent this (but, like with Iterators you can’t rely on these checks – best just to keep the scenegraph writing code in the same thread as the rendering).

But, this is a good thing! By not supporting multi-threaded access and access while rendering, we gain a cleaner and much faster API. If you need these things then Java3D is probably what you are looking for.

Xith3D took this approach as most games are single threaded (ignoring any input/network threads) anyway, so there is no need for the overhead that multi-threaded support brings.

If you need more info on Xith3D:
Xith3D java.net project homepage: https://xith3d.dev.java.net/
Xith3D community site (with webstartable demos): http://xith.org/

Cheers,

Will.

#18

Hi there,

[quote]physics (though Odejava),
[/quote]
I have seen some quite impressive examples of odejava in action. I wonder why you say “though” - is that some kind of disadvantage?

Also, does anyone know why JME is trying to include a homegrown binding to odejava (not even the native ODE AFAIK)? Is it sort of hard to use odejava in a modular or objectoriented way?

[quote]…HUD support,
[/quote]
Does this do the job when talking about non-opaque 2D components in the forreground? Or does this provide for 3D objects in the foreground which are independant of camera movement (say, e.g, a hand with a pistol like in every FPS)

#19

Typo, he meant “through”.

Cas :slight_smile:

#20

Please note that the physics in jme are NOT part of the core. They jme-physics is a completely side project aiming at bringing jme and odejava together.

The reason we include homegrown odejava is because we needed to remove all dependancies on vecmath and log4j as jme already has its own implementations of them. By doing so, we managed to shave off 500Kb of the distribution. The conversion from vecmath and log4j is very trivial (took me and per around 10 minutes to upgrade to the latest current odejava).

And yes, we are using the default natives for odejava.

Odejava’s design is useable, but we are adding another layer ontop of odejava to make it easier for people who use jme to automagically get physics:


DynamicPhysicsObject obj = new DynamicPhysicsObject(someSpatial, 100);
PhysicsWorld.getInstance().addPhysicsObject(obj);

And your done. There is alot of stuff going on behind the scenes to make this as easy as that. I.e if the spatial is a trimesh and its dynamic, we have to approxmiate it using the BoundingVolume of that trimesh. If its a node (we, we have to build a CompoundObject out of that node.

We also have a Vehicle class, make vehicles which corner properly and such very simply. This feature, odejava doesn’t provide.

Also, coming soon to jME-Physics is a physical particle system. Whereby a high density particle system (like a jet of steam) can add forces onto dynamic physics objects. This feature odejava doesn’t provide.

Ragdolls (coming soon too) and the list goes on and on!

Hope this makes things clearer for you.

DP