[RFE] LWJGL 3.0

[Kai]

Of course. The test is so silly simple that I just copy/paste it here as code snippet.

package simple;

import org.lwjgl.Sys;
import org.lwjgl.opengl.*;
import org.lwjgl.system.glfw.*;

public class Main {
	public static void main(String[] args) {
		Sys.touch();
		GLFW.glfwSetErrorCallback(ErrorCallback.Util.getDefault());
		GLFW.glfwInit();
		GLFW.glfwDefaultWindowHints();
		GLFW.glfwWindowHint(GLFW.GLFW_CONTEXT_VERSION_MAJOR, 3);
		GLFW.glfwWindowHint(GLFW.GLFW_CONTEXT_VERSION_MINOR, 2);
		GLFW.glfwWindowHint(GLFW.GLFW_OPENGL_PROFILE,
				GLFW.GLFW_OPENGL_CORE_PROFILE);
		GLFW.glfwWindowHint(GLFW.GLFW_OPENGL_FORWARD_COMPAT, 1);
		GLFW.glfwWindowHint(GLFW.GLFW_VISIBLE, 0);
		long window = GLFW.glfwCreateWindow(800, 600, "Test", 0L, 0L);
		GLFW.glfwMakeContextCurrent(window);
		GLContext.createFromCurrent();
		GLFW.glfwShowWindow(window);
		GL11.glClearColor(0.2f, 0.3f, 0.4f, 1.0f);
		while (0 == GLFW.glfwWindowShouldClose(window)) {
			GLFW.glfwPollEvents();
			GL11.glClear(GL11.GL_COLOR_BUFFER_BIT);
			GLFW.glfwSwapBuffers(window);
		}
		GLFW.glfwDestroyWindow(window);
	}
}

As for the native test, since I cannot compile for Mac OS X I would ask you for help to send me a native application that we can then execute on the Mac OS X 64-bit.

[kappa]

spasi, just noticed one thing in the Gears Demo

try {
	if ( LWJGLUtil.getPlatform() == Platform.MACOSX )
		CGLLockContext(context.getPointer());

		renderLoop();
	} finally {
		if ( LWJGLUtil.getPlatform() == Platform.MACOSX )
		CGLUnlockContext(context.getPointer());
}

is there any particular reason why there is OS X specific code in the gears demo? commented it out and still works fine on OS X, is it needed?

[spasi]

is there any particular reason why there is OS X specific code in the gears demo? commented it out and still works fine on OS X, is it needed?

You'll find that it will crash if you try to resize the window, because the AppKit thread "hijacks" the context. That's why you need locking, two threads may be accessing the context at the same time. Another drawback is that the windowRefresh callback is basically useless with the current implementation. Normally it's called during resize, so that you can redraw your app and avoid flicker. With the current event queuing scheme it's too late by the time the refresh event is received.

This is all the unfortunate consequence of how OS X works and how GLFW was (logically) designed. LWJGL can probably offer two modes:

- Use XstartOnFirstThread, use GLFW just like it was meant to (everything on the first/main thread), never touch AWT.
- Current scheme, with the drawbacks/gotchas mentioned.

Anything else would probably require a custom implementation or hacking GLFW.

[kappa]

Ah ok, that explains it. Anyway started experimenting on writing a basic LWJGL2 compatibility layer will post something about it shortly.

[kappa]

Working on the basic compatibility layer, however in org.lwjgl.openal.AL10, the following method seems to be missing/different

public static void alSourceStop(java.nio.IntBuffer sources);

in lwjgl 3 there is however the method

public static void alSourceStop(int n, java.nio.ByteBuffer sources);

what's the difference and reason for the change?

[spasi]

Thanks, has been fixed. New nightly will be up soon.

[kappa]

thx for the quick fix.

On windows 32bit getting the following error when trying to play sound

Caused by: java.lang.RuntimeException: Failed to locate the OpenAL library
   at org.lwjgl.openal.ALC$1.<init>(ALC.java:63)
   at org.lwjgl.openal.ALC.<clinit>(ALC.java:45)
   ... 7 more

Same code works fine on OS X 10.10.

[spasi]

I don't see an issue locally, could you post your JVM launch arguments? Also output with -Dorg.lwjgl.util.Debug=true would be useful.

[kappa]

