"Load from custom location" and "Save to custom location" don't work on MacOS

[lishaoxia1985]

I'm not sure whether it is related to openGL3.

[xlenstra]

On discord it was posted that you need to run java -jar Unciv.jar -XstartOnFirstThread to start unciv, but I don't have a mac so I don't know if that solves your problem

[lishaoxia1985]

I use MacOS to test this APP, if you are good at gradle, Maybe editing the gradle script is a good idea.

[yairm210]

I already edited the desktop gradle to add that parameter when running, as per libGDX instructions
Did this happen on both "run" and "debug"?

[SomeTroglodyte]

I vaguely remember reading something about startOnFirstThread needing to be the other way round for certain combinations of JRE and lwjgl2/3. In other words, "as per libGDX instructions" might have been specific to a backend. As my gut feeling was this whole mess is due to something fundamentally wrong in either macos, gdx or both, I didn't bother to understand the underlying issue well enough to remember now - should be searchable though in libgdx's issue tracker. Something about the "first" thread now being some wrapper/loader and no longer the one actually running the UI.

That said, the gradle scripts will only influence the setting when running the packaged app, Xander's command line suggestion is entirely independent, and should, as on other platforms, allow trying out a lot of combinations, meaning with/without the switch (but I'd suggest looking up and using the one to increase the heap size), and with independent java runtimes.

[yairm210]

You're right, I wanted to add this to the readme.md, but checking it now I obviously didn't do that in the end

[lishaoxia1985]

This happens on both "run" and "debug"
@xlenstra I download unciv.jar and use your method, the bug has not been solved.
use "java -jar -XstartOnFirstThread /Users/yuer/Downloads/Unciv.jar", the app window will appear, but it's always a blackscreen, I think it is half solved, I will find a way to solve this problem. Don't revert.
By the way, when you run ConsoleLauncher, we will get the error: UninitializedPropertyAccessException: lateinit property worldScreen has not been initialized at com.unciv.UncivGame.getWorldScreen

[lishaoxia1985]

This bug may be related to font, in 3.17.14, the log will be this:

Packing textures - 8ms
Error in LSRegisterURL: -10811
AL lib: (EE) ca_open_playback: AudioUnitInitialize failed
Loading Construction = Construction.atlas
Loading Flags = Flags.atlas
Loading Skin = Skin.atlas
Loading Tech = Tech.atlas
Warning: the fonts "Times" and "Lucida Bright" are not available for the Java logical font "Serif", which may have unexpected appearance or behavior. Re-enable the "Times" font to remove this warning.
Loading ruleset - 548ms
Loading percent complete of languages - 1ms
TileSetConfig loaded successfully: FantasyHex.json

In the latest branch, it's this:
Packing textures - 8ms
Error in LSRegisterURL: -10811
Loading Construction = Construction.atlas
Loading Flags = Flags.atlas
Loading Skin = Skin.atlas
Loading Tech = Tech.atlas

We'd better try to get an extra font and test it.

[SomeTroglodyte]

Disagree. Unciv is very unspecific about what Font it accepts (Font("", Font.PLAIN, size)), so the on-the-fly bitmap font generation from native should get glyphs no matter what. That warning is by the JRE or by some other library, not by Unciv - and it's a warning only.

[lishaoxia1985]

@SomeTroglodyte Ok, Have You read seriously? I said the bug branch has not this waring. That means after the APP load the picture, IT stop and can't run the next step, so it's my conclusion.
if we don't add -XstartOnFirstThread when we package the APP to jar, and add IT when we run the app, the bug may disappear, I'm not sure.

[SomeTroglodyte]

Have You read seriously

Sure, and thoroughly, or so I thought. What wasn't entirely clear - I had inferred the console output you are showing to be different is partial and doesn't end there, and you've shown only part to clarify that warning line makes a difference. I think now I have been wrong, and you do get that hang immediately after "Loading Tech = Tech.atlas" while the other does continue, so the warning part is actually the good sign. I assume what happens is nothing at all, no further output, no window, and you have to kill a dead process manually? Or does the process die silently? OK - that distinction actually doesn't make a big difference either, point is the next step never happens.

Hmmm - then sorry, this runs but I've never tested the results, just found out how to without it failing in silly ways:
In Android Studio, I'd open the studio-local terminal (Alt-F12), then do

