[RFE] LWJGL 3.0

[spasi]

The example from the website (getting started) crashes for me, if I try to close the window with either escape-key or the window's "close button"

Have you tried with the latest nightly build? If it still crashes, could you please share the full crash log? (you can attach it to a reply)

[shivshank]

I tested the Getting Started on my computer, to try to kill two birds with one stone, so to speak. It appears to work, rendering a red square. However, I've noticed that LWJGL is causing GL_INVALID_ENUM and GL_INVALID_OPERATION errors.

In a different test program I wrote, the same errors:

// code inside of main
System.setProperty("org.lwjgl.util.Debug", "true");
GLFW.glfwInit();

GLFW.glfwDefaultWindowHints();
GLFW.glfwWindowHint(GLFW.GLFW_RESIZABLE, GL11.GL_TRUE);
GLFW.glfwWindowHint(GLFW.GLFW_VISIBLE, GL11.GL_TRUE);
long window = GLFW.glfwCreateWindow(800, 600, "GL Test", 0, 0);
GLFW.glfwMakeContextCurrent(window);

GLContext.createFromCurrent();
checkGLError("Before anything:") // my error checking function

I enabled org.lwjgl.util.debug, and here is the programs output:

[LWJGL] Version 3.0.0a | Windows 7 | amd64
Hello LWJGL 3.0.0a!
[LWJGL] MemoryUtil MemoryAccessor: MemoryAccessorUnsafe
[LWJGL] A GL context was in an error state before the creation of its capabilities instance. Error: Enum argument out of range
[LWJGL] Failed to locate address for GL function glVertexArrayVertexAttribDivisorEXT
Before anything:
GL ERROR: GL_INVALID_OPERATION

I read that Invalid Operation will be raised if glGetError is called before the context is current, of course LWJGL won't let me do that (causes IllegalStateException). These errors don't seem to affect my program, though. I can still render triangles with shaders and control the color (though I haven't gotten my texture loader to work, but I think that's my problem.).

I tried looking through the LWJGL source, it appears that the error has to occur inside the GLContext class, but that's as far as I can understand.

[spasi]

[LWJGL] A GL context was in an error state before the creation of its capabilities instance. Error: Enum argument out of range
[LWJGL] Failed to locate address for GL function glVertexArrayVertexAttribDivisorEXT
Before anything:
GL ERROR: GL_INVALID_OPERATION

glGetError is the first OpenGL function LWJGL calls in GLContext.createFromCurrent(). So the error must be coming from something GLFW does. It's also interesting that you get an INVALID_OPERATION right after, so this could be something LWJGL does wrong, though it's really odd that this hasn't happened to anyone else.

Could you share some details about your system? (OS, GPU, driver version, JVM version)

[shivshank]

Hm, if I recall correctly the computer is from 2009. If I query the OpenGL version, I think it supports 3.2 now, but the original drivers did not.

GPU: ATI Radeon 5750 HD
Driver: ATI Radeon 5770 HD (v8.680.0.0) - that's not a typo... its apparently using a driver from a different card (November 2009)?
OS: Windows 7 Home Premium
JVM: (I ran java -version)
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

I just realized I actually have the source on my machine; out of curiosity, which file generates ContextCapabilities.java? I'm digging around trying to understand the GitHub repo, but I was unable to find the file on there.

[kappa]

Anyway, it's a freaking mess, I don't know why I'm still wasting time on this.

Its a challenge, which is always fun but yeh best not to continue wasting time on this. Once Java 9 and the jigsaw project are released, I suspect AWT will be phased out pretty quickly.

On freetype, I had a quick look and it seems straightforward. It's a simple C API with great documentation. On font rendering in general, an alternative approach would be building everything you need offline (glyph metrics, kerning info, texture/vector data in a custom binary format) and not have to depend on AWT or anything else at runtime.

The main reasons for the continued AWT usage in LWJGL applications are:

1) Support for multiple windows - This is now addressed in LWJGL3, it was by far the biggest reason people wanted to use AWT with LWJGL2.

2) Image Loading - This is another area where AWT usage was pretty high, LWJGL1 did provide Devil support for a while, however was removed as it was a needless time and effort drain to maintain when such functionality was already built into the JRE/AWT. With the rise of Android and other efforts we've since seen many pure java decoders appearing (notably the MatthiasM PNG/TGA/JPG Decoder series and others), which are faster and skip the unnecessary step of converting from an AWT Image to a NIO buffer. Therefore AWT is no longer required here.

3) Sound Loading - LWJGL use to have a Fmod binding and was removed for the same reasons as above. Again there are now a lot of nice standalone decoders (Wav, Ogg, MP3, XM, etc) which weren't around when LWJGL2 was released therefore again AWT is no longer required for this.

