OpenGL/LWJGL over Built-In Libraries?

General Discussions
#1

Hey, I’ve been messing around with Games and stuff in Java for a few days now(planning to not quit this time xD) and I haven’t been using any external libraries or anything, just Java’s built-in libraries. I’ve been able to get spritesheets and animations working pretty well.
I used to make a few Minecraft mods, and I’ve used OpenGL quite a bit, but I don’t like how LWJGL works, or at least how Minecraft uses it. Having to download different files for each operating system and all that jazz.

Are there any advantages to using OpenGL/LWJGL over regular Java libraries? If there are massive advantages, are there ways to use OpenGL without LWGJ? If not, is there a way to use your game without getting OS-dependant files all the time?

Thanks!

#2

If you use the standard Java libraries, you don’t get any 3D, you get an API that is surprisingly often even more obscure than OpenGL, you get random performance problems (in as much as the performance of any particular version of the JVM on any particular OS is never a known quantity and can range from as fast as OpenGL to 2fps).

If you want consistent, fastest possible performance, you need OpenGL, and the only way to access OpenGL from Java is through either LWJGL, or JOGL, which works in almost exactly the same way. There is no way around the need for native libraries for each OS, but honestly, why do you care about that? They’re tiny, insignificant little files that do nothing on the wrong OSes.

Also, you’ll probably be wanting some sort of reliable sound and input APIs for your game too, and LWJGL will achieve this for you as well. Games aren’t just graphics!

Just do what you want to do in whatever OS you prefer to use and never mind the others until you’re ready to show the world.

Cas :slight_smile:

#3

Thanks, princec! I didn’t really want to use LWJGL because of having to drag a bunch of files with it. I’d much rather prefer giving people a single file that just works by itself. I think I will start using LWJGL just because you made it sound so much better now xD

Thanks again!

#4

When you get to the stage of really wanting to show people stuff… it can be extremely helpful to distribute things in a way that the users of each respective OS expect and understand.

For Windows - that’s an installer, either a .exe built with the excellent NSIS installer, or a .msi
For MacOS - a .dmg or .zip containing a single .app structure.
For Linux - gaaaah. I recommend both .deb and .tar.gz. And there are 32 and 64 bit complications.

You’ll find significantly more people try out your stuff if you spoonfeed it to them in this way.

If you’re really brave you could try applets or even Webstart but then you’re into a world of considerably increased pain.

Cas :slight_smile:

#5

Speaking from personal experience here?

This has been mine so far.

Me: “Hey friends (because they are, no strangers but people I know and like), I’m working on this and that. Here, see these cool screenshots of the work in progress?”
everyone and their grandmother: “Hey cool man, can’t wait to try it out! I’m psyched!”
Me, a month later: “I have the first version ready to test! You can download it here and I created an executable to make it easy to run, etc. etc.”
crickets chirping

Now I just do stuff I like, its my hobby anyway :slight_smile:

#6

Java Web Start is not very painful, just still a bit buggy.

#7

Don’t tell your friends that you’re “ready to test, download it here and I totally made it easy to run blah blah”. Tell them what to do. "Hey check out what I made: ". And where the link leads to, include screenshots or heck, a youtube video.

Marketing 101: The less association they have with something that they didn’t care about before, the fresher it is. Sort of a reverse corollary to brand identity.

#8

Yes. Most users don’t care about that stuff. Or else they would be the ones writing the code.

#9

It is certainly good advice to apply to strangers, but I’m not going to play marketing/psychology tricks on my friends if you don’t mind :wink: Its already difficult enough to not do that seeing that I work for a marketing automation company…

(yes, I’m going to hell).

#10

On your way down, please kick the Webstart developers and original applet integration team.

Cas :slight_smile:

#11

Nah, those guys and gals only go to purgatory to have some time to think about their actions :wink:

Let me be a little more on-topic for a change:

I use Java2D myself and as long as you stick with games that are no more technologically advanced as the 2D games that were created in the late 80’s/begin 90’s it is fine. But as soon as you want just a little bit more such as draw hundreds of sprites per frame, applying transformations (rotation or scaling for example) or you want to use transparency, the whole thing can crumble depending on what system you run it on. At that point Java2D simply is not an option anymore and you should consider going directly to the hardware, which LWJGL or JOGL allows.

Its not like people use it because they want to make their life difficult you know, there is going to be a good reason for it :wink:

Yes, JOGL. But same difference with less features.

“all the time” is a bit strong isn’t it? Once per game install. Right now you could go the JavaFX 2 way and be able to have the games run on Windows and Mac environments with Linux following shortly. But you’d be pioneering a bit as I don’t think many people have attempted to create games on top of JavaFX 2 yet. It has a very active community and the JavaFX dev team is really responsive, so its not the worst choice you could make. But I’m doing a bit of guesswork here, I have no idea what the custom painting capabilities of JFX2 are.

#12

I heard JavaFX 2 is still slow and useless for games. :slight_smile:

#13

LWJGL should be compared to JogAmp (JOGL+JOAL+JOCL). I assume the Java binding for the OpenGL API of LWJGL has similar features than JOGL 2.0, neither less nor more, am I wrong? If I am, let us know.

It is almost impossible but in all APIs of JogAmp, you don’t have any OS dependent setting, you just put all JARs containing classes into the classpath and all JARs containing native libraries into the same directory (but it is not required to put them into the classpath), you don’t have to set the Java library path or any environment variable (which depends on the OS).

Only a small part of JavaFX 2.0 source code has been released (sse OpenJFX), I have not yet had a look at it. The previous version of JavaFX used a private build of JOGL 1, it was not that slow but I’m not really sure this API has been designed for games.

#14

Actually JOGL has features that LWJGL doesnt have, for example texture compression like S3TC…

#15

Pro tip: gouessej is one of the committers of JogAmp :wink: (And I still wonder, why I choose LWJGL instead of JogAmp… sorry LWJGL… :frowning: )

#16

Isn’t using compressed textures done in the driver, and thus accessed like any other extension? Not sure in that case how it wouldn’t be supported. A texture compressor would be a nice utility, but others have done it better, and lwjgl’s history is one of getting out the utilities morass (e.g. ditching DevIL and FMOD, and hopefully the vector classes in 3.0)

#17

Well, looking at this thread: http://www.java-gaming.org/topics/loading-dds-files-to-lwjgl/24633/view

[quote]I think JOGL has some support for it, but I’m using LWJGL.
I’m trying to load S3TC textures into OpenGL.
[/quote]

[quote]You have to do it on your own.
[/quote]
I’m no expert but our OpenGL guy told me this: LWJGL has no Texture Compression but JOGL does. Which of course does not mean it is not doable in LWJGL…

#18

I’m the guy responsible for engine support:
http://jogamp.org/wiki/index.php/Maintainer_and_Contacts
My biggest contributions are rather in the environment around JogAmp, more than in its core. I have contributed to a lot of projects including NiftyGUI, Xith3D, Ardor3D, JMonkeyEngine 2 & 3, Jeti, Java3D, etc… Maybe we should take care, I don’t want to start any flame war and each set of APIs has its weaknesses. For example, JOAL doesn’t have (yet) a fully working OpenALSoft support, JInput for JogAmp lacks a plugin to work with our native windowing system (NEWT). Maybe our abstraction of virtual and physical screens could be improved.

#19

Last time I looked, about 5 years ago, LWJGL supported texture compression.

Cas :slight_smile:

#20

Never mind then. Maybe texture compression is supported but specifically S3TC is not ? =o