Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (512)
Games in Android Showcase (121)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  LWJGL 3 - Wiki and a progress update  (Read 6861 times)
0 Members and 1 Guest are viewing this topic.
Online Spasi
« Posted 2013-11-19 00:14:29 »

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.
  • 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.
Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2013-11-19 09:50:32 »

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

Cas Smiley

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #2 - Posted 2013-11-19 10:04:43 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline P0jahn

Senior Duke


Projects: 3



« Reply #3 - Posted 2013-11-19 10:28:26 »

Will version 3 be compatible with Slick2D or LibGDX?
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #4 - Posted 2013-11-19 11:13:32 »

Will version 3 be compatible with Slick2D or LibGDX?
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.
Offline SHC
« Reply #5 - Posted 2013-11-19 12:21:43 »

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

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #6 - Posted 2013-11-19 12:45:05 »

I had to rewrite my tutorials to be compatible with it.
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.
Offline nsigma
« Reply #7 - Posted 2013-11-19 13:50:09 »


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.

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Online Spasi
« Reply #8 - Posted 2013-11-19 14:38:52 »

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.
Offline nsigma
« Reply #9 - Posted 2013-11-19 15:01:30 »

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?

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online Spasi
« Reply #10 - Posted 2013-11-19 15:46:53 »

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.
Offline P0jahn

Senior Duke


Projects: 3



« Reply #11 - Posted 2013-11-19 22:35:26 »

What benefits will version 3 have from a gamers perspective? I am talking about stuff like performance, glitches, key stroke reaction time etc.
Online Spasi
« Reply #12 - Posted 2013-11-20 00:02:11 »

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

Senior Duke


Projects: 3



« Reply #13 - Posted 2013-11-20 17:57:03 »

multi-GPU rendering
Doesn't that count as a performance improvement?
Online Spasi
« Reply #14 - Posted 2013-11-20 18:29:05 »

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.
Offline badlogicgames
« Reply #15 - Posted 2013-11-21 19:34:40 »

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!

http://www.badlogicgames.com - musings on Android and Java game development
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #16 - Posted 2013-11-22 11:33:02 »

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.
Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2013-11-22 12:54:34 »

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

Cas Smiley

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #18 - Posted 2013-11-22 13:43:13 »

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

Cas Smiley
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.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 818
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #19 - Posted 2013-11-22 18:24:41 »

I'm a huge proponent of the new
ngl*
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
Offline SHC
« Reply #20 - Posted 2013-11-23 13:08:25 »

Why are the
ngl*
functions
public
?

Online Spasi
« Reply #21 - Posted 2013-11-23 13:22:32 »

Why are the
ngl*
functions
public
?

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.
Online Spasi
« Reply #22 - Posted 2013-11-23 21:11:52 »

I'm a huge proponent of the new
ngl*
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)
Online Spasi
« Reply #23 - Posted 2013-12-01 19:01:03 »

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.
Offline jmguillemette
« Reply #24 - Posted 2013-12-01 19:15:30 »

keep up the good work spasi!

im sure there will be hard choices. just make them and let the community give feedback. Smiley

kudos for taking this on.

j.

-=Like a post.. give the author a medal!=-
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

theagentd (12 views)
2014-10-25 15:46:29

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (45 views)
2014-10-16 15:22:06

Norakomi (34 views)
2014-10-16 15:20:20

lcass (39 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (68 views)
2014-10-14 00:35:47

TehJavaDev (60 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!