ARM support

[Redo11]

Is your feature request related to a problem? Please describe.
It's hard to setup Atlauncher on ARM Linux

Describe the solution you'd like
Add ARM version of Linux native libraries, disable discord presence by default

Describe alternatives you've considered
Going into instance files manually and adding the libraries one by one

Additional context
https://cdn.discordapp.com/attachments/968921975869304892/968951274844336168/2022-04-27-15-02-32.log

[RyanTheAllmighty]

Minecraft itself doesn't support ARM libraries. Until they do, we won't add in hacks around it.

Good news is the latest snapshots have added in support for ARM Mac, so we may be seeing ARM support coming soon.

[CoolCat467]

@Redo11 One of those hacks is a script I made here, which makes Minecraft use the proper arm build of LWJGL instead of one for x86 processors.

[RyanTheAllmighty]

Would appreciate if someone can break down what needs to be done for this.

My understanding is we need to replace certain LWJGL libraries (maybe some others???) with ARM specific builds. A breakdown of what needs to be replaced, where to source it from, etc, would be great, as well as how different Minecraft versions require different versions, a mapping of MC version to custom LWJGL version would help speed this up and get this implemented.

[CoolCat467]

Breakdown of problem

So basically, Minecraft Java Edition (just Minecraft from here on out) uses a library called Light Weight Java Game Library (LWJGL) for most of the low level things. Minecraft doesn't seem to take into account what the CPU architecture of devices properly; It incorrectly assumes it's CPU is a x86 processor. This doesn't matter for anything except LWJGL, which has to be built specifically for whatever system and architecture your computer is running to be able to do the low level things.

Raspberry Pi's and other devices like new Mac's with the M1 or M2 chip have ARM processors, and so Minecraft uses the wrong version of LWJGL, and therefore you get errors and are sad that Minecraft does not work.

And to make things more complicated, different versions of Minecraft use different versions of LWJGL. Somewhere in the 1.13 snapshots Minecraft switched from using LWJGL 2 to LWJGL 3.

LWJGL 2 does exist for ARM 32 and 64 processors thanks to people porting it, but you also have to fix OpenAL which LWJGL 2 uses, or else you won't get sound properly.

LWJGL 3 supports arm devices just fine which is great and makes things a lot simpler.

How to fix this

LWJGL 2

If you are playing a Minecraft version before 1.13, since Minecraft will be using LWJGL 2 you can just swap out the Shared Object (SO) files that LWJGL will use. Create a folder somewhere on your computer to store LWJGL 2 for ARM32 or ARM64 files and add -Dorg.lwjgl.librarypath=path/to/folder to your Minecraft JVM launch arguments.

You can find lwjgl2 arm so files on the internet with a search engine, because people are great and have done the hard work here for us.
TuxThePenguin0 has the correct stuff in https://github.com/TuxThePenguin0/lwjgl2_arm64 inside the natives-linux jar files, but I've put everything together that I know works.
ARM 32 files
ARM 64 files

LWJGL 3

For any version of Minecraft 1.13 forward, it's not so simple to fix. For that, you have to change the actual lwjgl files Minecraft will be using to the proper versions for ARM devices instead of it's default, x86 devices. It's not really possible to do this easily, because most launchers check that the hash of the file it's going to tell Minecraft to use is a specific thing, and if it's not the same it will re-download that file, overwriting whatever you've replaced it with.

That makes things tricky, but still not impossible. The idea here is to intercept Minecraft's launch arguments, take apart the java class path it was going to run with, find all the LWJGL files and replace them with the ones for your particular device, and then put everything back together and run Minecraft yourself from the modified arguments.

You can get the LWJGL files from the official LWJGL website at https://www.lwjgl.org, just make sure to get the ARM versions of what Minecraft is trying to use for your device.

The solution

