Hello Guest

Recent Posts

Pages: [1] 2 3 ... 10
1
LWJGL can only work with direct NIO buffers, not ones wrapped around on-heap JVM byte arrays. That is because LWJGL will simply supply the underlying native library with the off-heap virtual pointer address, which does not exist with byte-array-wrapped NIO buffers.

That was super helpful, I didn't know you couldn't use array wrapped buffers with LWJGL. I fixed it by allocating a buffer with MemoryUtil.memAlloc() and writing the contents of the array into it. Then freeing the buffer with MemoryUtil.memFree() when no longer necessary.
2
LWJGL can only work with direct NIO buffers, not ones wrapped around on-heap JVM byte arrays. That is because LWJGL will simply supply the underlying native library with the off-heap virtual pointer address, which does not exist with byte-array-wrapped NIO buffers.
3
Hi, I'm working on a project written in Kotlin using LWJGL 3.2.2 and Gradle and I need some help.
I'm trying to load texture data from a png located in the resources folder using STBImage. The code is at the bottom.
The thing about this code is that, no matter what I do, it always throws the exception with the message "Image not of any known type or corrupt" and I don't know what I'm doing wrong. And, yes, I made sure that the data stored in the buffer is the actual image. If you turn it into a string and print it you can see the PNG header at the beginning and the IEND chunk at the end. Any ideas why this isn't working?

Code: [Select]
val id = glGenTextures()
glBindTexture(GL_TEXTURE_2D, id)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST)
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST)

Texture::class.java.getResourceAsStream("/textures/$path").use { file ->
    val fileArray = file.readBytes()
    val fileBuffer = ByteBuffer.wrap(fileArray).flip()
   
    if (!stbi_info_from_memory(fileBuffer, IntArray(1), IntArray(1), IntArray(1))) {
        throw Exception(stbi_failure_reason())
    } else {
        MemoryStack.stackPush().use { stack ->
            val xbuff = stack.mallocInt(1)
            val ybuff = stack.mallocInt(1)
            val cbuff = stack.mallocInt(1)
            val imageData = stbi_load_from_memory(fileBuffer, xbuff, ybuff, cbuff, 4)
                ?: throw STBLoadException("STB could not load image from memory.")
            glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, xbuff.get(), ybuff.get(), 0, GL_RGBA, GL_UNSIGNED_BYTE, imageData)
            stbi_image_free(imageData)
        }
    }
}
4
Now I guess I know why nglMultiDrawElements was crashing occasionally (it must have been when it was not aligned properly). I spoke too soon. Thanks for the help.
5
The description above is confusing, the count parameter is already an IntBuffer. If you mean that you need a version where the indices parameter is an IntBuffer, that would be wrong:

- When no GL_ELEMENT_ARRAY_BUFFER is bound, indices is an array of pointers to system memory. Each pointer points to an array of indices, with element type specified by the type parameter and length specified by the corresponding index in the count parameter.
- When a GL_ELEMENT_ARRAY_BUFFER is bound, indices is an array of byte offsets (cast to a pointer type) into the bound GL_ELEMENT_ARRAY_BUFFER to start reading indices from.

