LWJGL 3 - Wiki and a progress update

Engines, Libraries and Tools
#1

LWJGL 3 now has a dedicated Wiki.

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.

Recent changes:

  • OS X is now supported.
  • Updated GLFW to v3.0.3.
  • Added JavaDoc generation.
  • Added libffi bindings.
  • The required minimum JDK version is now 7.
    [li]Many fixes and improvements to code generation & documentation.

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.

#2

Great Wiki Spasi. What’s the score with input APIs? I’ve found Controllers to be particularly troublesome.

Cas :slight_smile:

#3

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.

#4

Will version 3 be compatible with Slick2D or LibGDX?

#5

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.

#6

It’s a better api when compared to the previous versions, but I had to rewrite my tutorials to be compatible with it. No static methods in the [icode]Display[/icode] class, no utility jar file, and many other things, I had to rewrite a lot of code to make it future compatible. It is good to include a physics library, and many optimisations.

But overall, it is very nice api than the past one with support to multiple GL windows.

#7

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.

#8

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.

#9

[quote=“nsigma,post:8,topic:45131”]
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.

#10

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?

#11

[quote=“nsigma,post:10,topic:45131”]
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.

#12

What benefits will version 3 have from a gamers perspective? I am talking about stuff like performance, glitches, key stroke reaction time etc.

#13

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).

#14

[quote=“Spasi,post:13,topic:45131”]
Doesn’t that count as a performance improvement?

#15

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.

#16

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!

#17

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.

#18

What do you mean by “the OSX JVM” in this context?

Cas :slight_smile:

#19

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.

#20

I’m a huge proponent of the new [icode]ngl*[/icode] 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.