It is not complete, but it has important information that I felt should readily be available to potential users and contributors. Please let me know if you'd like anything fixed, if something requires better explanation or if I've missed an important aspect of the project that deserves to be documented.

The wiki now has a long to-do list, so there's plenty more work to be done. The current plan is to wait for GLFW 3.0.4 (contains many important fixes) and then we'll release an alpha build for all platforms. If you'd like to try it out sooner, feel free to clone the project and build manually, I've tried to make it as easy as possible. If you encounter any issues, please do let me know.

Its very likely that JInput will be dropped in LWJGL3 as the main backend for Controllers and switched to use the GLFW3 Joystick API's. If its the actual API, there are some new methods coming for Controllers in the upcoming LWJGL 2.9.1 release that might help.

LWJGL3 is not going to be backwards compatible with LWJGL2 so as a drop in replacement Slick and LibGDX won't be compatible. There is a full rationale on the wiki above why this needs to be done.

However only a handful of the LWJGL API's are going to need changing/replacing and it should be a relatively easy task to migrate a LWJGL2 code base to LWJGL3. Besides if there is a need, a backward compatibility layer could be written on top of LWJGL3 which could allow LWJGL2 apps to work without any changes to them.

I'd wait a bit for the API to settle down a little more and there being a build people can actually use, before rewriting tutorials for it as much could still change.

Historically its been difficult to get involved with LWJGL as parts of it have been undocumented, too complex (entangled with too much) or inner workings of bits being familiar only to a few. LWJGL3 intends to change that, its a ground up rewite designed to be clean, modular, well documented, well tested and easier to approach for willing contributors.

Of course the original spirit remains roughly the same of being just a small, fast, simple & minimal enabling library.

There is a need for more contributors to help shape the direction it'll take, hence the wiki at this early stage to help people get involved, let them know what all the pieces do, what's done, what needs to be done and where project may be heading. So if you do intend to use the project in the future now is a good chance to get involved.

Is this purely an optional binding, or is LWJGL shipping with / dependent on libffi? If the latter (excuse my lack of understanding of linking!) then is this done in a way that wouldn't conflict with other loaded versions of libffi? Thinking particularly that I know various applications (my own included) that use LWJGL and JNA.

Is this purely an optional binding, or is LWJGL shipping with / dependent on libffi? If the latter (excuse my lack of understanding of linking!) then is this done in a way that wouldn't conflict with other loaded versions of libffi? Thinking particularly that I know various applications (my own included) that use LWJGL and JNA.

libffi is very small, so it's currently statically linked into the LWJGL binary. It is there for users that would like to call native functions for which LWJGL does not provide bindings out of the box. So it is indeed meant to be optional/advanced functionality. If static linking causes trouble, it can easily be refactored to dynamic linking.

libffi ... is there for users that would like to call native functions for which LWJGL does not provide bindings out of the box. So it is indeed meant to be optional/advanced functionality. If static linking causes trouble, it can easily be refactored to dynamic linking.

OK, thanks for the info. I'll do some testing when there's an alpha build.

If it's purely meant for optional / advanced functionality, are there advantages to doing this above suggesting JNA?

If it's purely meant for optional / advanced functionality, are there advantages to doing this above suggesting JNA?

It's just a lightweight alternative that you could use with one less runtime dependency. Ideally you'd only need it for a couple of function calls that LWJGL bindings don't cover, so you can avoid bringing in another whole library just for that. It's a direct binding to libffi's functions, so it's close to the metal and has nowhere the user-friendliness (and complexity) of JNA. It roughly corresponds to a few methods exposed in com.sun.jna.Native, but you do get the standard LWJGL overloaded methods that accept ByteBuffer/PointerBuffer/etc and there are also helper classes for the ffi_cif and ffi_type structs. Performance should be ideal for what libffi does (roughly 30% slower than JNI in a few of my tests), but you do pay the price of going low-level (and unsafe) to use it.

Do note that libffi's "closures" (basically, runtime callback generation) have not been exposed, so if you need that feature you should stick with JNA anyway. There are a few good reasons to avoid closures, but I may end up revisiting this decision in the future.

