[RFE] LWJGL 3.0

[kappa]

with the latest extensions in the nightly builds, jMonkeyEngine3 now runs on LWJGL3 using the LWJGL2 compatibility layer, yay

[xsupermetroidx]

Bug report:

glfwSetCursor(window, NULL) results in a NullPointerException. Which happens because glfwSetCursor explicitly checks for NULL as a value and throws the exception.

The documentation states:

cursor - he cursor to change to, or NULL to switch back to the default system cursor

This means that the only way to change back to the system default cursor is by using glfwDestroyCursor on the current cursor, which might be undesirable.

There's also a minor typo (he instead of the) in there.

[spasi]

Thanks, this has been fixed in build #31.

[ra4king]

Very nice job Kappa!

[Grum]

Would be wonderful if we could get a glimpse of the lwjgl2 compat-layer code so we can mess around with it a bit ourselves.

[kappa]

Would be wonderful if we could get a glimpse of the lwjgl2 compat-layer code so we can mess around with it a bit ourselves.

As soon as I get some time will drop it on Github.

[kappa]

The method GL20.glUniform1(int, IntBuffer) is fine, however don't see a similar method for ARBShaderObjects.glUniform1ARB(int, IntBuffer), there is however ARBShaderObjects.glUniform1ARB(int, int count, IntBuffer) available which seems inconsistent (and different from LWJGL2).

same applies for ARBShaderObjects.glUniform2ARB, ARBShaderObjects.glUniform3ARB & ARBShaderObjects.glUniform4ARB.

[spasi]

The method GL20.glUniform1(int, IntBuffer) is fine, however don't see a similar method for ARBShaderObjects.glUniform1ARB(int, IntBuffer), there is however ARBShaderObjects.glUniform1ARB(int, int count, IntBuffer) available which seems inconsistent (and different from LWJGL2).

same applies for ARBShaderObjects.glUniform2ARB, ARBShaderObjects.glUniform3ARB & ARBShaderObjects.glUniform4ARB.

This has been fixed in build #33.

[kappa]

This has been fixed in build #33.

Cool, can confirm works as expected.

Thanks.

[kappa]

Disruptor is not necessary anymore with the latest builds. It will soon be removed from the dependencies.

Nice, only a single jar (lwjgl.jar) to worry about (pretty lightweight ).

Just a random thought, does the method Sys.touch() need to be a public API? It only seems to be used internally now. Also touch input will be coming in later versions of GLFW 3.x, so maybe this method could be renamed to init() or initialize (as in LWJGL2) to avoid confusion.

[Umami]

Segfaults, Segfaults everywhere!

I'm a noob regarding OpenGL but a rather advanced programmer. I wanted to give the new version of lwjgl a try instead of messing around with the old one I used a couple of years ago and maybe even help with some debugging and stuff.

There are some rather annoying problems though, mostly being segfaults. I'm using Scala instead of Java but never really had a problem there. There are two major segfaults involved:

If I try to close the window with the escape-key or the close window button I always crash like so:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f85a4e9fa2a, pid=2620, tid=140213512292096
#
# JRE version: OpenJDK Runtime Environment (8.0_25-b18) (build 1.8.0_25-b18)
# Java VM: OpenJDK 64-Bit Server VM (25.25-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libffi.so.6+0x4a2a]  ffi_closure_free+0x49a

Another may be tied to my small knowledge of OpenGL. When I got a window to display I thought about trying to render something. But as soon as I try to create a new vertex array and bind it, I get a crash.

Using: JRE version: OpenJDK Runtime Environment (8.0_25-b18) (build 1.8.0_25-b18)

As I said, this may not actually be a problem in lwjgl code, but an error on my side. If so, I truly apologize. I'm just learning and maybe mixing up stuff or using it in some way it isn't meant to be used in version 3 of lwjgl anymore.

I attach my example code, just in case somebody wants to give it a try. I assume the erroneous code to be in the Loader class.

PS: I'm not here for you to debug my code, not even subliminal! Just wanted to make sure it's not an error on my side. So if you say that the code compiles and runs just fine, I'm absolutely good with it and will debug and dig through it on my own!

[SHC]

@Umami

The problem is because of you are not releasing the callbacks. To avoid this errors, just call the release method on the callbacks before the window is destroyed.

[Umami]

@Umami

The problem is because of you are not releasing the callbacks. To avoid this errors, just call the release method on the callbacks before the window is destroyed.

Thanks, but that's not it.

I switched these two so they look like:

mainWindow.destroy()
glfwDestroyWindow(mainWindow.id)

in the window destroy method the callbacks get released.
Still the same error(s).

(Or am I getting it wrong?)

[shivshank]

var vaos:ListBuffer[Int] = new ListBuffer[Int]()
I don't know Scala, but can those List Buffers be freed prematurely? Maybe your freeing fake pointers? Also make sure your using the BufferUtils whenever you pass data to the GPU, it looks like you are though.

Also, if I recall correctly, (it has been a while), this is a part of the VAO state, so just call it during VAO creation.
GL20.glDisableVertexAttribArray(0)
Although I don't think that will fix your problem...

Just noticed: has LWJGL been tested on OpenJDK at all? Is libffi tested on it?

[spasi]

Just noticed: has LWJGL been tested on OpenJDK at all? Is libffi tested on it?

I have never tested on OpenJDK, only on the Oracle JDK.