Topic: AGS engine Mac OS X port

[edenwaith]

Thanks for the tip, Morgan, I'll make sure to update allegro.

Code signing (and app notarization) is the last step you want to perform.  If you modify the app bundle after it has been code signed, that will invalidate the signing.  However, it is possible to build the app and then code sign once you have the completed bundle.  Of the AGS games I've ported (and other projects), it is possible to manually code sign the app so Xcode (or even the source code) is not necessary.

As far as I know, you need to be using the newer (and custom) Allegro version from the repository in order to have the colours work correctly:
https://github.com/adventuregamestudio/lib-allegro/tree/allegro-4.4.3.1-agspatch

One issue I struggled to test is whether the signing for an app bundle is invalidated when the game data file changes:
https://github.com/adventuregamestudio/ags/pull/1083#issuecomment-650588478
I don't suppose you know the answer?

[Snarky]

In coding, it's useful to have a big, high-resolution screen, and of course a comfortable keyboard. Keyboard quality has been a problem on some recent MacBook models (google "mac butterfly keyboard"), so that's something to look out for. The precise model shouldn't matter much otherwise, I don't think.

[edenwaith]

An issue I just encountered with the 3.5 build of AGS is that an allegro.log file is being written inside of a Mac's app bundle when the game launches.  Is there a way to disable this with the acsetup.cfg file, or is this something with Allegro that needs to be changed so it stops writing to the allegro.log file?  This is causing major problems since it breaks the code signing of the app if something changes within the app bundle.

As far as I know, you need to be using the newer (and custom) Allegro version from the repository in order to have the colours work correctly:
https://github.com/adventuregamestudio/lib-allegro/tree/allegro-4.4.3.1-agspatch

One issue I struggled to test is whether the signing for an app bundle is invalidated when the game data file changes:
https://github.com/adventuregamestudio/ags/pull/1083#issuecomment-650588478
I don't suppose you know the answer?

[Crimson Wizard]

I could be mistaken, but I thought allegro.log is only written if you compiled engine in Debug configuration or using debug version of allegro library. Could you double check that you are using a release build?

What kind of messages that log contains?

PS. AGS itself does not control that behavior.

[edenwaith]

I wouldn't be surprised if there was some debug setting in Allegro.

Here's an example of what is being written to the allegro.log:

Code: Adventure Game Studio

1. al-main INFO: Allegro initialised (instance 1)
2. al-gfx INFO: Called set_gfx_mode(1129268812, 356, 200, 0, 0).
3. al-gfx INFO: First call, remembering console state.
4. al-gfx INFO: The driver will wait for vsync.
5. al-gfx INFO: set_gfx_card success for 356x200x32.
6. al-osxgl INFO: OpenGL Version: 2.1 INTEL-12.10.24
7. al-osxgl INFO: Vendor: Intel Inc.
8. al-osxgl INFO: Renderer: Intel(R) Iris(TM) Pro Graphics 6200
9. al-gfx INFO: Called set_gfx_mode(-1, 0, 0, 0, 0).
10. al-gfx INFO: Closing graphics driver (0x1009feb90) Cocoa GL full.
11. al-gfx INFO: Closing, restoring original console state.
12. al-gfx INFO: Graphic mode closed.
13.  

I could be mistaken, but I thought allegro.log is only written if you compiled engine in Debug configuration or using debug version of allegro library. Could you double check that you are using a release build?

What kind of messages that log contains?

PS. AGS itself does not control that behavior.

[edenwaith]

