A user of my application has a computer with an Apple M1 Max CPU. When they launch the application, the red and blue channels are swapped.
Here’s what the same picture looks like when the image is Photoshopped to swap the red and blue channels (so it appears correct).
It appears this also happens in older versions of Minecraft when using an Apple Silicon chip. It is also mentioned that the bug only exists in Minecraft versions before 1.6. I wonder if an OpenGL or LWJGL upgrade causes this to not appear in new Minecraft versions?
My application uses org.jmonkeyengine:jme3-lwjgl:3.5.2-stable. LWJGL 3 does not seem to work on their computer.
Does there exist a known fix that will display the colors correctly?
Probably, JME requests the buffer in one order (RGB) and gets a buffer in BGR (or vice-versa) and nothing complains about it. (Or it did complain to the console and that information was not captured.)
I can’t speak to why.
Someone tried to run the new Mythruna engine on an m1 (Mythruna still uses lwjgl2) and the colors were correct… it failed later in one of my custom shaders. Up to that point, the UI and stuff seemed to be the right color.
I’ve downloaded your app and it seems that you are launching it with an x86_64 JVM as opposed to the M1 JVM, this will run it under the Rosetta compatibility layer (as Apple m1 cannot run x86 applications natively), this explains why you can run it with LWJGL2, however it might be related to the issue you are experiencing.
Generally i would suggest to look into what is preventing your app from running on LWJGL3, since LWJGL2 is not being maintained anymore.
Some possible things to look into:
Remove internal calls to LWJGL2 methods and classes (eg Display.*) from your app
Ensure the M1 JVM is used on Apple M1
Ensure the M1 (mac arm) natives are included in the final jar
Ensure the jar is launcher with -XstartOnFirstThread (this is required for macos when using LWJGL3) or see workaround below
-XstartOnFirstThread & Workaround
if your app uses AWT calls, as it seems it does, it will hang forever, since the windows manager used by LWJGL3 doesn’t like when its render loop is shared with other libraries (in this case awt).
To fix that you either need to replace AWT calls with something else, or when not possible, you can try to add this code before the start() call
Okay, after performing the following changes, my user only sees a black screen now.
Run using the Azul Zulu macOS ARM 64-bit JDK
Run with -XstartOnFirstThread
Move execution of JME application to main thread
At this point, I’m stumped. I think I’ll have my M1 tester try running a “hello world” JME application just to make sure that no other dependencies or frameworks I’m using are interfering. Just figured I’d post an update here since I’m sure there’s at least one other person who’s having a similar issue.
Okay, my M1 user was able to get the basic “hello world” application to run. It required disabling the settings window app.setShowSettings(false) (I’m assuming this is necessary because—as mentioned—AWT and LWJGL3 won’t mix) and executing on first thread -XstartOnFirstThread. This doesn’t explain why my application still shows a black screen, but I think my next plan is to try experimenting with adding
)