4) Solid and familiar GUI - AWT/Swing usage was pretty entrenched with Java users, however now that we have JavaFX, AWT/Swing is being depreciated, most users are moving away from it. We saw some pretty good and solid OpenGL GUI's with LWJGL2, now with all the new GLFW functionality LWJGL3 can potentially have much more multi-window GUI's that can emulate the functionality of AWT/Swing. In fact its probably even possible to write a clone for the AWT/Swing API running on LWJGL3.

5) Applets - This was another reason AWT was required in LWJGL2. Applets are all but dead now so this no longer applies.

6) Font Loading - This is probably the last area where Java/LWJGL support is weak and a library or binding to assist would really help. Other than the options mentioned previously, AWT is probably the most solid choice ATM to get Glyph information, even the support in JavaFX does not provide the low level details need for OpenGL usage. Freetype seems like the best choice for this as it has support for lots of formats, actively maintained and pretty small.

[spasi]

out of curiosity, which file generates ContextCapabilities.java?

It's src/templates/org/lwjgl/opengl/FunctionProviderGL.kt, see the generateContent() function.

[spasi]

Freetype seems like the best choice for this as it has support for lots of formats, actively maintained and pretty small.

I'm currently done with bindings to the Objective C Runtime (needs more work to be user-friendly) and have also started bindings to libOVR (Oculus SDK). I'll work on freetype after those two are done.

[kappa]

I'm currently done with bindings to the Objective C Runtime (needs more work to be user-friendly) and have also started bindings to libOVR (Oculus SDK). I'll work on freetype after those two are done.

super cool stuff

[Umami]

The example from the website (getting started) crashes for me, if I try to close the window with either escape-key or the window's "close button"

Have you tried with the latest nightly build? If it still crashes, could you please share the full crash log? (you can attach it to a reply)

Sure.

One note: The same thing happens if I compile with Java 7, so it's definitely not the Java-Version.

[spasi]

Sure.

One note: The same thing happens if I compile with Java 7, so it's definitely not the Java-Version.

Thank you Umami, the log helped a lot. Please try the current nightly (#37), the problem should be fixed.

[Umami]

Sure.

One note: The same thing happens if I compile with Java 7, so it's definitely not the Java-Version.

Thank you Umami, the log helped a lot. Please try the current nightly (#37), the problem should be fixed.

Seems to be fixed, yes! Thanks a lot.

Now I have to understand what I'm doing wrong with my shaders and rendering, but that's not for this thread

[kappa]

Came across a pretty cool little project called tiny file dialogs. There isn't an alternative to LWJGL2 Sys.alert in LWJGL3 and something like this could be useful if such functionality is needed.

In any event, with LWJGL3's new direction not sure if something like the above belongs in there anymore and should instead be requested to be included in GLFW.

[kappa]

I know we've looked at the layout of the natives before, however the directory structure is still a little rigid, most of the launchers for LWJGL2, tools for creating single jars and extracting natives at runtime, rely on the natives being in the same directory (and just simply extract by file extension).

The LWJGL native code is doing something roughly like the following:

String osName = System.getProperty("os.name"); // then trim the name
String arch = System.getProperty("os.arch");
String name = lwjgl; // name of native
String natives = System.getProperty("org.lwjgl.librarypath");

Then loaded by LWJGL as follow:

String path = natives + File.separator + osName + File.separator + arch + File.separator + System.mapLibraryName(name);

The problem for all the launchers is that the code complexity is then passed onto them when extracting natives, they need to either now have code to check the platform, arch, check if such directories exist and then extract the correct natives or they'll need to extract natives and create directories in the layout LWJGL3 uses (i.e. */osName/arch/*).

An alternative approach that LWJGL3 could use is put the osName and arch in the file name instead as follows:

String path = natives + File.separator + System.mapLibraryName(name + "-" + osName + "-" + arch);

In addition to being easily able to identify what os and arch the native is for it would allow bundling the natives in a single directory.

Alternatively we can get away with having just the arch in the file name (and osName can remain a folder), since the extensions for the 3 platforms LWJGL supports are named differently on each OS (*.dll, *.dylib, *.so) and then they could be included in the same folder where needed but distributed using the osName folder structure.

[Kai]

+1 for having all natives in a single folder with the proposed naming scheme.

[spasi]

We currently have to only deal with OpenAL and LWJGL itself. What happens if we later add more and more libraries? It becomes a pita to have to rename every 3rd party library to exactly match the LWJGL naming scheme.

What are the tools that have trouble with the current scheme?