After consulting with my wise rubber duck, I believe I have solved the problem.  The previous build of the Mac AGS shell app was likely a debug build, so Allegro thought that writing a log file into the app bundle's Resource folder was a good idea (it wasn't).  I followed the build instructions using CMake at this post (https://www.adventuregamestudio.co.uk/forums/index.php?topic=47264.msg636611972#msg636611972) and wrote up a small script and ran that from the ags-release-3.5.0 directory.  I have code signed the app and run it, and it appears that the allegro.log file is no longer appearing, so this looks promising now.

[TheVolumeRemote]

Here’s a build from the 3.5 release, I tested my game which is being made in 3.5 (patch 7) and it works (OSX 10.15.7).
It seems it wants the .exe renamed to game.ags instead of ac2game.dat (or ac2.dat), but once you rename it just right/control click on AGS.app then put the files in Contents > Resources

https://www.dropbox.com/s/u4bewlhouh2muqt/AGS%203.5%20Mac.zip?dl=0

[eri0o]

Hi @TheVolumeRemote,

The name change should be mentioned in the paragraph here: https://github.com/adventuregamestudio/ags/tree/master/OSX#adding-resources-for-the-game

After reading your message I am a bit confused, did you find a bug and you are reporting or did it not work? Can you explain it a bit more?

[TheVolumeRemote]

Thanks mate I had missed the name change info! I posted that because my game in progress (being made in 3.5 latest) didn’t work in the previous shell which is from the 3.4.4 build  (download posted on page 1 from someone’s google drive). I tried it as ac2game.dat, ac2.dat and game.ags. But it does work in the 3.5 build (the link I posted). So I mainly just posted that so that if anyone is working on a game in 3.5 and it won’t work in the old 3.4.4 wrapper, they can download my 3.5 wrapper and it should work

[bx83]

TheVolumeRemote, could you produce a version of the wrapper for AGS 3.5.0.31 / 3.5.0-p9?

(my game is p9, currently seems to work with p7, but testing might produce a crash)

[Manu]

I just tested it and it works perfectly! Thank you!
I have one question regarding the config file. After I run the game once, I modified the file acsetup.cfg in the Resources folder, to switch from fullscreen to windowed mode. But the change didn't produce any effect. Is the config file saved in the user directory and the default config is ignored the second time you run the game, like the Windows version?. If this is the case, where is the config file saved?
 
And another question. Can I rename AGS.app to mygame.app? Or this will break something?

Thanks a lot!

[bx83]

I renamed it LoCI.app, works fine.

[bx83]

Does Remote or anyone know how to change the icons from standard AGS by doing something *other* than re-compiling the MacOS engine from scratch?

[CrashPL]

Does Remote or anyone know how to change the icons from standard AGS by doing something *other* than re-compiling the MacOS engine from scratch?

Replace the ags.icns file in the Resources of your app with your icon of choice, and then type

Code: Adventure Game Studio

1. touch yourGameName.app

in the terminal.

[bx83]

Thank you

[Manu]

Hello! I used the AGS Mac Wrapper 3.5. I added all the files of my game into the Resources folder, I also renamed the app and changed the icon. The game worked perfectly. Then I zipped it and send it to my friend but he could not open the app, he saw an error message "you don't have permission to open this app". I tried to download the zip and this happened to me too. I also tried the usual Ctrl+Click to open it, but it's the same. There is no way to launch the game if it's downloaded.
Do you know if it's possible to fix this? Thanks a lot!

[eri0o]

I imagine things downloaded from the internet after Catalina gets tagged as insecure by the OS, so I it would require both code signing and notarization to run. But the SO answers says a bunch of different things: https://stackoverflow.com/questions/64842819/cant-run-app-because-of-permission-in-big-sur/64895860#64895860

[Manu]

I imagine things downloaded from the internet after Catalina gets tagged as insecure by the OS, so I it would require both code signing and notarization to run. But the SO answers says a bunch of different things: https://stackoverflow.com/questions/64842819/cant-run-app-because-of-permission-in-big-sur/64895860#64895860

So apparently it was a problem of permissions. I solved it with

Code: Adventure Game Studio

1.  chmod -R 755 NameofGame.app

After that, I was able to launch the game, after the usual warning about insecure source.
thanks!

[Crimson Wizard]

So apparently it was a problem of permissions. I solved it with

Code: Adventure Game Studio

1.  chmod -R 755 NameofGame.app

After that, I was able to launch the game, after the usual warning about insecure source.

I think this is the similar problem to the linux distribution that is packed by the Editor.

[Potajito]

I imagine things downloaded from the internet after Catalina gets tagged as insecure by the OS, so I it would require both code signing and notarization to run. But the SO answers says a bunch of different things: https://stackoverflow.com/questions/64842819/cant-run-app-because-of-permission-in-big-sur/64895860#64895860

So apparently it was a problem of permissions. I solved it with

Code: Adventure Game Studio

1.  chmod -R 755 NameofGame.app

After that, I was able to launch the game, after the usual warning about insecure source.
thanks!

As a side note, if you use itch.io's butler (the command line software to push builds), you can add the flag --fix-permissions (both for max and linux) so you don't have to do that manually.