Actually, you just have to set the Java library path correctly so that it finds the native libraries of OpenAL. Moreover, this bug doesn't concern OpenAL itself but in the worst case it concerns the backend of LibGDX based on LWJGL and you probably know that LibGDX has several backends.

I thought you packaged the native libraries in a JAR, I saw something called gdx-natives???.jar Then, maybe Netbeans moves these JARs somewhere, it would explain why the OpenAL libraries can't be located.

Anyway, this bug doesn't concern all backends for desktop environment as JogAmp automatically extracts and loads the correct native libraries without relying on the library path except as a fallback solution when the smartest mechanism fails or is disabled.

Ps: This is no bug with Netbeans, it just means that you did not setup the project correctly.

Maybe you're right, it was my first supposition. I know that I have to fill the "Native Location" field in Eclipse so that it finds the native libraries used by a JAR but this step shouldn't be mandatory with LibGDX whatever the IDE you use as it handles this aspect according to badlogicgames.

First I generate the subprojects.I create two projects from source (the game and the desktop backend) and use the "src" folder as source folder and the generated folders as project folders.

As a next step I added the libs from the "lib" folder of each project to the project libraries in the project properties. For the desktop backend I also add the game project as a library. At that moment I thought everything should work, but Netbeans doesn't copy the library dependencies of the game project to the build of the desktop project. Which has something to do with Netbeans not recognizing the game project as an Ant library. So I have to add the libraries of the game project to the desktop project.

Now I build only the Desktop project and I can start the App. There is only some little error which is not Netbeans fold, the example libgdx app is missing some image("data/libgdx.png"). When I add such an image to the game project everything builds and runs fine.

tl&drI setup the project correctly and hadn't any problems with any libgdx native libs.

If you want something to happen in Netbeans you had better explain in the bug report how LibGDX manages the native libraries, because otherwise I fear pretty soon the bug report is going to be rejected as a configuration problem.

If you want something to happen in Netbeans you had better explain in the bug report how LibGDX manages the native libraries, because otherwise I fear pretty soon the bug report is going to be rejected as a configuration problem.

I don't know how to put this the right way, but I think I have to rant a bit.

I took a look at your example application you posted on the Netbeans bug-tracker.Your example app is totally broken, you are using paths for the libs and source dir which are specific to your PC. Because of that, one has to configure the app oneself. After that, everything works fine for me, which confirms that your problem is NOT bug but a configuration Problem on your side.

When you need help with your wrong configuration, try to upload a working example application. Just try your example yourself before uploading it, this means extract your zip file to a different location and see if you can still open the project in Netbeans with everything working. Also don't use any Netbeans configured libraries, because they are specific too your Netbeans config.

I thought you packaged the native libraries in a JAR, I saw something called gdx-natives???.jar Then, maybe Netbeans moves these JARs somewhere, it would explain why the OpenAL libraries can't be located.

Anyway, this bug doesn't concern all backends for desktop environment as JogAmp automatically extracts and loads the correct native libraries without relying on the library path except as a fallback solution when the smartest mechanism fails or is disabled.

please stop spreading misinformation, we do exactly what you say jogamp does as well.

I thought you packaged the native libraries in a JAR, I saw something called gdx-natives???.jar Then, maybe Netbeans moves these JARs somewhere, it would explain why the OpenAL libraries can't be located.

Anyway, this bug doesn't concern all backends for desktop environment as JogAmp automatically extracts and loads the correct native libraries without relying on the library path except as a fallback solution when the smartest mechanism fails or is disabled.

please stop spreading misinformation, we do exactly what you say jogamp does as well.

At the very beginning, before Xerxes started contributing, the JogAmp backend of LibGDX didn't use the same mechanism than other backends. It changed later, it is more homogeneous now but anyway JogAmp really has the mechanism I talked about as you can see here. I'm sorry for the confusion.

I don't know how to put this the right way, but I think I have to rant a bit.

I took a look at your example application you posted on the Netbeans bug-tracker.Your example app is totally broken, you are using paths for the libs and source dir which are specific to your PC. Because of that, one has to configure the app oneself. After that, everything works fine for me, which confirms that your problem is NOT bug but a configuration Problem on your side.

When you need help with your wrong configuration, try to upload a working example application. Just try your example yourself before uploading it, this means extract your zip file to a different location and see if you can still open the project in Netbeans with everything working. Also don't use any Netbeans configured libraries, because they are specific too your Netbeans config.

I am sorry.I am just trying to fix this. It seems that it may be my fault but... Im not that sure.As you can see in the video.

There's a nice maven archetype available for GDX, at https://github.com/libgdx/libgdx-maven-archetype .. and yes, it'd be nice if gdx itself had a reasonable build system, though I suspect gradle would be more to the liking of the gdx devs than maven. Long as there's artifacts on the sonatype repo, I don't care.

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