tonihele
Investigate how to support MacOS with LWJGL 3
Get rid of AWT. With the LWJGL 3 we lost MacOS. We need some flags (see jMonkeyEngine build.gradle) to run OpenKeeper in Mac but that isn't enough. It doesn't work. I think getting rid of AWT is better than reverting to LWJGL 2. Unfortunately I don't own a Mac to test after this is done.
Does Nifty rely on AWT as well?
On 16 Dec 2017 21:15, "ufdada" [email protected] wrote:
What do you want to use instead? Directly run it in nifty?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tonihele/OpenKeeper/issues/304#issuecomment-352204920, or mute the thread https://github.com/notifications/unsubscribe-auth/AH9UviOdyq_Wr1L5X3NpkNYnpD_jjBv8ks5tBBbFgaJpZM4REbR5 .
Does Nifty rely on AWT as well?
No, but AFAIK Swing may do that and that was used for our "installation process" (file conversion etc.).
For the other usages (i think we used it for the whole point thing, right?) we can use easy wrappers.
Imagej to replace BufferedImage stuff and JavaFX for the installer? I have no experience on those. I tried JavaFX initially for the installer but wanted results quick and went for the Swing 😔
On 16 Dec 2017 21:26, "ufdada" [email protected] wrote:
Does Nifty rely on AWT as well?
No, but AFAIK Swing may do that and that was used for our "installation process" (file conversion etc.).
For the other usages (i think we used it for the whole point thing, right?) we can use easy wrappers.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tonihele/OpenKeeper/issues/304#issuecomment-352205523, or mute the thread https://github.com/notifications/unsubscribe-auth/AH9UvuLpIUF7BsEMLjIzzQ29Kh0E3RW_ks5tBBlZgaJpZM4REbR5 .
Some people have replaced BufferedImage stuff with direct byte writes to JME textures. But it is slow. It is just doing pixel by pixel stuff. Well, currently so is our map thumbnail creator, that is why it is so slow. If there is a chance to use somewhat more sophisticated stuff, it would be a huge plus.
Ok, so looking at it more than the 5 minutes... Like you said we can use some wrappers perhaps, to eventually help out any android business and have Android use the Bitmap and desktop the BufferedImage stuff.
It is the "installer" that causes the problems in MacOS alone since it initializes the AWT stuff. BufferedImage and those are headless and does not interfere with the GLFW (LWJGL 3). And JavaFX is not any better.
I don't know, would it make any difference to have the installer as separate "process" with main class. And wait for it to finish. I'm not sure does it clean the AWT stuff out. Or do they continue to run. Or is it anyway then f*ing up the GLFW....
But at least we need this (in Gradle) and this probably breaks up the installer (?) in normal conditions:
if (System.properties['os.name'].toLowerCase().contains('mac')) {
jvmArgs "-XstartOnFirstThread"
jvmArgs "-Djava.awt.headless=true"
}
We could replace the converter with SWT. I've never used it, but it looks promising. Mature and low footprint. JavaFX for me sounds still a bit bad. Okay, it is now again separated from Java releases which could be a good thing... This is just so minor thing this converter/setup thing. It just crashes now with LWJGL 3 in all systems...