LWJGL 3 is about features and robustness, not performance. You can do stuff with 3 that couldn't do with 2 (prime example: multiple native windows) and you'll get more features faster in the future. You'll be able to more easily implement custom features of your own (e.g. integration with SWT, multi-thread and multi-GPU rendering). LWJGL also directly benefits from how robust the GLFW implementation is and how many edge-cases it deals with, meaning you'll encounter less issues and less bug-reports from users.

From a pure performance perspective, technically LWJGL 3 does have a slight edge because it enables direct (and obviously unsafe) pointer management. If you're feeling adventurous, there can be situations where that flexibility enables skipping unnecessary work (e.g. in tight loops). But then you're also likely to be affected by JNI overhead and getting around that requires either custom native code (moving the loop to C) or JVM changes (a built-in FFI mechanism that eliminates the overhead completely).

As I said, the main focus of LWJGL 3 is to expose useful functionality. It's a library, not a framework or engine. In this case, vendor and platform specific extensions useful to multi-GPU rendering, like AMD_gpu_association and NV_gpu_affinity, will be directly accessible. You can use them however you like and there won't be abstraction obstacles in the way, like in LWJGL 2. That's a feature. LWJGL makes no promises about performance and it's up to you, or high-level frameworks like libGDX, to make the most out of the exposed functionality.

Awesome stuff, we'll definitely switch to 3 as soon as you consider it stable. Little worried about the problems we had with GLFW on Mac OS X. Nate send some patches, and i think the main author also did some fixes. Hoping for the best.

Awesome stuff, we'll definitely switch to 3 as soon as you consider it stable. Little worried about the problems we had with GLFW on Mac OS X. Nate send some patches, and i think the main author also did some fixes. Hoping for the best.

Thanks for all the hard work!

Yeh we also ran into the similar issues with the initial versions of LWJGL3 using GLFW not liking the OS X JVM, however spasi sorted that and seems to be working pretty nicely now.

Anyway if you do get a chance, do drop any feedback that you may have or things you'd like for LibGDX.

All Cocoa application need an application loop to run and have a main thread (Thread-0).

The JVM on OS X (both Apple and Oracle JVM's) by default reserve the main thread for AWT (which uses Cocoa internally) and its cocoa application loop. All java code by default therefore runs on threads other than the main thread (including JNI calls).

GLFW also starts its own cocoa application loop, so if you call any AWT (however small it may be) it starts the AWT cocoa application loop on the main thread, causing a situation where you have two cocoa application loops running in the same application, this causes everything to blow up. That is the problem I think badlogicgames was referring to.

Therefore we've had to implement special workarounds for this JVM behaviour in both LWJGL2 and LWJGL3.

methods, but I fear the function pointer parameter ruins it for practical use. I'd be thrilled with an ngl* like, non-native method, with the same parameters, except, ofcourse, the last one, which would set the function pointer in its body.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

It is briefly explained in this page, see the end of the first question. These functions enable direct pointer arithmetic, which means cleaner code or even better performance in some cases. I'll add examples in the wiki when I write the AL/GL/CL guides. They also can be used by anyone to create custom wrappers around the raw functions.

methods, but I fear the function pointer parameter ruins it for practical use. I'd be thrilled with an ngl* like, non-native method, with the same parameters, except, ofcourse, the last one, which would set the function pointer in its body.

This is now implemented for all methods with pointer argument/return types. You can see the generated code diff here. (warning: 17MB of HTML content)

I just completed a painful refactoring that breaks OpenCL API compatibility with LWJGL 2.x. All pointer wrapper classes have been removed and the bindings now use raw pointer values. I've been struggling with this issue since I started working on LWJGL 3 (there are pros and cons either way), but ultimately decided this is the best choice given the approach we're taking with 3.

On its own, this is obviously a major loss of utility, but I've tried to replace the old functionality as best as I could. Specifically:

The CLPlatform and CLDevice classes remain, but they're entirely optional. They're mainly containers for the CLCapabilities instances (which are expensive to create) and provide the familiar getPlatforms/getDevices methods. You can also create your own CLCapabilities instances if you prefer to store them in some other way.

There is a new generated class org.lwjgl.opencl.Info that can be statically imported. It provides custom glGet<object>Info<type> methods for easy information queries on OpenCL objects.

clSetKernelArg

has been overloaded with primitive versions, for all types and up to vector of 4 values. You can see that here. I'm still not sure if these should be moved to a custom class, similar to Info.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org