LWJGL or JOGL

General Discussions
#1

I am currently comparing LWJGL with JOGL + JOAL + JInput combination.

How to they compare in terms of support for OpenGL extensions?

With JOGL are you expected to use your own Vector and Matrix libraries? I did notice Java3D has vector package, can you just use that part of it without depending on the rest of Java3D.

I got the impression that jME (jMonkeyEngine) is better for games then Java3D. Would knowing LWJGL help with using jME?

Also is there any libraries for implementing menus with LWJGL or JOGL? I suppose JOGL can use Swing for GUI stuff.

#2

I have always said that LWJGL is more for games development whereas JOGL is more for general purpose OpenGL. This isn’t directly true since both APIs may be used for all types of OpenGL development.

Both api’s are usually pretty up-to-date with extensions(LWJGL usually supports the new APIs within a day of the release, courtesy of Spasi (LWJGL developer)), however JOGL does have a NURBS implementation.

not sure about the math stuff, but lwjgl provides some basic stuff - however I am not sure how complete that is, many roll their own, unfortunately.

JME is much better for games than Java3D afaik, but I dont think that knowing lwjgl provides an advantage when using jme - at least I hope not, else they’re exposing too much info in their API.

LWJGL and JOGL can both be integrated into Swing - however there are some custom UI’s like FengGui.

#3

From a technical POV, yes you can take the vector math package and use it with either LWJGL or Jogl. I have no idea about the licensing implications though.

Also, if you want reliable fullscreen support then LWJGL is your only option.

#4

Knowing LWJGL is not important when using jME, that’s right. But knowing about the concepts of OpenGL is still a big plus…

#5

With JOGL I had awful problems with tearing in windowed mode, runnig on windows. Trying to switch on vsync didn’t help, it only made the tearing appear on a fixed place (horizontal line), whereas without vsync it appeared at different places. I also have this problem with Java2D in windowed mode, but never saw it with LWJGL.

A big advantage of JOGL is in my opinion, when you use it with webstart or in an applet, the user won’t get scared by warnings that the program might be insecure.

#6

I think you’ll find that that’s true of LWJGL as well though.

Cas :slight_smile:

#7

A fixed tear line with vsync enabled is a driver issue. There is nothing lwjgl or jogl could do about that.

#8

I disagree with you, JOGL is reliable and we have a good fullscreen support. Since the bug in metacity was corrected, the fullscreen support under Linux has been improved with JOGL. It works fine under Unix Solaris too.

#9

Is there a way to grab the mouse with JOGL? Other than creating a transparent mouse cursor and using Robot.

#10

You still get a security dialog, and that’s enough to scare away a lot of users, no matter what.

#11

Nah, most users just click “Yes” to everything. Especially in later JVMs when they made the dialog look a lot less scary.

Cas :slight_smile:

#12

Go write a game which actually changes the display mode (rather than just using the current resolution) and release it to the general public. Then you’ll see how buggy it is.

#13

(Having said that LWJGL fullscreen is failing woefully on Vista at the moment with DWC enabled, Arrrgh)

Cas :slight_smile:

#14

I don’t know why I would need to change the display mode. Using the current resolution is enough for me. I prefer improving the performance by other ways rather than suggesting the user to change the display mode. I know it is harder. The players expect to have the possibility of choosing the resolution, I have never tried to give them this possibility in my games.

#15

For example, my gfx card is not the latest and greatest so usually I need to set games at a lower resolution than my desktop to get some performance. There’s only so much you can do when the main performance bottleneck is your gfx card’s fillrate…
Also, many games (especially 2D games) are often designed to look well in a certain resolution.

#16

On your specific vista :slight_smile: I have yet to see this problem on any of our vistas (we have three, one nvidia laptop, one nvidia dekstop and one intel x3100 laptop).

  • elias
#17

There’s no smoke without a fire! Fact is, other OpenGL apps run fine on it. The gold standard of OpenGL simplicy, the Quake 2 demo, runs fine in fullscreen; and in windowed mode with DWC enabled it doesn’t suffer refresh lag either. So something LWJGL does these days is plain wrong - not my Vista installation!

Cas :slight_smile:

#18

If quake2 and other opengl apps run fine, why are you not finding the difference between lwjgl and them? Also, make sure quake 2 et al. get the same opengl driver (GL_RENDERER/GL_VENDOR - I read somewhere that older games get the MSOGL opengl-on-directx emulation driver by default).

  • elias
#19

Quake2’s getting GeForce Go 6150/PCE/SSE2/3dNow! in its GL_RENDERER string.

I would have a look at the LWJGL source but I… er… can’t just at the mo :slight_smile:

Cas :slight_smile:

#20

A wild guess is that Display.isVisible()/isActive()/isDirty() return the wrong value, could you try a lwjgl program that doesn’t depend on that?

  • elias