[RFE] LWJGL 3.0

[mtronics]

Thanks for the help but it still gives me the same errors. It seems to not find a bunch of .c files in src/native/system/windows/ prefixed with org_lwjgl_system_windows_. Could it be that the code generator missed something (although the generator doesn't give me any error)?

[spasi]

From the log you attached, the error seems to be related to stdio.h. Afaict, the generated files are fine. Have you tried building from the command prompt? Are you sure nothing has changed in the output?

[mtronics]

Yes, I tried building from the command line and I tried it again but with a new fresh copy of lwjgl 3 and messing around with Visual Studio's C compiler. Now I'm getting a different log:

(Sorry that parts of the build log are in German but it basically says that there's a lot of syntax errors)
("Es fehlt" ... "vor" ... means "... is missing in front of ..." (occurs a lot of times in the log))

[spasi]

Thanks, that last log was helpful indeed. The bug has been fixed, you can pull, do an "ant clean-generated" and try again.

[mtronics]

Yes! It worked. Thank you, Spasi!

BUILD SUCCESSFUL

[spasi]

LWJGL 3 nightly builds are now available.

This is not an official release yet, but it's usable for early adopters. An official 3.0.0a release will be done when GLFW 3.1 is released.

The new nightly build infrastructure is also used to build all binary dependencies. These are currently GLFW, openal-soft and libFFI. They are forked here, so that there is better control of their integration with LWJGL. If you're building from source, the LWJGL build scripts have been updated to download them automatically.

Build status:

- Windows builds at http://teamcity.lwjgl.org. (use the guest login)
- Linux and OSX builds on Travis CI: LWJGL3, GLFW, openal-soft, libFFI.

Download:

- Nightly: build.lwjgl.org/nightly/lwjgl.zip (bleeding edge, possibly broken)
- Stable: build.lwjgl.org/stable/lwjgl.zip (latest build that has been verified to work)
- Release - latest: build.lwjgl.org/release/latest/lwjgl.zip (latest official release, nothing here atm)
- Release - version: build.lwjgl.org/release/{version}/lwjgl-{version}.zip (replace {version} with the specific version of a previous official LWJGL release)

Enjoy! Any issues may be reported here or (preferably) on github.

[mtronics]

Cool! Will there be big API changes when the official release comes out? If not, I'm off updating my game engine

[erlend_sh]

Very exciting, nice work! Are there any notable changes to the roadmap? (last edited 17. Nov, 2013)

Regarding the small note on "post 3.0" features:

JavaFX integration.

Cool

Physics bindings. (JBullet?)

I'd say don't bother with it, as it's unmaintained and much slower than the native version. You can check out the jMonkeyEngine 3.1 sources to study bindings for native Bullet. In my honest opinion physics bindings is out of scope for LWJGL though.

Video bindings. (libVLC? ffmpeg?)

Desperately needed in Java gamedev.

[spasi]

Cool! Will there be big API changes when the official release comes out? If not, I'm off updating my game engine

Ignore the org.lwjgl.api package, it will be dropped in the next update. Other than that, there's not much API left, just bindings. There is org.lwjgl.system which is considered internal API and subject to change at any time, though it has the very useful MemoryUtil class for power-users. A lot of work has gone into it, so I think its API will be pretty stable moving forward.

Very exciting, nice work! Are there any notable changes to the roadmap? (last edited 17. Nov, 2013)

Nothing important, except maybe that the main focus right now is getting all the bindings in place (many GL/CL extensions are missing and OpenGL ES) and there's no time to explore alternative windowing systems. It's quite possible that 3.0 will ship with only GLFW (which is fantastic btw). I'd love to have JavaFX integration, but the technical limitations make it very unlikely. A compatibility layer for LWJGL 2 would also be nice to have, but not a priority right now.

Physics bindings. (JBullet?)

I'd say don't bother with it, as it's unmaintained and much slower than the native version. You can check out the jMonkeyEngine 3.1 sources to study bindings for native Bullet. In my honest opinion physics bindings is out of scope for LWJGL though.

Yeah, that J there was unnecessary. I meant direct bindings to native Bullet. I just wish it had a C API, would make things easier. Anyway, I'll work on it only if LWJGL can do a better job than JME & libGDX, they each have their own Bullet bindings afaict.

[erlend_sh]

There is some progress being made with the C-API for Bullet Physics 3:
https://github.com/bulletphysics/bullet3/issues/130

[Kai]

Great work, spasi. Thanks!

It even seems that glfw window management results in much smoother animations (far fewer micro-stutters) compared to the "old" lwjgl2.9 Display.
I have a simple application that does very simple elapsed-time-based animations and tested it under both lwjgl2.9 and now lwjgl3 with glfw, and the latter looked much smoother.

I don't know whether that has something to do with v-sync (which I disabled for both Display and glfw window).

In short: lwjgl3 with glfw is great! :-)

[spasi]

Online javadoc is up at javadoc.lwjgl.org

[Kai]

Could you have lwjgl3 be compiled with class file version 49.0 (Java 5.0) or at most 50.0 (Java 6.0) instead of 51.0?
Some client still has Java 6 installed and the current version of lwjgl3 requires a Java 7 capable JVM.

[spasi]

I'm afraid not. The decision was made early on that LWJGL3 will be Java 7+. You have a couple of options:

a) Fork the project and refactor any usage of Java 7 features. They are not too many and iirc no Java 7 APIs are being used atm.
b) Try retrolambda.

Note that most people these days ship their apps with a private JRE. The additional download overhead is insignificant for most users. It is (and has always been) a nightmare to have to depend on a pre-installed JRE on the user's machine.

[Kai]

Okay, thanks for the info.

There were really only a very few places where some diamonds must be undiamonded and some try-with-resources refactored to try-finally statements.

Apart from that: How do you bundle the compiled classes to a final jar? The build.xml in the lwjgl3 repo does not seem to have such a target. Especially, the "api" package seems to be missing when building from sources.

Cheers,
Kai