Hello Guest

Recent Posts

Pages: 1 [2] 3 4 ... 10
11
Lightweight Java Gaming Library / Re: Travis Build, Natives Not Loading
« Last post by spasi on June 04, 2019, 08:57:45 »
Looks like LWJGL finds libassimp.so but loading it fails. However, in LWJGL 3.1.6 we cannot see the failure reason, this has been fixed in 3.2.0.

The most likely issue is that Assimp has a dependency that is not satisfied on the Travis instance. What's the output of `ldd libassimp.so` there? You can use curl to get it in the CI build, from here.
12
Lightweight Java Gaming Library / Re: Travis Build, Natives Not Loading
« Last post by TheDudeFromCI on June 04, 2019, 02:28:47 »
Update: after more fiddling with the Travis.yml, it now prints the LWJGL debug.

Code: [Select]
[02:27:12][Info][Time-limited test] Loading the resource [Res: unit_tests/cube.fbx].
[LWJGL] Version: 3.1.6 build 14
[LWJGL] OS: Linux v4.4.0-101-generic
[LWJGL] JRE: 1.8.0_151 amd64
[LWJGL] JVM: Java HotSpot(TM) 64-Bit Server VM v25.151-b12 by Oracle Corporation
[LWJGL] Loading library (system): lwjgl
[LWJGL] Using SharedLibraryLoader...
[LWJGL] Extracting: file:/home/travis/.m2/repository/org/lwjgl/lwjgl/3.1.6/lwjgl-3.1.6-natives-linux.jar!/liblwjgl.so
[LWJGL] Loaded from org.lwjgl.librarypath: /tmp/lwjgltravis/3.1.6-build-14/liblwjgl.so
[LWJGL] Loading library: assimp
[LWJGL] Using SharedLibraryLoader...
[LWJGL] Extracting: file:/home/travis/.m2/repository/org/lwjgl/lwjgl-assimp/3.1.6/lwjgl-assimp-3.1.6-natives-linux.jar!/libassimp.so
[LWJGL] MemoryUtil accessor: MemoryAccessorUnsafe
java.lang.NullPointerException
at org.lwjgl.system.Checks.check(Checks.java:99)
at org.lwjgl.system.Pointer$Default.<init>(Pointer.java:52)
at org.lwjgl.system.SharedLibrary$Default.<init>(SharedLibrary.java:18)
at org.lwjgl.system.linux.LinuxLibrary.<init>(LinuxLibrary.java:19)
at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:124)
at org.lwjgl.system.Library.loadNative(Library.java:329)
at org.lwjgl.system.Library.loadNative(Library.java:313)
at org.lwjgl.system.Library.loadNative(Library.java:235)
at org.lwjgl.assimp.Assimp.<clinit>(Assimp.java:1859)
at net.whg.frameworks.external.AssimpAPIBridge.load(AssimpAPIBridge.java:13)
at net.whg.we.resource.MeshConverterFuture.run(MeshConverterFuture.java:48)
at java.lang.Thread.run(Thread.java:748)
[LWJGL] libassimp.so not found in java.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Exception in thread "Thread-7" java.lang.ExceptionInInitializerError
at net.whg.frameworks.external.AssimpAPIBridge.load(AssimpAPIBridge.java:13)
at net.whg.we.resource.MeshConverterFuture.run(MeshConverterFuture.java:48)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at org.lwjgl.system.Checks.check(Checks.java:99)
at org.lwjgl.system.Pointer$Default.<init>(Pointer.java:52)
at org.lwjgl.system.SharedLibrary$Default.<init>(SharedLibrary.java:18)
at org.lwjgl.system.linux.LinuxLibrary.<init>(LinuxLibrary.java:19)
at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:124)
at org.lwjgl.system.Library.loadNativeFromSystem(Library.java:300)
at org.lwjgl.system.Library.loadNative(Library.java:286)
at org.lwjgl.assimp.Assimp.<clinit>(Assimp.java:1859)
... 3 more
13
Lightweight Java Gaming Library / Re: Travis Build, Natives Not Loading
« Last post by TheDudeFromCI on June 03, 2019, 23:54:37 »
I updated my Travis config file to the following, however, the output log has not changed in any way.

Code: [Select]
language: java

jdk:
  - oraclejdk8

before_install:
  - cd WraithEngine

env:
  - Dorg.lwjgl.util.Debug=true Dorg.lwjgl.util.DebugLoader=true

after_success:
  - mvn jacoco:report coveralls:report
14
Lightweight Java Gaming Library / Re: Travis Build, Natives Not Loading
« Last post by spasi on June 03, 2019, 09:37:30 »
What output do you get if you run the CI build with -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugLoader=true?
15
Lightweight Java Gaming Library / Travis Build, Natives Not Loading
« Last post by TheDudeFromCI on June 03, 2019, 06:18:53 »
Hello,

I'm currently working on a personal game engine project. For this project, I am using Travis and Maven for unit testing and code coverage. While tests all work fine on my laptop, even pulling and building from a completely clean slate, some of the tests which require LWJGL libraries in order to run while failing on Travis. The library in question is Assimp.

