jME 3.2 Beta phase

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 :smiley:


Awesome!!! :smile:


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?

1 Like

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.

1 Like

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.

1 Like

Have you checked things like dmesg and /var/log

1 Like

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:

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
MetalDevice for accelerator(0x4adb): 0x7fc4c6604038 (MTLDevice: 0x7fc4c6820400)
MetalDevice for accelerator(0x4e2b): 0x7fc4c671acd8 (MTLDevice: 0x7fc4c7838e00)

Thread 0 Crashed:: Dispatch queue:
0    	0x00007fff3fd0d1a9 0x7fff3fbb8000 + 1397161
1    	0x00007fff3fd18def 0x7fff3fbb8000 + 1445359
2    	0x00007fff3fd0bba4 0x7fff3fbb8000 + 1391524
3    	0x00007fff3fcfe206 0x7fff3fbb8000 + 1335814
4    	0x00007fff3fcb1cb6 0x7fff3fbb8000 + 1023158
5            	0x00007fff65d9ab27 MetalIOAccelSurfaceBacking::AddTextureForCurrentIndex() + 103
6            	0x00007fff65c9d25e CGXNextSurface + 8687
7            	0x00007fff65d36575 generate_layers_for_window_surfaces(CGXRedrawState*, CGXWindow*, CGSOrderOp, unsigned int, int*, WSCompositeSourceLayer**, CGSRegionObject*) + 5532
8            	0x00007fff65d374a2 generate_layers_for_window(CGXRedrawState*, CGXWindow*) + 3196
9            	0x00007fff65d33cf1 CGXUpdateDisplay + 13980
10            	0x00007fff65d30422 update_display_callback(void*, double) + 257
11            	0x00007fff65d77160 run_timer_pass + 495
12            	0x00007fff65da6b6e CGXRunOneServicesPass + 247
13            	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"
1 Like

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 :slight_smile:


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)

1 Like

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 :stuck_out_tongue:
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


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 :slight_smile:

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.

1 Like

One more post and you are our gradle/maven expert

1 Like

I HATE Gradle and Maven in the meantime :smiley: But thats probably because I spend 99% of my gradle time fixing gradle problems.

Travis CI - Test and Deploy Your Code with Confidence Looks like success though. The downside is that it’s still a dirty workaround

1 Like