It's not easy to do all of that manually, so I made a wrapper script which does everything I just described automatically. You can find it at https://github.com/CoolCat467/fix-lwjgl. There are better instructions there, but basically download fix_lwjgl.py and save it somewhere on your computer, and then specify fix_lwjgl.py as a wrapper script and it will take care of the rest. Everything is open source under the MIT license, so go nuts.

If you are having problems with java.lang.NoClassDefFoundError: Could not initialize class com.mojang.blaze3d.systems.RenderSystem, basically you can tell Mesa OpenGL to pretend it's using an older version of OpenGL with by running export MESA_GL_VERSION_OVERRIDE=4.3 as a pre-launch command. This is black magic and somehow gets things running. I've also seen 4.5 and 4.2COMPAT, but all I know is somehow this fixes things. Don't do this unless you are having problems.

[RyanTheAllmighty]

Yeah if I can implement this at the launcher level, it won't be an issue modifying the libraries since we have full control of it.

So for any LWJGL2 libraries we swap them all out for this same singular version in your repo? All the way back even to 1.0 and further? Or just the 2.9.3 version of LWJGL?

And then for anything 3.0 just swap for the correct ARM32/64 version for version the same?

Sounds fairly straight forward.

[CoolCat467]

I have not tested earlier versions of LWJGL 2, the oldest version I know for certain this works with is Minecraft 1.8.9. "Prior to release 1.6, Minecraft used LWJGL 2.4.2", so supposedly 1.6 and up would work fine. I'm not sure how compatible different versions of LWJGL 2 are with each other, but this wiki page makes it seem like it might work.

[CoolCat467]

For LWJGL 3, the earliest release to support ARM for Linux was version 3.2.3, earliest release to support ARM for MacOS was 3.3.0, and the earliest release to support ARM for Windows was also version 3.3.0. In my script it assumes 3.3.1 and will go higher if the original version was higher and things seem to work ok.

[RyanTheAllmighty]

Okay, good to know it's not just a swap like for like, needs a version bump in some cases. I'll likely do the same as what you've done, use 3.3.1 as minimum.

Thanks for the clarification, probably got all I need on this to get it going now.

[RyanTheAllmighty]

Okay so I've mirrored all the LWJGL native libraries into our own maven and have automation setup to monitor new LWJGL version as well as Mojang changing LWJGL versions in newer versions so when they update, it should get mirrored for all arm devices automatically.

Now to actually implement the library swapping/addition into the launch commands.

[RyanTheAllmighty]

Okay so I've managed to get this going for both LWJGL 2 and 3.

Will need to test across different Minecraft versions to be sure, but old LWJGL 2 seemed good, as well as 1.18.2 which used classifier natives with extraction and 1.19.1 which uses flat libraries as natives and it seems to extract and update the classpath correctly.

I'll need to test this on an actual device. I have a Pi which I can test 32 and 64 bit linux on. OSX I can get a VM on to test on M1, but going to need to figure out Arm on Windows, maybe see if I can emulate it or get some VM on some cloud service for it.

[RyanTheAllmighty]

Okay so testing on my Raspberry Pi, it seems to be good. Minecraft doesn't actually launch, only has a tiny amount of ram, but the launch arguments look good.

[CoolCat467]

The wrapper script works for sure up to 1.19 on a Raspberry Pi 4, 4GB version

[atlauncher-bot]

This has been fixed with version 3.4.20.0

[theofficialgman]

Hi
I am the resident ARMhf/ARM64 lwjgl 2/3 and jinput builder and integrater here.
Nobody pinged me about this so I was not aware of this until now... the changes in ATLaucher are quite invasive and in my opinion entierly unnecessary.

for Multimc (the only launcher I currently support), I already have a modified meta repo for almost 2 years now (one for linux arm64 and the other for linux armhf) which supports all versions of minecraft using custom armhf/arm64 builds of lwjgl 2.9.4-nightly-20150209 3.1.6, 3.2.1, 3.2.2, and the official 3.3.1. no launcher changes necessary for multimc (simply a meta repo location change specified through cmake)

