[RFE] LWJGL 3.0

[spasi]

I'm afraid I'm still super busy at work and haven't had any free time lately. Once the storm passes, I'll focus first on doing the 3.0a release (which is long overdue) and then work on new features.

[Wolftein1]

Question:

Running an empty loop gives me about 50.000.000 execution per second, but after adding glfwSwapBuffers its slowed down to only 250 executions per second; is that how it suppose to work? (Take in mind i'm not rendering anything). I'm using lastest LWJGL3 stable version.

My current hardware is:

CPU: Intel I7 950.
GPU: NVIDIA GTX 570
Driver: Lastest Nvidia drivers.
OS: Windows 8.1 Home Premium.
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

UPDATE: Set GLFW.DOUBLE_BUFFER to false and now i get upto 30.000 executions per second (Desired) just using glfwSwapBuffers, is that a bug? shouldn't DOUBLE_BUFFER be deactivated by default?

[spasi]

Dear LWJGL users,

I'm excited to announce that LWJGL 3.0a is ready to be released. Please, if you've got the time, download the current nightly build (#45) and give it a spin. If no problems are reported, it will be promoted as the first official release.

Latest noteworthy changes:

- Java methods now have the same postfixes as the corresponding native functions (see this thread for details).
- Updated the GLFW and OpenAL Soft binaries to the latest versions. LibFFI is on 3.1.1, newer revisions are still broken on MSVC.
- Added support for the Objective-C Runtime. With the existing LibFFI bindings, you now have a (disgustingly horrible) way to use Cocoa APIs, if you have to.
- Added support for libOVR, the C API of the Oculus Rift SDK. The bindings are up-to-date with the recently released 0.5.0.1-beta SDK.
- The build is now "modular", which means that if you decide to manually build LWJGL, you have the option to include or exclude any bindings you like. For example, if you never use OpenCL, you can exclude it from the build. Currently, the default build includes all modules, except libOVR.
- There's been much effort to simplify the build process and make it easier for contributors to get started. The IntelliJ project should now work out-of-the-box. If you're a Rift user and would like to build LWJGL with libOVR enabled, all you have to do is extract the Oculus SDK somewhere and point to it in config/build-modules.xml.
- The dynamically linked libraries that LWJGL must load at runtime have all been moved to the same location (see this discussion). The old "/os/arch/" structure is now gone. The x64 binaries are simply named (e.g. lwjgl.dll, OpenAL.dll), while the x86 binaries have a "32" postfix (e.g. lwjgl32.dll, OpenAL32.dll).

Features coming soon:

- Gradle build + Maven deployment
- Mantle bindings

Features coming later:

- Support for all (still relevant) OpenGL extensions
- EGL and OpenGL ES bindings
- Vulkan bindings (when the spec is released)
- D3D12 bindings

There will be a post on the LWJGL blog with more details.

[SHC]

I'm just updating my code to #45 from #41, and my code did break at some places, but I think most of them are intended. Here are the differences that I have noticed.

• The post suffix fv for glUniformMatrix4 calls.
• The natives file locations
• The GLFWgammaramp class seems to have missing out the malloc(short, short, short, int) method. It's now taking long variables instead.
• The getSize method of the GLFWgammaramp class seems returning 256 when there are only 128 elements in the buffer.
  
  
  
  I'm creating the arrays with length returned from the getSize method. Can you please give me clarity on what maybe wrong here?

Everything else is fine with this build.

[spasi]

The postfixes and new native file locations are intended, as explained above.

GLFWgammaramp never had a malloc(short, short, short, int), it was malloc(long, long, long int). That method is now gone though, there's only malloc(ByteBuffer, ByteBuffer, ByteBuffer, int).

getSize returns the value stored in the GLFWgammaramp.size field, which should be 256.

[SHC]

Thanks for clearing it, but the returned buffers only have 128 elements? That's what I'm not able to understand.

[spasi]

I'm guessing here, but I think you're calling the getRed(int), getGreen(int), getBlue(size) methods and pass the value returned from getSize() there. Then, you're probably converting the ByteBuffers to ShortBuffers.

The problem is that getSize() returns the number of elements in each buffer, but the getR/G/B methods expect a byte size. So, if getSize() returns 256, you should pass 256*2 = 512 to the getR/G/B methods.

[SHC]

Thanks a lot, that worked awesome. There are no other issues, everything is fine.

[kappa]

oh, nice changes, upgraded fine here (only minor code changes needed) and works nicely.

Good job.

[spasi]

This is a good opportunity to mention that structs in general will be redesigned before the final 3.0 release (most likely in a breaking way). In GLFWgammaramp's case, we should either change the getters/setters to use ShortBuffers instead of ByteBuffers, or change the size argument to always mean elements instead of bytes.

I have not been happy with the current situation and Java (the language) doesn't help at all. There hasn't been much feedback or suggestions from users either. I'm also planning to improve Javadoc generation for structs, so that non-obvious fields can be documented. Note that new APIs, like Mantle and Vulkan, make heavy use of structs (vs having tons of methods, like in OpenGL). We didn't have to worry about this in LWJGL 2, but in 3 we'll have to provide a decent solution. For example, an (optional) integration with LibStruct would be nice.

[kappa]

Are the Projects Valhalla or Panama going to be of any help to LWJGL's structs implementation? If so, might be worth waiting for them as an official solution.

Just curious, is the Mantle library even relevant anymore or worth implementing? given that its specific to AMD hardware (and the Windows OS, unlikely to come to Mac or Linux now) and most companies are throwing their weight behind Vulkan (including AMD) and will likely do what Mantle does but better.

[spasi]

Are the Projects Valhalla or Panama going to be of any help to LWJGL's structs implementation? If so, might be worth waiting for them as an official solution.

Valhalla, no. Anything they do will be heap-based for sure. Super-interesting and useful if you're doing server programming, but does nothing for native interop. Panama is more promising, but we're talking Java 10 (at best). LWJGL 4 will be out when that's mainstream enough.

Just curious, is the Mantle library even relevant anymore or worth implementing? given that its specific to AMD hardware and most are now throwing their weight behind Vulkan (including AMD) and will likely do what Mantle does but better.

Yes, for a few reasons:

- It won't affect the official LWJGL build. The Mantle bindings will be an optional module and you'll have to manually build LWJGL to use it. It's currently Windows-only anyway.

- Mantle is not dead. AMD will use it as a faster way to get exciting new features to customers. Like NV's CUDA. If you only care about Mantle 1.0 features, then obviously Vulkan will be better (and that's AMD's suggestion too).

- I think many people are excited about Vulkan and Mantle is a very nice way to get a glimpse of what's coming. The two APIs are very similar and you can start preparing for Vulkan right now.

[kappa]

just tested LWJGL3.0a on Windows XP, 32bit but getting the following exception on startup:

[LWJGL] Version 3.0.0a | Windows XP | x86
[LWJGL] MemoryUtil MemoryAccessor: MemoryAccessorUnsafe

INFO: Initialising sounds..
Exception in thread "main" java.lang.ExceptionInInitializerError
   at org.lwjgl.openal.ALDevice.create(ALDevice.java:71)
   at org.lwjgl.openal.ALDevice.create(ALDevice.java:60)
   at org.ninjacave.mech.audio.SoundStore.createAL(SoundStore.java:80)
   at org.ninjacave.mech.audio.SoundStore$1.run(SoundStore.java:294)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.ninjacave.mech.audio.SoundStore.init(SoundStore.java:291)
   at org.ninjacave.mech.Sound.<init>(Sound.java:54)
   at org.ninjacave.game.topjump.GameState.init(GameState.java:34)
   at org.ninjacave.mech.App.initStates(App.java:208)
   at org.ninjacave.mech.App.init(App.java:171)
   at org.ninjacave.mech.App.start(App.java:152)
   at org.ninjacave.game.topjump.TopJump.main(TopJump.java:14)
Caused by: java.lang.RuntimeException: Failed to load library: C:\Documents and Settings\computer\workspace\myapp\native\OpenAL32.dll (error code = 0)
   at org.lwjgl.system.windows.WindowsPlatform.windowsThrowException(WindowsPlatform.java:34)
   at org.lwjgl.system.windows.WindowsLibrary.<init>(WindowsLibrary.java:33)
   at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:54)
   at org.lwjgl.LWJGLUtil$2.load(LWJGLUtil.java:403)
   at org.lwjgl.LWJGLUtil$2.load(LWJGLUtil.java:400)
   at org.lwjgl.LWJGLUtil.loadLibrary(LWJGLUtil.java:411)
   at org.lwjgl.LWJGLUtil.loadLibraryNative(LWJGLUtil.java:371)
   at org.lwjgl.openal.ALC.create(ALC.java:55)
   at org.lwjgl.openal.ALC.create(ALC.java:48)
   at org.lwjgl.openal.ALC.<clinit>(ALC.java:27)
   ... 12 more

[spasi]

just tested LWJGL3.0a on Windows XP, 32bit but getting the following exception on startup:

Thanks, I cleaned-up the synchronization scrips for CI and forgot the fixes for Windows XP. Build #46 is up and should work fine.

In GLFWgammaramp's case, we should either change the getters/setters to use ShortBuffers instead of ByteBuffers, or change the size argument to always mean elements instead of bytes.

For now, I have renamed the "size" parameter to "byteLen". This avoids the confusion with the struct's size field and makes it clear that you must specify a length in bytes for the returned ByteBuffer.

[kappa]

Thanks, I cleaned-up the synchronization scrips for CI and forgot the fixes for Windows XP. Build #46 is up and should work fine.

Thanks, can confirm that it works fine now.