Travis Build Log:
Code: [Select]
[05:10:33][Info][Time-limited test] Loading the resource [Res: unit_tests/cube.fbx].
Exception in thread "Thread-7" java.lang.ExceptionInInitializerError
at net.whg.frameworks.external.AssimpAPIBridge.load(AssimpAPIBridge.java:13)
at net.whg.we.resource.MeshConverterFuture.run(MeshConverterFuture.java:48)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at org.lwjgl.system.Checks.check(Checks.java:99)
at org.lwjgl.system.Pointer$Default.<init>(Pointer.java:52)
at org.lwjgl.system.SharedLibrary$Default.<init>(SharedLibrary.java:18)
at org.lwjgl.system.linux.LinuxLibrary.<init>(LinuxLibrary.java:19)
at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:124)
at org.lwjgl.system.Library.loadNativeFromSystem(Library.java:300)
at org.lwjgl.system.Library.loadNative(Library.java:286)
at org.lwjgl.assimp.Assimp.<clinit>(Assimp.java:1859)
... 3 more

The code on the line in question is simply the line indicated below.
Code: [Select]
@Override
public AssimpScene load(File file)
{
>>>>> AIPropertyStore settings = Assimp.aiCreatePropertyStore();
Assimp.aiSetImportPropertyInteger(settings, Assimp.AI_CONFIG_PP_SLM_VERTEX_LIMIT, 65535);

AIScene scene = Assimp.aiImportFile(file.toString(),
Assimp.aiProcess_Triangulate | Assimp.aiProcess_GenSmoothNormals | Assimp.aiProcess_FlipUVs
| Assimp.aiProcess_CalcTangentSpace | Assimp.aiProcess_LimitBoneWeights
| Assimp.aiProcess_SplitLargeMeshes | Assimp.aiProcess_OptimizeMeshes
| Assimp.aiProcess_JoinIdenticalVertices);

Assimp.aiReleasePropertyStore(settings);

if (scene == null)
return null;

AssimpScene s = new AssimpSceneBridge(scene);
Assimp.aiReleaseImport(scene);

return s;
}

I'm not sure how to approach the issue of configuring the native library path to load in this scenario, and any advice to point me in the right direction would be wonderful. I've spent several hours on Google looking this problem up, but to no avail. It also worth noting I am currently using LWJGL version 3.1.6.

Thank you in advance and have an amazing day.
16
You are are right, the tutorial was created in 2014, so the author did not have access to LWJGL  3.2.0 or later.

Now I can simply import the the highest version of GL classes in my code, and it works like a charm:

Code: [Select]
      //import the highest version of GL classes
      import static org.lwjgl.opengl.GL46.*;

      glBindVertexArray(model.getVaoID());
      glEnableVertexAttribArray(0);
      glDrawElements(GL_TRIANGLES, model.getVertexCount(),  GL_UNSIGNED_INT, 0);
      glDisableVertexAttribArray(0);
      glBindVertexArray(0);

It also saves quite bit of typing too :-)
17
The tutorial probably was written against LWJGL < 3.2.0. Before 3.2.0, a GLxx classes did not inherit from the GLyy class where yy denoted the previous GL version prior to version xx. There you had to invoke the static methods of the GLxx class where the particular function/method you wanted to invoke was introduced in GL version xx.
Starting with LWJGL 3.2.0 you can just use GL functions introduced prior to and including version xx by calling static methods of class GLxx.
So it's just a question of which LWJGL version that particular tutorial was written against and whether the author actually knew about the added class hierarchy.
18
For example the following code (I copied from a tutorial site) invokes gl fucntions from GL30, GL20 and GL11.

Code: [Select]
GL30.glBindVertexArray(model.getVaoID());
GL20.glEnableVertexAttribArray(0);
GL11.glDrawElements(GL11.GL_TRIANGLES, model.getVertexCount(),  GL11.GL_UNSIGNED_INT, 0);
GL20.glDisableVertexAttribArray(0);
GL30.glBindVertexArray(0);             

I played with the code myself a little bit and found that if I change everything to GL30, the program still runs fine.
I understand that some functions were introduced in earlier version of OpenGL, but since the same functions are
also supported by the later versions of OpenGL, why do we still invoke them from the earlier versions of OpenGL?


Thanks in advance!
Pan
19
Bug Reports / RFE / Re: EGL VM Crashes
« Last post by spasi on May 29, 2019, 18:41:51 »
When implicit linkage fails, Windows terminates the process instead of LoadLibrary returning NULL and producing an error. So the JVM doesn't have a chance to recover.
20
Bug Reports / RFE / Re: EGL VM Crashes
« Last post by smith on May 29, 2019, 18:05:08 »
Thanks for looking into this. I moved the dll's to the working directory which works fine and seems to be what everyone does when bundling EGL/GLES with an application. I think pretty much all implementations are based on ANGLE so I wonder if it would be useful to include it as an optional LWJGL bundle. I did have one final question, why does the VM crash rather than the usual unsatisfied link exception?
Pages: 1 [2] 3 4 ... 10