Pyra Java game that looks like it would be fun on the Pyra, except for one problem.

[MTPDA]

So there's a game called Space Haven that I just recently got on Steam, it's a lot of fun and it looks like it would be perfect for the pyra except it's 64 bit java only. Considering the minimum requirements I decided to ask in the forums whether or not the 64 bit Java was a design choice or actual requirement, forgetting that the internet isn't as nice as here. After wading through the people decrying 32 bit I found one person claiming they got it working on a 32 bit system. I tried it and the closest I got was a segfault with no other errors. My question is it actually possible to get working or was that person just messing with me?

 

[ptitSeb]

#32bitsisnotdead

Also on what machine did you tried it? I don't have the game in my collection, so I cannot really test. I guess it's also not drm-free, so you probably need some of the Steam lib in 32bits version too (is it a JAR ?).

 

[MTPDA]

Wow, I was not expecting a reply that fast!
I tried it in a 32 bit Ubuntu 16.04.4 Virtualbox VM with 4 GB of ram and 2 cores to get as close as I could to the pyra. And yes, in the steam downloads directory it's s .jar file. According to the person who allegedly got it working it requires Java 8 because of some programming qwerk.

 

[ptitSeb]

And you get any error message?

Usualy, JAR contains the lib that will used. Open the jar with any zipfile utils to see if it's the case. You may have to modify the jar itself to inject some 32bits libs to get it to run.

 

[daveshah]

Unless it uses more memory than a 32 bit address space provides, then usually the Java bytecode itself should work the same on 32 and 64 bit JVMs (Java has fewer 32/64bit differences than C/C++). The problem is more likely the native libraries it comes with, which would need to exist for 32 bit x86 on PC and 32 bit armhf on Pyra. Google suggests it uses the libgdx engine, which looks like it exists for 32 bit platforms, but maybe other native dependencies are a bigger problem.

 

[MTPDA]

In the .jar file there's a /linux/arm32 folder that has the .so files in it along with /linux/arm64 and /linux/x64

 

[daveshah]

That sounds promising for running on the Pyra.

 

[MTPDA]

Just thew it in a fresh 64 bit vm with only openjdk 8 installed and it runs, there's no DRM!

 

[MTPDA]

Thank you @ptitSeb and @daveshah!

 

[Letalis Sonus]

Unless it uses more memory than a 32 bit address space provides, then usually the Java bytecode itself should work the same on 32 and 64 bit JVMs (Java has fewer 32/64bit differences than C/C++).

Java itself is not hindered by 32bit address space limitations when running on a 32bit JVM, it can handle multiple processes with overlapping address spaces to allocate more memory just fine. However, this feature is only supported if the JVM is running in server mode, which is not the default setting on Oracle's 32bit x86 Windows binaries (the 32bit x86 Linux binaries default to server mode). I'm pretty sure this is the whole reason behind the "64bit Java only" deal.

Pro tip: Java's memory allocation and thread spawning behavior collides harshly with glibc's memory allocation optimizations, resulting in a lot of unnecessary RAM usage overhead on Linux. On Linux systems with low RAM you may want to try to limit the amount of glibc's pre-allocated memory pools for Java programs using the MALLOC_ARENA_MAX environment variable.

 

[levi]

That and according to the report on the previous page, it had .so files in it for arm32 and 64-bit but only x86-64 files, not x86-32.

 

[MTPDA]

That and according to the report on the previous page, it had .so files in it for arm32 and 64-bit but only x86-64 files, not x86-32.

Yeah, I thought that was kinda odd when I initially saw it, but daveshah and Letalis Sonus' explanations make sense.

 

[levi]

Daveshah's last post at least says you still need 32-bit x86 libraries. Letalis Sonus's post only address bytecode processing. I don't see how they explain the missing x86-32 bit libraries for when you were trying to run it in a 32-bit VM.

But yeah, it has arm32 bit .so's for the Pyra, and if you want to run it in a 64-bit x86 VM I don't have a problem with that.

 

[MTPDA]

Daveshah's last post at least says you still need 32-bit x86 libraries. Letalis Sonus's post only address bytecode processing. I don't see how they explain the missing x86-32 bit libraries for when you were trying to run it in a 32-bit VM.

But yeah, it has arm32 bit .so's for the Pyra, and if you want to run it in a 64-bit x86 VM I don't have a problem with that.

I just meant it explained one reason why they might be missing only for 32 bit x86. I'm thinking they removed it from all OSes so as to avoid the JVM not running in server mode on Windows, but is running in server mode on Linux problem as a quick and easy solution (I.E. Don't support it at all) and since it's on steam they never imagined anyone would run it on an ARM device so didn't explicitly exclude it. But I might be misinterpreting something in their explanations though.

 

[Letalis Sonus]

...or the decision wasn't even done by the game's developers themselves but originates from whatever type of game development kit they might have used for it. I do remember seeing something like this before, but I can't remember what it was.