Research the cause(s) of major issues preventing 1.5.2, and therefor BTWCE, from running on ARM64 macOS machines.

[cocona20xx]

The issues are:

• When not in fullscreen, the red and blue color bytes rendered to the screen invert. This does not occur due to an issue with render code; as screenshots show the correct colors. Possibly related to the now-deprecated java.applet.Applet class?

• When the game is not in fullscreen mode, resizing the game window often causes the rendering process of the game to hang, though the rest of the game seems to continue running. Almost certainly caused by an interaction between java.applet.Applet and this bug https://bugs.openjdk.java.net/browse/JDK-8221261 in openjfx.

• When in fullscreen, the game only renders fully in the bottom left fourth of the screen. The skybox color will render in the unused space when actually in-game. I have no clue as to why this happens, though if I had to bet, it's probably something to do with java.applet.Applet or java.awt.*?

If anyone wants to help dig into this, and they have a Apple Silicon device to test stuff on, please let me know.

[cocona20xx]

Potential method for testing the first bullet-point would be to create a hello world program that uses LWJGL2 and the deprecated java.applet.Applet class to render to a window, and then create a nearly identical hello world program using a method more similar to what 1.8.9 and later uses (which doesn't use java.applet.Applet.

If the colors do invert in the former but not the latter, then we have the culprit. However, a fix in that case would be a really big project, as it'd involve porting the 1.5.2 client window code to use a somewhat more modern class, instead of the Applet class.

[SimonMeskens]

https://github.com/BTW-Community/BTW-source/blob/28079c879db20f5c6abdef5c969184eff6379574/minecraft/net/minecraft/src/Tessellator.java#L416

This if statement seems to set the colors according to ByteOrder, might be worth investigating, I think you can fix the issue there. My guess is that ByteOrder reports an incorrect endianness for the colorspace in windowed.

[cocona20xx]

Ill try it in a second, thanks.

[cocona20xx]

@SimonMeskens yeah i'm not entirely sure thats the right spot, but it goes give me a lead!

I did manage to get the colors of biome-colored block textures (grass for instance) and particles to look correct with a bit of tinkering in that class; this confirmed that the main color-in-window-space issue is because Apple's Metal-GL Driver seems to take color bytes in a different order than what the Applet window seems to supply them; seemingly as ARGB instead of ABGR (Applet seems to supply the latter perhaps?). Managed to confirm that by swapping the position of the R and B bytes when converted into a color int via signed bit shift stuffs, which made it render correctly when windowed, but probably breaks when in fullscreen.

[SimonMeskens]

if it renders correctly in windowed, just check whether you are windowed or fullscreen and adapt accordingly?

[cocona20xx]

Thing is, that'll break compat with non Apple ARM64 machines; and is a rather large bodge if you ask me; and fails to fix the other core issues with ARM64 macOS rn.

I'm going to look into the now-deprecated Applet class and see if its possible to redistribute a version of that class which fixes the bugs present, maybe? That's almost certainly the easiest fix that doesn't break any existing compatibility hopefully.

[cocona20xx]

Update: Applet doesn't seem to be the direct source of the bugs; resize softlock seems to occur specifically when the game tries to change the "internal" resolution in order to use space more efficiently I think?

[ammoore00]

Related: betacraftuk/betacraft-launcher#38 (comment)

[SimonMeskens]

lwjgl: https://github.com/craftycodie/MineOnline/raw/main/src/main/resources/libraries/org/lwjgl/lwjgl-mac-m1/2.9.3/lwjgl-mac-m1-2.9.3.jar
lwjgl_util: https://github.com/craftycodie/MineOnline/raw/main/src/main/resources/libraries/org/lwjgl/lwjgl_util-mac-m1/2.9.3/lwjgl_util-mac-m1-2.9.3.jar

Can someone with a Mac M1 try these two libraries and see if that fixes the issue?

[SimonMeskens]

MultiMC installation guide, could use confirmation it works:

https://gist.github.com/SimonMeskens/9ddc16cb4fe6f20a74c191e7868e7978

[cocona20xx]

Unless those binaries are different than other ones that are compiled for Apple Silicon support, that wont work
Native binaries dont fix the issue, usually; I'll double check it with these ones now though

[cocona20xx]

@SimonMeskens Confirmed to not fix the issue. Native binaries actually make it slightly worse, somehow
Issue is almost certainly in java or macOS itself; probably needs a rather large workaround

[cocona20xx]

Note that afaik the binaries you linked are pretty much the same as any other LWJGL2 binaries which were compiled for macOS on Apple SIlicon, and none of those have made it work, either.

[cocona20xx]

MinecraftMachina/ManyMC#39 this is good news: While the issue isn't fixed fully, the ManyMC launcher makes it possible to run Minecraft 1.5.2 with normal rendering behaviors in fullscreen mode only on Apple Silicon Macs running macOS. Best course of action is probably to add documentation about this to various places people can download BTW:CE.

[cocona20xx]

Even more good news! betacraftuk/legacyfix#1
We might have a way to fix this bug once and for all soon~

[cocona20xx]

Closing as fixed since it has been for a while. For posterity, the issue was with certain AWT and Canvas related classes, which required backporting the 1.6.x+ style of applet drawing to 1.5.2 to fix.