AGS engine Mac OS X port

[Hobbes]

Alternative question: Is there a way to build an M1 compatible version? I found something related to the topic here for cmake:

https://discourse.cmake.org/t/how-to-determine-which-architectures-are-available-apple-m1/2401

I tried to add the IF(APPLE) section to the cmake_install.cmake file but it resulted in the same binary file as before. Or would the process be a bit more complex for AGS?

[eri0o]

I am not familiar with M1 (too expensive for me), but the way CMake is currently set up is there's no architecture information at all in the files, the idea is you pass a toolchain and it will follow along, if you don't it follows what's default for your system. So, say you are on a raspberry pi, you get raspberry pi binary compatible with your model's arm. Or say you want to crosscompile to arm like it's done on Android or to wasm (web builds), you pass the compatible toolchain.

Apple usually doesn't play well with cross-platform solutions so maybe things are different, but if there is nothing weird on their side it should simply build to the host architecture.

The thing mentioned on that forums is NOT about building for M1 alone, afaict it's focused on building "universal binaries" meaning, it builds twice, once for each arch, and them glues them somehow, and the system can then boot up the selected binary. It appears to be tied to Xcode (would not be just "make" after and building, it would require using Xcode).

Edit: ah, additionally, the CI system we use currently don't have M1 compatible hardware, so we can't provide binaries for it yet.

I asked in January but the situation still holds: https://github.com/cirruslabs/cirrus-ci-docs/issues/762

It would require maintaining persistent m1 workers.

Edit2: just read CMake git history and there has been a change of behavior for m1 from launch to now. On the latest version of CMake available, from what I understand, it should just build for arm if you launch an arm terminal and build for amd64 if you launch from a Rosetta terminal. In theory you should be able to build to each architecture separately already - or use the Xcode generator, and set it to use universal binaries in it's interface. Again, in theory, with the latest CMake.

[Manu]

Hi Manu, would it be OK if I added this to the AGS Wiki? It would be a great resource for people to keep an eye on. And then if the procedure changes, we can always update the wiki page.
Thanks for doing this!

Yes of course! Feel free to copy it, or if I have access to the wiki I can do it.

It works a treat by the way! I just compiled my game from scratch using the latest AGS version source code. I imagine this is how the wrapper is also created?

I'm not sure if it's created with Xcode or CMake, but I think the result is the same. Basically you are creating your "wrapper" in this way (if this is the right term). In fact, you can replace the files inside Resources, change the icon and rename it, and use it for another game.

[bx83]

BTW...
Why do we have to launch the GUI of CMake? I didn't even write in any info on it's main screen; went off and compiled fully without a hitch. :/

[eri0o]

There's a GUI?

[Manu]

BTW...
Why do we have to launch the GUI of CMake? I didn't even write in any info on it's main screen; went off and compiled fully without a hitch. :/

You are right, it's useless if you follow the guide, because I copied and pasted the command you have to type to use CMake from the command line. For me, it was useful because the CMake gui told me what to do to have CMake in the path
I guess the guide can be simplified.

[Hobbes]

I installed CMake through Homebrew so that might be the way to avoid any GUI stuff, since all that gives me is the CLI version. Worked a treat!

Eri0o, thank you so much for your investigation into the M1/Intel situation. I discovered I was running Homebrew through Rosetta and therefore got the Intel-version of CMake. I've now installed everything M1-native, but it seems that CMake will still only compile an Intel version of the game, not an M1-version. Not a big deal at this point in time anyway, since Rosetta2 is going to stick around for the next... 2 year I believe, at least. So we have plenty of time to explore this further as time moves on.

On that note, speaking as someone who has NO clue about programming, I have no idea how feasible it is to update the Mac version of the engine to Metal instead of OpenGL. The translation layer of MoltenVK (which is now open source I believe) only seems to work for Vulkan-to-Metal, but if we want to future-proof the MacOS port, then I think moving to Universal binary (Apple Silicon + Intel version combined) + Metal-graphics layer support (through a translation layer) would need to happen at some stage.

That being said, Apple has deprecated OpenGL since version 10.14 (Mojave) and it's not been removed for the past few years (since I think quite a few games/software packages rely on it). But the signs are there that OpenGL will get dropped by Apple at some stage.

A quick Google search showed up something like this: https://github.com/kakashidinho/metalangle as a potential solution, but since it's not an actively maintained thing anymore, probably not the right path to go down.

As a completely ignorant person when it comes to programming, is it "hard" to add Vulkan as a graphics driver to AGS Windows? Because then we could explore MoltenVK instead (which is actively maintained and has Valve-backing because of their Proton project on Linux).

[eri0o]

About M1, the command line terminal that's native, what output you get from uname -a ?

[Hobbes]

If I run uname -a I get the following result:

Code: ags

Darwin My-MacBook-Pro.local 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64

[eri0o]