wget -q -O packr-all-4.0.0.jar https://github.com/libgdx/packr/releases/download/4.0.0/packr-all-4.0.0.jar
wget -q -O jre-macOS.tar.gz https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.11%2B9/OpenJDK11U-jre_x64_mac_hotspot_11.0.11_9.tar.gz
./gradlew desktop:packrmac

..then look under /deploy. The wget lines are taken from .github/buildAndDeploy.yml, which may be outdated in the project clone as it's mac-specific part is commented out. But maybe you can try - see you can build the same way, test the result, then patch desktop/build.gradle.kts line 135, build again and compare?

All very shot-in-the-dark, as mac is not within my reach to test. If Apple actually welcomed independent developers...

[yairm210]

Maybe this has something to do with the screen resize?
Try removing the height and width set from the desktoplauncher and see if that makes a difference?

[lishaoxia1985]

@yairm210 have you consider about using mini2Dx to package the APP for MacOS?
I have said, use "java -jar -XstartOnFirstThread /Users/yuer/Downloads/Unciv.jar", the app window will appear, but it's always a blackscreen. I think it's no business with screen height/width.

[yairm210]

I'm completely open to suggestions for packing for MacOS, my main problem is that I don't have a device I can test on...
when I tried to pack with packr I got responses that it didn't work, but that was with the previous version

In the worst case scenario, I'm not against having 2 desktop launcher classes, one for mac, bit as time goes on it'll be problematic since it's deprecated

[yairm210]

Min2dx looks like an entirely different framework though?
Not sure if that's even doable

[SomeTroglodyte]

I think I found my "sources" (as in I've read them accidentally while just snooping around): A test suite run by a teacher and another game dev's blog about game publishing for mac - no wonder I marked macOS down with the "hostile territory" prejudice. But Mr. Walker's experiments might be valuable to find a mac packr combo that works.

[yairm210]

Okay... Notarizing for Apple added to the list of "things to never do"
But the second article is beautifully written
I looked at his game page as well and I really like his sense of humor :)

[SomeTroglodyte]

Exactly.

[lishaoxia1985]

When you add -XstartOnFirstThread the latest branch will show like that, 3.17.4 is very good for macos.

[lishaoxia1985]

@yairm210 @SomeTroglodyte @xlenstra OK, it's solved, In MacOS you should use this:
"java -jar -XstartOnFirstThread -Djava.awt.headless=true /Users/yuer/Downloads/Unciv.jar", the bold and italic words means your Unciv.jar place.
Why we should add "-Djava.awt.headless=true"? because we use BufferImage in the class NativeFontDesktop, you can see this:
https://stackoverflow.com/questions/46793769/bufferedimage-causes-a-program-freeze-on-mac
By the way, package these two arguments into jar seems meaningless.
OK, adding "-Djava.awt.headless=true" will create a new bug:
You cannot use "Load from custom location" and "Save to custom location" because the class CustomSaveLocationHelperDesktop runs normally only when Djava.awt.headless = false.
If we want to solve this problem, we should refactor the class CustomSaveLocationHelperDesktop without java.awt or javax.swing.

[yairm210]

Should be solved with upgrade to libgdx 1.11.0!

https://github.com/libgdx/libgdx/releases/tag/gdx-parent-1.11.0

[touhidurrr]

Should be solved with upgrade to libgdx 1.11.0!

https://github.com/libgdx/libgdx/releases/tag/gdx-parent-1.11.0

The resolve #5679 thing didn't work for some reason. Needs to be closed manually.

[lishaoxia1985]

Have somebody test this? My macbook is broken, if this bug has been fixed, we can close this issue.

[SomeTroglodyte]

Now waitaminute. The analysis by @lishaoxia1985 up there must be on the spot. BufferedImage is an awt class, and if you tell awt there's no display, well, displaying an awt dialog can't work. What has that got to do with libGdx? Nil. ...So if any libGdx upgrade improves anything here then it is interoperability with awt, and we need to remove awt=headless to see any effect. And that option is still here for the desktop:run task and here in readme and here in wiki . By the way, the gdx releases link is a 404 now and the wiki link in the build script has been killed by them.

Best approach: Someone with a Mac go and test please? If only there were a testing VM free for devs.. But there isn't which to me sounds like Apple proclaiming "we don't want you" 😉.

[yairm210]

Since it should work but no one has checked, I'm closing this as "resolved"