AGS engine Mac OS X port

[Nine Toes]

Ack. My mistake. But I'll look into the wrapper thing. Thanks for trying to help anyhow.

[Monsieur OUXX]

Engine status: there is a Mac port by Wadjet Eye that can play games made with AGS 3.2.1 and lower. It is practically possible to update it to more contemporary version of engine, but it will take some work. Last time I heard about this, Janet Gilbert from WE wanted to hire programmer again to do this; also Nick Sonneveld mentioned plans to help them, but I do not personally track the progress in that area at the moment.

Alos Janet's post has been converted to a Wiki article, with added screenshots and some on-screen stuff clarified : http://www.adventuregamestudio.co.uk/wiki/Releasing_a_game_on_iOS
(PS: I apologize if I'm confusing MacOS and iOS; I'm not sure if it's the same realm or not)

[Crimson Wizard]

(PS: I apologize if I'm confusing MacOS and iOS; I'm not sure if it's the same realm or not)

No, these are different ports.
Although Mac OS and iOS are both Apple .
Our repository currently supports iOS, but only for jailbroken devices.

[Mehrdad]

Isn't any news for Mac OS port? Is it in progress or not? Mac OS is more important of Linux I think so.

[Crimson Wizard]

Isn't any news for Mac OS port? Is it in progress or not? Mac OS is more important of Linux I think so.

We do not work on Mac OS port right now, our work in that direction was not started properly yet. But I think Janet Gilbert might have something since they were hiring programmer.

[Mehrdad]

Thanks CW
So Does Janet Gilbert will put here or github source or method of this port ?   

[Crimson Wizard]

So Does Janet Gilbert will put here or github source or method of this port ?   

AFAIK she keeps it open source and available for public use in her repository, but I do not really track her progress right now, so it is up to her to explain where you get the latest version and how you use it. I guess the fastest way is to contact her directly for this kind of info.

[StillInThe90s]

I contacted Janet about her/their OS X port last june and she directed me here. It was open source then and it probably still is.
That was as far as I got, since I don't know anything about compiling source. It would be great if you could post about your progress.

[JanetC]

So Does Janet Gilbert will put here or github source or method of this port ?   

AFAIK she keeps it open source and available for public use in her repository, but I do not really track her progress right now, so it is up to her to explain where you get the latest version and how you use it. I guess the fastest way is to contact her directly for this kind of info.

There is no real progress on Mac at the moment, but the version that StillInThe90s linked to is just fine for most uses.

It will always be open source. We literally *can't* make it closed source as AGS is open source - we'd be breaking the terms of agreement! Besides, we don't want to

Anyone know a Mac programmer? We'd like some things fixed

[Snarky]

It will always be open source. We literally *can't* make it closed source as AGS is open source - we'd be breaking the terms of agreement!

Sorry to be a stickler, but this is not actually correct, since the license that AGS uses, The Artistic License 2.0, allows the distribution of modified versions without the source under certain conditions. The most relevant case is as long as you ensure that it does not interfere with installation of the standard version (which it shouldn't) and you give it a name that is different from the standard version (and I believe for this purpose, it's enough that you're distributing your games under their own titles, not just as "AGS").

Besides, we don't want to

[Bialy]

I contacted Janet about her/their OS X port last june and she directed me here. It was open source then and it probably still is.
That was as far as I got, since I don't know anything about compiling source. It would be great if you could post about your progress.

Is it possible for someone to post a download link to a compiled version of the latest mac os port? I don't really know how to compile github registries. Thanks!

[edmundito]

I had some free time, so I tried merging and resolving a few conflicts from the official v3.3.5.1 tag to JanetC's branch. Note that I am no expert in the AGS Engine source.

The result looked promising at a first glance. I was able to run a game. I think some of the more advanced animations seemed slow compared to the windows version.

There were a couple of major issues that I disabled in the meantime:

- The entire mouse handler has been rewritten; the way to get the mouse position is very different. This definitely causes some major cursor problem in full screen, and the mouse does not move correctly at all. In windowed mode, I saw the mouse reset to 0,0 when moving the cursor to the top outside the window.
https://github.com/JanetGilbert/ags/blob/humble-ports/Engine/device/mousew32.cpp#L99
https://github.com/adventuregamestudio/ags/blob/v.3.3.5.1/Engine/device/mousew32.cpp#L103

The window mode issue can be fixed by switching this variable to 1, but the full screen problems still prevail.
https://github.com/adventuregamestudio/ags/blob/v.3.3.5.1/Engine/device/mousew32.cpp#L62

- There's some hack involving reading the config file in the AGSMac. The way the INI file is loaded has changed as well, but may not be too much of a hard fix. I am not sure why was added:
https://github.com/JanetGilbert/ags/blob/humble-ports/Engine/platform/osx/acplmac.cpp#L132

- One issue I also foresee is that the graphics settings have changed from 3.2 to 3.3 and may affect the OS X migration more than expected and may cause more issues than anticipated.

[Crimson Wizard]

The result looked promising at a first glance. I was able to run a game. I think some of the more advanced animations seemed slow compared to the windows version.

What renderer does OSX build use? If it has only software one supported (like on Linux) then it will be generally slower (and more slow the higher scaling filter is used).

- The entire mouse handler has been rewritten; the way to get the mouse position is very different. This definitely causes some major cursor problem in full screen, and the mouse does not move correctly at all. In windowed mode, I saw the mouse reset to 0,0 when moving the cursor to the top outside the window.
https://github.com/JanetGilbert/ags/blob/humble-ports/Engine/device/mousew32.cpp#L99
https://github.com/adventuregamestudio/ags/blob/v.3.3.5.1/Engine/device/mousew32.cpp#L103

The window mode issue can be fixed by switching this variable to 1, but the full screen problems still prevail.
https://github.com/adventuregamestudio/ags/blob/v.3.3.5.1/Engine/device/mousew32.cpp#L62

We have some mouse issues in latest code, which hopefully be resolved soon. Although the particular ones you describe are different from ones we know.
Since I do not own Mac, I can only rely on user description of the problem, so the more details you can provide (game config, logs, etc) the better. Also, the situation may be different with the latest code in the "develop-3.3.5" branch, which does not have the release tag yet.

- There's some hack involving reading the config file in the AGSMac. The way the INI file is loaded has changed as well, but may not be too much of a hard fix. I am not sure why was added:
https://github.com/JanetGilbert/ags/blob/humble-ports/Engine/platform/osx/acplmac.cpp#L132

This hack is no longer needed after you make this merge, because there is a similar option our engine supports, just implemented differently (category "override", item "os", for details refer to the recently added readme (https://github.com/adventuregamestudio/ags/blob/master/OPTIONS.md) ). It may be safe to completely remove this INI reading from AGSMac::GetSystemOSID().

[edmundito]

Crimson Wizard, merging develop-3.3.5 did indeed fix the mouse issues. This is looking very promising. I have pushed the changes into my own fork. Here is a comparison:

https://github.com/adventuregamestudio/ags/compare/develop-3.3.5...edmundito:edmundito/osx-develop-3.3.5-clean?expand=1

To get it into the main source code, probably need to do the following:

- Pick only the os x changes (over linux and wadjet eye games specific) into a clean branch
- Encapsulate the mac modifications as #if defined (MAC_VERSION)
- Merge/rebase to develop-3.3.5 and resolve conflicts
- Fix the make files (right now I am hacking one of the game projects to make a build)
- Push and create a PR for adventuregamestudio/ags

[Crimson Wizard]

Please, we had this discussion many times. I am against putting this branch into our main repository. Two main reasons are:
1) it adds precompiled library binaries to repository, and we are against that (also, are these modified and are there sources of these?).
2) AFAIK it hacks SDL code into Allegro to make it run on mac, thus increasing general mess.
It makes it work and so serves its purpose, but it is not a clean way to do things.


Of course, separating OSX changes into a clean branch would make things easier to analyse. Also, so far it is the only up-to-date OSX version that actually works, so it would be silly to reject one. But I would suggest to keep this version in a separate repository for now until the issues I mentioned are resolved.


I also found my own suggestion made several months ago:

E: Since we now have an automation server, one of the options could be making a pull request that combines Janet's Humble Bundle port (not their pull request, but the most up-to-date version, I think this: https://github.com/JanetGilbert/ags/commits/humble-ports) and our current master.
The pull request will never be meant for actual merging (at least not until removing precompiled binaries), but it could serve for automatic building working OSX port.

[edmundito]

Please, we had this discussion many times. I am against putting this branch into our main repository. Two main reasons are:
1) it adds precompiled library binaries to repository, and we are against that (also, are these modified and are there sources of these?).
2) AFAIK it hacks SDL code into Allegro to make it run on mac, thus increasing general mess.
It makes it work and so serves its purpose, but it is not a clean way to do things.


Of course, separating OSX changes into a clean branch would make things easier to analyse. Also, so far it is the only up-to-date OSX version that actually works, so it would be silly to reject one. But I would suggest to keep this version in a separate repository for now until the issues I mentioned are resolved.


I also found my own suggestion made several months ago:

E: Since we now have an automation server, one of the options could be making a pull request that combines Janet's Humble Bundle port (not their pull request, but the most up-to-date version, I think this: https://github.com/JanetGilbert/ags/commits/humble-ports) and our current master.
The pull request will never be meant for actual merging (at least not until removing precompiled binaries), but it could serve for automatic building working OSX port.

Great points, I think your suggestion great and it's a good step to take. I would agree that having those binaries without the modified source code is dirty, but even if we can get to the point that there's an experimental "acmac" build for 3.3 and 3.4 that remains forked from the main repo would be a big accomplishment.

[JanetC]

I've really let this go (busy on other stuff), but we at Wadjet Eye are interested in releasing our games on OSX. Our old port by Edward Rudd of Humble Bundle isn't up to commercial standards anymore. It would be fantastic if OSX compatibility was part of the standard project. If anyone knows of any OSX developers who would be interested in working on this project, let us know. Otherwise I might try and muddle through (but I'm not experienced on Mac.)

The issue with the sticking mouse cursor was the worst for us (that's fixed, right?), but we also had issues with the right click not working, which is really important for our games.

We also need some fixes done on some Steam Integration stuff, but that's probably not relevant to the open source project

[sonneveld]

I've really let this go (busy on other stuff), but we at Wadjet Eye are interested in releasing our games on OSX. Our old port by Edward Rudd of Humble Bundle isn't up to commercial standards anymore. It would be fantastic if OSX compatibility was part of the standard project. If anyone knows of any OSX developers who would be interested in working on this project, let us know. Otherwise I might try and muddle through (but I'm not experienced on Mac.)

I'm keen to look at this again.. Just need to find time/energy.

Nick.

[maximara]

Isn't any news for Mac OS port? Is it in progress or not? Mac OS is more important of Linux I think so.

That depends on how close Darwin (which is the "under the hood" part of the MacOS so to speak and is a BSD Unix flavor certified SUS V3 OS) is to Linux. The Command-Line Tools component of Xcode (you get the GCC and LLVM compilers with this) and XQuartz could make everybody's life saner then having a separate coding just for the MacOS.  Macports is another tool in this regard.

I have seen a lot of things from the *nix world ported over to the Mac this way with Wine and Python being just two.

[JanetC]

I've really let this go (busy on other stuff), but we at Wadjet Eye are interested in releasing our games on OSX. Our old port by Edward Rudd of Humble Bundle isn't up to commercial standards anymore. It would be fantastic if OSX compatibility was part of the standard project. If anyone knows of any OSX developers who would be interested in working on this project, let us know. Otherwise I might try and muddle through (but I'm not experienced on Mac.)

I'm keen to look at this again.. Just need to find time/energy.

Nick.

Nick found the time/energy

Anyone who wants to build on Mac can check out our OSX port at https://github.com/JanetGilbert/ags/tree/osx-nick