[Solved] Jme3 implementation of lwjgl3 doesn't support 32 bit windows

Troubleshooting gui
1

So, while messing around on another thread, I’ve noticed that Jme3’s lwjgl3 implementation doesn’t bother with 32 bit. This is a pretty big issue for me, as I’m not only trying to support 32 bit, I also develop on a 32 bit machine, so this throws both runtime compatibility and development options out the window.

On the lwjgl3 download page, checking all supported systems produces the build file:

import org.gradle.internal.os.OperatingSystem

project.ext.lwjglVersion = "3.2.3"

switch (OperatingSystem.current()) {
	case OperatingSystem.LINUX:
		def osArch = System.getProperty("os.arch")
		project.ext.lwjglNatives = osArch.startsWith("arm") || osArch.startsWith("aarch64")
			? "natives-linux-${osArch.contains("64") || osArch.startsWith("armv8") ? "arm64" : "arm32"}"
			: "natives-linux"
		break
	case OperatingSystem.MAC_OS:
		project.ext.lwjglNatives = "natives-macos"
		break
	case OperatingSystem.WINDOWS:
		project.ext.lwjglNatives = System.getProperty("os.arch").contains("64") ? "natives-windows" : "natives-windows-x86"
		break
}

repositories {
	mavenCentral()
}

dependencies {
	implementation platform("org.lwjgl:lwjgl-bom:$lwjglVersion")

	implementation "org.lwjgl:lwjgl"
	runtimeOnly "org.lwjgl:lwjgl::$lwjglNatives"
}

Which properly checks the os type and provides the correct natives, but the current jme3 implementation ignores architecture and simply adds all the 64 bit natives, breaking support for 32 bit systems. Unless I’m mistaken, applying the above build file from lwjgl to jme3’s lwjgl3 build file will restore balance to the architectures.

I’ve tried doing this myself in my projects build.xml, but it seems gradle imports are not working for me (could not resolve class org.gradle.internal.os.OperatingSystem). Assuming this is just a me issue, and that the engine’s gradle isn’t broken(?) like mine, this should be an easy fix, of simply adding the above os check to Jme3’s lwjgl3 build.xml

2

Most computer repair shops have used computers for sale that can be picked up for a couple hundred dollars. This usually includes the latest version of windows. If Linux is your preference, you wont have any problem either as its free and they or you can install it also.

These computers can have some pretty nice peripheral equipment included, that although older, still works great. Like sound, video, networking, extra memory.

You can even dicker with them to toss in a few extras if its a bare bones box as they usually have this stuff laying around from upgrading other computers for customers.

It will feel like your working on a super computer afterwards.

1 Like
3

You write about “32 bit” as all 32-bit platforms were identical. Which operating system(s) have you actually tested?

Looking at NativeLibraryLoader, I see that there are separate native libraries for most 32-bit platforms. The exception seems to be MacOSX, for which the same native libraries are selected on both 32-bit and 64-bit systems (other than the BulletJme library).

1 Like
4

And this only because Macs have some kind of “combined binary” format that has both bitwidths packed in the same library file.

Looking into the lwjgl build situation, it appears that JME just pulls lwjgl binaries in using gradle. The build correctly detects bitwidth and platform.

Lwjgl project itself dropped Linux x86 support from it’s automated builds in 2016 due to issues with cross-compiling, as the CI farms don’t have an x86 version. 32-bit support for windows, mac, and arm-linux still exist.

The file that @sgold linked in hasn’t been updated since before they made that change, but doesn’t cause issues unless you actually try to use the library.

@werlious: what kind of hardware are you expecting to target that you still need x86 support? My ~10 year old laptop is unabashedly 64-bit, and it was middle-upper business class even then, not anywhere near a high-power gaming rig. For that matter, I bought my first laptop nearly 14 years ago, when Windows Vista was new, and even then, there wasn’t much ‘new’ for x86 systems out there except open-box/overstock models, all the way down to the entry-level stuff.

If you are really, truly determined/needful to support Linux x86, you’ll need to build the entire lwjgl stack from source, including all of it’s dependencies.

4 Likes
5

Sorry, targeting windows, 32.

And I have no idea what the NativeLibraryLoader is or does. All I know is following the gradle dependencies up the tree showed me jme3-lwjgl3-3.3.2-stable doesn’t include the 32 bit dll. And whatever NativeLibraryLoader is doing, there is no 32 bit dll in any of the jars or files in my build project, so I don’t think it’s doing much anyway.

1 Like
6

Sorry I didn’t specify an OS. I have no intention of ever supporting Mac or any apple devices to start.
And yes, jme3 does pull lwjgl binaries, in its own here. But I was pointing out that this build file specifies 64 bit binaries.
And yes, I know 32 bit support for windows exists, my issue is it’s not being utilized by jme3.
I’m targeting lower end machines. My dev machine is a windows 64 bit processor 32 bit OS. Stupid, yes, but it’s what I have and if I want to actually finish the project I will have to make it work.
Linux x86 is of no concern, linux communities are a lot smart smarter than microsoft and dropped 32 bit, yet microsoft still pulls it off to try and save their billion dollar company a few pennies.

