AGS engine Mac OS X port

[eri0o]

@Dualnames, which wrapper? I think your game will only work in the Allegro4 version of the Engine - the SDL engine for now has conflicts with plugins that also use SDL.

There was a change how the Mac port find games (it will look in the place it was passed on command line and where the engine is), so how EXACTLY is the structure of your .app directory? And what is the entry point you wrote in your info.plist (it needs the game here) ? I think ags will search for plugins where the engine is and not the game.

Unfortunately the pastebin is not that useful since AGS doesn't print where it's looking for the plugins...

[Dualnames]

The wrapper is the one TheVolumeRemote provided. The dylibs are present in the resource folder with the .ags file.

[eri0o]

Can you place the plugins where ags Engine is located instead? It should then load them. I think the name of the directory is MacOS/ .

[Hobbes]

Hi Dualnames, I've got a Mac running Big Sur 11.4, so happy to help out if you send me the files?

[Dualnames]

Hobbes couldn't get it to work, any other takers?

Here's his reply, I hope it's okay for me to post it here:

Just to let you know I'm still trying to make this happen... the first issue I had, after downloading the app, is that MacOS was keen to tell me I didn't have permission to open the app. I used the two terminal instructions listed on this page (which had the same issue for someone else with another downloaded app) to fix that.

However, the game still won't run. I tried to load it into my own compiled container (which runs my games and others without issues). So I think there's something in your game that's currently broken in the core MacOS port for AGS. As far as I can see, no error log is being generated by the MacOS version that I can trace?

I'm a bit stuck as to how to help you further with this. Could it be the Steam plugin that's running whilst Steam isn't part of this game? Or the video file? I think multiple tests might be the way forward until this can be sorted?

[Dualnames]

I got it working guys!

[Hobbes]

Oooh, good news, congrats! Was it something MacOS-port related? I'm curious to hear what the issue was in the end?

[Dualnames]

So here are my two cents. This takes about 2-3 days to get a hold off. Imho, as I did on Linux, try googling every step and try to hold off your frustration. The more one fails the more they realize how an OS works. After grasping that everything else comes into place. The issue on my case was that the custom plugin Strangeland uses had its dependencies wrongfully set.

For future reference if you ever have trouble of a plugin loading.

Code: ags

otool -L dylibnamehereorlocationifnotonthefolderthedylibisat

Will show dependencies.

Code: ags

install_name_tool -change old new file

Will change a dependency.

[Dualnames]

I assume one can't build an arm64 architecture executable, unless they are on an arm64 architecture OS, right?

Edit: Also does that mean all dylibs need to be arm64 arch?

[Crimson Wizard]

I assume one can't build an arm64 architecture executable, unless they are on an arm64 architecture OS, right?

Edit: Also does that mean all dylibs need to be arm64 arch?

The second is definitely true.

About the first, there may be tools that allow building for a different architecture (cross compiling), but i'm unaware what is available for mac.

[Hobbes]

If it helps, I can build an empty one? And then you can a lot your stuff into it?

The difficulty will be a Universal Binary.

[Dualnames]

I managed to build the executable and made a script that checks between the two.
What happens if the dylibs are not arm64?

Essentially the issue being steam dylibs being x86_64 (They don't support arm64 yet AFAIK)

[Dualnames]

ARM native can only be directly uploaded to the APP store not gog, epic or steam.

[Crimson Wizard]

What happens if the dylibs are not arm64?

I believe they won't load on arm64.

Perhaps try making a version without libs for which you don't have a arm64 variant.

[Dualnames]

I only have to compile libagswaves.dylib under Arm64 so imma try and see if i can.

EDIT: I got it, I had to compile SDL2 framework and SDL2 mixer framework and their individual frameworks under arm64 to be able to compile my plugin agswaves under arm64.

[Hobbes]

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)

Following on from this post a while back, I've discovered cmake is perfectly able to compile a Universal Binary! Which is great news. Just to make a small modification to Eri0o's post above, the cmake command should be:

Code: ags

cmake "-DCMAKE_OSX_ARCHITECTURES=arm64;x86_64" -DCMAKE_BUILD_TYPE=Release ../

This will then build a universal binary, which means it's only one binary to distribute for MacOS which includes both x86 and Apple Silicon. Works a treat with 3.6.0 too!

[Dualnames]

@Hobbes

Did you ever manage to compile the steam under the universal thing?

https://github.com/monkey0506/agsteam

I've been unable to compile it even in x86_64.
Any ideas?

[Crimson Wizard]

I've been unable to compile it even in x86_64.

Could you post errors you are getting?

[Dualnames]

It says "undefined symbol _SteamApi_gethuser" and 10 more errors related to the linking phase [when i've linked nothing].
When I've linked the dylib inside the project files it does compile but when running the exe it shows me an error "AGS2client:issetachievement^1" is not defined, as if the plugin is empty, which it is not.

[Hobbes]

I've been successfully compiling universal binaries for a while now, but I do believe plugins have to be universal for things to work? The steam plugin probably isn't. But with Steam now slowly moving towards M1 compatibility, that might change? I think right now, there's no option to upload a universal binary / M1 binary to Steam regardless?