LWJGL3 with Oculus Rift - OVR SDK 0.8.0.0

[BrickFarmer]

It's been a while (another relocation) but I'm just updating my ye olde openGL Oculus example.  I see quite a bit has changed on both libs, and I had a couple of questions or clarifications on my asumptions:

1. SharedLibraryLoader is no longer required, and no java.library.path  -very nice especially with maven since no stress with natives
2. ovr_GetTrackingState(hmd, ftiming, true, hmdState);  requires boolean vs ovrTrue?
3. Is there some deallocation required for statements like this: OVRPosef.Buffer outEyePoses = OVRPosef.createBuffer(2);  or is the only explicit free() required for explicit malloc /calloc?
4. initParams.LogCallback(callback.address());  - was missing .address() in HelloLibOVR.java
5. is there a replacement for Sys.JNI_LIBRARY_NAME

Anyway my example is running, and checked in, albiet without any free() calls...  My next task
Thanks for including OVR in the final build!

[spasi]

1. SharedLibraryLoader is no longer required, and no java.library.path  -very nice especially with maven since no stress with natives

Yes, the SharedLibraryLoader is now used automatically if normal init fails.

2. ovr_GetTrackingState(hmd, ftiming, true, hmdState);  requires boolean vs ovrTrue?

This is similar to GLboolean, which is mapped to boolean instead of byte. Byte is annoying in Java because it requires a cast if you pass a literal.

3. Is there some deallocation required for statements like this: OVRPosef.Buffer outEyePoses = OVRPosef.createBuffer(2);  or is the only explicit free() required for explicit malloc /calloc?

The create methods use BufferUtils and hence do not require an explicit free. The malloc/calloc methods do.

Note that createBuffer(int capacity) has been renamed to just create(int capacity) in the nightly builds.

4. initParams.LogCallback(callback.address());  - was missing .address() in HelloLibOVR.java

There have been many improvements to the struct APIs and this is one of them (.address() is called internally).

5. is there a replacement for Sys.JNI_LIBRARY_NAME

Yes, JNI_LIBRARY_NAME is now in org.lwjgl.system.Library.

[BrickFarmer]

thanks for the clarifications!

I've adjusted my code now with some free calls, and everything still runs fine but I'm less than certain in my usage of free().  For example if I malloc/calloc and then pass off a structure to an OVR call, can I then free that memory straight away? ie. will native calls take a copy or do I need to add a load of global variable to hold that memory references until I close the app.

I also have a call for memAllocPointer that I'm not sure of the memory responsibilities.

https://github.com/WhiteHexagon/example-lwjgl3-rift/blob/master/src/main/java/com/sunshineapps/rift/experimental/RiftWindow0800.java

Is there a replacement for Sys.getVersion()?
btw Is the new nightly you mentioned going to be 3.0.0c

Cheers

[spasi]

I've adjusted my code now with some free calls, and everything still runs fine but I'm less than certain in my usage of free().  For example if I malloc/calloc and then pass off a structure to an OVR call, can I then free that memory straight away? ie. will native calls take a copy or do I need to add a load of global variable to hold that memory references until I close the app.

There is no general rule for this question, it depends entirely on the specific API. Most C functions copy their arguments, but there's usually documentation when they don't.

I also have a call for memAllocPointer that I'm not sure of the memory responsibilities.

https://github.com/WhiteHexagon/example-lwjgl3-rift/blob/master/src/main/java/com/sunshineapps/rift/experimental/RiftWindow0800.java

You're missing a memFree(pHmd) after pHmd.get(0).

Is there a replacement for Sys.getVersion()?

See the org.lwjgl.Version class.

btw Is the new nightly you mentioned going to be 3.0.0c

No, it's going to be just 3.0.0 (without a build type postfix), the first production ready release.

[BrickFarmer]

No, it's going to be just 3.0.0 (without a build type postfix), the first production ready release.

It might be worth to add something like build number into the Version class?  I remember automating this once with the ant buildnumber task, and a code substitution at build time on a class variable.  It might make it easier for developers that need to reference/discuss a particular nightly, just an idea

Anyway I've applied the fixes, and now I'm finnaly working on the modern openGL version.  Although I seem to be running out of time with the Oculus pre-orders going live today!  I was using an example from Sri Harsha Chilakapati, but it seems to be out of date with the new API changes.  Can you please point me at a simple 'triangle demo' with keyboard mouse usage similar to the tutorial1? or just something that describes the parameters to the following:

        glfwSetErrorCallback(errorCallback);
        glfwSetKeyCallback(windowID, keyCallback);
        glfwSetCursorPosCallback(windowID, cursorPosCallback);
        glfwSetMouseButtonCallback(windowID, mouseButtonCallback);
        glfwSetScrollCallback(windowID, scrollCallback);

since things like GLFWKeyCallback no longer are correct?
Apologies that I am still playing catchup with the last few months changes.

[Kai]

For thorough GLFW API examples:
https://github.com/LWJGL/lwjgl3/tree/master/modules/core/src/test/java/org/lwjgl/demo/glfw

For modern and advanced OpenGL usage:
https://github.com/LWJGL/lwjgl3-demos/tree/master/src/org/lwjgl/demo/opengl

Optionally, OpenGL with LWJGL 3 and JOML:
https://github.com/JOML-CI/joml-lwjgl3-demos/tree/master/src/org/joml/lwjgl

[spasi]

It might be worth to add something like build number into the Version class?  I remember automating this once with the ant buildnumber task, and a code substitution at build time on a class variable.  It might make it easier for developers that need to reference/discuss a particular nightly, just an idea

It already exists as part of the version string (see the Version.getVersion() method). The build number is stored in the manifest of lwjgl.jar. This was broken in the beta release, but it's fixed in the nightly builds.

since things like GLFWKeyCallback no longer are correct?

You do you mean? The callbacks haven't changed recently.

[BrickFarmer]

I'm just porting my code to SNAPSHOT, and just wanted to confirm 2 things.  Firstly that snapshot is no longer 3.0.0b-SNAPSHOT, but is now just 3.0.0-SNAPSHOT?

Also I have this snippet:

        
textureSetOne = new OVRSwapTextureSet(MemoryUtil.memByteBuffer(hts, OVRSwapTextureSet.SIZEOF));
        texturesPerEyeCount = textureSetOne.TextureCount();
...
        long hTextures = textureSetOne.Textures().address();

The last line no longer compiles (problem with Textures() call) after switching from 3.0.0b and I cant work out the equivalent, can someone help me with that please?

[spasi]

Firstly that snapshot is no longer 3.0.0b-SNAPSHOT, but is now just 3.0.0-SNAPSHOT?

Yes.

Also I have this snippet:

        
textureSetOne = new OVRSwapTextureSet(MemoryUtil.memByteBuffer(hts, OVRSwapTextureSet.SIZEOF));
        texturesPerEyeCount = textureSetOne.TextureCount();
...
        long hTextures = textureSetOne.Textures().address();

The last line no longer compiles (problem with Textures() call) after switching from 3.0.0b and I cant work out the equivalent, can someone help me with that please?

The Textures field is a pointer to an array of ovrTexture structs. This is mapped to an OVRTexture.Buffer in LWJGL. Since LWJGL doesn't know how big the array is, you must specify the capacity in the "getter", like so:

OVRTexture.Buffer textures = textureSetOne.Textures(texturesPerEyeCount);

textureSetOne = new OVRSwapTextureSet(MemoryUtil.memByteBuffer(hts, OVRSwapTextureSet.SIZEOF));

The above can be written concisely like so:

textureSetOne = OVRSwapTextureSet.create(hts);