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?

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.

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

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 .msiFor 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.

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

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*

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: <link here>". 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.

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: <link here>". 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.

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 Its already difficult enough to not do that seeing that I work for a marketing automation company...

Are there any advantages to using OpenGL/LWJGL over regular Java libraries?

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.

Quote

If there are massive advantages

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

Quote

, are there ways to use OpenGL without LWGJ?

Yes, JOGL. But same difference with less features.

Quote

If not, is there a way to use your game without getting OS-dependant files all the time?

"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.

If not, is there a way to use your game without getting OS-dependant files all the time?

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.

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)

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)

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.

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

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

I'm the guy responsible for engine support:http://jogamp.org/wiki/index.php/Maintainer_and_ContactsMy 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.

The latter feature is probably what had you mistaken about texture compression. It includes a DDS format, which means it can decode a DXTn (S3TC) compressed image. LWJGL doesn't include any image decoders, and so you need to write your own DDS decoder (a basic decoder is fairly simple). However, the actual process of using compressed textures on the GPU has been supported by OpenGL (and thus LWJGL and JOGL) for ages.

Note that these aren't "missing features" of LWJGL. The library is designed to be a "thin wrapper," without the fluff of textures, fonts, etc. This is why Slick-Util tends to be a popular starting point for decoding.

Ideally one day a library more suitable than Slick-Util will take the stage.

@gimbal it's the other way around. LWJGL tries to have as little utilities as possible. It's only job is to have bindings for OpenGL, OpenAL, and OpenCL. Any other utility is for higher level wrapping libraries.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org