This is weird, because if you ARE using the latest CMake you should not have to do this, it sets the variable CMAKE_OSX_ARCHITECTURES from the arch in the uname output from the invoking shell in theory, but you can pass it on the command line.

In AGS source code directory, create a clean build directory, generate files with cmake and try to build with make as this:

Code: bash

cd ags
mkdir cmake-build-release
cd cmake-build-release
cmake -DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_BUILD_TYPE=Release ..
make -j8

I don't have a way to verify this. I also am not sure, but I think you can verify the architecture of a binary. After building, in the same directory, try this

Code: bash

file ./ags

Also, the CMake version would be useful...

Code: bash

cmake --version

(note I am just trying to understand why you are not getting an arm64 build, but I am not familiar with the particular way MacOS works...

But about universal binaries, that is different. If one don't want to deal with them though, just make a bash script that checks the architecture with uname and boots the specific ags_arm64 or ags_amd64 binary with the game, and set this script as the entry point of the app in info.plist)

[Hobbes]

Hi eri0o, so sorry for the delay in getting back to you. I did exactly as you asked and the outcome of "file ./ags" is:

Code: ags

./ags: Mach-O 64-bit executable arm64

So it would appear we have success, an ARM executable! I just tried to run it, and it works flawlessly on my M1 Macbook Pro. So it works, when I use "Get Info" on the app, it tells me it's Apple Silicon (so ARM as well). This is great news.

The annoying thing for future reference is that people will need to fork out for an Apple Developer account and notarise/sign the app. MacOS is getting increasingly funny with running unsigned apps and everything on Apple Silicon has to be signed in order to run (unless you compile it yourself). Or you run the xattr -cr command on it, which is a hassle for non-command-line people. But that's a matter for another day, for now, it's great to see the future-proofing I was seeking is in place. :-)

[eri0o]

Just to give some update. It appears even though the CI system we use is Intel based, turns out there are new Big Sur images there. With Big Sur, I can at least cross compile to arm. I don't promise anything right now (there's a few other things), but at least it's possible to generate pre-built binaries of the engine that would be compatible with arm and x86.

About the extended attributes, on Windows/Linux the lazy way to remove them is to move the file to a pen-drive that is formatted to FAT and moving them back to disk. FAT filesystem doesn't support extended attributes, so they get cut. Never verified if it works on MacOS too. Obviously not a real solution, just workaround.

[morganw]

I've seen that programs supplied within a dmg image don't get restricted in the same way that programs distributed in a zip file do, although I imagine it may get stricter in the future. But if the app is copied into a dmg image within the CI environment I think that would likely prevent any issues relating to extended atributes flagging the files as high risk. The only thing that has tripped me up in the past is that the utility to progamatically create a dmg image now defaults to using APFS as the filesystem but not all macOS versions can open that.

[Manu]

I've seen that programs supplied within a dmg image don't get restricted in the same way that programs distributed in a zip file do, although I imagine it may get stricter in the future.

Are you sure about that? I tried creating a DMG with "create-dmg" (installed via brew), it's not complicated. But when I send the dmg to my friends, they see exactly the same warnings when they try to launch the game. The only advantage is that dmg is more "mac style", but apart from this, I think it's the same.

[morganw]

Very sure.
https://github.com/renpy/renpy/issues/1326

[Manu]

Very sure.
https://github.com/renpy/renpy/issues/1326

Ok, I'll do some more tests. Just to be sure, you downloaded a DMG from a website, then you double-clicked it to open it, and then dragged & dropped the application icon to Applications?

[eri0o]

@morganw, in the gazillion of possible outputs of CPack (from CMake), dmg is a valid one. It needs appropriate install() commands in the cmake file to tell the files that needs to be packaged though.

[Hobbes]

I do think that with Big Sur / M1 changes, the link provided holds some outdated information. From what I've read in various places (can test this in more detail later) it seems that Intel / Universal apps (x64 or joint x64/ARM binary) can launch with the right-click-open feature. ARM binaries (Apple Silicon) "demand" notarization/signing unless every individual downloaders runs xattr -cr themselves, this to negate ownership issues, making MacOS go "OK, this is yours". Doesn't make any difference whether the download came from a ZIP or DMG, from what I can find out.

[Manu]

Doesn't make any difference whether the download came from a ZIP or DMG, from what I can find out.

I can confirm, at least with the way I created the DMG. If there is a better way, I don't know. I packed the .app into a DMG using create-dmg (installed with homebrew). I uploaded the dmg to a server, then downloaded it, extracted it, and tried to launch it. It has the same warnings as the ZIP. Basically, you need to use right-click and then "open" two times before you can really launch the game.

[Dualnames]

Heya guys, I'm trying to use the port, but unfo this error happens.

https://pastebin.com/UMXp3i09

Which is weird, cause the files are there. I unfo don't have a mac myself, so it's harder for me to test. I just put all the relevant files in the wrapper as aforementioned.
The OS this was run in is Big Sur, Version 11.4. If you have a mac and can help out, do dm me, i'll gladly share the files!