In both cases, count is an IntBuffer and indices is a PointerBuffer. In the first case you fill the PointerBuffer with pointers (e.g. by calling memAddress on NIO buffers containing the indices), in the second case you fill the PointerBuffer with offsets (automatically converted to pointer values by LWJGL).
6
In the OpenGL spec, the 'count' parameter of glMultiDrawElements is a pointer to an array of offsets if GL_ELEMENT_ARRAY_BUFFER  is bound, and a pointer to an array containing index arrays otherwise. The standard glMultiDrawElements methods in LWJGL only accept a PointerBuffer as the count parameter, and memAddress is called on that PointerBuffer, making it not useable for the offsets version of the function (unless there's some way to coerce an IntBuffer into a PointerBuffer?). for the time being nglMultiDrawElements can be used to get around this, but it would be nice to have an overload of the function with an IntBuffer count parameter who's memory address is passed to the unsafe version, it would avoid confusion.

Correct workaround:
Code: [Select]
nglMultiDrawElements(GL_TRIANGLES, MemoryUtil.memAddress(counts), GL_UNSIGNED_INT, MemoryUtil.memAddress(offsets), offsets.remaining());
7
Bug Reports / RFE / Re: Cannot load lwjgl.dll when running from JNLP
« Last post by spasi on July 13, 2019, 12:18:01 »
Based on org.lwjgl.Sys, it sounds like you're on lwjgl2 which is no longer supported. Migrating to lwjgl3 is recommended. It has a more flexible and robust mechanism for loading shared libraries.
8
Bug Reports / RFE / Cannot load lwjgl.dll when running from JNLP
« Last post by guich on July 13, 2019, 10:39:45 »
Hi,

First of all, i know that Java Web Start was removed from JDK but there are alternatives that we will use instead.

I'm trying to run libGDX from the JWS. I added all needed classes and native libraries to a single signed jar file. The gdx.dll is being correctly found, but it then breaks on lwjgl.dll. The reason and the partial solution is described here:

http://forum.lwjgl.org/index.php?topic=6612.0

This is the stack trace:

Code: [Select]
JNLPClassLoader: Finding library lwjgl.dll
JNLPClassLoader: Finding library lwjgl64.dll
[LwjglApplication] Couldn't initialize audio, disabling audio
java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at org.lwjgl.Sys$1.run(Sys.java:72)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
at org.lwjgl.Sys.loadLibrary(Sys.java:96)
at org.lwjgl.Sys.<clinit>(Sys.java:117)
at org.lwjgl.openal.AL.<clinit>(AL.java:59)
at com.badlogic.gdx.backends.lwjgl.audio.OpenALAudio.<init>(OpenALAudio.java:72)
at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:90)
at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:71)
at com.u.desktop.DesktopLauncher.<init>(DesktopLauncher.java:59)
at sup.library.gui.desktop.DesktopLauncher.<init>(DesktopLauncher.java:14)
at sup.library.gui.desktop.DesktopLauncher.main(DesktopLauncher.java:9)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Looking at org.lwjgl.Sys, it uses System.loadLibrary(lib_name). The thread i mentioned said that: "Library.class.getResource("lwjgl.dll") returns null, while Library.class.getClassLoader().getResource("lwjgl.dll") does return the dll Resource."

So i tried these two options when starting my app and got this:

Code: [Select]
      System.out.println("1: "+DesktopLauncher.class.getResource("lwjgl.dll"));
      System.out.println("2: "+DesktopLauncher.class.getClassLoader().getResource("lwjgl.dll"));

Result:

Code: [Select]
   1: null
   2: jar:file:/G:/desktop/build/jnlp/lib/core_java_sign.jar!/lwjgl.dll

Can this be fixed?

thanks

    guich

Ps: this is my launch.jnlp file:

Code: [Select]
<?xml version='1.0' encoding='UTF-8'?>
<jnlp spec='7.0' href='launch.jnlp' version='1.0'>
  <information>
    <title>desktop</title>
    <vendor>mClient</vendor>
  </information>
  <security>
    <all-permissions />
  </security>
  <resources>
    <j2se version='1.8' />
    <jar href='lib/core_java_sign.jar' />
    <nativelib href='lib/core_java_sign.jar' />
  </resources>
  <application-desc main-class='sup.library.gui.desktop.DesktopLauncher'>
    <argument>-verbose</argument>
  </application-desc>
</jnlp>
9
Thank you, will be fixed in the next snapshot with 7cf5f4f.
10
As a note, by going through the commit history of the GL45/GL45Core.kt files, this issue has been here since OpenGL 4.5 was originally supported by lwjgl3 in https://github.com/LWJGL/lwjgl3/commit/57c2db0855379b6fe76a64fce9752586e4b62d05
Pages: [1] 2 3 ... 10