I don't see an issue locally, could you post your JVM launch arguments? Also output with -Dorg.lwjgl.util.Debug=true would be useful.

Not using any extra JVM Launch arguments (other than setting the path to the natives as normal), OpenGL demo's not using sound work fine, using the argument "-Dorg.lwjgl.util.Debug=true" the output is as follows:

[LWJGL] Version 3.0.0a
Use -fullscreen for fullscreen mode
[LWJGL] MemoryUtil MemoryAccessor: MemoryAccessorUnsafe
[LWJGL] Failed to load C:\Documents and Settings\workspace\testl\native\windows\x86\OpenAL32.dll: Failed to load library: C:\Documents and Settings\workspace\testl\native\windows\x86\OpenAL32.dll (error code = 0)
[LWJGL] Failed to load C:\Documents and Settings\workspace\testl\OpenAL32.dll: Failed to load library: C:\Documents and Settings\workspace\testl\OpenAL32.dll (error code = 126)
[LWJGL] Failed to load OpenAL32.dll: Failed to load library: OpenAL32.dll (error code = 126)
Exception in thread "main" java.lang.ExceptionInInitializerError
   at org.lwjgl.openal.AL$1.<init>(AL.java:29)
   at org.lwjgl.openal.AL.<clinit>(AL.java:24)
   at org.lwjgl.demo.glfw.spaceinvaders.SoundManager.initialize(SoundManager.java:120)
   at org.lwjgl.demo.glfw.spaceinvaders.Game.initialize(Game.java:251)
   at org.lwjgl.demo.glfw.spaceinvaders.Game.<init>(Game.java:186)
   at org.lwjgl.demo.glfw.spaceinvaders.Game.main(Game.java:594)
Caused by: java.lang.RuntimeException: Failed to locate the OpenAL library
   at org.lwjgl.openal.ALC$1.<init>(ALC.java:63)
   at org.lwjgl.openal.ALC.<clinit>(ALC.java:45)
   ... 7 more

[spasi]

kappa, a new build which may solve the problem is up.

[kappa]

kappa, a new build which may solve the problem is up.

can confirm new builds solves problem, nice work.

[kappa]

Trying to read the available display modes using glfwGetVideoModes(long, ByteBuffer/IntBuffer); however seems a bit tricky and difficult to do.

Noticed that glfwGetVideoMode() has the convenient GLFWvidmode type, this makes it pretty easy to use that method, is there some equivalent type or utility to make this easy for glfwGetVideoModes() too?

Maybe there could be an overloaded version of glfwGetVideoModes(long) that could return an array of GLFWvidmode's or an array of ByteBuffers (which could then be read with the GLFWvidmode type)?

[spasi]

The style and utilities provided by the struct classes is one of the things I'd like to revisit, after the alpha release. I want to wait for more feedback, but we certainly can make them more convenient. Your suggestion is noted of course.

With that said, this is the intended usage, with the current API:

IntBuffer count = BufferUtils.createIntBuffer(1);
ByteBuffer modes = glfwGetVideoModes(monitor, count);
for ( int i = 0; i < count.get(0); i++ ) {
	modes.position(i * GLFWvidmode.SIZEOF);

	int w = GLFWvidmode.width(modes);
	int h = GLFWvidmode.height(modes);
	int r = GLFWvidmode.refreshRate(modes);

	System.out.println(w + " x " + h + " @ " + r + "Hz");
}

[kappa]

The style and utilities provided by the struct classes is one of the things I'd like to revisit, after the alpha release. I want to wait for more feedback, but we certainly can make them more convenient. Your suggestion is noted of course.

With that said, this is the intended usage, with the current API:

IntBuffer count = BufferUtils.createIntBuffer(1);
ByteBuffer modes = glfwGetVideoModes(monitor, count);
for ( int i = 0; i < count.get(0); i++ ) {
	modes.position(i * GLFWvidmode.SIZEOF);

	int w = GLFWvidmode.width(modes);
	int h = GLFWvidmode.height(modes);
	int r = GLFWvidmode.refreshRate(modes);

	System.out.println(w + " x " + h + " @ " + r + "Hz");
}

cool, the above seems good enough for my needs.

[kappa]

GL11.GL_COLOR_INDEX seems to be missing in LWJGL3