[RFE] LWJGL 3.0

Started by spasi, November 08, 2012, 13:23:54

Previous topic - Next topic

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:
Quote
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

-Roi

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

Quote from: Grum on December 14, 2014, 11:14:46
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

Quote from: kappa on December 16, 2014, 23:35:38The 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

Quote from: spasi on December 18, 2014, 22:13:37
This has been fixed in build #33.
Cool, can confirm works as expected.

Thanks.

kappa

Quote from: spasi on December 21, 2014, 09:55:09
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

Quote from: SHC on December 22, 2014, 08:01:13
@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

Quote from: shivshank on December 22, 2014, 21:05:17Just 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.