LWJGL v2 versus v3

Development
1

Currently the jme3-lwjgl library is used by default, both in the SDK and in jme3-examples. This means a lot of people are probably still using LWJGL v2.9.3, software which hasn’t been updated since 2015.

There are currently open issues with both jme3-lwjgl and jme3-lwjgl3, but on the whole, I want to encourage people to use jme3-lwjgl3 rather than jme3-lwjgl.

Would there be any objection to making jme3-lwjgl3 the default for jme3-examples? It’s a 2-line change, so it’s easy to switch back when you want to test v2.

6 Likes
2

I agree that it is well past time to make lwjgl3 the default. I ran into a few showstopper bugs with lwjgl2 with spoxel and had to swap to 3.

1 Like
3

well we just use v3 and no issues so far.

1 Like
4

The biggest v3 issue I’m aware of is issue 942.

5

What are the issues with lwjgl2?

1 Like
6

Full-screen graphics don’t work for me on Linux with LWJGL v2. I don’t know whether an issue has been filed on that yet, but it comes up regularly at the Forum. For instance:

7

Fullscreen support on OSX is pretty bad as well. I had a freeze bug related to alt-tabing out of the game when in full screen on all platforms. Also, I there was a bug with applying settings during the game that would crash jme as well.

1 Like
8

+1 for LWJGL3

2 Likes
9

I agree to make LWJGL3 the default.

Using lwjgl2 on Linux I am getting the following errors on some tests :

SEVERE: An OpenGL error has occurred!
org.lwjgl.opengl.OpenGLException: Invalid enum (1280)
	at org.lwjgl.opengl.Util.checkGLError(Util.java:59)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.checkGLError(LwjglAbstractDisplay.java:136)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:157)
	at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:197)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:232)
	at java.base/java.lang.Thread.run(Thread.java:835)

and:

SEVERE: An OpenGL error has occurred!
org.lwjgl.opengl.OpenGLException: Invalid value (1281)
	at org.lwjgl.opengl.Util.checkGLError(Util.java:59)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.checkGLError(LwjglAbstractDisplay.java:136)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:157)
	at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:197)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:232)
	at java.base/java.lang.Thread.run(Thread.java:835)

Switching to LWJGL3 fixes them.

2 Likes
10

If we really want, we can fix both issues, i have working fixes in place in my game. One requires a patch on the lwjgl2 source and the other a workaround in the engine.

But clearly, if the current lwjgl3 implementation can reliably replace lwjgl2, then i guess there is no point in keeping lwjgl2 as default.

I have only one concern, it seems that lwjgl3 uses borderless windows for fullscreen, this might be a problem for some window managers.

Also i think that, since this is a very essential part of the engine,someone should do a full review of the implementation, before making it the default.

For example, you need to implement the framelimiter by yourself with lwjgl3, and from a quick look at the source, i noticed that the code we are using is not appropriate

Compare it with the code from lwjgl2

1 Like
11

For examples I don’t care, but we can’t “remove” v2 anytime soon, because I had a few bugs with v3:

  • Keyboard Layout handling (can be fixed on our side, but doesn’t affect everybody)
  • On Mac OS completely problematic (special jvm launch arguments, must not run awt [Settings Dialog CANNOT be used], crashed my computer a few times)
  • On Linux, Fullscreen didn’t work, because the FPS readout was wrong [Settings Dialog Problem? It was like 59.97Hz, where lwjgl needed 60]
1 Like
12

Also this s rather nasty: Nifty GUI doesn't display correctly after context restart · Issue #1013 · jMonkeyEngine/jmonkeyengine · GitHub

For Nifty users of course. But that is still the default in JME.

1 Like
13

LWJGL2 can straight up crash when restarting after changing settings when using nifty so the lwjgl3 bug you linked is the lesser of two evils. I had to move the settings changes to a launcher and switch to lwjgl3 to avoid major ship bugs.

The OSX issues with lwjgl3 didn’t take much to work around since most people will need to build their own settings dialog anyways and the jvm arguments are baked into the project. Most of the problems I had with osx and lwjgl3 were more OSX related issues with Intel graphics cards and retina / hidpi display issues.

I don’t test on linux very often, but I am pretty sure I ran into that bug as well.

1 Like
14

Point me to the workaround please.

15

Except for this issue, LWJGL3 seems to work very well here. I think we should concentrate our efforts on resolving LWJGL3’s issues since v2.9.3 is not going to be updated anymore.

Edit: Linux here.
Kubuntu 19.04 with OpenJDK 11.0.4.

1 Like
16

fullscreen fix

alt-tab workaround (the idea here is to disable fullscreen when the focus is lost and enable it when it’s regained)

2 Likes
17

Did you check that is this just about the app settings? Are you using a renderer in LWJGL 2 that is from LWJGL 3? The OpenGL version thingie? You might have cross configured them if you switch between the LWJGL versions.

18

If we switch to lwjgl3 then what should we use for a settings dialog? I understand that the lwjgl folks don’t care if their stuff works with AWT or not… so we should plan on not getting that one bug fixed, I guess.

2 Likes
19

I’ve never had any trouble with the settings dialog with LWJGL v3. Under what circumstances does it give trouble?

20

AWT doesn’t work on OSX with LWJGL3.

1 Like