Here we go, following this → 3.2.0 alpha phase - #41 by nehon
Alpha Phase is done.
Let’s enter the Beta phase
artifacts should be available in a couple of hours on jcenter
Depending on bug reports I guess the number of beta could vary. I’d like to release 3.2 stable in the beginning of January.
Time for monkey testing 
Awesome!!! 
This is the new version of actual LIBRARY (not the branded official IDE), am I right?
What JDK/JRE does 3.2.0 require? Does it work with Java 8 JDK?
The engine to be specific. The sdk is seperate, yes. As in maintained seperately in a different repository.
I think the min is 1.7 without actually looking. It will state in the gradle build configuration.
Java 7 unless you use lwjgl3 which is java 8
So i’m still having issues with the current build LWJGL3 and OSX. I am getting a hard crash that is crashing OSX to the login screen. As a result, I don’t have any log to look at. I replicated this using the basic game project from the sdk with all the libraries built from master. I was also using the “-XstartOnFirstThread” flag. I’ve stepped through the code a little bit to try to narrow it down and it appears that it is crashing when it polls events at some point after the window is shown. Has anyone else had an issue on OSX with LWGL3? I can’t even get a crash log because of how badly it is crashing on osx.
Have you checked things like dmesg and /var/log
So I went through my logs again and the only reference I can remotely find is a crash log in the system reports for the “WindowServer” which shows a divide by zero error in the apple geforce driver. This error repeats itself every time I try to run the basic application. I assume this error is what is kicking me back to the login screen, but I don’t know what the root cause is with lwjgl3.
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_ARITHMETIC (SIGFPE)
Exception Codes: EXC_I386_DIV (divide by zero)
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Floating point exception: 8
Termination Reason: Namespace SIGNAL, Code 0x8
Terminating Process: exc handler [0]
Application Specific Information:
StartTime:2017-12-21 14:11:03
GPU:IG&NV
MetalDevice for accelerator(0x4adb): 0x7fc4c6604038 (MTLDevice: 0x7fc4c6820400)
MetalDevice for accelerator(0x4e2b): 0x7fc4c671acd8 (MTLDevice: 0x7fc4c7838e00)
IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/P0P2@1/IOPP/GFX0@0/NVDA,Display-A@0/NVDA
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.GeForceMTLDriver 0x00007fff3fd0d1a9 0x7fff3fbb8000 + 1397161
1 com.apple.GeForceMTLDriver 0x00007fff3fd18def 0x7fff3fbb8000 + 1445359
2 com.apple.GeForceMTLDriver 0x00007fff3fd0bba4 0x7fff3fbb8000 + 1391524
3 com.apple.GeForceMTLDriver 0x00007fff3fcfe206 0x7fff3fbb8000 + 1335814
4 com.apple.GeForceMTLDriver 0x00007fff3fcb1cb6 0x7fff3fbb8000 + 1023158
5 com.apple.SkyLight 0x00007fff65d9ab27 MetalIOAccelSurfaceBacking::AddTextureForCurrentIndex() + 103
6 com.apple.SkyLight 0x00007fff65c9d25e CGXNextSurface + 8687
7 com.apple.SkyLight 0x00007fff65d36575 generate_layers_for_window_surfaces(CGXRedrawState*, CGXWindow*, CGSOrderOp, unsigned int, int*, WSCompositeSourceLayer**, CGSRegionObject*) + 5532
8 com.apple.SkyLight 0x00007fff65d374a2 generate_layers_for_window(CGXRedrawState*, CGXWindow*) + 3196
9 com.apple.SkyLight 0x00007fff65d33cf1 CGXUpdateDisplay + 13980
10 com.apple.SkyLight 0x00007fff65d30422 update_display_callback(void*, double) + 257
11 com.apple.SkyLight 0x00007fff65d77160 run_timer_pass + 495
12 com.apple.SkyLight 0x00007fff65da6b6e CGXRunOneServicesPass + 247
13 com.apple.SkyLight 0x00007fff65da7729 SLXServer + 832
14 WindowServer 0x000000010f99bdde 0x10f99b000 + 3550
15 libdyld.dylib 0x00007fff6bbea145 start + 1
I also found another error that looks like it was related:
Dec 21 14:01:33 {} java[24681]: assertion failed: 17B48: libxpc.dylib + 35351 [58676E88-35FD-3CF3-99BB-2A82E09F8058]: 0x20
do you use Gradle? can you try to use newer versions of lwjgl libraries?
ext.lwjglVersion = "3.1.2"
dependencies {
// LWJGL
compile "org.lwjgl:lwjgl:${lwjglVersion}"
compile "org.lwjgl:lwjgl-glfw:${lwjglVersion}"
compile "org.lwjgl:lwjgl-jemalloc:${lwjglVersion}"
compile "org.lwjgl:lwjgl-openal:${lwjglVersion}"
compile "org.lwjgl:lwjgl-opencl:${lwjglVersion}"
compile "org.lwjgl:lwjgl-opengl:${lwjglVersion}"
compile "org.lwjgl:lwjgl-stb:${lwjglVersion}"
runtime "org.lwjgl:lwjgl:${lwjglVersion}:natives-windows"
runtime "org.lwjgl:lwjgl:${lwjglVersion}:natives-linux"
runtime "org.lwjgl:lwjgl:${lwjglVersion}:natives-macos"
runtime "org.lwjgl:lwjgl-glfw:${lwjglVersion}:natives-windows"
runtime "org.lwjgl:lwjgl-glfw:${lwjglVersion}:natives-linux"
runtime "org.lwjgl:lwjgl-glfw:${lwjglVersion}:natives-macos"
runtime "org.lwjgl:lwjgl-jemalloc:${lwjglVersion}:natives-windows"
runtime "org.lwjgl:lwjgl-jemalloc:${lwjglVersion}:natives-linux"
runtime "org.lwjgl:lwjgl-jemalloc:${lwjglVersion}:natives-macos"
runtime "org.lwjgl:lwjgl-openal:${lwjglVersion}:natives-windows"
runtime "org.lwjgl:lwjgl-openal:${lwjglVersion}:natives-linux"
runtime "org.lwjgl:lwjgl-openal:${lwjglVersion}:natives-macos"
runtime "org.lwjgl:lwjgl-opengl:${lwjglVersion}:natives-windows"
runtime "org.lwjgl:lwjgl-opengl:${lwjglVersion}:natives-linux"
runtime "org.lwjgl:lwjgl-opengl:${lwjglVersion}:natives-macos"
runtime "org.lwjgl:lwjgl-stb:${lwjglVersion}:natives-windows"
runtime "org.lwjgl:lwjgl-stb:${lwjglVersion}:natives-linux"
runtime "org.lwjgl:lwjgl-stb:${lwjglVersion}:natives-macos"
}
Technically no matter what lwjgl3 does, the driver must not crash. Can you try older/newer versions of the Driver?
On the other hand it looks like the WindowServer is crashing (usually a dieing gpu driver could be reload without destroying the Session)
Yes, that is the worst crash I’ve seen in awhile. I have tried both older / newer version of the osx driver as well as nvidia’s driver and updated to the latest version of osx. Changing between the drivers still crashes in exactly the same way. I’ve also tested with version 3.1.2 of lwjgl as well as 3.1.5.
Quick question: would it be possible to release beta-1 as SDK binaries? The last version I get offered as binary download is v3.2-prealpha-sdk1. My guess is it would increase beta-testing participation if an SDK download were present. Would definitely work for me 
This would be the official case yes, however we are currently experiencing build problems
So unless they are solved we’re not able to release a new sdk version.
It seems like an error which is easy to fix, but that’s only the case if you know what to do exactly (apart from dropping jbullet support)
Would it not be possible for one of you guys to make an SDK build locally on your own machines and provide us with a build version of the SDK?
This is not a problem of where it’s built. the build fails wherever you run it. You experienced it yourself.
I’ll try to take a look.
Well I got it to work and made a build for Windows, MacOS and linux.
So maybe I can upload the files somewhere for people to use?
Oh except I have a bandwidth problem now.
Well you removed jbullet 
Some parts of your SDK might be broken.
I’ve also looked into it deeper and have found a workaround for travis, but that’s linux-only then firstly.
I wonder what happens if you take the gradle template and just specify jme3-jbullet as dependency, you should also experience that problem?
So what’s the case: These POM Entries are new
<dependency>
<groupId>jbullet</groupId>
<artifactId>jbullet</artifactId>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>stack-alloc</groupId>
<artifactId>stack-alloc</artifactId>
<scope>compile</scope>
</dependency>
We have jbullet as jar in our libs directory, however it’s not known to maven as jbullet:jbullet, it’s just there.
This means, I’d do an mvn install:install-file -Dfile=jbullet.jar -DgroupId=jbullet -DartifactId=jbullet -Dversion=0.0.1 -Dpackaging=jar
@Momoko_Fan Any Idea what a better solution would be?
The SDK itself isn’t really broken but I’ve decided against dropping jbullet because of that, so that SDK users can debug their physics problems by simply swapping out jbullet and bullet-native.
So removing jbullet is not a good workaround 
Edit: Further Investigation has shown that the actual problem seems to be that jbullet did not mention a version and hence it couldn’t even be parsed.
One more post and you are our gradle/maven expert
I HATE Gradle and Maven in the meantime 
But thats probably because I spend 99% of my gradle time fixing gradle problems.
Travis CI - Test and Deploy with Confidence Looks like success though. The downside is that it’s still a dirty workaround