LWJGL 3 - Wiki and a progress update

Why are the [icode]ngl*[/icode] functions [icode]public[/icode]?

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.

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 glGetInfo methods for easy information queries on OpenCL objects.
  • [icode]clSetKernelArg[/icode] 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.

keep up the good work spasi!

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

kudos for taking this on.

j.