AGS engine Mac OS X port

Started by JanetC, Mon 10/12/2012 19:12:16

Previous topic - Next topic

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

#221
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

Quote from: Hobbes on Fri 02/07/2021 00:11:52
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.

Quote from: Hobbes on Fri 02/07/2021 00:11:52
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


Manu

Quote from: bx83 on Fri 02/07/2021 14:27:00
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

#229
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

Quote from: morganw on Mon 05/07/2021 19:35:05
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.


Manu

Quote from: morganw on Tue 06/07/2021 13:00:00
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

Quote from: Hobbes on Wed 07/07/2021 10:08:14
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!
Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

SMF spam blocked by CleanTalk