README with a lot of info including my sources -> https://github.com/theofficialgman/meta-multimc
lwjgl2/3 arm64 here, yeah the name is bad -> https://github.com/theofficialgman/lwjgl3-binaries-arm64
lwjgl2/3 armhf here, yeah the name is bad -> https://github.com/theofficialgman/lwjgl3-binaries-arm32

I am currently working on modifying mojangs official meta json files which will basically require zero launcher changes. All you would do is change one string to point to a new custom meta location that has armhf/arm64 libraries instead of mojangs x86_64 only natives

ATLauncher/src/main/java/com/atlauncher/constants/Constants.java

Line 126 in 561f23f

+ "/mc/game/version_manifest.json";

once this is done, basically you can revert all of these changes and just use that without any hacks necessary.

what my script does now:

1. downloads all minecraft versions json from the version_manifest
2. determines the lwjgl and jinput version for every minecraft version (turns out there are only 2 formats used by mojang so far)
3. remove all lwjgl and jinput libraries from every version and create a new json
4. add the armhf/arm64 libraries (lwjgl2/3 and jinput) to the json for every version (based on the original version found in the json). In the future, a merged json files could be made to contain all architectures but for now this is simpler as I don't intend x86_64 users to use this manifest

and the only things left to do are:

5. recompute the version_manifest_v2.json and version_manifest.json (the sha1 hashes don't match since the json have been modified)
6. host this somewhere (server or github pages) with a cron job to keep it updated
7. integrate into launchers by replacing one string

Once finished, the script and the repo will be open source so launchers can choose to use it directly, or host it themselves on their own infrastructure. It is very simple and only consists of a few dozen lines of bash code. The hard work for backporting lwjgl code, compiling, and packaging proper .jar files for the armhf and arm64 libs was already done a long time ago.

[theofficialgman]

pinging @RyanTheAllmighty as the relavent person ^

[RyanTheAllmighty]

We mirror all the Minecraft json ourself, so unless your script to transform the versions is open source for me to essentially integrate into our own processes for mirroring, then we'd need to stick with what is currently going on.

I also don't see any issue with what we have now honestly, as it's all done at launch time, and doesn't involve manipulating/changing any Minecraft json files from Mojang.

But happy to take a look at your conversation script/process when you have it up and then decide the way I want to go.

[theofficialgman]

We mirror all the Minecraft json ourself, so unless your script to transform the versions is open source for me to essentially integrate into our own processes for mirroring, then we'd need to stick with what is currently going on.

Yup that's the plan as I said. When it is done it will be open source (it's already in discord). Probably will be up next week when I finish it due to the holiday weekend. I will message here again when it is up

The changes you made to the source are extremely hacky.. I perceive unexpected issues with them not to mention it isn't really proper.

[RyanTheAllmighty]

Cheers. Be interesting to see what you're doing.

We're essentially doing at runtime, what you're doing to each JSON I would imagine going off your description. But there's been no issues raised yet, which is my only concern, not so much around hacky vs non hacky

[theofficialgman]

The manifest is up as well as the script using github actions to keep it updated.
README on the main page: https://github.com/theofficialgman/piston-meta-arm64

it has been integrated seemlessly into GDLauncher by myself already

[theofficialgman]

I have tested the one line change (version manifest change in the constants file) on launcher version v3.4.19.3 (before all those hacks were added), built the launcher, and everything works great on ARM64.

You should seriously consider it over your 1000 line hacks that don't even solve all the problems (like changing out jinput and actually using proper lwjgl 3.X.Y versions that don't cause crashes in mods).

I also have an ARM32 manifest up and running as well now https://github.com/theofficialgman/piston-meta-arm32

All of this is automated and I can control what libraries get replaced, and what minecraft versions show up all with basically no launcher changes.

[RyanTheAllmighty]

This should be reopened and reevaluated. At a high level need to look at gmans replacement manifest and somehow finding a way to custom build all those binaries used then update version manifests to include arm libraries for arm devices using the existing logic in the launcher for selective libraries like is done for 64/32 bit