And really, I don’t need to build the entire stack. I just need an upstream dependency to change a few lines in a build file to fix downstream support. I.E., jme3-lwjgl3 pulls 64 bit dlls as specified in in its build.xml, and has no inclusion of any 32 bit dll’s

7

I am going to pull jme3-lwjgl3 myself, add the line to build.xml, and put the results back here

2 Likes
8

Update: Still working on this one. Pulling just jme3-lwjgl3 is finicky, and I don’t have enough space to pull the entirety of jme3 on this machine.
Soon I’ll have another of my machines converted to a dev machine, but seeing as it’s gonna be linux, and linux doesn’t do the 32 bit non-sense, I don’t think I can test this on that machine.

I’ve also tried pulling just lwjgl3 instead of jme3-lwjgl3, but they don’t seem compatible, but I probalbly should have saw that coming.

If someone has the ability make the change I propose, I’ll gladly test it, but at the moment, I’m too limited to continue working on this issue

1 Like
9

I added native libraries for Linux-on-ARM and 32-bit Windows to the “master” branch of jme3-lwjgl3 at commit 6711986.

2 Likes
10

I’m tempted to cut a 3.4.0-alpha1 release from “master” branch, just so that @werlious can test our 32-bit support. Any reason I shouldn’t?

1 Like
11

Nice, is that available via gradle already? Or will it take some time to propagate?

I’d love to help test 32-bit support. Can’t think of a reason not to other than not wanting to make you do more work (you already do so much)

1 Like
12

JMonkeyEngine has continuous integration running at GitHub, but there are no automatic releases that I’m aware of. (I checked JitPack and didn’t find anything usable there.)

Bottom line: it’s not yet available via Gradle.

1 Like
13

Gotcha, much appreciated!

Is there a custom gradle task I could use that would say use a local version of the lib? So that I could download just jme3-lwjgl3 and use it locally to test?

14

./gradlew :jme3-lwjgl3:install should install a “3.4.0-SNAPSHOT” build of jme3-lwjgl3 to your local Maven repo. Then you should be able to prioritize that version in your Gradle build, like so:

repositories {
    mavenLocal()
    jcenter()
}
dependencies {
    implementation 'org.jmonkeyengine:jme3-core:3.3.2-stable'
    implementation 'org.jmonkeyengine:jme3-lwjgl3:3.4.0-SNAPSHOT'
}

I can’t guarantee that would work, but it’s worth a try.

1 Like
15

Hang on, it looks like GitHub generated Maven artifacts!

I went to jme3-lwjgl3: add native libraries for Linux_ARM and 32-bit Windows · jMonkeyEngine/jmonkeyengine@6711986 · GitHub and clicked the “Artifacts (8)” pulldown and selected “maven”. That downloaded a 260-MByte ZIP that includes jme3-lwjgl3 artifacts with the “3.4.0-SNAPSHOT” version ID.

So no need for an alpha release, and no need to build the library from source.

Edit: just need to figure out how to make Gradle aware of that jme3-lwjgl3 POM…

2 Likes
16

I tried that link, and didn’t see any links for artifacts. Might be a permissions thing.

I would have tried it out with something I’ve already stole/borrowed/“acquired”:

repositories {
    //put pom in this directory
    // would also need a jar if I recall
     maven { url "${projectDir}/repo/local" }
}
dependencies {
//or something similar
    compile "org.jmonkey:jme3-lwjgl3:3.4.0-SNAPSHOT"
}

So if i can get my hands on the pom and jar file I can definitely plug it in with that.

In the meantime, I can try your first suggestion, but I’m wary since command line utilities seem to hate running on windows (or more like the other way around)

1 Like
17

I’m not a member of the engine team at all, and I see it:

artifact
artifact1874×583 78.7 KB

2 Likes
18

Ahh I see it, I wasn’t signed in. Give me some time to fork my environment and test it out.
Much appreciated!

1 Like
19

So, 251mb at about 200kb/s, maybe about 20 minutes to download. So it’ll be at-least that long before I can post a test result. I’ll keep you all posted

1 Like
20

Confirmed that snapshot fixes 32-bit support.

Create a directory somewhere to put maven artifacts (I put mine in my project under repo/local)

And in your build.gradle, link to it by putting this line in the dependencies section:

    runtimeOnly "org.jmonkeyengine:jme3-lwjgl3:3.4.0-SNAPSHOT"

Making sure to remove/comment out any mention of lwjgl2, and your game will work on 32 bit platforms (and according to the commit, linuxARM as well)!

Much appreciated @sgold for your time and help!

1 Like