On macOS Mojave, the game will start black; the correct fix would be to upgrade SDL and use the Metal framework, which would make us drop versions 10.9 to 10.11.
Alternatively, starting the game windowed works around the bug by trigerring a redraw of the window.
Details
Details
- Reviewers
trompetin17 - Trac Tickets
- #5341
Check that a bundle generated like this has the correct tweaked default config.
Diff Detail
Diff Detail
- Repository
- rP 0 A.D. Public Repository
- Lint
Lint Skipped - Unit
Unit Tests Skipped - Build Status
Buildable 6443 Build 10672: Vulcan Build Jenkins
Event Timeline
Comment Actions
Successful build - Chance fights ever on the side of the prudent.
Link to build: https://jenkins.wildfiregames.com/job/differential/776/
Comment Actions
Itms, could you point me where do you see about drop 10.9 to 10.11, because when i tried sdl2.0.9 i didnt change minimal osx version and builded normally
Comment Actions
Yes, but if you linked Metal dynamically, users of the built bundle will not be able to start the game if they are below 10.11. Did I misunderstand something about the availability of Metal for older versions?
| build/workspaces/build-osx-bundle.sh | ||
|---|---|---|
| 185 | This won't work for people who already have a user.cfg.
Which would be changing a number and seeing if it falls apart? | |
| build/workspaces/build-osx-bundle.sh | ||
|---|---|---|
| 185 |
Yeah basically. I believe we are still trying to limit changes for this re release... | |
| build/workspaces/build-osx-bundle.sh | ||
|---|---|---|
| 185 | Which makes not much sense to me especially since we are trying to fix Mac. | |
| build/workspaces/build-osx-bundle.sh | ||
|---|---|---|
| 185 | Ah right I was thinking that users with the bug couldn't have had changed the windowed value before, since they can't use 0ad, but I was forgetting about the people who used to have a working game and upgraded to Mojave. This is not really about limiting the number of changes, rather about not dropping users who don't have Metal. But maybe we can make two packages, one for platforms with Metal, and one for platforms without Metal (those don't have the bug). | |
| build/workspaces/build-osx-bundle.sh | ||
|---|---|---|
| 185 | A HardwareDetect implementation would likely also prevent the user from enabling fullscreen mode. | |
Comment Actions
Metal was introduced in El Capitan (OSX 10.11)
https://en.m.wikipedia.org/wiki/Metal_(API)
I'd like trompetin17 to try to play with us and Vladislav to make sure everything is fine.
Comment Actions
Just an idea, could we add code in osx about include explicitly at run time Metal Lib is you already have, because SDL2.0.9 check witch use depending on osx, isnt?
The other option is to disable "Full Screen" in osx, we already have "windowed full screen".
So we could detect that we are using osx so disabled "FULL Screen", this should be another option
Comment Actions
It's true the older macOS'es don't yet have Metal, but as I understand it SDL 2.0.9 added support for Metal, it didn't remove support for older macOS.
I don't know SDL internals at all, but I see two possibilities here that could pose a problem. Sorry if this is obvious :)
- Maybe SDL makes a compile-time decision about which implementation to use (instead of compiling both paths and deciding once at run-time). Is that the case?
- Maybe SDL needs to be on a newer macOS host to be able to compile the Metal version and maybe it needs to be on an older macOS install to compile the old path, e.g. if there are compile-time dependencies on stuff that ships only with the OS and that the newer macOS no longer bundles the old thing. Is that the case?
If it's only the first problem, then I wonder if it is feasible to somehow change our wiring code or apply a source patch to make it compile both variants and decide at run-time. Or perhaps upstream SDL might be open to making that work. Or if that's not possible, perhaps we could have two invocations of build-osx-bundle, e.g. two downloadables for osx, both the the latest version of the game, but one targtting= macOS <= 10.11, and the other newer macOS.
If it's the second problem (or both), I suppose we'd have to not just make two bundles but also make them from differnet hosts as it would mean you need to be on older macOS to build for that macOS. Would that be a viable option? It seems straight forward, but I also get that it's extra work around release :)
Comment Actions
We dropped 10.11 and earlier yesterday, so SDL2 could be updated and this can be closed.