I very rarely use the .jar or the .exe but I wanted to test my problem (weird update loop burst) from the command line but it seems there’s a problem, maybe a missing library?
When using:
java -jar StellarConquest.jar
I get:
Jul 1, 2011 5:21:01 PM com.jme3.system.Natives extractNativeLib
WARNING: Cannot locate native library: windows/bulletjme64.dll
Exception in thread "jME3 Audio Thread" java.lang.UnsatisfiedLinkError: org.lwjgl.openal.EFX10.nalGenAuxiliaryEffectSlots(ILjava/nio/IntBuffer;I)V
at org.lwjgl.openal.EFX10.nalGenAuxiliaryEffectSlots(Native Method)
at org.lwjgl.openal.EFX10.alGenAuxiliaryEffectSlots(EFX10.java:529)
at com.jme3.audio.lwjgl.LwjglAudioRenderer.initInThread(LwjglAudioRender
er.java:221)
at com.jme3.audio.lwjgl.LwjglAudioRenderer.run(LwjglAudioRenderer.java:1
22)
at java.lang.Thread.run(Unknown Source)
I assume where your StellarConquest.jar is you have a lib sub-directory with all of the dependencies? And that the .jar was built with the standard JMP build?
Yeah, everything has been unzipped in an isolated directory and ran from there. I should’ve removed the bullet warning as I know it’s not coming from that. The same happen if I try to run the jar from the dist folder inside the project.
damn, I -am- tired. Yes Paul, the build has been done from the standard JMP build. I actually rebuilt it a couple of times to make sure there wasn’t some leftover from the profiler, just in case.
At some point in my jmp upgrades, (I haven’t updated in a long time though) I started getting that warning too. I didn’t change anything about my project but it started showing up. Maybe if I update it will go away… but I think a lot of users see it and ignore it… and otherwise didn’t change anything about their projects.
@normen, I don’t use bullet -at all- in my game. There shouldn’t be an import anywhere. It’s not supported for now. It’s planned but not implemented at all. I have no idea where this is coming from. Maybe some other import?
Besides, what jBullet has to do with jME Audio Thread?! Please enlighten me.
Duh, @Momoko_Fans “fix” of the native loading fooled me again… No, this looks more like the openal library can either not be extracted due to user rights issues or is incompatible with the platform. E.g. if you are on 64bit windows you have to run 64bit java to have working sound. Idk whose fault it is here, OpenAL or windows but I think you know my guess
Actually, JVM is x64 bits here, the x86 version isn’t even installed. As far as window’s permissions, I’ll tell you the exact same thing I’ve told you since the first time you mentioned it; they don’t suddenly change by themselves (not since Vista and certainly not in Win7 anyway). It’s the exact same thing as with any “modern” OS; unless the user changes the perms, they don’t change. The only exception to that is the “Program files” directory. This whole tree is protected so only the application that installed its stuff there is supposed to have read/write access to it. Of course a user with admin rights can override this, but it has to be done manually every time you want to move/delete/edit/save a file there (other app can’t even overwrite a file in a dir there if it’s not the rightful owner/installer and up to now I haven’t seen one able to but then again I’m not going out of my way to find one).
Don’t believe me if you want. The fact remains that with the .zip file uncompressed in a brand new standard dir far away from “program files” should work. It was working before (months ago).
I vaguely remember an update that have been applied to openAL/updated in jME, but that was some time ago. Maybe that broke it? As I said, I extremely rarely use running from .exe/.jar.
Hm… So the problem is that java reports “32bit” because java is 32bit and then the 64bit dll (which is needed for native) doesn’t work… Actually I am not quite sure how that is in general on windows…
normen said:
Hm.. So the problem is that java reports "32bit" because java is 32bit and then the 64bit dll (which is needed for native) doesn't work.. Actually I am not quite sure how that is in general on windows..
There's only one JVM installed here and it's x64. OpenAL dlls (x86 or x64) do NOT get extracted. And since extracting OpenAL64.dll make it work (not OpenAL32.dll, I've tried) windows properly report the platform. Just so we're clear, the OpenAL64.dll was extracted from jME3-lwjgl-natives.jar in nativeswindows.
I’ve checked options in the project’s properties and everything looks fine. I tried with multiple rebuilds and the openAL dll is always absent. Any option in the project’s property that would stop the dll from being extracted?
Yes Paul, the build has been done from the standard JMP build. I actually rebuilt it a couple of times to make sure there wasn’t some leftover from the profiler, just in case.
