Lwjgl - Lightweight Java Game Library - Suitable?

[thantik]

I'm not very active here as I started off as a VB6 coder back in my early teens but haven't really had anything to motivate me to program (or learn a GOOD language) for a long time - I'm very excited about the pandora so I've decided to get myself back in the groove and figured Java would be a good place to start due to how friendly it is for cross-platform development. (VB6 isn't my only experience, I also regularly used ASP, PHP, JavaScript as a web designer a few years back.) Unfortunately I've had some bit-rot in the brain and although I can *read* code now, I haven't kept up with any languages or the changes certain languages have incorporated.

I've been seeing a lot of the projects on here and they're all impressive, my personal goal is to make something that is cross platform - something that will work equally well on any system I would like to compile it on. Even if it's only a hello world program .

So I did some searching and ran across this library...lwjgl; Lightweight Java Game Library.

You can check it out at lwjgl.org and I would like some help in determining if this would be a suitable platform for the andora1 They have a lot of demos that are impressive and a lot of in-depth documentation with tutorials for developing with the library.

Since my main concern is cross-platform compatibility between architectures & operating systems, would something like this be compatible with Pandoras hardware on a performance-level or even compatibility level? The reason I ask is because I have no idea what OpenGL ES 1.1, or 2.0 supports or if this library would even be compatible with it but I don't want to spend the next 3 days learning about it only to find out that I've just wasted my time and have to chose another route.

From what I've gone over in the last few hours reading the tutorials - the language looks very familiar to me. I'm sure I'll have to go over java basics before I dive head-first but this seems to be the path of least resistance. I'm familiar enough with Linux that I can build a workable GUI from ArchLinux without reading the walk-through beginners book although I don't really have any real-world compiling experience other than make, make install, make uninstall.

If I get feedback from the community that this could be an "ok" path for pandora development, I'll probably get started on the reading and development of my first java hello world program and afterwards try to document available resources for building with this environment/language/library combo while I build a simple side-scroller space-ship shooter with powerups. (Old-school games ftw).

 

[Bonbon-Chan]

lwjgl is a OpenGL/OpenAL binding + jinput. Actually, it doesn't support OpenGL ES. I'm planning to make/help/beg for an OpenGL ES binding (when I get the hardward ).

I don't really know how the OpenGL ES will be done but I'm pretty sure that you will need to add an abstract layer to deal with OpenGL and OpenGL ES.

 

[skeezix]

"java is cross platform" is one of th biggest 'lies' around, imho.

Realy 'java' has nothing to do with it.. thats just a language, like C or python or anything else. Its the APIs that it allows for that are the real trick. (And to date, really only C is the most portable, but gets a bad rap.)

So as above, you're smart, checking for libs first .. the trick is to find out what your needs are, and what libs support those, and which of those candidate libs are actually portable.

Just because it is java doesn't make it portable, so you have ot be careful. Being java means the language itself is probably portable, but the rest of it is the question.

(ie: Java on RIM is different than Java on Android is diffeent than Java on cell phones and again different on smartphones, and different to desktops, and different to servers.. all because of different APIs, different garbage collection policies, etc.)

Sadly though I don't track thing slike this offhand so can' tbe of much positive help

Look for soethign that is not a lot of layers or dependancies, and does 'small scope' .. ie: if you need only basic 2d then don't look for a full blown fancy game engine or 3d system.. th emore it does, the less chance it'll be portable

(If this is overnegative, then I might be in a grumbly mood; don't take it that way.. java is probably a good choice for you, but you'll have to look for your libs carefully; java under linux is pickier than others, and being a handheld makes it doubly so)

jeff

 

[todd]

An interesting-looking library, indeed!

lwjgl is a OpenGL/OpenAL binding + jinput. Actually, it doesn't support OpenGL ES. I'm planning to make/help/beg for an OpenGL ES binding (when I get the hardward ).

I don't really know how the OpenGL ES will be done but I'm pretty sure that you will need to add an abstract layer to deal with OpenGL and OpenGL ES.

From the FAQ:
QUOTE
Q: Will LWJGL support OpenGL ES
A: OpenGL ES is basically a subset of OpenGL, and we will make the best efforts to get LWJGL running on a device. However we have yet to get our hands on one .


From the "about" page:
QUOTE
Just because there aren't any phones or consoles yet with fast enough JVMs and 3d acceleration is neither here nor there - there will be, one day. We're carefully tailoring the library so that when it happens we'll have OpenGL ES support in there just like that.


So they want to do it. I think they're describing exactly the Pandora in that paragraph! But they haven't yet implemented their intentions.

And in the paragraph above the one I just quoted:
QUOTE
Made the library throw an exception when hardware acceleration is not available on Windows. No point in running at 5fps is there?


They specify Windows. But it sounds like they have no interest in building in the capacity to degrade to software-drivers in the absence of OepnGL ES support. Hmmm....

Look for soethign that is not a lot of layers or dependancies, and does 'small scope' .. ie: if you need only basic 2d then don't look for a full blown fancy game engine or 3d system.. th emore it does, the less chance it'll be portable

Also from the "about" page:
QUOTE
Minimalism
This is another critical factor in our design decisions. If it doesn't need to be in the library, it's not in the library. Our original aim was to produce a library that provided the bare minimum required to access the hardware that Java couldn't access, and by and large we're sticking to this mantra. The vector math code in the LWJGL is looking mighty scared at the moment because it's probably for the chop - well, at least, from the core library - as it's not an enabling technology at all, and there are numerous more fully featured alternatives. We chucked out GLU because it's mostly irrelevant to game developers except for a few functions that we really need to get redeveloped in pure Java - but basically, GLU is just a library of code built on top of the enablement layer.


It sounds like this library is headed in a pretty positive direction. It could be just what we need (assuming there are no issues getting a good Angstrom JVM in the first place). But it sounds like it might be useless (or close to useless) for the Pandora until they obtain a device on which to develop for OpenGL ES.

I like your comments about "cross-platform" and the API's, Jeff. I've been thinking recently, as well, about how straight-up C is one of the most "cross-platform" languages around. We only get into trouble when we start calling out to libraries to do the cool stuff (like, I dunno, drawing pretty pictures on the screen or doing I/O apart from the terminal). And that, of course, is also what makes languages which can be "compiled" to C interesting.

--Todd

 

[thantik]

Well, from this library what I've seen from the demos and projects section is that it should be quite portable with a proper JVM - One of the more interesting projects to look at on their page is JMugen, I've already run it on my windows box, and they even have windows/java/mac osx libraries compiled and instructions on how to compile from source for all 3 platforms.

http://lwjgl.org/wiki/doku.php/lwjgl/tutorials/index

That URL is what impressed me the most - they seem to have a lot of documentation fleshed out (a lot more than some libraries I've seen) and it looks like they've taken the time to even document some simple game how-tos using the library.

Don't get me wrong - I know that C is cross platform too, but from my understanding Java is primarily reliant on the JVM running it, and with C you have to manage memory yourself, etc etc. Honestly I am more interested in the rapid-prototyping aspect of the library and the java language. I don't want to have to worry about things like endianness, memory management, memory leaks, and all of that. I just want to get back to the nitty-gritty of coding.

From what I understand even if it's just a regular OpenGL binding - can't you just limit yourself to the OpenGL ES subset and have it run fine? I've looked into the Angstrom Distro and seem to have found this:

http://www.angstrom-distribution.org/repo/?pkgname=jamvm

So it looks as if Angstrom already has a java interpreter; I just wonder if it's worth a shit performance-wise and how optimized it is for the ARM architecture. Another thing I noticed as well though is they use Apache ANT to compile these things (at least in the tutorial) - however in the angstrom distro I don't see the ant compiler so I figure before I can do anything useful on REAL hardware that will probably have to be cross-compiled for the ARM, unless there is another java compiler that I am unaware of or another route of compiling this library.

And another beauty of it is the license. Yeah take a look at that. Not many restrictions on it. I'll probably leave the source open anyhow. But just-in-case something I make gets popular I have options open to me. (for example if I were to port to the android g1/iPhone. I'll always leave my pandora stuff free and open.)

This particular library seems to have the backing of 2 online game companies who look like they are using the library for their games and I do have to admit after playing a couple they are very impressive performance-wise..

http://oddlabs.com/
http://puppygames.net/

My biggest concern honestly is performance. *SOME* of the commercial games by these companies take up 20% of my 2.8ghz P4 HT at times. They usually sit somewhere around 4%-8% though.

 

[todd]

Ant, I believe, runs in Java. If you have a reasonably compliant JVM, ant should be no problem.

This particular library seems to have the backing of 2 online game companies who look like they are using the library for their games and I do have to admit after playing a couple they are very impressive performance-wise..

Commercial software houses using the library is surely a great sign: they have a strong interest in maintaining and even improving the library. If that meant they could tout Pandora support in addition to the other platforms, so much the better for their sales!

gcc has a Java front-end. That would be fabulous if it was kept up-to-date.

--Todd

 

[cb88]

also... java and lightweight ... pfft yeah right

 

[Kramy]

also... java and lightweight ... pfft yeah right

Runs faster than SDL. :lol:

Now beat it, fanboy. (I call em where I see them)

lwjgl is an impressive library, but there are a few hurdles.
-Currently it's x86 only.
-It requires AWT to be running on the platform, so the JRE can't be headless.
-It needs to be ported to OpenGL ES 2.0.

As far as ARM + Java goes, there's another hurdle. JamVM is a full interpreter - a very fast one, but an interpreter none the less. For most of the benchmarks I've seen, it performs better than your average JIT compiler - but that isn't saying much, since it's still significantly slower than Sun's JVM.

In terms of performance, languages available on the pandora will go something like this:
C/C++ > C#(Mono) > Java > Python/other/etc.

Luckily much of the code running will be lwjgl stuff, which is compiled, so performance would likely be within 40% of C? :unsure:


ANT is for building JAR files. You have to have it set up on your dev machine. I just manually build the jars; ANT scripts look really complicated. :lol:


GCJ seems to be rather painful to work with - but if a proper toolchain is built, it should be doable. On the GP2X, GCJ wouldn't work - it didn't like mixing old kernel with new glibc, and if I remember right it didn't like whatever version of gcc the code::blocks project used.


ThantiK: CPU usage of a game is partly dependant upon the style of the game loop. Many games cap fps at your monitor's refresh rate (VSYNC), while others run 100% nomatter what. h34r: I do believe some systems get 2000+ fps on the original half-life.

The CPU usage of Java is very low on x86. The memory usage isn't - but considering what java has to beat(unoptimized C programs), that also shouldn't matter. The only place it loses is poor start times. The first time you run a java app after a reboot, expect a wait.

 

[thantik]

@Kramy - THANKS!

Glad to finally get a reply from someone who has seen this library before and has at least some background on why it would or wouldn't work. The reason I got behind this library is primarily because it looked like it kept coding small, not a lot of management the coder had to do, etc.

Think we'll get some sort of library that's specific to the Pandora with bindings for java or other languages? I honestly don't want to have to deal with memory management, worrying about all of that...like I said I originally started on VB6 and then only really worked with scripting languages past that point which required none of that kind of work on my end.

What would some of you developers suggest for hitting these points:
Performance on the Pandora (All I'm really looking for is 2D with object collision for non-rectangular sprites, and efficient use of the pandora's hardware)
Ease of Use/Simplicity (Not having to manage your own memory - garbage collection libs might be fine)
Cross-platform-compatibility (I regularly switch from windows, to linux, to mac which are all x86 but now I'm adding an ARM platform to my library...ugh! - What is it going to take to program once, COMPILE ONCE and run everywhere?)

That's why I'm really shying-away from C, C++ and C# - They're more of a Write-once, Compile for each architecture/OS your running on, debug, go back and write SPECIFIC code for each, then re-compile again for each OS and each platform. Java just seems to be the path of least resistance from a coding perspective. The problem now is finding libraries that are usable from that same point of view whilst still accomplishing what I need. I'm sure that same point is why so many people are just developing web-applications now; It's write once, use everywhere. Unfortunately games are a whole different ballgame.

 

[hdonk]

Your best bet is to look a jogl - it's an implentation of the official Java binding for OpenGL. Also it has been previously hacked to run against OpenGL ES 2.0. The interesting URLs are:

JSR 239: JavaTM Binding for the OpenGL® ES API
JSR 231: JavaTM Binding for the OpenGL® API
Jogl - User's Guide
and
Java on the NVidia APX 2500
- which indicates it would take about a week to get something working :rolleyes:

Each time I've started on a 3D Java applet, it's been a toss-up between Jogl and Lwjgl.

 

[todd]

Performance on the Pandora (All I'm really looking for is 2D with object collision for non-rectangular sprites, and efficient use of the pandora's hardware)
Ease of Use/Simplicity (Not having to manage your own memory - garbage collection libs might be fine)
Cross-platform-compatibility (I regularly switch from windows, to linux, to mac which are all x86 but now I'm adding an ARM platform to my library...ugh! - What is it going to take to program once, COMPILE ONCE and run everywhere?)

I'm no expert, but I really believe you have just described Python with Pygame. I betcha' it would be plenty sufficient for 2D sprites. But I could be wrong.

 

[Kramy]

@Kramy - THANKS!

Glad to finally get a reply from someone who has seen this library before and has at least some background on why it would or wouldn't work. The reason I got behind this library is primarily because it looked like it kept coding small, not a lot of management the coder had to do, etc.

I don't have a huge amount of experience with LWJGL - I know it requires more coding than just AWT/Java2D, but that seems to be the way things go. C/C++ have more coding too. I never really measured the performance differences. 60fps with Java2D, 60fps with lwjgl. But I did notice the screen tearing vanished, and apparently Java2D misbehaves on OSX, so that was another plus.

Think we'll get some sort of library that's specific to the Pandora with bindings for java or other languages? I honestly don't want to have to deal with memory management, worrying about all of that...like I said I originally started on VB6 and then only really worked with scripting languages past that point which required none of that kind of work on my end.

Doubt it - or at least, not right away. The closest we'll get is Mono, which someone had working on a dev board. I heard mono could in theory run/compile java bytecode? :unsure:

That's why I'm really shying-away from C, C++ and C# - They're more of a Write-once, Compile for each architecture/OS your running on, debug, go back and write SPECIFIC code for each, then re-compile again for each OS and each platform. Java just seems to be the path of least resistance from a coding perspective. The problem now is finding libraries that are usable from that same point of view whilst still accomplishing what I need. I'm sure that same point is why so many people are just developing web-applications now; It's write once, use everywhere. Unfortunately games are a whole different ballgame.

Unless you're brilliant, you'll have to compile, make changes, compile again, etc. etc.; no language is spared from this. :lol: I have done a few projects, and miraculously, they worked fine under Linux without any changes - but OSX was grumpy.

Your best bet is to look a jogl - it's an implentation of the official Java binding for OpenGL. Also it has been previously hacked to run against OpenGL ES 2.0. The interesting URLs are:

JSR 239: JavaTM Binding for the OpenGL® ES API
JSR 231: JavaTM Binding for the OpenGL® API
Jogl - User's Guide
and
Java on the NVidia APX 2500
- which indicates it would take about a week to get something working :rolleyes:

Each time I've started on a 3D Java applet, it's been a toss-up between Jogl and Lwjgl.


Yes, I mentioned in another thread that basic JOGL is probably the way to go...

A week from a skilled dev to port it to OGL ES? Would probably take a bit longer for someone that has no clue what they're doing.

Thanks for the links, though. More reading material.

 

[cb88]

FYI I am an anti-fanboy

I have programed in java and even the simplest programs become a blight of bloat

True I would prefer C/C++ but what else is new... if java ran in a 10mb or so runtime well that might be alright but it does't

 

[sindbad]

if java ran in a 10mb or so runtime well that might be alright but it does't
Python does

Seriously, give python and pygame a try. You will be surprised just how easy it is to program in and it'll work just fine on the pandora.

 

[Kramy]

FYI I am an anti-fanboy

I have programed in java and even the simplest programs become a blight of bloat

True I would prefer C/C++ but what else is new... if java ran in a 10mb or so runtime well that might be alright but it does't

What Platform + JRE? :lol:

I just ran a simple reminder program - it started at 6MB memory usage, and quickly went up to 14MB after using it for a while. Pagefile usage hovered around 30MB.

This is on Windows 2000 (x86/jre1.6u11); seems to me your requirement has already been met?

JamVM is pretty light on memory usage. I've never benched it, but being fully interpreted, it doesn't have to store multiple copies of code.

 

[thantik]

if java ran in a 10mb or so runtime well that might be alright but it does't
Python does

Seriously, give python and pygame a try. You will be surprised just how easy it is to program in and it'll work just fine on the pandora.

Doesn't Python have to have an interpreter just like Java does? - From what I've researched Python looked like a language I could get into as well, however I'd have to get used to the whitespace stuff - I like to typically lay things out myself and not let the language tell me how far I should be indenting things but I guess python could help me rid myself of some bad coding habits

Also - Is it possible to compile python into a package/single executable by chance, even if I would have to compile it for multiple platforms?

 

[cb88]

how about LLVM? If im thinking right it can jit compile C and C++ code and D and a few other things

I could really care less myself about interpreters... and yeah python has problems too (anyone noticed the memory leakes in fretsonfire ... hideous) although I would probably take to it better than java

@kramy seriously not that many people are running Windows 2000 which is aguable a better proforming platform than XP WRT ram usage I have had horrific memory usage with Windows XP in several variations and locations and Linux (debian 4.0r3 and 5.0RC1 specifically off the top of my head)

 

[Kramy]

@Kramy seriously not that many people are running Windows 2000 which is aguable a better proforming platform than XP WRT ram usage I have had horrific memory usage with Windows XP in several variations and locations and Linux (debian 4.0r3 and 5.0RC1 specifically off the top of my head)

I can't really argue with that. My XP PC is a bit flaky too. :lol: That's why I don't code on it. It's weird having stuff crash when it runs out of addressing space.

LLVM is interesting, but it hasn't matured yet. Only in very few select cases is it faster than C (quite similar to java), and most of the time it's slower.

Plus..err...you still have to code in C? Where's the benefit? :unsure:

 

[hessiess]

if java ran in a 10mb or so runtime well that might be alright but it does't
Python does

Seriously, give python and pygame a try. You will be surprised just how easy it is to program in and it'll work just fine on the pandora.

Python is interpreted, java is compiled to byte code, then JIT compiled to the platforms native instructions. So java should be faster.

 

[Eniko]

Python's speed - or alleged lack thereof - should (almost) never be an issue. Unless ThantiK wants to program Crysis for Pandora. Also, Python doesn't compile, but there are several ways to create stand alone packages for various OSes. Worse comes to worst you could just create a quick C binary for every target platform that does nothing besides start the included interpreter with your scripts.

Which is essentially what the stand alone package creator utilities do too, just...prettier.