In LWJGL3 it is possible to enable OpenAL HRTF ( OpenAL Soft HRTF in Devil Daggers - YouTube , ioquake3 OpenAL HRTF test - YouTube ) which sounds really nice. So i’m considering whether switching to the new lwjgl3 renderer for jme would be a good idea.
Does anyone have any good or bad experience with lwjgl3 vs lwjgl2 in jme?
My only bad experience with lwjgl3 was :
1 Like
So I don’t think that is a problem with LWJGL3 as much as it is the screen recording software that AMD runs in the background. Screen recording software has been a huge pain to deal with and I’ve had to make a lot of changes to ensure Spoxel runs with screen capture software. For example, creating viewports after the application initializes will cause the wrong viewport to be displayed on most capture software.
So, I recently switched to LWJGL3 mainly because of the fact that LWJGL2 was having issues getting the context back after alt tabbing in full screen so it would effectively freeze the game. It did introduce some minor keyboard input problems that I had to deal with but it wasn’t too bad.
The big problem I’ve run into is in packing the software. I package Spoxel using packr in order to have a native executable “run” the game and after I switched to lwjgl3 it basically broke that. On Windows it broke because it couldn’t find resources files that were packaged in the application jar anymore and I had the 32 bit lwjgl dll in the directory next to the 64 bit which causes it to crash with no error message. On OSX it still won’t run. That being said, it will still run correctly if you run it directly from java. So depending on what you are doing this may not be a big deal for you.
1 Like
Yeah, for mac you need to use some flags to get it working. runinmainthread etc. These are in the jMonkeyEngine gradle.build also.
But feature-wise, in JME features, they both should be pretty much on par. I get a minor FPS drop with LWJGL 3. But nothing major. I have understood that this has something to do with NVIDIA and that it is a minor bug.
1 Like
Yea, that reminds me… the NVidia Threaded Optimization flag really tanks the render time with lwjgl3. Like on my dev machine spoxel averages around 7-9ms render time per frame. With threaded optimization on the cpu time drops to 4-5ms but the gpu time more than doubles (18-20ms). I had to make a custom exe that runs on steam when spoxel is run for the first time to create a profile that disables threaded optimization.
1 Like
Did you measure any change in memory usage? IIRC some code that takes care of deallocation has been reworked in jme for lwjgl3, that’s what worries me the most.
I didn’t measure that since I pretty much had to make the switch. I know there is a memory leak in Spoxel at the moment but that was before the switch that I need to track down still.
Hi. i switched to lwjgl3,too. I’m having the keyboard problems aswell… could you explain how you fixed it ?
and to the lwjgl2 fullscreen bug, i fixed that one with the following:
in the SimpleApplication class:
@Override
public void gainFocus() {
super.gainFocus();
if (settings.isFullscreen()) {
try {
Display.setFullscreen(true);
} catch (LWJGLException ex) {
}
}
}Are we talking about the same bug? I noticed that under Linux it still uses the en_US Keyboard scheme, even though it used the de_DE scheme under Windows. And lwjgl2 correctly always used the de_DE scheme.
So the keyboard problems I ran into had to do with jmonkey and nifty. If I remember correctly, there were certain areas of the application which didn’t normally have certain keyboard events which did after I switched. In that case I just added additional checks to make sure it was a good part of the application to run those hotkeys. Also, I had used the lwjgl2 keyboard class to query key states which I couldn’t do any longer since it doesn’t exist. I just wrote a quick custom class to keep track of the keyboard state so I could query those whenever I needed to.
no this is not the problems see.
my problem:
I use tonegod gui, which receives empty characters and makes Strings uncomparable. In more detail, i have written a auto-completer for a console, whenever i type some text the glfw character callback sends not usable characters, which get placed into the String, and this results in uncomparable strings. “profile” is not longer equal to “profile” the length of the string is two times the regular one.
in short: Rawinputlistener is not as handy as it was with LWJGL2, you will have to change your code for the migration.
ok that sound like a totally different problem.