Hello Guest

Recent Posts

Pages: 1 ... 7 8 [9] 10
81
Vulkan / Re: 3.3.2 native JARs missing at MavenCentral
« Last post by spasi on June 24, 2023, 15:35:32 »
The Vulkan bindings do not require natives to work. LWJGL calls the functions provided by the Vulkan loader/driver directly (via the org.lwjgl.system.JNI class, which lives in the core LWJGL library).

The native jars for macOS are there because macOS does not natively support Vulkan. They contain a build of MoltenVK, which is a Vulkan emulation layer over the Metal API.
82
Vulkan / 3.3.2 native JARs missing at MavenCentral
« Last post by sgold on June 24, 2023, 11:23:19 »
I'm trying to build a Vulkan app using Gradle and LWJGL v3.3.2 on Windows 11.
I get the following build error:

```console
> Error while evaluating property 'relativeClasspath' of task ':app:startScripts'.
   > Could not resolve all files for configuration ':app:runtimeClasspath'.
      > Could not find lwjgl-vulkan-3.3.2-natives-windows.jar (org.lwjgl:lwjgl-vulkan:3.3.2).
        Searched in the following locations:
            https://repo.maven.apache.org/maven2/org/lwjgl/lwjgl-vulkan/3.3.2/lwjgl-vulkan-3.3.2-natives-windows.jar
```

When I browse to https://repo.maven.apache.org/maven2/org/lwjgl/lwjgl-vulkan/3.3.2
I see there are natives for macos and macos-arm64, but not for Linux or Windows.

How should I obtain Linux/Windows native JARs for Vulkan?
83
Bug Reports / RFE / Re: [BUG] Potential issue with Linux natives?
« Last post by foxel on June 21, 2023, 19:36:04 »
Ah thank you.  My mistake for not updating LWJGL on my build machine recently.
84
Bug Reports / RFE / Re: [BUG] Potential issue with Linux natives?
« Last post by spasi on June 21, 2023, 18:14:27 »
Hey foxel,

Please upgrade to LWJGL 3.3.2. The Linux x64 build now only requires GLIBC 2.17 and GLIBCXX 3.4.19, or higher. See this for more details.
85
Bug Reports / RFE / [BUG] Potential issue with Linux natives?
« Last post by foxel on June 20, 2023, 21:49:25 »
Hello, I'm getting ready to release a LWJGL game on Steam, and had an interesting bug come up in the Steam forums:

https://steamcommunity.com/app/2277110/discussions/0/3816284554973125189/

Now, I am absolutely not an expert with compiling or packaging Linux libraries, so I can't really speak to what's going wrong here.  My game runs without issue on Ubuntu and SteamOS, so something about the poster's custom minified Linux is surfacing this, and I don't have a way to repro the crash.

I really don't have the Linux knowledge or time to be supporting custom Linux distros.  Is this something that could be fixed in an update to LWJGL?
86
Ah, I had not noticed that while XrActionSuggestedBinding.create() returns a XrActionSuggestedBinding that XrActionSuggestedBinding.create(number) returns a Buffer. I was looking for a XrActionSuggestedBinding.Buffer.create(number) not finding it, and ending up creating something weird.

That simplifies things a lot. Thanks
87
No, new Thing.Buffer(BufferUtils.createByteBuffer(Thing.SIZEOF)) is not the recommended way to do it. It works, but that constructor is there in case you already have some memory around and you need to "cast" it to a specific struct type.

Typically, you'd do:

Code: [Select]
Thing.Buffer myThings = Thing.create(10); // myThings is now a pointer to an array of 10 Thing structs
You can replace create with malloc/calloc for explicit memory management.
88
Hmm, you're right. I was convinced I had introduced the suggested lines one by one and that was the point it started working but I must have made a mistake. Thanks.

Just for my understanding, most OpenXR LWJGL stuff is created with a
Code: [Select]
Thing.create(); but the XrActionSuggestedBinding.Buffer is created with a
Code: [Select]
new Thing.Buffer(BufferUtils.createByteBuffer(Thing.SIZEOF));. Why the difference? Is it because XrActionSuggestedBinding.Buffer is an array?
89
Hey Richtea,

Both ways to initialize XrActionSuggestedBinding are equivalent. The allocated memory is zero-initialized either way, so ChatGPT is not helpful here. The difference is that the first way uses a GC-managed ByteBuffer as the backing memory (created with ByteBuffer.allocateDirect), whereas the second way uses memory allocated with calloc, which must be explicitly freed to avoid a memory leak. Recommended reading: Memory management in LWJGL

Afaict, the second way works because you added .type(XR10.XR_TYPE_INTERACTION_PROFILE_SUGGESTED_BINDING). It is missing from the original code.
90
I asked chatgpt and it suggested I change it to this

Code: [Select]
XrActionSuggestedBinding.Buffer suggestedBindingsBuffer = XrActionSuggestedBinding.calloc(1)
        .action(action.address())
        .binding(xClickPathBuffer.get());

XrInteractionProfileSuggestedBinding xrInteractionProfileSuggestedBinding = XrInteractionProfileSuggestedBinding.calloc()
        .type(XR10.XR_TYPE_INTERACTION_PROFILE_SUGGESTED_BINDING)
        .next(NULL)
        .interactionProfile(oculusProfilePath.get())
        .suggestedBindings(suggestedBindingsBuffer);

withResponseCodeLogging("xrSuggestInteractionProfileBindings", XR10.xrSuggestInteractionProfileBindings(xrInstance, xrInteractionProfileSuggestedBinding));

Which works! Which freaks me out slightly. I think the actual change that was needed (which was a part of the changes chatpt suggested) was that I shouldn't be doing

Code: [Select]
XrActionSuggestedBinding.Buffer suggestedBindingsBuffer = new XrActionSuggestedBinding.Buffer(BufferUtils.createByteBuffer(XrActionSuggestedBinding.SIZEOF));
But should be doing

Code: [Select]
XrActionSuggestedBinding.Buffer suggestedBindingsBuffer = XrActionSuggestedBinding.calloc(1)
It seems like quite a useful explanation so here is why chatgpt said the working version is better

Quote
In Java, when working with LWJGL bindings, it's usually safer and more convenient to use the calloc methods provided by the LWJGL data structures. This method allocates and initializes the buffer for you, which can help avoid issues with uninitialized fields or incorrectly-sized buffers.

In contrast, BufferUtils.createByteBuffer just allocates a block of memory and gives you a ByteBuffer pointing to it. When you pass this to new XrActionSuggestedBinding.Buffer, it creates a view of this memory as XrActionSuggestedBinding structures, but it doesn't initialize them. This can lead to issues if the memory isn't correctly initialized.

By using XrActionSuggestedBinding.calloc(1), you're asking LWJGL to allocate memory for one XrActionSuggestedBinding and initialize it to zero. This is typically what you want when creating new structures to pass to LWJGL functions.
Pages: 1 ... 7 8 [9] 10