Hi, I'm still relatively new to java and game programming, but I've noticed a lot of people using openGL for their games, so I thought I would try and learn how to use it. Searching around a bit, I found that the two main java opengl libraries(if that's the correct term) are JOGL and LWJGL. Most posts I've seen on which is best to use says it's on personal preference, so which do you much more experienced game developers and programmers think is better/most user friendly for someone like me who isn't very experienced in programming? Also, where would be the best place to start learning how to use openGL in java, as I couldn't seem to find many up to date tutorials out there, most were for C/C++.

Also a final question, is there anything other than OpenGL that you would recommend I learn/try due to my programming knowledge/ability?

Tutorials written in C++ are almost trivial to port to LWJGL as the APIs are very, very similar, apart from the use of Buffers where C/C++ use pointers, types, and length arguments (a Buffer implies all of type, pointer, and length of data already).

EDIT: is there an easy way to change C++ code to java, or is it just done manually, changing the line of code here and there?

It's very possible for you to turn the OpenGL to Java code yourself.However, since those tutorials get complicated very quickly, it's best to not waste your time with doing it yourself.Here are the Java ports of those tutorials.

It's very possible for you to turn the OpenGL to Java code yourself.However, since those tutorials get complicated very quickly, it's best to not waste your time with doing it yourself.Here are the Java ports of those tutorials.

Wow thankyou, this will save me tonnes of time!

+1

EDIT: decided to not learn opengl right now, it seems a bit too advanced for my Java level. I'm going to keep developing in 2D so I can increase my abilities in java and be more adept for when I choose to move onto 3D/opengl. Thanks all for the help though, I hope others may have somehow found this useful too.

1. How to set up the display for 2D (relevant commands: glMatrixMode, glLoadIdentity, glOrtho)2. How to do a "main loop" (read input, do logic, clear screen, render things, sync and update) and close the app when someone closes it (classes: Display, Keyboard, Mouse; API glClear)3. How to load a graphic and get it into OpenGL (glTexture2D, glBindTexture)4. How to draw a sprite (glEnable, GL_TEXTURE_2D, glBegin/glEnd, GL_QUADS, glVertex2f, glTexCoord2f)5. How to draw sprites transparently (glBlendFunc, GL_BLEND, GL_ONE, GL_SRC_ALPHA)6. How to draw sprites additively

1. How to set up the display for 2D (relevant commands: glMatrixMode, glLoadIdentity, glOrtho)2. How to do a "main loop" (read input, do logic, clear screen, render things, sync and update) and close the app when someone closes it (classes: Display, Keyboard, Mouse; API glClear)3. How to load a graphic and get it into OpenGL (glTexture2D, glBindTexture)4. How to draw a sprite (glEnable, GL_TEXTURE_2D, glBegin/glEnd, GL_QUADS, glVertex2f, glTexCoord2f)5. How to draw sprites transparently (glBlendFunc, GL_BLEND, GL_ONE, GL_SRC_ALPHA)6. How to draw sprites additively

Come back when you get stuck. Work out those things one at a time.

Cas

Okay, I'll start searching when I have some time to sit down and properly start learning some stuff. I'm busy with lots of school stuff at the moment though, so I have hardly any spare time Thanks for all the help Cas!

EDIT: So far I've learnt a bit on both 1 and 2, hopefully should be able to start writing my own basic game using lwjgl soon!

The "war" over abunch of trivial JNI wrappers for OpenGL/OpenAL is extremely funny to watch for an outsider.

On topic, the steps Cas told you about are a neat way to get into OpenGL. However, once you mastered them, don't get to comfortable. Look into the tutorial on modern OpenGL linked to above, it will allow you to target more platforms, e.g. mobile phones/tablets.

The "war" over abunch of trivial JNI wrappers for OpenGL/OpenAL is extremely funny to watch for an outsider.

I wouldn't call them trivial, since both have really big windowing systems, I think the JogAmp Windowing codebase is even bigger then LWJGL's.Also, I'd really say that both princec and gouessej are pretty agressive in this war But everything is okey right now, so thats nothing to worry about

JOGL's improved a lot, and the speed differences are negligible now. JOGL's got better native window support with multiple windows, and it has some interesting utility classes for things like animation (that probably don't belong in there). The use of a graphics context object similar to how AWT/Java2D works does allow at least in theory for overrides (it'd probably take a lot of source hacking)

But JOGL's packaging is rubbish. The release engineering is just bizarre (better now I'm told) and there's no artifacts on maven central so I can't easily work it in to any of my projects. So when the functionality I actually care about is otherwise equal, I'm going to go for convenience every time, and right now the winner is LWJGL.

And what better way than to fork TUER and "port" it to LWJGL, pointlessly!

I have done my best to ease this task in case someone really needs to do it, especially in the pre-beta version in which almost all references to classes relying on JOGL are done in the main class. It's under GPL v2 after all, feel free to do so; while you respect the license, I won't complain.

Then, you have to retrieve the width, the height and the bits per pixel without using NEWT which should be trivial.

After that, if you want to port JFPSM too, you will only have to replace com.jogamp.common.nio.Buffers by something else (plain standard Java or an helper coming from the binding you use) which is trivial again.

Finally, you will have to modify the Ant script. I advise you to take as an example an older revision that does not use the automatic extraction and loading of native libraries from JARs as you won't rely on a feature coming from JogAmp. You have to replace all references to GlueGen, JOAL and JOGL resources by their equivalents... When you're ready, you'll be able to use this script to generate all signed JARs and the JNLP files.

Yes, LWJGL needs NEWT! Time for you guys to bury the hatchet, preferably somewhere other than each others' skulls!

You can mix NEWT with the competitor of JOGL or port it, both use similar licenses.

The fun thing would anyways be, that you couldn't be able to use the NEWT multi-window feature because LWJGL is all static. And then it would even make no sense, because when you built the stuff in LWJGL from static to instanced, then you'd have a small part of JogAmp...If you want NEWT you'd just go with JOGL/JogAmp

Yes, LWJGL needs NEWT! Time for you guys to bury the hatchet, preferably somewhere other than each others' skulls!

You can mix NEWT with the competitor of JOGL or port it, both use similar licenses.

The fun thing would anyways be, that you couldn't be able to use the NEWT multi-window feature because LWJGL is all static. And then it would even make no sense, because when you built the stuff in LWJGL from static to instanced, then you'd have a small part of JogAmp...If you want NEWT you'd just go with JOGL/JogAmp

As soon as I know, they plan to fix this design flaw in the third version. you're right to point out this aspect. "all static" drives it simple/simplistic which is nice for newbies but it has a cost. JogAmp and its competitor already share some classes, we borrowed some classes (for projections) and they did it too (Java GLU implementation).

And what better way than to fork TUER and "port" it to LWJGL, pointlessly!

I have just removed some references to com.jogamp.common.nio.Buffers from JFPSM. I will try to move the mechanism that retrieves the screen size and the bits per pixel into Ardor3D. If you want, I will add an option allowing to restart TUER with the third version of the competitor of JogAmp when it is ready.

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