Everything seems a little quiet round here. Is there any current progress on a port of AGS to Mac? Because Wadjet Eye gets a tonne of requests for Mac versions of our games.
The notes on the OSX port at https://github.com/adventuregamestudio/ags read:
QuoteThe OSX port is currently only interesting for developers.
Main reason for this is that it only runs on OSX versions 10.6 (Snow Leopard) or lower. Important frameworks used by Allegro 4 were removed in later releases.
What were these important frameworks, and how feasible is a working port?
You could ask the Allegro Development list [1] how difficult porting Allegro 4 would be.
An alternative would be porting AGS to Allegro 5. [2]
[1] http://alleg.sourceforge.net/maillist.html
[2] http://www.adventuregamestudio.co.uk/forums/index.php?issue=355.0
I'll add my "two cents". To be frank, I did not yet have chance to explore Allegro 5 and learn how much is different from A4 (code-wise). But the general issue is that allegro 4 calls are scattered throughout the engine (those that deal with graphics and controls mainly) instead of being groupped (like in helper functions or classes). If it is only about changing function names, it is not much of a problem. But I fear that there may be changes to logic of usage, in such case certain parts of AGS should be completely overwritten.
As I see it (just a basic idea) there is fast way and "good" way. Fast way is just discard all code style considerations and brute-force Allegro 5 into engine. "Good way" is to properly reorganize the code, hide Allegro 4 calls under interfaces, like Bitmap, Graphics, Mouse etc classes, only then port to A5. I like second way more, but I have no idea how much more time it will take. Depends on how many people involved, I guess. Maybe hacking A5 in place of A4 won't make AGS code too much worse, than it is :).
EDIT: Couple things more:
- The editor uses Allegro 4 too, for converting graphics. I guess (only guess) that is minor issue and could be fixed more easier.
- I really hope there's compatibility between A4 and A5 resources (like bitmaps structure). Otherwise there must be a conversion.
The graphics code including data structures has probably changed quite a lot. Allegro 5 was written for OpenGL, Allegro 4 for DOS. But then it's probably a good thing if AGS uses it's own data structures and the game file format is disentangled from the library dependencies of the engine.
@JanetC, also, a small note, seeing as you (https://github.com/JanetGilbert/ is your repository, right?) are merging our refactored code from time to time:
current 'ags/master' branch, while having more potential due to rewritten script interpreter (it is more compatible with 64-bit builds), is still considered a bit unstable (well, for the same reason ;)), and had new bugs in recent past. So if you are using your branch for shortly upcoming releases, I'd recommend not to update from our repository for some time.
Quote from: Crimson Wizard on Tue 11/12/2012 10:08:54
@JanetC, also, a small note, seeing as you (https://github.com/JanetGilbert/ is your repository, right?) are merging our refactored code from time to time:
current 'ags/master' branch, while having more potential due to rewritten script interpreter (it is more compatible with 64-bit builds), is still considered a bit unstable (well, for the same reason ;)), and had new bugs in recent past. So if you are using your branch for shortly upcoming releases, I'd recommend not to update from our repository for some time.
Do you mean not to update from Refactory or master? Because I haven't updated in a while, but when I do, I use Refactory.
Thanks for the info on Mac, guys. Sounds like quite a task!
When you say "You could ask the Allegro Development list [1] how difficult porting Allegro 4 would be.", BigMc, I googled quickly and the Allegro downloads page seems to show that Allegro 4 is already Mac compatible. Am I not following something?
http://alleg.sourceforge.net/download.html
It works up to Mac OS X 10.6 and Allegro 4.4 was released before Mac OS X 10.7, so that information is probably outdated.
Quote from: JanetC on Tue 11/12/2012 20:30:30
Do you mean not to update from Refactory or master? Because I haven't updated in a while, but when I do, I use Refactory.
I mean both. There was a big change made in refactory branch (script interpreter). Then we created master branch and now working in there.
I hope it will become safe in a while, people are using it to play games, so these changes will be tested.
Quote from: JanetC on Tue 11/12/2012 20:30:30
Thanks for the info on Mac, guys. Sounds like quite a task!
Well, I do not want to overestimate things or scare people off. I don't think it is a year-long of work, maybe 2-3 months of work. There just should be dedicated someone who would do that fairly.
There's already my Bitmap class in use, someone need to do the rest (probably Graphics class for storing drawing settings like colors, Font class, etc).
I was hoping to work on this, but then I switched to something that I wasn't even planned to work on, and that distracted me for nearly 3 months.
If you have a will to help, you are most welcome :)
Quote from: Crimson Wizard on Tue 11/12/2012 22:33:56
I mean both. There was a big change made in refactory branch (script interpreter). Then we created master branch and now working in there.
I hope it will become safe in a while, people are using it to play games, so these changes will be tested.
When was the unsafe change made? I have a beta of Gemini Rue on iOS running on the Wadjet Eye boards at the moment, and we are getting a lot of crash reports.
Quote from: Crimson Wizard on Tue 11/12/2012 22:33:56If you have a will to help, you are most welcome :)
I have a will but no time, since I am busy on the iOS ports of our game and will be even busier with a baby next spring. :)
Quote from: JanetC on Wed 12/12/2012 14:43:08
When was the unsafe change made? I have a beta of Gemini Rue on iOS running on the Wadjet Eye boards at the moment, and we are getting a lot of crash reports.
29th November.
But according to network graph, you made last update from "refactory" 29th october, so it might be something different.
I don't remember anyone tested our latest changes on iOS. JJS should know better though. We confirmed it works on Windows, 32-bit Linux, 64-bit Linux and old big-endian Mac (I think).
Well, and Android (judging on this user report: http://www.adventuregamestudio.co.uk/forums/index.php?topic=44768.msg634773#msg634773)
The newest builds work for me on iOS too. But I have not done extensive testing, really. I would also recommend not to update your source to the latest "refactory" or "master" version because this might have new bugs and will have zero benefit for only running on iOS.
Quote from: JanetC on Wed 12/12/2012 14:43:08When was the unsafe change made? I have a beta of Gemini Rue on iOS running on the Wadjet Eye boards at the moment, and we are getting a lot of crash reports.
Doesn't sound so good. If you have something that seems to be a general port problem please forward it to me. The most likely cause of crashes is still the multithreaded audio. If so I would expect it to mostly affect devices with multiple processor cores.
Hey guys - just a quick jump in, asking if there's still any development with this? Just curious, because Infamous Quests is definitely interested in having a native Mac Port, instead of a Wine Wrapper.
Bt
Dave posted a recruitment ad for someone to port AGS to Mac.
http://www.adventuregamestudio.co.uk/forums/index.php?topic=47577.0
Having our back catalogue on Mac is something Wadjet Eye Games really wants to do.
Not much interest here... is it worth pointing out that Wadjet Eye would be willing to pay someone to do this port?
Quote from: JanetC on Fri 08/02/2013 22:01:53
Not much interest here... is it worth pointing out that Wadjet Eye would be willing to pay someone to do this port?
On a practical note, maybe not many coders here have access to Mac OS X and/or XCode? Maybe you should try to advertise this on a freelancer site, maybe one orientated towards Mac programming.
Quote from: Sslaxx on Fri 08/02/2013 22:20:56On a practical note, maybe not many coders here have access to Mac OS X and/or XCode? Maybe you should try to advertise this on a freelancer site, maybe one orientated towards Mac programming.
That's the second option if no one is interested. I'd prefer to work with someone who understands AGS if possible. I might just do it myself, but that wouldn't be until at least late this year, probably next year, which would be a shame.
I can't give any promises in regards to timeline, but I was going to work on separating Allegro 4 from the general code anyway. Or someone else could do that too to speed things up (I think more people are becoming interested in working on the engine, like scotchchiefbaker and Slaxx). I will be returning to this task very soon. I think the situation here would become more clear in couple of months.
Something I totally missed, there was a Mac OSX port made by Nick Sonneveld using SDL: http://www.adventuregamestudio.co.uk/forums/index.php?topic=45708.0
Notice, it is said that Gemini Rue was successfully run with that port.
What is its status? Why was it discontinued?
Also, he mentions a reasonable argument about using SDL instead of Allegro 5. May anyone on comment that?
Quote from: Crimson Wizard on Fri 15/03/2013 11:05:46
What is its status? Why was it discontinued?
I guess it's much less polished than the the 3.3 engine.
Quote
Also, he mentions a reasonable argument about using SDL instead of Allegro 5. May anyone on comment that?
He just said Allegro 5 is lacking pixel drawing and palette manipulation features. Is pixel drawing really a problem? Do you think SDL provides everything, so that it would require less code to be moved to AGS itself?
Quote from: BigMc on Fri 15/03/2013 15:36:28
He just said Allegro 5 is lacking pixel drawing and palette manipulation features. Is pixel drawing really a problem? Do you think SDL provides everything, so that it would require less code to be moved to AGS itself?
I know nothing of SDL, so don't know if it's less coding... I just see there's already a Mac port that probably could be used to make few releases, like Wadget Eye wanted to.
Palette manipulation may be a problem if we care of supporting 8-bit games. I know there might be some solutions for A5 too, but don't know how difficult it will be to implement them (and how effective they would be). Not sure what he meant about pixel drawing though (I ignored that part); if he means setting certain pixels, or setting raw bitmap data, Allegro 5 supports that pretty well.
CW, I think your refactoring plan for abstracting the interface between the engine and low-level drawing, control and audio routines, gives us the best hope. With such an abstraction, we have more room to replace parts (or all) of Allegro 4 for whatever reason we choose. Perhaps that could be to bring in Allegro 5, or perhaps it could be OpenGL/OpenAL via SDL. To my knowledge, SDL is a fine library, highly-portable, performant, and comes with a strong and healthy community to support it. But it is a lower-level construct than Allegro.
I haven't spent much time looking at Sonneveld's port, specifically, but from my meager experience with SDL, I would assume that an SDL port would almost certainly require more code (to provide some of the higher-level functionality we expect from Allegro). This, by itself, is not a bad thing, just something to consider. Ultimately, it's certainly not the case that all the engine runtime ports must absolutely use all the same renderer, but we do save a lot of time and effort by sharing common code.
SDL has some nice handling for error conditions (segmentation faults, etc) that help to restore the machine to the state it was prior to crashing out. This would be an improvement over current Linux handling of certain error conditions (where the player can get stuck in some small resolution, and must log out and back in, or restart, to restore the proper resolution mode). Allegro is reportedly much easier to integrate into a game engine, and provides many nice features for game engine designers. In any case, some of the struggles Sonneveld had in porting out Allegro may teach us some lessons in abstraction which may help (even if, for some reason, his work cannot be continued). I have no loyalty to either library, but I will note that far more cross-platform commercial games are based on SDL than on Allegro. Perhaps there is a reason for that.
SDL isn't perfect there either. Had plenty of crashes involving SDL-using games that did not restore the prior resolution - if it ain't coded properly in the first place it isn't going to happen.
If we're going to consider SDL, then SFML - http://www.sfml-dev.org/ - should also be considered. In any case, the abstraction layer idea is a sound one.
I personally feel now, after months of thinking about it, that AGS should move on from Allegro 4. However, that doesn't mean move away from Allegro all together. But I am open to other libraries as well. The big thing for me is portability. Pretty much all these libraries support Mac, Windows and Linux. Great. But I also own/have owned portable devices such as the PSP and Android (No longer have the psp though as I sold it) and my brother has an IPhone and IPad. We do most of our gaming on these devices rather than on our pc's. So to me, its a big deal to have those ports. It seems as if, even though its possible to port, SDL and SFML do not have official ports to those systems. No biggie I Suppose. With extra hard work, it can be done. But it makes things challenging. Here are my observations:
Latest updates:
SDL was last updated in January 2012
SFML was last updated in April 2012
Allegro was last updated in January 2013.
Ports:
SDL will function officially with Windows/Win CE, MacOS, BSD, Linux, Solaris, Irix and QNX along with unofficial ports to OS that people generally do not use anymore.
Allegro officially supports Windows, Mac, Linux, IOS, Android. Older Versions support PSP, QNX, BeOS, etc... To me, you can probably easily port version 5 to those OS as well.
SFML officially supports Windows, Linux and Mac with a promise to support more in the future.
Ease of use:
SFML - Have not messed around with it, so I couldn't tell you.
Allegro - To me, as a sort of novice C++, Allegro is complicated to me.
SDL - Even to me, this is fairly easy to implement.
Convenience:
AGS already uses Allegro. So I would think that moving from 4 to 5 would be a somewhat smooth transition. On the other hand, since SDL is easier to understand, you would have also have more of the developers understanding how to use it and improve the engine. But again, I don't think it would be that much harder with Allegro being as the developers seem to be doing very well with it.
Mixing with other libraries:
Pretty much all of them support mixing with OpenGL or DX. However, my understanding is that Allegro is far more modular than SDL or SFML, allowing you to really integrate seemlessly with other libraries. So for instance, if you wanted to use OpenGL ES for portable versions of AGS, or if you wanted to include 3D capabilities with Ogre3D, Allegro can do that easily and without any mixed interference.
Community:
SDL seems to have diminished as a community and from what I hear, support from the development team is non-existent. I haven't really checked what its like with Allegro, but it might be the same, it might night. SFML Seems to be somewhat still active on the forums though.
Speed of updates:
In order for AGS to continue to have timely updates, it should stay with what is familiar. If AGS was to move on to SDL or SFML, it would probably require a whole new rewrite of much of the engine, thus probably taking a year or longer to achieve.
Here is a good overview of these libraries that can really tell us which is better for AGS: http://elysianshadows.com/phpBB3/viewtopic.php?f=6=6933#p80119
For me personally, I would move to Allegro 5. However, I am not a team member and I do not understand the source code all that much to begin with anyway. But from all the things I understand, Allegro 5 is the way to go. The other option would be to go the same direction of the AGS Scripting language and just have the team just create their own multimedia layer for AGS.
Well, I am doing a preliminary convert to Allegro 5 now. I think I forgot to mention this on forums... I told this to Janet Gilbert and JJS & BigMC via emails.
Quote from: Crimson Wizard on Sun 17/03/2013 18:39:45
Well, I am doing a preliminary convert to Allegro 5 now. I think I forgot to mention this on forums... I told this to Janet Gilbert and JJS & BigMC via emails.
You rock!
Quote from: Crimson Wizard on Sun 17/03/2013 18:39:45
Well, I am doing a preliminary convert to Allegro 5 now. I think I forgot to mention this on forums... I told this to Janet Gilbert and JJS & BigMC via emails.
Awesome!
Well, my point was not to "champion" a particular library at all. I'm no more advocating SDL than any other (nor was my statement "perhaps there is a reason" supposed to be read "we should use it because there must be a reason"). On the contrary, I was supporting CW's statement from earlier where he thought we should create an abstraction that helps unbind us from the underlying library. Of course this could be Allegro 5!
Quote from: Crimson Wizard on Sun 17/03/2013 18:39:45
Well, I am doing a preliminary convert to Allegro 5 now. I think I forgot to mention this on forums... I told this to Janet Gilbert and JJS & BigMC via emails.
Yes, I think I recall you mentioning it somewhere, but I forget exactly where.
I'm sure that others, like BigMC and I, may be able to help with some of this API work if we had a better concept of how you'd like it to turn out, like general or specific design goals. Otherwise we step on each other's toes, or waste each other's time (or worse, slow you down ;)).
Is this a one-person job, or are there specific areas we can help with?
Quote from: s_d on Sun 17/03/2013 20:42:36
Is this a one-person job, or are there specific areas we can help with?
Well, I have wrote graphic classes, and now trying to make the "Common" part of the source at least compile; then I will move to the "Engine" part.
I'd be very glad if someone could do the audio part, it's something I almost haven't invenstigated.
If you would have any suggestion on other parts and what I do, I will use them too ofcourse.
I am doing the work in a separate branch in my private repository, but since we will have to share the code, I guess, I'd better pull that to central repo.
I just need couple of days more to finish the changes I am doing right now.
I am trying to keep both versions of the engine (with A4 and A5) sharing same source, just using different precompile definitions and few distinct *.cpp.
Quote from: Crimson Wizard on Sun 17/03/2013 21:28:54
I'd be very glad if someone could do the audio part, it's something I almost haven't investigated.
If you would have any suggestion on other parts and what I do, I will use them too of course.
Yes, I suspected as much. That's good because the next thing I was going to look into the widely reported audio corruption issue on Linux, which seems to be related to a very common audio daemon (runs like a Windows service, and handles all audio I/O, including mixing). So I suppose this would be a good way for me to research both things.
Quote from: Crimson Wizard on Sun 17/03/2013 21:28:54
I am doing the work in a separate branch in my private repository, but since we will have to share the code, I guess, I'd better pull that to central repo.
I just need couple of days more to finish the changes I am doing right now.
Ok, although I would be fine working with you in a shared branch, like you guys did with refactory. Git is practically made for that sort of thing :)
Quote from: s_d on Mon 18/03/2013 00:53:42
Quote from: Crimson Wizard on Sun 17/03/2013 21:28:54
I am doing the work in a separate branch in my private repository, but since we will have to share the code, I guess, I'd better pull that to central repo.
I just need couple of days more to finish the changes I am doing right now.
Ok, although I would be fine working with you in a shared branch, like you guys did with refactory. Git is practically made for that sort of thing :)
But that's what I propose to do. Aren't we mean same thing?
Ah, OK. I read "pull to central repo" to mean that you'll send a pull request to master, and then merge your changes into it, having us all collaborate on master. You're meaning that you will pull to a new central repo for sharing work? Sorry to misunderstand!
Quote from: s_d on Mon 18/03/2013 01:49:15
Ah, OK. I read "pull to central repo" to mean that you'll send a pull request to master, and then merge your changes into it, having us all collaborate on master. You're meaning that you will pull to a new central repo for sharing work? Sorry to misunderstand!
No, I mean making a new branch in the central repository, like "develop_allegro5" or "feature_allegro5".
I don't want to merge any WIP to master now, when the beta release is being prepared.
Also, I learnt one may add contributors to personal repository. We may use that too.
Quote from: Crimson Wizard on Mon 18/03/2013 07:25:56
No, I mean making a new branch in the central repository, like "develop_allegro5" or "feature_allegro5".
...
Also, I learnt one may add contributors to personal repository. We may use that too.
Perfect, sounds great to me.
Alright, I know this may become annoying... but I want to honestly confess that I am in trouble here.
First, I was trying to make a lot of things at once, and could not finish single one, except for maybe releasing 3.3.0 beta, which still have irritating bugs.
At certain point I stopped working on Allegro 5 convertion, because I decided to clean up engine code more first, then I tried to work on removing some of the engine limits, which is now almost done, but so the A5 work became much delayed.
Second, I still couldn't get rid of doubts about Allegro 5 choice. 8-bit support in particular, and that really troubles me. I know some may say that it's not important, but AGS was made for people who want old-school look, and I know that there are still game developers who make 8-bit games, pretty popular ones, like Scavenger.
I must set priorities for myself to complete anything, and I really need a help of someone who knows the Allegro 5 and/or SDL libs well to help us make a good choice. I'd really wish if Scavenger, or anyone else with a knowlege in graphic programming, could check is it possible to effeciently emulate 8-bit graphics with palette on Allegro 5; because I honestly don't have time to do all this, and when I try to, my head nearly explodes :(.
I think that Wadjet Eye may be able to help here as we have got to the point where we are working with someone to port AGS to Mac. I've emailed you about it, Crimson Wizard!
What do people think about the possibility of changing the graphics library to SDL?
SDL is ok. However, I feel that SDL has been abandoned or at the very least, slowly upgraded. I know that SDL supports porting easily (Easier than Allegro anyway) to other OS. But Allegro is feature rich and powerful and it can be made to work with MacOS and other OS. It is supported after all, officially. With JJS and CW and everyone else working on this, I think we will see Mac support much sooner than we think. I think the trick is to actually try and upgrade AGS to Allegro 5. However, that may break a few ports such as the PSP port. But again, I am sure it can also be remedied.
A small update, after short discussion the porting guy chose a path of patching Allegro 4.4 libs to make them compatible with latest OSX versions (he is up to change a graphics API used for drawing on Mac). He sounds pretty optimistic, let's hope he will achieve what he wants :).
Is JJS doing that or are the Allegro people going to do that?
Quote from: Joseph DiPerla on Wed 05/06/2013 12:48:45
Is JJS doing that or are the Allegro people going to do that?
Wadjet Eye people do that.
Hey folks.
Forgive the thread necro. Has there been any progress on AGS for OS X 10.6+?
I ask this with high optimism because we're in the final release phase for our first commercial AGS game.
So, obviously broadening our audience is in our best interests. Porting to OS X will cover a significant market portion for us (approx. 47% consumer uptake) if our previous consumer base is anything to go by.
8-bit image loading for Allegro 5 is happening here:
https://www.allegro.cc/forums/thread/610190 (https://www.allegro.cc/forums/thread/610190)
I'm also quite interested in this. I know almost nothing about code portability, but I want to learn. It's been said here that Mac OS removed some things which Allegro 4 depended on, but later it seems that WEG had someone working on it who was quite optimistic that this could be resolved. What exactly changed, and what would need to be done to fix it?
Also, what remains to be done in the way of abstracting Allegro code from the main source?
I did not have any news for a long time now, we probably should ask Janet about this.
Last time I heard of them, the developer's idea was to upgrade Allegro 4 code to make it compatible with newer OSX.
Quote from: monkey_05_06 on Fri 01/11/2013 06:31:02
Also, what remains to be done in the way of abstracting Allegro code from the main source?
I remember palette & colors, and path operations, slightly different way to access bitmap data directly, also controllers (mouse, keyboard).
There is a research made by BigMC: http://www.adventuregamestudio.co.uk/forums/index.php?issue=355.0
Quote from: subspark on Fri 01/11/2013 03:11:50
8-bit image loading for Allegro 5 is happening here:
https://www.allegro.cc/forums/thread/610190 (https://www.allegro.cc/forums/thread/610190)
Yes, I saw that. If I understood that right, it is about converting 8-bit image on disk to some other format in memory (AFAIK Allegro5 uses OpenGL textures?). But what about palette manipulations, like color changing? The only information I found on this was one guy's suggestion to use shaders. I have no idea how difficult/effective that would be.
I suggest to very seriously consider the 8-bit aspect here, if we want to keep 8-bit compatibility (this was feature of AGS for years, and some people still use it in their projects).
I heard that SDL2 supports 8-bit natively. I am not an expert here, so I'd rather not make this decision (at least not alone).
UPDATE: I emailed Janet Gilbert, and what she sais basically is that the people still working on that, but this work is not their first priority, so... dunno what that means in time terms. I asked for a bit more information.
I'm very interested in this as well. The only thing preventing me from using AGS is not having an OSX engine that works on modern versions. Thanks for following up on it.
Quote from: Crimson Wizard on Fri 01/11/2013 07:28:01
The only information I found on this was one guy's suggestion to use shaders. I have no idea how difficult/effective that would be.
This is probably the most forward thinking - and the fastest solution. A shader based solution would be GPU accelerated and very fast. It would however be more initial work.
Quote from: Crimson Wizard on Fri 01/11/2013 07:28:01dunno what that means in time terms. I asked for a bit more information.
I'd assume "not going to happen" as those sort of projects get no time usually.
Question - would not the best start to be to just move all the Allegro 4 calls into an abstracted class/lib so that they are centralized for porting to 5 at a later date?
That would probably allow the community to help too.
Quote from: abritinthebay on Mon 02/12/2013 23:52:11
Quote from: Crimson Wizard on Fri 01/11/2013 07:28:01
The only information I found on this was one guy's suggestion to use shaders. I have no idea how difficult/effective that would be.
This is probably the most forward thinking - and the fastest solution. A shader based solution would be GPU accelerated and very fast. It would however be more initial work.
Well, I am concerned about palette cycling, which means that all the screen should have colors replaced. Does this mean applying same shader to every sprite, or some filter over final image?
Maybe someone can make a test program that shows how this can be done? I'd suggest we be sure that will work before starting this change.
Quote from: abritinthebay on Mon 02/12/2013 23:52:11
Question - would not the best start to be to just move all the Allegro 4 calls into an abstracted class/lib so that they are centralized for porting to 5 at a later date?
Well, certainly.
When I tried to do this, the biggest problem I met was color type: A4 uses integer (which meaning depends on color depth mode), but A5 uses a struct of four floats. This color type is referenced everywhere in the code, so you can't "hide" this easily.
But the internals of the engine is not the only thing; we should take plugin API into account too. Changing to different library means breaking plugin API, which means we should plan to write a new one. One thing pulls another here.
Hi, HumbleBundle ported the AGS engine to Mac so that we could have Gemini Rue on the Humble Bundle With Android (it's up now! So exciting!)
This means we now have a working port to Mac, and it's still Open Source, of course!
Where do you guys want it put?
Quote from: JanetC on Fri 20/12/2013 00:15:20
Hi, HumbleBundle ported the AGS engine to Mac so that we could have Gemini Rue on the Humble Bundle With Android (it's up now! So exciting!)
This means we now have a working port to Mac, and it's still Open Source, of course!
Where do you guys want it put?
Haha, great to hear! I was suspecting something about this since I've seen your news mail. I am sure alot of people will be happy :D.
Regarding this new port, we would need to see the code to compare changes and learn what needs to be done to make a merge. Is the code still originate from ags repository you have? In this case you could probably submit it as a separate branch to your personal repository on github.
Quote from: Crimson Wizard on Fri 20/12/2013 00:39:30
Quote from: JanetC on Fri 20/12/2013 00:15:20
Hi, HumbleBundle ported the AGS engine to Mac so that we could have Gemini Rue on the Humble Bundle With Android (it's up now! So exciting!)
This means we now have a working port to Mac, and it's still Open Source, of course!
Where do you guys want it put?
Regarding this new port, we would need to see the code to compare changes and learn what needs to be done to make a merge. Is the code still originate from ags repository you have? In this case you could probably submit it as a separate branch to your personal repository on github.
It is not related to my AGS repository, which is heavily mucked about with to make mobile games. It is derived from the main AGS port at:
https://github.com/adventuregamestudio/ags
Is there a way that the porting engineer (Edward) could push his changes back there to a separate branch? I assume we want to use his changes if we can, to make the port native Mac compatible from now onward. I'm not an expert on Git. Is this a good idea? Would he need permissions to do this?
The port also contains fixes to Linux which were made for the commercial release of Gemini Rue on that platform.
Quote from: JanetC on Fri 20/12/2013 14:50:45
It is not related to my AGS repository, which is heavily mucked about with to make mobile games. It is derived from the main AGS port at:
https://github.com/adventuregamestudio/ags
Is there a way that the porting engineer (Edward) could push his changes back there to a separate branch? I assume we want to use his changes if we can, to make the port native Mac compatible from now onward. I'm not an expert on Git. Is this a good idea? Would he need permissions to do this?
Oh, I see.
He should not push his changes directly in our main branch, because we need to check the code difference first to make sure that merging won't break our own version of the code.
Sharing code between repositories on GitHub is done using "pull requests". This is when a person has his own repository and he creates a request to merge one of his branches into one of the other people's branches (not necessarily matching ones).
If Edward used git to maintain changes history all the way, then it should not be a problem for him to create his personal GitHub repository, put the changes there, then make a pull request from his to ours.
I don't know how much has changed, maybe we will need to keep the code in a separate branch at first. We are preparing a 3.3.0 release now, and it will be not good to mess the code up. On other hand, if the changes are mostly in Mac-specific code (not the engine core), then things will be simplier.
In the worst case, if he did not maintain changes history but just has the code as-is, the steps may be:
1. Clone our ags repository to create his personal one.
2. Create a new branch (like "mac-port", etc), forking from the point at which he started his work back then.
3. Copy his new code over and make a one big commit.
Then, continue with pull request as usual.
Wow, Christmas came early this year! Thanks Wadjet Eyes for bribing the nice folks at humblebundle into doing this ;) ;-D
Quote from: Crimson Wizard on Fri 20/12/2013 16:43:19
3. Copy his new code over and make a one big commit.
Then, continue with pull request as usual.
Even if there's no history it can be useful to commit the changes in multiple steps, which may be doable to some extend if unrelated changes are in different files. But let's hope history exists.
Already purchased Gemini Rue a second time for Android(Always try to do my the best I can to support AGS'ers that create commercial games) and gave Gemini Rue 5 star rating and review. More than any of the code that is available, I would love to see the full Android port seeing as you got past the Obb issues and even some user interface hickups. Great Job!
Quote from: BigMc on Fri 20/12/2013 20:32:48
Quote from: Crimson Wizard on Fri 20/12/2013 16:43:19
3. Copy his new code over and make a one big commit.
Then, continue with pull request as usual.
Even if there's no history it can be useful to commit the changes in multiple steps, which may be doable to some extend if unrelated changes are in different files.
Aye, that's true. In fact one can split changes in one file into separate commits: http://stackoverflow.com/questions/1085162/how-can-i-commit-only-part-of-a-file-in-git (does not work 100% time though).
This all depends on whether the author is going to bother doing this ;).
Good guy HumbleBundle. Now I've found another reason to love it. ;-D
Edward just made a pull request so we could finally see the code.
https://github.com/adventuregamestudio/ags/pull/109
It is not 100% compatible with current engine, there are few differences and at least one feature duplication, but I am sure we will sort everything out in time and merge it.
This is really a git question, I suppose, but is it possible to get the repository exactly as Edward left it so I can compile Wadjet Eye's other games for Mac and Linux? I have my own fork of the repository which is not really compatible with anyone elses (for iOS) and I don't want to overwrite or merge it.
Quote from: JanetC on Sun 29/12/2013 15:56:19
This is really a git question, I suppose, but is it possible to get the repository exactly as Edward left it so I can compile Wadjet Eye's other games for Mac and Linux? I have my own fork of the repository which is not really compatible with anyone elses (for iOS) and I don't want to overwrite or merge it.
First (and fastest) you can just clone Edwards repository (https://github.com/humble/ags-geminirue.git).
If you want to have that as another branch in your current repository, go to your "master" branch, find commit (f021439669696b3f94d194e2317108b56059ff4a), fork new branch from exactly that commit and then ask Edward to make a pull request on top of that branch. This will guarantee that you'll have exactly the code that Edward has.
There's an alternative way to do this without asking Edward and arranging pull request. Unfortunately I do not know how to do this in git generally, I always used "GitExtensions" UI program for this (but I may find out).
Idea is to add another one remote source for the local repository on your computer. You will need to "register" Edward's repository as a known code source, this will let you to "see" his branches. Then you just merge his "humble" branch into your "master", or another new branch, if you like to keep that separate.
I will probably be able to give more explanations, but only after you clarify how do you work with git: do you work with git's command line (git bash), or use any program with GUI? or else?
If you want to add someone elses branch to your repository asking him for a pull request is a very complicated way of doing it. In your repo add his repository as remote (git remote add), check out the branch and push it to your remote repoostory. That's it.
Yes, right. Something like this, I recon:
(Go to your local repository folder and type those commands to command line; alternatively run git bash in that folder)
1) this registers Edward's repo at your local repo:
git remote add humble-geminirue https://github.com/humble/ags-geminirue.git
2) this adds information about Edward's branches current state to your local repo:
git remote update humble-geminirue
3) this copies his remote branch into yours local one (new branch named "humble-ports" will be created):
git checkout -b humble-ports humble-geminirue/humble
Now you have a local branch, which is a copy of Edward's, in your local repository and can push to your remote repository, or do what you like.
Depending on whichever git UI application you are using (if you do) those steps can be performed by using menus, but without knowing which program do you use, I can't tell more.
Thanks guys. I'll do this as soon as my baby takes a good, solid nap tomorrow!
I use a simple GUI but it can't do anything complicated, so I use the command line for most things more complicated than committing or branching.
Well, my baby is at her grandmothers for the day so I finally got a chance to try this! But it didn't work :(
It seemed to work, but when I try to use Github for Mac to commit changes, it commits them and then doesn't remove the commit from the list of unsynced commits. When I try to commit again, it gives me this error message:
! [rejected] humble-ports -> humble-ports (non-fast-forward)
error: failed to push some refs to 'git@github.com:JanetGilbert/ags.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.
If I instead try using the terminal, I get a different error after using git push:
error: The requested URL returned error: 403 while accessing https://github.com/humble/ags-geminirue.git/info/refs
fatal: HTTP request failed
(the password and user name I supplied to git push were correct)
What could I be doing wrong?
Thanks,
Janet
Quote from: JanetC on Tue 07/01/2014 20:58:34
! [rejected] humble-ports -> humble-ports (non-fast-forward)
error: failed to push some refs to 'git@github.com:JanetGilbert/ags.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.
Error like this indicates that there were changes to remote that are not found in your local branch. Don't know how it happened to be. Maybe you have two local repositories, or something like that?
On usual occasion this is solved by making a "git pull" before doing anything else.
Quote from: JanetC on Tue 07/01/2014 20:58:34
If I instead try using the terminal, I get a different error after using git push:
error: The requested URL returned error: 403 while accessing https://github.com/humble/ags-geminirue.git/info/refs
fatal: HTTP request failed
Which address do you use in git command? It should be just "https://github.com/humble/ags-geminirue.git" instead.
Quote from: Crimson Wizard on Tue 07/01/2014 23:44:54
Quote from: JanetC on Tue 07/01/2014 20:58:34
! [rejected] humble-ports -> humble-ports (non-fast-forward)
error: failed to push some refs to 'git@github.com:JanetGilbert/ags.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.
Error like this indicates that there were changes to remote that are not found in your local branch. Don't know how it happened to be. Maybe you have two local repositories, or something like that?
On usual occasion this is solved by making a "git pull" before doing anything else.
No, no local changes. "git pull" responds that there are no changes.
Quote from: Crimson Wizard on Tue 07/01/2014 23:44:54
Quote from: JanetC on Tue 07/01/2014 20:58:34
If I instead try using the terminal, I get a different error after using git push:
error: The requested URL returned error: 403 while accessing https://github.com/humble/ags-geminirue.git/info/refs
fatal: HTTP request failed
Which address do you use in git command? It should be just "https://github.com/humble/ags-geminirue.git" instead.
I did exactly what you suggested in your post above. I don't know where the "info/refs" came from.
Quote from: JanetC on Tue 07/01/2014 20:58:34
If I instead try using the terminal, I get a different error after using git push:
error: The requested URL returned error: 403 while accessing https://github.com/humble/ags-geminirue.git/info/refs
fatal: HTTP request failed
I suddenly realized you said
push. This probably means you are trying to push your branch to Edward's repository instead of your own...
EDIT: actually nevermind this, see updated section below.
Spoiler
The command should be (assuming you used same names as in my example few posts above)
git push origin humble-ports
Just tested this on my own repository.
:
Ok, I found what was also wrong in previous commands. We should set proper connection between local branch and remote branch, so that your local is connected with your remote, and not with Edward's remote.
Anytime after you created a local branch, you can change the connection with:
git branch --set-upstream humble-ports origin/humble-ports
This will make your local branch connect exactly to the appropriate branch in your remote repository (and not to Edward's). Also you will not have to use extra options with "push" (e.g. after this you can use just "git push").
There might be a way to do this using your gui application (probably somewhere in the repository settings).
Thanks, CrimsonWizard! That worked.
I think we may combine few problems together into a larger "patch Allegro" one. There are number of patches that may be beneficial for AGS, including OSX support and resizing window. I think the solution could be to clone official Allegro repository, make a new branch and apply patches there. If this will be done, we may then refer version builders to this branch instead of official Allegro repository (for windows version we may remove precompiled libraries from repository and use this branch too).
Maybe there's someone who would like to try this out?
I think I will take a whack at this after I finish the build/packaging VM for Linux builds. Maybe I'll have better luck than refactoring the audio API :X
One group I'm working with (which has, indeed, consumed nearly all of my time for engine fiddling) is going to need a Mac port pretty soon. I'll be going with the Humble branch for their release, but it will be so good to have that stuff in the main branch someday.
Humble Bundle is going a strange way, for OSX & Linux (I think) they are putting parts of SDL2 under Allegro 4 to serve as a hidden backend.
Although I understand that Wadjet Eye needs a working result any way, I don't like where this is going. I don't think their work will help AGS much :(.
I thought SDL2 is just used for audio there and their port of Allegro 4 to OS X would still be useful?
Quote from: BigMc on Tue 18/03/2014 19:04:55
I thought SDL2 is just used for audio there and their port of Allegro 4 to OS X would still be useful?
No, I just mean that their
latest additions does not give us much benefit. I am speaking of the changes made last week to Janet's repository. I see Edward is making more SDL2 "injections" in allegro.
I wish these were changes to AGS code instead, but oh well. :tongue:
Sorry if I ask, especially if it's been already discussed.
Is possible to compile our games for Mac Osx? I mean for playing only, not editing. Thanks
Sorry, wrong, post deleted.
Is any news for MAC port? Is it in WIP ?
Quote from: Mehrdad on Mon 05/10/2015 06:39:11
Is any news for MAC port? Is it in WIP ?
It's on my list to at least get an automated build going soon of what's there. There's been a few port efforts that I probably need to look through.
Any there any ports that I don't know of?
- My SDL port - https://github.com/sonneveld/ags/tree/sdlwrap (there was an osx build)
- Humble Bundle port - https://github.com/humble/ags-geminirue/tree/humble-release-3.3.0 (old pull request here: https://github.com/adventuregamestudio/ags/pull/109 )
- Janet's ios work https://github.com/JanetGilbert/ags/tree/ios (some might be osx relevant) (some changesets here: https://github.com/adventuregamestudio/ags/issues/278 )
Our engine should build for Mac, unless something was broken, but it is only compatible with older versions:
Quote from: BigMc on Tue 11/12/2012 20:39:33
It works up to Mac OS X 10.6 and Allegro 4.4 was released before Mac OS X 10.7, so that information is probably outdated.
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.
Quote from: Crimson Wizard on Mon 05/10/2015 09:27:33
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.
First step is to have the automation server produce osx builds :) Sooon!
CW and sonneveld
Thank you for pointing that out.I'm waiting for your great news.
What bugs do we currently have on Wadjet Eye's Mac games and installers? I'm making a list for fixing. Have they been fixed in the latest version of the official engine?
I see there's some recent activity regarding this. I came back to the forums after a very long hiatus, and my issue is that I no longer own a Windows machine, so I'm very interested in the status of this.
What's the long and short of it? Is there a version of the editor that I can use on Yosemite currently?
Quote from: Nine Toes on Mon 28/12/2015 00:25:01
What's the long and short of it? Is there a version of the editor that I can use on Yosemite currently?
This particular thread never touched
Editor; it is dedicated to porting AGS
engine to OSX (as stated in the title).
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.
Editor status: there were
talks about moving to Mono (as Editor is a C# program), but number of Editor parts still have dependencies on Windows runtime libraries, and it is unknown if anyone works on this.
I also heard that you may run Editor on Mac using some wrapper, but I am not a Mac person, so cannot help you here.
Ack. My mistake. But I'll look into the wrapper thing. Thanks for trying to help anyhow.
Quote from: Crimson Wizard on Mon 28/12/2015 01:17:07
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)
Quote from: Monsieur OUXX on Mon 04/01/2016 10:37:53
(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 :tongue:.
Our repository currently supports iOS, but only for jailbroken devices.
Isn't any news for Mac OS port? Is it in progress or not? Mac OS is more important of Linux I think so.
Quote from: Mehrdad on Thu 28/01/2016 08:27:55
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.
Thanks CW
So Does Janet Gilbert will put here or github source or method of this port ?
Quote from: Mehrdad on Thu 28/01/2016 14:52:55
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.
I contacted Janet about her/their OS X port last june and she directed me here (https://github.com/JanetGilbert/ags/tree/humble-ports). 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.
Quote from: Crimson Wizard on Thu 28/01/2016 15:43:14
Quote from: Mehrdad on Thu 28/01/2016 14:52:55
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 :)
Quote from: JanetC on Mon 01/02/2016 15:52:08
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 (https://opensource.org/licenses/Artistic-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").
QuoteBesides, we don't want to :)
:)
Quote from: StillInThe90s on Thu 28/01/2016 16:21:44
I contacted Janet about her/their OS X port last june and she directed me here (https://github.com/JanetGilbert/ags/tree/humble-ports). 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!
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.
Quote from: Edmundito on Thu 10/03/2016 08:48:42
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).
Quote from: Edmundito on Thu 10/03/2016 08:48:42
- 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.
Quote from: Edmundito on Thu 10/03/2016 08:48:42
- 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().
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
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:
Quote from: Crimson Wizard on Mon 05/10/2015 09:27:33
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.
Quote from: Crimson Wizard on Sat 12/03/2016 15:36:24
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:
Quote from: Crimson Wizard on Mon 05/10/2015 09:27:33
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.
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 :)
Quote from: JanetC on Fri 03/06/2016 18:00:59
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.
Quote from: Mehrdad on Thu 28/01/2016 08:27:55
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.
Quote from: sonneveld on Thu 09/06/2016 02:39:22
Quote from: JanetC on Fri 03/06/2016 18:00:59
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
I'm interested in checking this out, but before delving in the complexities of OSX development I'd really like to see an AGS executable at work.
I've found that the Engine OSX branch on the AGS Team City successfully compiles but produces no artifacts. I'm not sure why that is, perhaps someone could enable it?
Conversely the code in Janet's repo is somewhat newer but doesn't include a build.
Can someone give me a hand please? I think I could probably set up a team city account, include a fork of Janet's repo, and have it automatically build that; but somebody else has probably already done that? TIA!
Quote from: Radiant on Mon 06/02/2017 19:50:54
I'm interested in checking this out, but before delving in the complexities of OSX development I'd really like to see an AGS executable at work.
I've found that the Engine OSX branch on the AGS Team City successfully compiles but produces no artifacts. I'm not sure why that is, perhaps someone could enable it?
Conversely the code in Janet's repo is somewhat newer but doesn't include a build.
I suggest contacting Janet or Nick Sonneveld (http://www.adventuregamestudio.co.uk/forums/index.php?action=profile;u=13138) directly, they do not seem to come on forums very often, but they are probably only people that may shed some light on this.
BTW, from what I noticed, Janet's version may be compatible only to AGS 3.3.5.
All right, I can do that.
But can you tell me why artifacts are disabled for OSX on Teamcity? That would be an easy place to get a sample executable, otherwise.
Quote from: Radiant on Mon 06/02/2017 20:13:16
But can you tell me why artifacts are disabled for OSX on Teamcity? That would be an easy place to get a sample executable, otherwise.
Um... no idea. Also it was built 3 months ago last time, which makes me think that it was excluded from work at some point.
I have a suspicion that it does not produce a working universal engine, but you have to build an application for every your game separately.
Could we switch it on and try?
Quote from: Radiant on Mon 06/02/2017 20:41:33
Could we switch it on and try?
It was scheduled to run on machine that is no longer available. That could be one the Nick Sonneveld's private computer, or some server he owned.
Anyone who wants to build for Mac, check out the port Nick Sonneveld did for Wadjet Eye!
JanetGilbert/ags
Branch: osx-nick
Quote from: JanetC on Wed 08/02/2017 18:08:34
Anyone who wants to build for Mac, check out the port Nick Sonneveld did for Wadjet Eye!
Thank you, I have found the git branch but I'm wondering if a compiled executable is on the web somewhere.
Quote from: Radiant on Wed 08/02/2017 21:56:56
Quote from: JanetC on Wed 08/02/2017 18:08:34
Anyone who wants to build for Mac, check out the port Nick Sonneveld did for Wadjet Eye!
Thank you, I have found the git branch but I'm wondering if a compiled executable is on the web somewhere.
No, you have to compile it yourself! Sorry!
Hi
Isn't any manual step by step for compile to Mac OS ? I haven't knowledge for use from Github .
Much appreciate for any help
Quote from: Mehrdad on Thu 09/03/2017 15:15:16
Hi
Isn't any manual step by step for compile to Mac OS ? I haven't knowledge for use from Github .
Much appreciate for any help
It works in much the same way as the iOS version, described here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=52219.0
(That is a little outdated now but it should provide a starting point.)
Note that Nick changed the way that projects work so now you add a new scheme to the existing project, rather than copying and renaming a project.
Thanks a lot Janet . I'll try it and get helps by my friends and this topic if was any serious question .
Hello, I'm trying to make a build with the Mac port again and I forgot all the steps. I ran into an issue with patching allegro:
cd OSX/buildlibs
make
I get the error:
"patch: **** malformed patch at line 1874: diff --git a/src/ios/idrivers.c b/src/ios/idrivers.c"
When I look in OSX/buildlibs/build/allegro-4.4.2/src, there is no "ios" directory. I also looked at the allegro source and the tag "4.4.2" and there was no "ios" directory.
I see a comment from Nick in the Makefile:
"# - to update patch: git diff 4.4.2..osx-update > ../ags/OSX/patches/allegro-4.4.2.patch"
Is there a step I am missing?
Edmundito,
Did you have any luck building a Mac port? Which version of Xcode are you using?
I'm running 9.1 and it's complaining about a lot of missing frameworks (CoreVideo, Cocoa, etc) from the osx-nick branch. Could use some help getting this off the ground.
Thanks!
I was able to make a build with 3.4.1 but it was not easy and not perfect. It seems that the game runs for now, we are testing to see where it breaks.
I've detail the current instructions here, you will need to be familiar with Xcode, Make, etc. Please follow them step by step:
https://gist.github.com/edmundito/4cc578f6eee51db7d20882cfa222b015
In summary:
- The OSX project is outdated with ags 3.4.1 but may work with ~3.4.0.13
- Some hacking needs to be done to make it work
- Allegro needs to be repatched properly to support ags 3.4.1
I recommend trying with v.3.4.0.13 or a later master hash 911fa50e7d19ea03629523bac952af5dc1b18453, I had luck making a build with around the part of the code last year. If you can get it to work then I would try v.3.4.0.16 which is the latest tag.
Thanks so much for the build instructions - I'm going to try these out today and see how far I get. The Xcode branch has always been extremely fragile and difficult to patch/build plugins for - I'll let you know what my results are.
Update: Ah, I had forgotten to 'make install' the buildlib folder. Again, I'm using the osx-nick branch, so 99% of the work was already done for me.
Ok, I'm giving this a spin now, following Edmundito's instructions.
The step "make the libraries" fails. If I then do a checkout to v.3.4.0.13 and make again, it again fails. The error I'm getting is 'QuickTime/QuickTime.h' file not found.
Any advice on how to proceed from here please?
(edit) wait, I thought this was El Capitan but it turns out to be High Sierra. SDK 10.11 did the trick. The make process throws a lot of warnings but nothing stands out as problematic.
(edit edit) nope. I cheeck out to master again; replace the file.c file; remove the patch line from the Makefile and make again. This doesn't work. The two errors are cannot find interface declaration for NSQuickDrawView, superclass of llegroView; and unknown type name CGDirectPaletteRef. Maybe I should just try building 3.4.0 instead of the latest AGS version?
(edit edit edit) ignoring the above error, I open Xcode. First I get two errors to "change to recommended settings", which I allow. Now I get eight 'multiple build commands' warnings which don't seem important, and an allegro.h file not found (in draw.h)...
Ok, it seems the AGSKit project cannot find the library files, and the ags project cannot find the header files. Adding these to the search paths in the respective xcode targets seem to help, but perhaps there's a better way than doing this manually?
I'm now getting a file not found on alplatf.h; looking through the folder there's an alplatf.h.cmake file which appears to be a proper C header; I'm not sure where the .cmake part comes from, maybe allegro didn't properly build?
Quote from: Radiant on Tue 26/12/2017 13:56:03
I'm now getting a file not found on alplatf.h; looking through the folder there's an alplatf.h.cmake file which appears to be a proper C header; I'm not sure where the .cmake part comes from, maybe allegro didn't properly build?
Don't know anything about OSX build, but I know that alplatf.h is supposed to be generated if you run cmake script.
Yes, most .h files appear to be generated but not this one...
(edit) I basically conclude that the trick with getting file.c from sourceforge causes Allegro to not build. If I skip this step, then Allegro does build, but it appears to not cmake the proper header files. I'm not sure how to proceed from here.
@Radiant: I'm away from my workstation right now, but have you tried to build Janet's 'osx-nick' branch? It built fine for me on Sierra with the latest Xcode. The trick for me was building the libraries using Terminal properly. If you can get it to build, it might help narrow down your header/search path issues.
I was using the main AGS branch so far, I'll give Janet's branch a shot. What do you mean by "using Terminal properly"?
Gah, sorry. Back at my workstation now.
To clarify, I meant that I needed to build the libraries properly in the /buildlibs folder, and I had to do it from within the Terminal.
In the osx-nick branch, the /ags/OSX/buildlibs folder has a README.md file that details how to build the libraries from scratch:
1. install homebrew
2. brew install pkg-config autoconf automake libtool cmake curl
3. install xcode *and* the command line tools
4. sudo xcode-select --reset
5. build the libraries with: make install
I initially missed those steps the first time I checked out the osx-nick branch and could not build.. hence why I meant 'using Terminal properly' ;)
Quick update: I have AGS 3.4.1.11 working successfully. I had to modify a few of Edmundo's steps to get it working on my machine. There are many issues with getting it working, thankfully there are workarounds.
Ok, I'm trying this out now. But neither the AGS repo nor Janet's has a branch named osx-nick...
Quote from: Radiant on Sun 28/01/2018 21:38:39
Ok, I'm trying this out now. But neither the AGS repo nor Janet's has a branch named osx-nick...
https://github.com/JanetGilbert/ags/tree/osx-nick
Thanks. Looks like I missed the 'next page' button on the GitHub site :)
Ok, so far so good. Brew install etc etc reported nothing new was required. Xcode reset gave no response, which I take to mean 'no errors' Linux-style. Now running make install.
(edit) Ok, that generated a bunch of warnings but appears to work. Thanks for the tip. Now let's see about Xcode...
(edit) Success! Ok, I had to google some odd stuff like 'how to switch xcode to release mode' and 'where on earth does Xcode place my executable' but it seems to work fine :)
Great, thanks everyone for your help.
I have a few questions though. If a game has a (filename).001 file with extra rooms and such, can I just add this to the ags/Resources folder within Xcode? What about .TRA translation files? The OSX version doesn't appear to have acsetup so how do I set a translation? Finally, does this support the AGSteam plugin and if so, how? Currently running an AGSteam game aborts with an unresolved import.
Hey Radiant! Did things eventually worked out for you?
We've got a Discord group that's working on it. I'll have to test the current build this weekend.
Did you had to fork and do new stuff to get it working? Are your modifications public? I am.going to start messing with OSX build soon. Can it run plug-ins? I was interested into trying to add joystick support.
So far I'm running off a clone, not a fork. I haven't figured out how to use plugins yet. It would be easiest if you PM Edmundito and ask him to add you to the Discord channel, we're discussing it there. HTH!
Heads up: Apple is deprecating OpenGL for macos: https://developer.apple.com/macos/whats-new/ :~(
Seems as the 2 possible options for supporting mac long term are either metal or vulcan using moltenvk (https://arstechnica.com/gadgets/2018/02/vulkan-is-coming-to-macos-ios-but-no-thanks-to-apple/) (and of course supporting vulkan should give performance benefits on all platforms whereas metal is apple platforms only).
Quote from: tzachs on Tue 05/06/2018 16:12:45
Seems as the 2 possible options for supporting mac long term are either metal or vulcan using moltenvk (https://arstechnica.com/gadgets/2018/02/vulkan-is-coming-to-macos-ios-but-no-thanks-to-apple/) (and of course supporting vulcan should give performance benefits on all platforms whereas metal is apple platforms only).
Hopefully we won't have to do that ourselves; when we switch to SDL we just use whatever it supports.
Ah, right, forgot about the SDL effort, yeah, they seem to have vulkan support for mac: https://discourse.libsdl.org/t/sdl-2-0-8-released/23957
It's still a bit of a mess, but I got a working build of a game project (not a real game) running on OS X High Sierra with Steam achievements.
I cloned Janet's osx-nick branch and reused the WEG Xcode workspace files (and the Shivah project files). I tried to figure out how to embed a binary version of AGSteam into the app, but I kept getting an error that the library didn't exist in the final executable. So instead I followed the approach that was already partially implemented by WEG (judging by the project files and the lack of an existing port of AGSteam to Mac), and built the AGSteam source directly as part of the project files. Took a bit of knackering about as I've never used Xcode (or even OS X) before, but it definitely is working.
I will try to make a more detailed post of what I did after I try to abstract it out of the WEG files. ;)
That's great news, Monkey! Thank you for doing that!
Hi guys i was able to start my game on ios with janet branch on 3.3.3, any news about 3.4 or 3.4.1, it was a mess to downgrade my game.
edit: i know that the post is for mac but i read some interesting things.
Hey, if anyone out there is interested, I'd really love to port our games (Quest for Infamy, Order of the Thorne and our upcoming QFI:Roehm to Ruin) to Mac. Get in touch with me if you're interested. I could use the help with this kind of thing.
Bt
It doesn't look like the libraries build now:
Spoiler
Quote from: make install
~/Build/ags-osx-nick/OSX/buildlibs/build/allegro-4.4.2/build ~/Build/ags-osx-nick/OSX/buildlibs/build/allegro-4.4.2
- The C compiler identification is AppleClang 10.0.0.10001145
- The CXX compiler identification is unknown
- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang - broken
CMake Error at /opt/pkg/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/mwillcock/Build/ags-osx-nick/OSX/buildlibs/build/allegro-4.4.2/build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/xcodebuild" "-project" "CMAKE_TRY_COMPILE.xcodeproj" "build" "-target" "cmTC_c3c50" "-configuration" "Debug"
Prepare build
note: Using legacy build system
=== BUILD TARGET cmTC_c3c50 OF PROJECT CMAKE_TRY_COMPILE WITH CONFIGURATION Debug ===
Check dependencies
error: The i386 architecture is deprecated. You should update your ARCHS build setting to remove the i386 architecture.
** BUILD FAILED **
The following build commands failed:
Check dependencies
(1 failure)
CMake will not be able to correctly generate this project.
Presumably the cmake config for Allegro needs to be updated, but this branch is downloading libraries from AWS?
Just to confirm - today I successfully compiled the buildlibs from the latest osx-nick branch without problems. Are you running Xcode 10? I suspect it's a clang10 issue.
I'm running 10.13.5 and compiling with clang9 on Xcode 9.3 without problems.
I did build them by switching from Xcode 10 to 9, and was looking at updating everything for Xcode 10. I think to make it work the minimum OS version needs to be raised to 10.9 though, as well as removing the 32 bit builds. I don't know what Apple developers normally do to keep the greatest level of compatibility, maybe 10.9 is the new baseline for everything.
Yeah I know that the 32/64 bit issue for the buildlibs was going to become a problem at some point. Looks like Xcode10 is the first to enforce 64-bit only. Glad you got it figured out.
Quote from: monkey0506 on Thu 07/06/2018 01:59:42
It's still a bit of a mess, but I got a working build of a game project (not a real game) running on OS X High Sierra with Steam achievements.
I cloned Janet's osx-nick branch and reused the WEG Xcode workspace files (and the Shivah project files). I tried to figure out how to embed a binary version of AGSteam into the app, but I kept getting an error that the library didn't exist in the final executable. So instead I followed the approach that was already partially implemented by WEG (judging by the project files and the lack of an existing port of AGSteam to Mac), and built the AGSteam source directly as part of the project files. Took a bit of knackering about as I've never used Xcode (or even OS X) before, but it definitely is working.
I will try to make a more detailed post of what I did after I try to abstract it out of the WEG files. ;)
Just want to pass along word that I figured out how to build AGSteam as a dynamic library in Xcode, and link it to my AGS project... just as monkey0506 did. I'll be posting instructions here soon, for anyone interested.
Hey everybody!
I just managed to build AGS 3.4.4 on macOS 10.14.5 and wanted to let you know how:
- Download AGS 3.4.4 sources (https://github.com/adventuregamestudio/ags/archive/release-3.4.4.zip) and unzip them:
curl -sL -o release-3.4.4.zip https://github.com/adventuregamestudio/ags/archive/release-3.4.4.zip && unzip release-3.4.4.zip- In the directory OSX/patches, overwrite the file allegro-4.4.2.patch with the corrected version in master (https://raw.githubusercontent.com/adventuregamestudio/ags/master/OSX/patches/allegro-4.4.2.patch):
cd ags-release-3.4.4/OSX/patches && curl -sL -o allegro-4.4.2.patch https://raw.githubusercontent.com/adventuregamestudio/ags/master/OSX/patches/allegro-4.4.2.patch && cd -- In the directory OSX/buildlibs, remove the i386 architecture from the Makefile and replace the target 10.7 with 10.14:
cd ags-release-3.4.4/OSX/buildlibs && sed -i -e "s/10\.7/10.14/g;s/-arch i386 //g;s/;i386//g" Makefile && cd -- Run make install in that directory and go get yourself a coffee in a blue cup. ;)
cd ags-release-3.4.4/OSX/buildlibs && make install && cd -- Copy your game files (eventually replace the built .exe file with acgame.dat) to OSX/xcode/ags/game_files:
mkdir ags-release-3.4.4/OSX/xcode/ags/game_files
cp /ac2game.dat /acsetup.cfg /audio.vox /speech.vox ags-release-3.4.4/OSX/xcode/ags/game_files- Open the Xcode workspace (accept the warning about the workspace coming from the internet):
cd ags-release-3.4.4/OSX/xcode && open ags.xcworkspace
- Add missing files into the workspace by right clicking on the corresponding subfolder in the AGSKit target, AGSKit group:
- the complete folder Plugins/agspalrender
- in the folder Common/debug the files debugmanager.cpp and debugmanager.h
- in the folder Engine/Debug the files messagebuffer.cpp and messagebuffer.h
- Remove the file debug.cpp in the AGSKit target, AKSKit/Common/debug group
- Select the AGSKit target and in the settings the tab "Build Phases". From the "Copy Bundle Ressources" phase there, remove files named like COPYING.txt, Makefile.in, README.txt, vssver2.scc, README, AUTHORS.txt, Makefile.am, CHANGES.txt and MAKEFILE.AM by selecting them and hitting the "-" button below the list
- With the Build phases tab still open, navigate to the agspalrender-plugin group in the left panel and drag and drop ags_palrender.cpp and raycast.cpp to the list in the "Compile Sources" phase and agspalrender.h, palrender.h and raycast.h to the list in the "Headers" phase. (In the dialog, that pops up, just click Finish)
- Run the Game in XCode
- Have fun playing
(tested with the awesome Metaphobia (https://www.adventuregamestudio.co.uk/forums/index.php?topic=57264.0))
You can also download a pre-compiled version without a game here. (https://drive.google.com/file/d/1DrnbmHUKiR1WQLbjdCpXAkR4aH0iJRnO/view?usp=sharing) Check out the README.md file on how to put your game into it.
As 3.4.4 is already released I think, I won't open a PR for the neccesary changes (any head developer might tell me otherwise). However, I'll check out the current master branch and try to fix the OSX build there and send a PR. And after that, I'll try to fix the ios-branch.
Kind regards
Dennis
Quote from: Dennis Plöger on Sat 20/07/2019 16:16:54
As 3.4.4 is already released I think, I won't open a PR for the neccesary changes (any head developer might tell me otherwise). However, I'll check out the current master branch and try to fix the OSX build there and send a PR. And after that, I'll try to fix the ios-branch.
It's perfectly valid to update 3.4.4 branch, we may release an update.
Please don't use "master" branch for now, we were currently developing in "ags3", and there's also "release-3.5.0" branch for current beta release.
master branch in turn contains an experimental change to the engine which became controversial and it's still under question (while people are discussing future plans and goals).
Thanks. Will do.
This is a extremely dumb question, but I can't get my head around it.
1. Change compile targets to Windows (and DataFile)
2. Compile the MacOS engine on a Mac
3. Take datafile...to Mac??
4. ???
5. Your game runs in MacOS
Could someone explain 3+4 to me? If there is no editor for Mac, and there is no compile target, how is the game running on Mac?
AGS Editor compiles to an intermediary "AGS Bytecode" (I don't know the actual name) and you can think on the AGS Engine as a "virtual machine" (like Java Virtual Machine or a videogame emulator) that reads the bytecode and makes it work in the machine it's being ran. You only need the Engine running in other hardware and system, once you get that, you can run the "AGS Bytecode" (again, don't know the actual name for it).
I see, thanks :)
I'm hoping to do a MacOS port of my game, which is unfortunately designed in 3.5.0 in Windows.
Is MacOS a fairly up-to-date channel? Is it likely that 3.5.0 might be released for MacOS in the next 6mo?
Quote from: bx83 on Mon 19/08/2019 09:28:20
Is MacOS a fairly up-to-date channel? Is it likely that 3.5.0 might be released for MacOS in the next 6mo?
I already built 3.4.4. I can take a look if I can build 3.5.
I currently can't find the time to integrate my changes properly into the repo, but I'm on it.
Kind regards
Dennis
There are automated builds, but I don't think they will be classed as an official release at this point because they aren't well tested and aren't integrated with the existing game build process. I think the issues with the older builds were coming from maintaining hand-built XCode projects (potentially these are no longer needed because CMake is used instead), but actual obstacles to releasing a game (that works everywhere) will be signing with an Apple Developer ID and having the game notarized.
Quote from: morganw on Mon 19/08/2019 15:40:24
There are automated builds, but I don't think they will be classed as an official release at this point because they aren't well tested and aren't integrated with the existing game build process. I think the issues with the older builds were coming from maintaining hand-built XCode projects (potentially these are no longer needed because CMake is used instead), but actual obstacles to releasing a game (that works everywhere) will be signing with an Apple Developer ID and having the game notarized.
Still, this is a major step forward. I think, the signing process can be automated as well, if the user selects macOS as a target. The building process has to be done on a macOS machine anyway.
Hi, just an update on my awful Mac skillz and perhaps someone can give me a few pointers.
I have a Mac Mini 2.5GHz i5, 16gb ram, MacMini5,2, running El Capitain v10.11.6.
I have Xcode - I think with command line utilities, but anyway I would be grateful if someone could tell me where I could get these.
I've tried running a copy of AGS 3.3.4, with the game files in Contents/Resources - it didn't work, unsurprisingly.
Three possible reasons:
The game was compiled with 3.5.0 b6
The game file is a .ags, not a .dat (don't know if this makes a difference, but the Data directory contained a .ags)
This version was compiled with MacOS 10.14
I couldn't find any log files, so either they're not there or it just crashed out of the gates.
Could anyone give me a definite answer of one of those three possibilities? Should I get a newer version of MacOS (new mac mini), a new version of the compiled (only up to b6), or....?
Basically I'm trying to run the compiled game in OS X.
Has anyone tried compiling/running the 3.5.0 engine yet?
Getting a Mac mini 2014 with high Sierra.
Yikes. I tried to build the 3.5 latest but ran into issue and after issue. The Xcode project is way out of date, with many files missing. I tried removing them and the adding the ones that had been added, but have had no luck getting a successful build.
I was hoping it would be like the Linux build where it just created the Mac .app folder for you by adding your game files and with a pre-compiled binary and setting up the info.plist.
Ran into the same issues with iOS. If anyone has any suggestions, I'm all ears. Otherwise I will keep trying....
For macOS it should build with CMake, and there are pre-defined paths for copying items into a .App from ./Resources.
export BUILD_TYPE=release
mkdir build_$BUILD_TYPE
cd build_$BUILD_TYPE
cmake -DCMAKE_BUILD_TYPE=$BUILD_TYPE ..
make
If you want to test a recent build, they are here:
https://cirrus-ci.com/github/adventuregamestudio/ags
The iOS version is another story, I don't think anyone has built this recently.
Quote from: morganw on Tue 22/10/2019 23:11:40
For macOS it should build with CMake, and there are pre-defined paths for copying items into a .App from ./Resources.
export BUILD_TYPE=release
mkdir build_$BUILD_TYPE
cd build_$BUILD_TYPE
cmake -DCMAKE_BUILD_TYPE=$BUILD_TYPE ..
make
If you want to test a recent build, they are here:
https://cirrus-ci.com/github/adventuregamestudio/ags
The iOS version is another story, I don't think anyone has built this recently.
Oh wow, this is good stuff. Thanks so much!
I was able to build my game successfully and everything appears to be working. Thanks again for your help.
This is amazing work, Dennis, thank you! This has been the key to help me port several games to the Mac.
I'm having some issues trying to port another game, so I'm guessing the game might be built using AGS 3.5.0 (or whatever is the most current), so I am trying to follow Dennis's instructions above to download and build AGS 3.5.0. However, I've encountered a couple of issues.
The first stumbling block was trying to run the sed command against the Makefile:
cd ags-release-3.5.0/OSX/buildlibs && sed -i -e "s/10\.7/10.14/gi" -e "s/-arch i386 //gi" -e "s/;i386//gi" Makefile && cd -
sed: 1: "s/10\.7/10.14/gi": bad flag in substitute command: 'i'Not sure why this is complaining about the 'i' substitute. I also tried adding a backslash before the period in "10.14", but this didn't fix the error. However, I was able to make the updates by opening up the Makefile in a text editor and making the three sets of replacements (change 10.7 to 10.14 and remove the i386 architecture references).
I then moved on to trying to perform the installation, and it appears to have downloaded a bunch of packages, before it failing
% cd ags-release-3.5.0/OSX/buildlibs && make install && cd -
allegro-4.4.2.tar.gz: OK
dumb-0.9.3.tar.gz: OK
libogg-1.3.2.tar.gz: OK
libtheora-20150828-gfbb2758.tar.bz2: OK
libtheora-20160525-g50df933.tar.bz2: OK
libtremor-20150108-r19427.tar.bz2: OK
libvorbis-1.3.5.tar.gz: OK
lua-5.1.5.tar.gz: OK
./checkenv.sh
make: *** [prepare] Error 1If I run checkenv.sh by itself, no error, so perhaps the next step, or perhaps I am missing something with my system. Any ideas what might be causing this issue? Thanks for any tips and assistance.
Best regards,
Chad Armstrong
Quote from: Dennis Plöger on Mon 19/08/2019 10:04:45
Quote from: bx83 on Mon 19/08/2019 09:28:20
Is MacOS a fairly up-to-date channel? Is it likely that 3.5.0 might be released for MacOS in the next 6mo?
I already built 3.4.4. I can take a look if I can build 3.5.
I currently can't find the time to integrate my changes properly into the repo, but I'm on it.
Kind regards
Dennis
Hey chad!
Thanks, happy to help. :)
Ah, I'm sorry. I guess, I used the GNU sed version I installed with Homebrew for the command. BSD's sed, which is installed by default on macOS has no case-insensitive search. But actually, that isn't needed anyways. I updated my post with the correct command. Perhaps you can try to rerun the command?
However, I can not reproduce the error you're getting. I get past that checkenv.sh and later get errors around a missing freetype library:
~/Downloads/ags-v.3.5.0.24/OSX/buildlibs ➜ make install
cd /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/../../libsrc && ./download.sh
allegro-4.4.2.tar.gz: https://s3-ap-southeast-2.amazonaws.com/ags-shared/allegro-4.4.2.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 4565k 100 4565k 0 0 1002k 0 0:00:04 0:00:04 --:--:-- 1177k
dumb-0.9.3.tar.gz: https://s3-ap-southeast-2.amazonaws.com/ags-shared/dumb-0.9.3.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 163k 100 163k 0 0 74225 0 0:00:02 0:00:02 --:--:-- 74225
libogg-1.3.2.tar.gz: https://s3-ap-southeast-2.amazonaws.com/ags-shared/libogg-1.3.2.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 537k 100 537k 0 0 156k 0 0:00:03 0:00:03 --:--:-- 156k
libvorbis-1.3.5.tar.gz: https://s3-ap-southeast-2.amazonaws.com/ags-shared/libvorbis-1.3.5.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1600k 100 1600k 0 0 481k 0 0:00:03 0:00:03 --:--:-- 481k
libtheora-20150828-gfbb2758.tar.bz2: https://s3-ap-southeast-2.amazonaws.com/ags-shared/libtheora-20150828-gfbb2758.tar.bz2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 996k 100 996k 0 0 157k 0 0:00:06 0:00:06 --:--:-- 224k
libtheora-20160525-g50df933.tar.bz2: https://s3-ap-southeast-2.amazonaws.com/ags-shared/libtheora-20160525-g50df933.tar.bz2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 958k 100 958k 0 0 269k 0 0:00:03 0:00:03 --:--:-- 269k
libtremor-20150108-r19427.tar.bz2: https://s3-ap-southeast-2.amazonaws.com/ags-shared/libtremor-20150108-r19427.tar.bz2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 122k 100 122k 0 0 49498 0 0:00:02 0:00:02 --:--:-- 49478
lua-5.1.5.tar.gz: https://s3-ap-southeast-2.amazonaws.com/ags-shared/lua-5.1.5.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 216k 100 216k 0 0 93654 0 0:00:02 0:00:02 --:--:-- 93654
allegro-4.4.2.tar.gz: OK
dumb-0.9.3.tar.gz: OK
libogg-1.3.2.tar.gz: OK
libtheora-20150828-gfbb2758.tar.bz2: OK
libtheora-20160525-g50df933.tar.bz2: OK
libtremor-20150108-r19427.tar.bz2: OK
libvorbis-1.3.5.tar.gz: OK
lua-5.1.5.tar.gz: OK
./checkenv.sh
mkdir -p /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt
mkdir -p /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/build
tar xf /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/../../libsrc/lua-5.1.5.tar.gz -C /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/build
cd /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/build/lua-5.1.5 && \
patch -p1 < /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/../patches/lua-5.1.5.patch && \
make macosx INSTALL_TOP="/Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt" PLAT_LDFLAGS="-mmacosx-version-min=10.14 -arch x86_64" PLAT_CFLAGS="-mmacosx-version-min=10.14 -arch x86_64" && \
make install INSTALL_TOP="/Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt"
patching file src/Makefile
cd src && /Applications/Xcode.app/Contents/Developer/usr/bin/make macosx
/Applications/Xcode.app/Contents/Developer/usr/bin/make all MYCFLAGS=-DLUA_USE_LINUX MYLIBS="-lreadline"
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lapi.o lapi.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lcode.o lcode.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ldebug.o ldebug.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ldo.o ldo.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ldump.o ldump.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lfunc.o lfunc.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lgc.o lgc.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o llex.o llex.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lmem.o lmem.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lobject.o lobject.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lopcodes.o lopcodes.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lparser.o lparser.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lstate.o lstate.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lstring.o lstring.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ltable.o ltable.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ltm.o ltm.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lundump.o lundump.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lvm.o lvm.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lzio.o lzio.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lauxlib.o lauxlib.c
lauxlib.c:577:61: warning: while loop has empty body [-Wempty-body]
while ((c = getc(lf.f)) != EOF && c != LUA_SIGNATURE[0]) ;
^
lauxlib.c:577:61: note: put the semicolon on a separate line to silence this warning
1 warning generated.
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lbaselib.o lbaselib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ldblib.o ldblib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o liolib.o liolib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lmathlib.o lmathlib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o loslib.o loslib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ltablib.o ltablib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lstrlib.o lstrlib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o loadlib.o loadlib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o linit.o linit.c
ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o # DLL needs all object files
ranlib liblua.a
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lua.o lua.c
gcc -o lua -mmacosx-version-min=10.14 -arch x86_64 lua.o liblua.a -lm -lreadline
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o luac.o luac.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o print.o print.c
gcc -o luac -mmacosx-version-min=10.14 -arch x86_64 luac.o print.o liblua.a -lm -lreadline
cd src && mkdir -p /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/bin /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/include /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/lib /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/man/man1 /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/share/lua/5.1 /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/lib/lua/5.1
cd src && install -p -m 0755 lua luac /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/bin
cd src && install -p -m 0644 lua.h luaconf.h lualib.h lauxlib.h ../etc/lua.hpp /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/include
cd src && install -p -m 0644 liblua.a /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/lib
cd doc && install -p -m 0644 lua.1 luac.1 /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/man/man1
tar xf /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/../../libsrc/freetype-2.4.12.tar.bz2 -C /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/build
tar: Error opening archive: Failed to open '/Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/../../libsrc/freetype-2.4.12.tar.bz2'
make: *** [freetype] Error 1
I guess there's some dependency, that has not been downloaded. Can't check that right now.
Oh, did you perhaps don't have the xcode command line tools installed? I guess, those are required. Please try to run
xcode-select --install
first and then try again.
Kind regards
Dennis
Oh, to solve the freetype error you have to download https://download.savannah.gnu.org/releases/freetype/freetype-2.4.12.tar.bz2 to the libsrc directory.
Thanks for the quick response, Dennis!
I forgot to mention (even though I thought about it while writing the original post) to mention that I am running macOS 10.14.6 using the built in Bash shell. That you are using a custom version of sed explains the the first issue.
Yes, I have Xcode installed, and I verified that the path looks good.
I don't have freetype, most likely, so that's the next step I'll take.
Best regards,
Chad Armstrong
Quote from: Dennis Ploeger on Tue 05/05/2020 07:37:11
Oh, to solve the freetype error you have to download https://download.savannah.gnu.org/releases/freetype/freetype-2.4.12.tar.bz2 to the libsrc directory.
Suuuuccess!
I compiled 3.5.0.24 and completely without xcode. Only a few fixes finished and I could play an advjam20-game without problems (so far).
So add freetype like I commented earlier. Also, in Engine/Makefile-defs.osx, add ../Common/libsrc/alfont-2.0.9 to INCDIR in the fourth line.
Then, in the main root run
make --directory Engine
After that you can find the engine binary as ags in the Engine subfolder.
I have recompiled my App container. You can download it here:
https://drive.google.com/file/d/1f3pt_e1lRoqmkJYqrdU-DwQFxwExv2F9/view?usp=sharing
Without XCode I now have means on how to easily compile the engine and will send a PR on github in the next days.
Dennis
Aaand here's the PR: https://github.com/adventuregamestudio/ags/pull/1063
That should fix the OSX build for now and hopefully newer versions.
Awesome work, Dennis. I'll test these out and see how things run.
Quote from: Dennis Ploeger on Wed 06/05/2020 21:09:45
Aaand here's the PR: https://github.com/adventuregamestudio/ags/pull/1063
That should fix the OSX build for now and hopefully newer versions.
Time to beg! :=
Do you think you guys could upload the 3.5.0.x engine executable for MacOS somewhere? And since you're there, maybe also the Linux one? (I'm guessing they're not too different but maybe I'm wrong).
Asking for my personal sanity. The learning curve for compiling on Mac is just too much.
Quote from: Monsieur OUXX on Thu 07/05/2020 14:41:26And since you're there, maybe also the Linux one?
https://github.com/adventuregamestudio/ags/releases/tag/v.3.5.0.24
I tried the latest version of the AGS shell app.
The Good:
• It worked with an AGS 3.5.0 game I was trying to port.
The Bad:
• macOS Catalina only (a macOS Mojave build would be nice, I'll see if I can get that working)
• Some of the colors in the game were inverted. Not sure if it is the game, the engine, or some combo. I'll need to do some research.
Quote from: edenwaith on Fri 08/05/2020 04:58:31
• Some of the colors in the game were inverted. Not sure if it is the game, the engine, or some combo. I'll need to do some research.
I swear, this happens all the time. Each 2-3 years someone fixes it, and then it appears again.
There are two places where color conversions are mentioned, first: https://github.com/adventuregamestudio/ags/blob/master/Engine/main/engine_setup.cpp#L185
and second this bitmap->video mem conversion: https://github.com/adventuregamestudio/ags/blob/master/Engine/gfx/gfxdriverbase.cpp#L314
Quote from: edenwaith on Fri 08/05/2020 04:58:31
• macOS Catalina only (a macOS Mojave build would be nice, I'll see if I can get that working)
• Some of the colors in the game were inverted. Not sure if it is the game, the engine, or some combo. I'll need to do some research.
Could you try it with the CMake build instead, the colour issues were already meant to be fixed.
The build instructions are one page back on this same topic:
https://www.adventuregamestudio.co.uk/forums/index.php?topic=47264.msg636611972#msg636611972
Or you can download a binary from here:
https://cirrus-ci.com/task/5955130990264320
I'm still interested in the MacOS executable though, even with the colors issue :=
I can act as a tester if you guys wish.
I have no idea who wrote this but I found it very interesting:
http://www.edenwaith.com/blog/index.php?p=112 | backup (https://github.com/adventuregamestudio/ags/files/4855239/porting-ags-games-to-mac.zip)
Spoiler
Porting Adventure Game Studio Games to the Mac
18th April 2020 | Games
During the 1980s, there was a plethora of competing computer systems
(Atari, Apple \]\[, DOS, Macintosh, Amiga, etc.), which was instrumental
in encouraging Sierra On-Line to develop their AGI and SCI game engines
to support many of these systems. Since those game engines were
interpreters, it was the game engine which needed to be ported, but the
resources and code could remain fairly consistent, which reduced the
effort to bring the games to multiple platforms.
After things shuffled out and settled down to two or three platforms
during the 1990s, most games came out for DOS/Windows. Only a handful of
games were ported to the Mac, and even if they were, it was often years
later. In an effort to come up with a more platform neutral solution, I
developed for my Master's Thesis the [Platform Independent Game
Engine](http://www.edenwaith.com/downloads/pige.php) which was based off
of cross-platform frameworks like C++, OpenGL, and OpenAL. This was more
of a proof of concept than a full fledged tool for game development.
Several months ago, Steven Alexander of Infamous Quests fame directed me to a
way that shows how games created with the Adventure Game
Studio can be ported to the Mac with minimal effort. (Note: Minimal to the level that it doesn't involve
having to rewrite 80% of the code to support another platform.) The
process to take the resources from the Windows version of an AGS game
and turn it into a Mac application only takes a couple of minutes and
does not require fragile third party frameworks like Wine. However, the
process does not end there after copying a couple of files.
This article will detail several areas to help add the extra polish to
make your game port feel like a proper Mac app by designing an
appropriate app icon, configuring the Info.plist, and finally code
signing and notarizing the app for security. I'll demonstrate porting
the hypothetical game Knight's Quest (where you play the intrepid
adventure Sir Club Cracker and roam the countryside picking up anything
which hasn't been nailed down) and how to add the extra polish to make
it into a "proper" Mac application.
Porting
The aforementioned link to the Adventure Game Studio Forum post details
one method how to set up AGS to create a Mac version of a game.
Fortunately, there is already a gameless AGS shell application which can
be modified for your game to work on the Mac without having to go
through a number of convoluted steps to retrofit the Adventure Game
Studio to work on the Mac to develop an application.
Download (https://drive.google.com/file/d/1DrnbmHUKiR1WQLbjdCpXAkR4aH0iJRnO/view?usp=sharing)
the pre-compiled shell Mac application which is built for version 3.4.4
of AGS. This is an empty app, but we will soon populate it with the
required game assets. Mac apps are bundles, essentially a folder with a
collection of additional folders and files contained within. To port an
existing Windows AGS game, we will need to move a couple of the Windows
assets into the appropriate locations in the Mac app.
Right-click on the file [code single]AGS.app[/code] and select Show Package Contents
from the context menu. This will reveal the barebones contents of the
app. Inside the Contents folder is an Info.plist, a MacOS folder (which
contains the AGS executable), PkgInfo, and an empty Resources folder.
Take the executable file (.exe) of your Windows game (*not* the
winsetup.exe file that comes with some AGS games) and rename it to
[code single]ac2game.dat[/code]. If you run the [code single]file[/code] command against the [code single]ac2game.dat[/code]
file, you will see it is still a Windows executable file.
$ file ac2game.dat
ac2game.dat: PE32 executable (GUI) Intel 80386, for MS Windows
Next, copy the ac2game.dat, acsetup.cfg, audio.vox, music.vox,
speech.vox, and any other support files (such as files ending in .dll,
.tra, .000, .001, etc.) to the Resources folder. Your project may not
have all of these files, but most projects will contain at least
ac2game.dat, acsetup.cfg, and audio.vox.
Next rename the app bundle from AGS to the name of your game.
...and now the port is done\! Really. That wasn't so difficult, was it?
Except, it's not quite a polished Mac app, yet. To have the proper
look and feel of a proper Mac app, we still need to add that extra
shine.
One of the first things you'll notice about an app is its icon. Like so
many things in life, it's important to make a good first impression. The
same applies here. Right now, the app has a generic looking icon. For so
many years, icons were limited to small, pixelated blobs, but modern Mac
icons come in a wide range of resolutions from a tiny 16x16 to a
glorious 1024x1024.
If you have an older Mac on hand, use Icon Composer (one of the many
utilities which comes along with Xcode), otherwise, use an app like
Icon Slate (http://www.kodlian.com/apps/icon-slate) to create a Mac
icon file (icns).
If you are starting with this barebones AGS app, the next section will
not apply, but this situation did come up with one app I helped port to
the Mac where the app's icon was set using an old fashioned resource
fork, a throwback of the Classic Mac OS days. If you need to check if
there is a icon resource fork present, go to the Terminal and [code single]cd[/code] into
the app bundle, then list the files contained. If you see a file that
says [code single]Icon?[/code], then there is a resource fork hidden within to represent
the app's icon.
% cd SomeOtherGame.app
$ ls -la
total 2568
drwxr-xr-x@ 4 chadarmstrong staff 128 Jan 1 14:15 .
drwxr-xr-x 11 chadarmstrong staff 352 Jan 1 20:33 ..
drwxr-xr-x@ 6 chadarmstrong staff 192 Jan 1 14:15 Contents
-rw-r--r--@ 1 chadarmstrong staff 0 Nov 26 08:26 Icon?
To remove the resource fork, either delete [code single]Icon?[/code] from the command
line, or if you prefer a more visual method, right-click on the app and
select the Get Info menu. In the Get Info window, click on the app icon
in the top left of the window, then hit the Delete key on your keyboard.
(//Edenwaith%20Blog_files/Get_Info_With_Icon.png%20"Get%20Info%20screenshot")
Other resource forks might still be lurking within the app, but we will
take care of those later.
Place the app icon file into the Resources folder of the app bundle.
Next, we will modify the Info.plist to add the app icon and other
important details.
Info.plist
The skeleton AGS app contains an Info.plist, which can be opened up in
any text editor or Xcode. A couple of additions, modifications, and a
deletion are necessary to properly customize for your game.
- Update the bundle identifier (CFBundleIdentifier) to be unique to
your game (e.g. com.companyname.productname)
- Update the Bundle name (CFBundleName) and Display name
(CFBundleDisplayName) with your game's name. The CFBundleExecutable
should remain as AGS
- Update the version (CFBundleShortVersionString) and build number
(CFBundleVersion)
- Add the human-readable copyright (NSHumanReadableCopyright)
- Add name of the app icon (CFBundleIconFile)
- Remove the [code single]UIStatusBarHidden[/code] key since this is for iOS and
probably not necessary for a Mac port unless there is ever an iOS
version.
- Add the category type: [code single]LSApplicationCategoryType[/code]. Since this is
the Adventure Game Studio, let's assume that many games being
made with this IDE will be adventure games, so the
[code single]LSApplicationCategoryType[/code] should be set to
[code single]public.app-category.adventure-games[/code].
- The Info.plist in the skeleton AGS app bundle contains a bunch of
other odd cruft (such as DTSDKBuild) which probably can be removed,
but I leave it in for now since it doesn't seem to hurt anything.
Following is a subset of the Info.plist file with the necessary changes.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
.
.
.
<key>CFBundleDisplayName</key>
<string>Knight's Quest</string>
<key>CFBundleName</key>
<string>Knight's Quest</string>
<key>CFBundleIdentifier</key>
<string>com.edenwaith.kq</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleVersion</key>
<string>1</string>
<key>LSApplicationCategoryType</key>
<string>public.app-category.adventure-games</string>
<key>NSHumanReadableCopyright</key>
<string>Copyright © 2020 Edenwaith. All Rights Reserved</string>
<key>CFBundleIconFile</key>
<string>KQ-Icon</string>
.
.
.
</dict>
</plist>
Now when you launch the app, the new app icon will appear in the Dock.
Code Signing
Code signing is one of those things which has given me several new grey
hairs over the years. If code signing wasn't enough, Apple has now added
yet another layer of security with app notarization. Notarizing an app
does require several additional steps, but it has fortunately proven to
have not been too harrowing of an experience to figure out and
implement. If you are going to make an app for macOS Mojave, Catalina,
or later, it is a good idea to both code sign and notarize the app so
macOS will not pester the player with annoying warnings about the
validity and security of the app.
I have written (http://www.edenwaith.com/blog/index.php?p=57)
about (http://www.edenwaith.com/blog/index.php?p=52) about code signing
before, so this is not a brand new topic, but with the introduction of
notarization, there is some new information to share.
With the introduction of Xcode 11, there are new types of development
and distribution certificates (e.g. Apple Development, Apple
Distribution), but for this example, I use the older style Developer ID
Application certificate for signing the app for distribution.
Let's start by verifying that the app is not code signed:
$ codesign --verify --verbose=4 Knight\'s\ Quest.app
Knight's Quest.app: code object is not signed at all
In architecture: x86_64
$ spctl --verbose=4 --assess --type execute Knight\'s\ Quest.app
Knight's Quest.app: rejected
source=no usable signature
This looks as expected. The next step is to code sign the app bundle. In
the past, we would use a command like the following:
codesign --force --sign "Developer ID Application: John Doe (12AB34567D)" MyGreatApp.app/
However, with the introduction of notarization, there is a new set of
options to add to further harden the code signing process: `--options
runtime`
codesign --force -v --sign "Developer ID Application: John Doe (12AB34567D)" --options runtime Knight\'s\ Quest.app
If everything works as hoped, you will see a successful message like
this:
Knight's Quest.app/: signed app bundle with Mach-O thin (x86_64) [com.edenwaith.kq]
If the code signing was successful, skip to the next section about
Notarization.
Unfortunately, it is far too easy for things to go wrong. With some apps
I've helped port, there would be resource forks or other Finder info
hidden somewhere in the app, so I'd see an error message like this one:
SomeOtherGame.app: resource fork, Finder information, or similar detritus not allowed
This error is due to a security hardening change that was introduced
with iOS 10, macOS Sierra, watchOS 3, and tvOS 10. According to Apple:
Code signing no longer allows any file in an app bundle to have an
extended attribute containing a resource fork or Finder info.
The first time I saw this error, I determined that the "offending" file
was the icon file, so I used the following command:
find . -type f -name '*.icns' -exec xattr -c {} \;
In one case, the problem was because I had added a Finder tag on the app
bundle. Removing the tag fixed the problem. With another instance, some
other file was causing issues, but I was not able to immediately
discover which was the suspect file.
To ferret out the problem, I used the [code single]xattr[/code] command to see what
extended attributes were available in the app bundle.
$ xattr -lr Knight\'s\ Quest.app/
Knight's Quest.app//Contents/_CodeSignature: com.apple.quarantine: 01c1;5e0d5c84;sharingd;E82F3462-E848-4A3A-846C-C497474C0E1C
Knight's Quest.app//Contents/MacOS/AGS: com.apple.quarantine: 01c1;5e0d5c84;sharingd;E82F3462-E848-4A3A-846C-C497474C0E1C
Knight's Quest.app//Contents/MacOS: com.apple.quarantine: 01c1;5e0d5c84;sharingd;E82F3462-E848-4A3A-846C-C497474C0E1C
Knight's Quest.app//Contents/Resources/audio.vox: com.apple.quarantine: 01c1;5e2e7a68;Firefox;7587AE66-F597-423C-8787-1DAE23ECA136
Knight's Quest.app//Contents/Resources/ac2game.dat: com.apple.quarantine: 01c1;5e2e7a68;Firefox;7587AE66-F597-423C-8787-1DAE23ECA136
Knight's Quest.app//Contents/Resources/acsetup.cfg: com.apple.quarantine: 01c1;5e2e7a68;Firefox;7587AE66-F597-423C-8787-1DAE23ECA136
Knight's Quest.app//Contents/Resources: com.apple.quarantine: 01c1;5e0d5c84;sharingd;E82F3462-E848-4A3A-846C-C497474C0E1C
Knight's Quest.app//Contents/Info.plist: com.apple.lastuseddate#PS:
00000000 CD 72 0D 5E 00 00 00 00 B4 1E 64 2C 00 00 00 00 |.r.^......d,....|
00000010
Knight's Quest.app//Contents/Info.plist: com.apple.quarantine: 0181;5e0d5c84;sharingd;E82F3462-E848-4A3A-846C-C497474C0E1C
Knight's Quest.app//Contents/PkgInfo: com.apple.quarantine: 0181;5e0d5c84;sharingd;E82F3462-E848-4A3A-846C-C497474C0E1C
Knight's Quest.app//Contents: com.apple.quarantine: 01c1;5e0d5c84;sharingd;E82F3462-E848-4A3A-846C-C497474C0E1C
Knight's Quest.app/: com.apple.quarantine: 01c1;5e0d5c84;sharingd;E82F3462-E848-4A3A-846C-C497474C0E1C
To clean up the extraneous resource forks (and other detritus), use the
command:
xattr -cr Knight\'s\ Quest.app/
Once the cruft has been removed, verify with [code single]xattr -lr[/code] again and then
try code signing the app once more. Perform one more set of
verifications to ensure that things look good.
$ codesign --verify --verbose=4 Knight\'s\ Quest.app
Knight's Quest.app: valid on disk
Knight's Quest.app: satisfies its Designated Requirement
$ spctl --verbose=4 --assess --type execute Knight\'s\ Quest.app
Knight's Quest.app: accepted
source=Developer ID
Notarization
Now on to the new stuff\! The first thing you'll need to do is generate
an app-specific password (https://support.apple.com/en-us/HT204397) for
this app. Log in to [Manage Your Apple ID
page](https://appleid.apple.com/#!&page=signin) with your Apple
developer credentials. Under the Security section, tap on the **Generate
Password...** link. In the pop up, enter in a description for the app
(e.g. Knight's Quest), and then an app-specific password will be
generated. The app-specific password will be a sixteen character
password that will look similar to this: [code single]wcag-omwd-xzxc-jcaw[/code] . Save
this password in a secure place\! You will need this password for
notarizing the app.
The next step will involve packaging the app to be notarized. It can be
packaged as either a zip archive (zip), disk image (dmg), or an
installer package (pkg). Since this is just a single app bundle, a zip
file will work.
// Zip up the app
ditto -c -k --sequesterRsrc --keepParent *app KQ.zip
For the next step, if your Apple ID is only part of a single developer
account, you can skip ahead. However, if your Apple ID is associated
with multiple accounts (such as multiple companies), then you will need
to obtain more specific information before notarizing the app.
Otherwise, if you try to notarize an app and your Apple ID belongs to
multiple accounts, you will see this error:
`Error:: altool[7230:1692365] *** Error: Your Apple ID account is
attached to other iTunes providers. You will need to specify which
provider you intend to submit content to by using the -itc_provider
command. Please contact us if you have questions or need help. (1627)`
To get the list of providers linked to your Apple ID, use this command:
xcrun iTMSTransporter -m provider -u john.doe@edenwaith.com -p wcag-omwd-xzxc-jcaw
This command will output a bunch of cruft, but ends with:
Provider listing:
- Long Name - - Short Name -
1 John Doe JohnDoe18675309
2 Acme, Co. AcmeCo
In this hypothetical example, the developer John Doe has his own
personal Apple developer account and also belongs to Acme's developer
account, as well. For this project, John will use his personal account,
so he will use the short name of [code single]JohnDoe18675309[/code], which will be used
as the ASC provider value in the following command. Again, you can omit
the [code single]asc-provider[/code] option for the notarization call if your credentials
are associated with only a single team.
To notarize the app, you will use the application launcher tool
([code single]altool[/code]), which can also be used for other purposes (such as
uploading the app (http://www.edenwaith.com/blog/index.php?p=105) to
Apple's servers). The format of notarizing is as follows:
xcrun altool --notarize-app --primary-bundle-id com.example.appname --username APPLE_DEV_EMAIL --password APP_SPECIFIC_PASSWORD --asc-provider PROVIDER_SHORT_NAME --file AppName.zip
For our example, we filled in the blanks with the following values:
- primary-bundle-id : com.edenwaith.kq
- APPLE\_DEV\_EMAIL : john.doe@edenwaith.com
- APP\_SPECIFIC\_PASSWORD : wcag-omwd-xzxc-jcaw
- asc-provider : JohnDoe18675309
- AppName.zip : KQ.zip
xcrun altool --notarize-app --primary-bundle-id "com.edenwaith.kq" -u john.doe@edenwaith.com -p wcag-omwd-xzxc-jcaw --asc-provider JohnDoe18675309 --file KQ.zip
For a more in depth break out of what each of these options mean, refer
to Davide Barranca's [excellent
post](https://www.davidebarranca.com/2019/04/notarizing-installers-for-macos-catalina/)
on this topic.
This process can take awhile, depending on how large your file is, since
it needs to get uploaded to Apple's servers and be notarized.
Unfortunately, this potentially long wait time comes with consequences
if there is an error. One reason notarization might fail is if you need
to accept Apple's terms of agreement (which may have also been updated),
so you might see an error like:
/var/folders/pv/xtfd6hjn7hd8kpt70q0vwl8w0000gq/T/15A31C27-F6AF-48E8-9116-A30A7C76AD03/com.edenwaith.kq.itmsp - Error Messages:
You must first sign the relevant contracts online. (1048)
2020-04-11 11:23:19.745 altool[22640:1119844] *** Error: You must first sign the relevant contracts online. (1048)
One approach to fix this is to log in to the Apple developer portal and
check to see if new terms of service need to be reviewed. If so, agree
to the terms, and wait a couple of minutes before trying to notarize
again. You can also check Xcode's license agreement from the Terminal by
typing in the command:
sudo xcodebuild -license
However, if everything works properly with uploading the file, you will
get a message like this:
No errors uploading 'KQ.zip'.
RequestUUID = 2de2e2f9-242f-3c78-9937-1a7ef60f3007
You'll want that RequestUUID value so you can check on the notarization
status to see if the package has been approved yet. After uploading your
app, the notarization process typically takes anywhere from several
minutes to an hour. When the process completes, you receive an email
indicating the outcome. Additionally, you can use the following command
to check the status of the notarization process:
$ xcrun altool --notarization-info 2de2e2f9-242f-3c78-9937-1a7ef60f3007 -u john.doe@edenwaith.com -p wcag-omwd-xzxc-jcaw
No errors getting notarization info.
Date: 2020-01-04 22:44:42 +0000
Hash: adf86725dec3ab7c26be17178e07efaf3b2806f743fefd0dd1059f68dcf45398
LogFileURL: https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma123/v4/a5/15/64/2d...
RequestUUID: 2de2e2f9-242f-3c78-9937-1a7ef60f3007
Status: success
Status Code: 0
Status Message: Package Approved
Once the package has been approved, we can move on to the stapling the
ticket to the app.
Stapler
At this point, the app has been validated and notarized, so if an app
launches, macOS will check with the servers and verify that the app has
been properly notarized. However, if the computer is not online, then it
cannot perform this step, so it is useful to staple the ticket to the
app for offline usage.
xcrun stapler staple -v KQ.app
Once again, a ton of text will scroll across the Terminal. If it works,
the last line should read: [code single]"The staple and validate action worked!"[/code]
For sanity's sake, validate that stapling worked:
stapler validate Knight\'s\ Quest.app
Process: Knight's Quest.app
The validate action worked!
However, if the stapling hasn't been completed, there will be an error
like this:
$ stapler validate Knight\'s\ Quest.app/
Processing: Knight's Quest.app
Knight's Quest.app does not have a ticket stapled to it.
For a final verification, use [code single]spctl[/code] to verify that the app has been
properly signed and notarized:
$ spctl -a -v Knight\'s\ Quest.app
Knight's Quest.app: accepted
source=Notarized Developer ID
Notice that this check varies slightly from when we first did this check
before the notarization â€" the source now says [code single]Notarized Developer ID[/code].
[h3]Final Packaging[/h3]
Now that the game has been ported, code signed, and notarized, it is
time to package it up for distribution. There are a variety of ways to
do so, whether via an installer, a disk image, or a zip archive. If you
are distributing the game via download from your website, you'll
probably want to bundle the game and any other extras (such as README
files, game manuals, etc.) into a single containing folder. If you are
going to upload the game to Steam, then you may not want an enclosing
folder.
To be a good internet citizen, make sure when the zip archive is
created, that any Mac-specific files are removed, such as the .DS\_Store
file and \_\_MACOSX, which stores excess metadata and resource forks.
zip -r KQ.zip . -x ".*" -x "__MACOSX"
This example zips up everything in the current directory, but excludes
any dot files and any unwanted metadata. With the game packaged up, it's
ready to go\!
[h3]Ported Games[/h3]
It has been a pleasure and joy to help bring a number of adventure games
to the Mac. Below is the list of AGS games I've helped port. I highly
recommend that if you enjoy adventure games, give them a try\! I hope
that this extensive tutorial has been useful in learning how to port
games developed with the Adventure Game Studio to the Mac, in addition
to learning how to code sign and notarize a Mac application. If you
would like assistance in porting, contact me via
e-mail (http://www.edenwaith.com/support/contact.php) or
Twitter (https://twitter.com/edenwaith).
- Space Quest 2 VGA (https://infamousadventures.itch.io/space-quest-ii-vga-remake)
by Infamous Adventures
- King's Quest 3 VGA (https://infamousadventures.itch.io/kings-quest-iii-vga-remake)
by Infamous Adventures
- Order of the Thorne - The King's Challenge (http://www.infamous-quests.com/order-of-the-thorne/) by
Infamous Quests
- Quest for Infamy (http://www.infamous-quests.com/home/games/quest-for-infamy/)
by Infamous Quests
- Feria D'Arles (https://tomsimpson.itch.io/feria-darles) by Tom
Simpson
- The Crimson Diamond (https://www.thecrimsondiamond.com/) by Julia
Minamata
- Stair Quest (https://decafjedi.itch.io/stair-quest) by No More For
Today Productions
[h4]Resources[/h4]
- Adventure Game Studio (https://www.adventuregamestudio.co.uk/)
- AGS engine Mac OS X port (https://www.adventuregamestudio.co.uk/forums/index.php?topic=47264.msg636608357#msg636608357)
- Notarizing macOS Software Before Distribution (https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution?language=objc)
- Customizing The Notarization Workflow (https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow?language=objc#3087734)
- Your Apps and the Future of macOS Security (https://developer.apple.com/videos/play/wwdc2018/702/)
- Apple ID (https://appleid.apple.com/#!&page=signin) - Create Per App-Specific Passwords
- Using app-specific passwords (https://support.apple.com/en-us/HT204397)
- How to Notarize Your Software on macOS (https://successfulsoftware.net/2018/11/16/how-to-notarize-your-software-on-macos/)
- App Notarization: A Quick Primer (https://blog.fleetsmith.com/macos-mojave-app-notarization/)
- Apple Ramps Up Fight against Malware with Notarization, Stapling, and Hardening (https://twocanoes.com/apple-ramps-up-fight-against-malware-with-notarization-stapling-and-hardening/)
- Replacing Application Loader with altool (http://www.edenwaith.com/blog/index.php?p=105)
- Notarization Provider IDs (https://indiestack.com/2019/09/notarization-provider-ids/)
- Selecting iTunes Provider for Notarization (https://cutecoder.org/software/select-itunes-provider-notarization/)
- Technical Q\&A QA1940 Code signing fails with error 'resource fork, Finder information, or similar detritus not allowed' (https://developer.apple.com/library/archive/qa/qa1940/_index.html)
- Signing and Notarizing macOS Apps for Gatekeeper (http://lessons.livecode.com/a/1088036-signing-and-notarizing-macos-apps-for-gatekeeper)
- Codesigning and notarizing your LC standalone for distribution outside the Mac Appstore (http://lessons.livecode.com/m/4071/l/1122100-codesigning-and-notarizing-your-lc-standalone-for-distribution-outside-the-mac-appstore)
- Signing and Notarizing for Catalina (http://www.zarkonnen.com/signing_notarizing_catalina)
- Dev Journal â€" Automate notarizing macOS apps (https://blog.zeplin.io/dev-journal-automate-notarizing-macos-apps-94b0b144ba9d)
- Mac zip compress without \_\_MACOSX folder? (https://stackoverflow.com/questions/10924236/mac-zip-compress-without-macosx-folder)
- Compress without .DS\_Store and \_\_MACOSX (https://apple.stackexchange.com/questions/239578/compress-without-ds-store-and-macosx)
- Notarizing installers for macOS Catalina (https://www.davidebarranca.com/2019/04/notarizing-installers-for-macos-catalina/)
- Notarize a Command Line Tool (https://scriptingosx.com/2019/09/notarize-a-command-line-tool/)
- Building and delivering command tools for Catalina (https://eclecticlight.co/2019/06/13/building-and-delivering-command-tools-for-catalina/)
© 2001 - 2020 Edenwaith - http://www.edenwaith.com/
Look up a few posts and see the author posting in this very thread
Ha! Thanks Privateer Puddin! ;-D
Yep, that's my extensive blog post on the steps I take to port an AGS game to the Mac. Glad someone else found it and hopefully it will prove useful to anyone wanting to bring their game to the Mac.
Once I figure out how to download and get the AGS source building on my Mac, I'll probably write up a follow up post.
Quote from: eri0o on Wed 01/07/2020 03:11:20
I have no idea who wrote this but I found it very interesting:
http://www.edenwaith.com/blog/index.php?p=112 | backup (https://github.com/adventuregamestudio/ags/files/4855239/porting-ags-games-to-mac.zip)
I'm starting to make some progress. A couple of things which were causing issues on my machine.
1. I upgraded my version of homebrew, which required its own amount of fixing permissions on the /usr/local directory.
2. I've been using macOS/Mac OS X since the 10.0 beta days, so there are still some hidden remains of the tcsh shell (even though my shell is currently set to Bash), which might have been causing some of the issues. I ended up downloading iTerm, and this seems to be more successful in running "make install".
3. I was missing several tools, such as pkg-config, etc. so I ended up running this command:
brew install curl pkg-config autoconf automake libtoolAfter running
make install, it is progressing much further now, but it is still failing. It appears there is a code signing issue (a perpetual bane of my programming existence):
/usr/bin/codesign --force --sign - --entitlements /Users/edenwaith/Programs/ags/AGS-macOS-3.5.0/ags-release-3.5.0/OSX/buildlibs/build/allegro-4.4.2/build/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_67420.build/cmTC_67420.xcent --timestamp=none /Users/edenwaith/Programs/ags/AGS-macOS-3.5.0/ags-release-3.5.0/OSX/buildlibs/build/allegro-4.4.2/build/CMakeFiles/CMakeTmp/Debug/cmTC_67420
/Users/edenwaith/Programs/ags/AGS-macOS-3.5.0/ags-release-3.5.0/OSX/buildlibs/build/allegro-4.4.2/build/CMakeFiles/CMakeTmp/Debug/cmTC_67420: No such file or directory
Command /usr/bin/codesign failed with exit code 1
** BUILD FAILED **
The following build commands failed:
Ld /Users/edenwaith/Programs/ags/AGS-macOS-3.5.0/ags-release-3.5.0/OSX/buildlibs/build/allegro-4.4.2/build/CMakeFiles/CMakeTmp/Debug/cmTC_67420 normal x86_64
CodeSign /Users/edenwaith/Programs/ags/AGS-macOS-3.5.0/ags-release-3.5.0/OSX/buildlibs/build/allegro-4.4.2/build/CMakeFiles/CMakeTmp/Debug/cmTC_67420
(2 failures)Any thoughts on was is missing here now? Hmm...
Regards,
Chad
Quote from: Dennis Ploeger on Tue 05/05/2020 07:14:38
Hey chad!
Thanks, happy to help. :)
Ah, I'm sorry. I guess, I used the GNU sed version I installed with Homebrew for the command. BSD's sed, which is installed by default on macOS has no case-insensitive search. But actually, that isn't needed anyways. I updated my post with the correct command. Perhaps you can try to rerun the command?
However, I can not reproduce the error you're getting. I get past that checkenv.sh and later get errors around a missing freetype library:
~/Downloads/ags-v.3.5.0.24/OSX/buildlibs ➜ make install
cd /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/../../libsrc && ./download.sh
allegro-4.4.2.tar.gz: https://s3-ap-southeast-2.amazonaws.com/ags-shared/allegro-4.4.2.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 4565k 100 4565k 0 0 1002k 0 0:00:04 0:00:04 --:--:-- 1177k
dumb-0.9.3.tar.gz: https://s3-ap-southeast-2.amazonaws.com/ags-shared/dumb-0.9.3.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 163k 100 163k 0 0 74225 0 0:00:02 0:00:02 --:--:-- 74225
libogg-1.3.2.tar.gz: https://s3-ap-southeast-2.amazonaws.com/ags-shared/libogg-1.3.2.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 537k 100 537k 0 0 156k 0 0:00:03 0:00:03 --:--:-- 156k
libvorbis-1.3.5.tar.gz: https://s3-ap-southeast-2.amazonaws.com/ags-shared/libvorbis-1.3.5.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1600k 100 1600k 0 0 481k 0 0:00:03 0:00:03 --:--:-- 481k
libtheora-20150828-gfbb2758.tar.bz2: https://s3-ap-southeast-2.amazonaws.com/ags-shared/libtheora-20150828-gfbb2758.tar.bz2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 996k 100 996k 0 0 157k 0 0:00:06 0:00:06 --:--:-- 224k
libtheora-20160525-g50df933.tar.bz2: https://s3-ap-southeast-2.amazonaws.com/ags-shared/libtheora-20160525-g50df933.tar.bz2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 958k 100 958k 0 0 269k 0 0:00:03 0:00:03 --:--:-- 269k
libtremor-20150108-r19427.tar.bz2: https://s3-ap-southeast-2.amazonaws.com/ags-shared/libtremor-20150108-r19427.tar.bz2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 122k 100 122k 0 0 49498 0 0:00:02 0:00:02 --:--:-- 49478
lua-5.1.5.tar.gz: https://s3-ap-southeast-2.amazonaws.com/ags-shared/lua-5.1.5.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 216k 100 216k 0 0 93654 0 0:00:02 0:00:02 --:--:-- 93654
allegro-4.4.2.tar.gz: OK
dumb-0.9.3.tar.gz: OK
libogg-1.3.2.tar.gz: OK
libtheora-20150828-gfbb2758.tar.bz2: OK
libtheora-20160525-g50df933.tar.bz2: OK
libtremor-20150108-r19427.tar.bz2: OK
libvorbis-1.3.5.tar.gz: OK
lua-5.1.5.tar.gz: OK
./checkenv.sh
mkdir -p /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt
mkdir -p /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/build
tar xf /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/../../libsrc/lua-5.1.5.tar.gz -C /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/build
cd /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/build/lua-5.1.5 && \
patch -p1 < /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/../patches/lua-5.1.5.patch && \
make macosx INSTALL_TOP="/Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt" PLAT_LDFLAGS="-mmacosx-version-min=10.14 -arch x86_64" PLAT_CFLAGS="-mmacosx-version-min=10.14 -arch x86_64" && \
make install INSTALL_TOP="/Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt"
patching file src/Makefile
cd src && /Applications/Xcode.app/Contents/Developer/usr/bin/make macosx
/Applications/Xcode.app/Contents/Developer/usr/bin/make all MYCFLAGS=-DLUA_USE_LINUX MYLIBS="-lreadline"
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lapi.o lapi.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lcode.o lcode.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ldebug.o ldebug.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ldo.o ldo.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ldump.o ldump.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lfunc.o lfunc.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lgc.o lgc.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o llex.o llex.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lmem.o lmem.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lobject.o lobject.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lopcodes.o lopcodes.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lparser.o lparser.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lstate.o lstate.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lstring.o lstring.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ltable.o ltable.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ltm.o ltm.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lundump.o lundump.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lvm.o lvm.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lzio.o lzio.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lauxlib.o lauxlib.c
lauxlib.c:577:61: warning: while loop has empty body [-Wempty-body]
while ((c = getc(lf.f)) != EOF && c != LUA_SIGNATURE[0]) ;
^
lauxlib.c:577:61: note: put the semicolon on a separate line to silence this warning
1 warning generated.
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lbaselib.o lbaselib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ldblib.o ldblib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o liolib.o liolib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lmathlib.o lmathlib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o loslib.o loslib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o ltablib.o ltablib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lstrlib.o lstrlib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o loadlib.o loadlib.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o linit.o linit.c
ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o # DLL needs all object files
ranlib liblua.a
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o lua.o lua.c
gcc -o lua -mmacosx-version-min=10.14 -arch x86_64 lua.o liblua.a -lm -lreadline
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o luac.o luac.c
gcc -O2 -Wall -DLUA_USE_LINUX -mmacosx-version-min=10.14 -arch x86_64 -c -o print.o print.c
gcc -o luac -mmacosx-version-min=10.14 -arch x86_64 luac.o print.o liblua.a -lm -lreadline
cd src && mkdir -p /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/bin /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/include /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/lib /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/man/man1 /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/share/lua/5.1 /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/lib/lua/5.1
cd src && install -p -m 0755 lua luac /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/bin
cd src && install -p -m 0644 lua.h luaconf.h lualib.h lauxlib.h ../etc/lua.hpp /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/include
cd src && install -p -m 0644 liblua.a /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/lib
cd doc && install -p -m 0644 lua.1 luac.1 /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/opt/man/man1
tar xf /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/../../libsrc/freetype-2.4.12.tar.bz2 -C /Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/build
tar: Error opening archive: Failed to open '/Users/dennis.ploeger/Downloads/ags-v.3.5.0.24/OSX/buildlibs/../../libsrc/freetype-2.4.12.tar.bz2'
make: *** [freetype] Error 1
I guess there's some dependency, that has not been downloaded. Can't check that right now.
Oh, did you perhaps don't have the xcode command line tools installed? I guess, those are required. Please try to run
xcode-select --install
first and then try again.
Kind regards
Dennis
OK, finally got everything built. I believe the final issue was the Makefile had some issues because I edited it by hand when the native version of sed didn't work properly to replace "10.7" with "10.14" and I ended up fat fingering a few values. After properly swapping out "10.7" for "10.14", things built.
- Chad
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?
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.
Quote from: morganw on Sun 26/07/2020 12:05:16
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?
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.
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.
Quote from: morganw on Sun 26/07/2020 12:05:16
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?
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.
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:
al-main INFO: Allegro initialised (instance 1)
al-gfx INFO: Called set_gfx_mode(1129268812, 356, 200, 0, 0).
al-gfx INFO: First call, remembering console state.
al-gfx INFO: The driver will wait for vsync.
al-gfx INFO: set_gfx_card success for 356x200x32.
al-osxgl INFO: OpenGL Version: 2.1 INTEL-12.10.24
al-osxgl INFO: Vendor: Intel Inc.
al-osxgl INFO: Renderer: Intel(R) Iris(TM) Pro Graphics 6200
al-gfx INFO: Called set_gfx_mode(-1, 0, 0, 0, 0).
al-gfx INFO: Closing graphics driver (0x1009feb90) Cocoa GL full.
al-gfx INFO: Closing, restoring original console state.
al-gfx INFO: Graphic mode closed.
Quote from: Crimson Wizard on Tue 08/12/2020 04:09:15
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.
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.
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
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?
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 :)
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)
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!
I renamed it LoCI.app, works fine.
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?
Quote from: bx83 on Tue 18/05/2021 09:05:10
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
touch yourGameName.appin the terminal.
Thank you :)
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!
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
Quote from: eri0o on Wed 26/05/2021 00:11:28
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
chmod -R 755 NameofGame.app After that, I was able to launch the game, after the usual warning about insecure source.
thanks!
Quote from: emabolo on Wed 26/05/2021 13:29:55
So apparently it was a problem of permissions. I solved it with 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.
Quote from: emabolo on Wed 26/05/2021 13:29:55
Quote from: eri0o on Wed 26/05/2021 00:11:28
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 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.
Quote from: Potajito on Wed 26/05/2021 14:55:27
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.
I didn't know about the butler. I'm definitely going to use itl! Thank you!
I just tried TheVolumeRemote's wrapper and it works beautifully, with one caveat: if I run the game fullscreen in my external monitor, which has a ratio of 16:9, the image gets stretched to fill the screen even though I've set screen_def to "scaling" in the cfg file. I wonder if there's another copy of the cfg file that gets created somewhere else, same as in Linux, or are multiple monitors a known issue with this port?
Quotewindowed=0
screen_def=scaling
game_scale_fs=max_round
game_scale_win=max_round
LauraHunt, ags currently does not detect multiple monitors correctly, maybe that's the part of the problem. Also, I would not use "scaling" in fullscreen, maybe it's best to use "max" to make it keep at current desktop resolution, and "proportional" for "game_scale_fs".
Quote from: Crimson Wizard on Wed 26/05/2021 16:58:57
LauraHunt, ags currently does not detect multiple monitors correctly, maybe that's the part of the problem. Also, I would not use "scaling" in fullscreen, maybe it's best to use "max" to make it keep at current desktop resolution, and "proportional" for "game_scale_fs".
Hey CW, thanks, setting it to "proportional" seems to have fixed it. However, this mode is not listed here, which is what I was using for reference: https://github.com/adventuregamestudio/ags/blob/master/OPTIONS.md
Quotescreen_def = [string] - determines how display mode is deduced:
- explicit - use screen_width and screen_height parameters;
- scaling - sets equal to scaled game size;
- max - sets equal to device/desktop size.
Maybe it would be useful to add it?
Edit: to clarify, what I did was leave
game_scale_fs as "max_round", and set
screen_def to "proportional", even though it's not listed as one of the possible parameters. Somehow seems to have worked.
Edit 2: Actually no, it didn't work. What DOES seem to work is to start the game in windowed mode and, once it's running, pressing Alt+Enter to go into fullscreen mode; then the game scales correctly. But running the game directly in fullscreen stretches the image to fill the screen instead.
screen_def cannot be "proportional", I was referring to game_scale_fs option. "screen_def" could be set to "max" that would use current desktop resolution.
The thing is that "screen_def = scaling" will try to set new display resolution to the integer scale of a game's size. Changing resolution itself may be problematic on some systems, but if proper resolution is not supported it will try to find nearest one which may be not what you want.
Quote from: Crimson Wizard on Wed 26/05/2021 17:47:00
screen_def cannot be "proportional", I was referring to game_scale_fs option. "screen_def" could be set to "max" that would use current desktop resolution.
Yeah sorry for the confusion, I realized that afterwards. Hope my second edit clarifies things, but to conclude: if you start the game in windowed mode with the "normal" parameters (screen_def=max, and max_round for both fs and windowed) and press alt+enter once the game is running,
then it scales correctly on the second monitor. It's a workaround, at least.
people,
I started to try to update the AGS Xcode project for MacOS and discovered that Xcode is super alien for me (I normally do MacOS through CLion using CMake). If some of the MacOS devs that occasionally appear here see this message, I made some initial work to get at least the libraries in a newer version and in a state they build and install, but I am stuck trying to understand how to add files in Xcode in a way the headers actually work. In case some Xcode expert wants to join and upgrade the projects, here is the initial work: https://github.com/ericoporto/ags/tree/macos-xcode-sdl2
@LauraHunt, I just noticed that the MacOSX port does not create window sized like the Windows or Linux ports do, it has some different logic to this and likely not even using mode size from the config.
You mentioned that the problem occurs on the "external monitor", does it also happen on the main monitor (I'm not sure what your setup is).
Quote from: Crimson Wizard on Mon 31/05/2021 18:44:51
@LauraHunt, I just noticed that the MacOSX port does not create window sized like the Windows or Linux ports do, it has some different logic to this and likely not even using mode size from the config.
You mentioned that the problem occurs on the "external monitor", does it also happen on the main monitor (I'm not sure what your setup is).
I'm using a 15-inch MacBook Pro (2880x1800) and an external 24-inch Dell (1920x1080). The issue does not happen on the laptop display, but it might be because both the game (320x200) and the display have a ratio of 16:10.
Still, the behaviour is always the same: if I start the game in windowed mode and then switch to fullscreen, the image scales correctly on the external display without any stretching (but if I quit while in fullscreen mode and then start the game again at some other time, it will once more stretch to fill the screen, so the best thing to do is switch to windowed mode before quitting).
Interestingly, if I run the game in windowed mode, the cfg file that's located in the user's Saved Games profile folder sets itself to "scaling". If I run the game in fullscreen mode, the cfg sets itself to "max".
Quote from: Laura Hunt on Mon 31/05/2021 19:30:33
Still, the behaviour is always the same: if I start the game in windowed mode and then switch to fullscreen, the image scales correctly on the external display without any stretching (but if I quit while in fullscreen mode and then start the game again at some other time, it will once more stretch to fill the screen, so the best thing to do is switch to windowed mode before quitting).
When switching modes it uses different algorithm than on startup for MacOSX port, which may be related.
When you startup in mode A engine remembers its settings, so switch forth and back will return to same settings. But when you start in mode B and switch to mode A later, these settings will be taken from "defaults" instead.
Quote from: Laura Hunt on Mon 31/05/2021 19:30:33
Interestingly, if I run the game in windowed mode, the cfg file that's located in the user's Saved Games profile folder sets itself to "scaling". If I run the game in fullscreen mode, the cfg sets itself to "max".
This is how default settings work for these modes, for fullscreen it's "max" which means current desktop size, and for windowed it's "scaling" which means take game size and scale by a integer factor.
I think it could use the main monitor for determining the desktop size. But this does not explain why it improves on switching modes.
PS. Also, in the latest version I disabled saving config by engine itself, so it will not longer change these settings in config file.
I just refreshed my Mac wrapper with a new version of the game, just copying the .exe and the .tra and renaming the exe "game.ags". Unfortunately, the app does not even open. I can see the icon on the dock, and it shuts down immediately. If I put the old game back, it's working. Is it possible that the wrapper 3.5.0 is not compatible with AGS 3.5.1 ? If not, what else could be the reason?
emabolo, TheVolumeRemote should generate a new wrapper for 3.5.1, or produce a tutorial on how to compile the 3.5.1 code into a Mac engine so I no longer have to bother him by proxy, HINT HINT HINT ;P
Quote from: bx83 on Thu 17/06/2021 14:37:25
emabolo, TheVolumeRemote should generate a new wrapper for 3.5.1, or produce a tutorial on how to compile the 3.5.1 code into a Mac engine so I no longer have to bother him by proxy, HINT HINT HINT ;P
I have no desire to install Xcode, it's too much for my Mac, it will probably destroy it :)
I'll be waiting for the new wrapper, thanks a lot to the developers!
Quote from: emabolo on Thu 17/06/2021 09:10:30
I just refreshed my Mac wrapper with a new version of the game, just copying the .exe and the .tra and renaming the exe "game.ags". Unfortunately, the app does not even open. I can see the icon on the dock, and it shuts down immediately. If I put the old game back, it's working. Is it possible that the wrapper 3.5.0 is not compatible with AGS 3.5.1 ? If not, what else could be the reason?
Could you clarify, what is the "wrapper" and what versions are wrapper and the game files? I may be confused by the above description.
I don't know if related, but I did a small change for 3.5.1. macos port:
Quote
- When looking for game files engine will no longer use hardcoded filename, will search for any compatible pack file instead.
It's a compiled version of the Mac (3.5.0) engine; not really a wrapper. Well, in the sense it wraps a system-agnostic version of the game (say the windows exe file) as a Mac .app?...
I think mac port should write a log? If you enable logging in config file, or from command line (if you can run this port from cmd line on your mac), then you may know more information on what is happening.
If I understand correctly, the log should be inside a game files subfolder, same place where it puts saves to.
How to configure log is described in the OPTIONS.md file in our repository (scroll down for command line options).
Here's one from 3.5.1: https://github.com/adventuregamestudio/ags/blob/release-3.5.1/OPTIONS.md
and older one from 3.5.0: https://github.com/adventuregamestudio/ags/blob/release-3.5.0/OPTIONS.md
Quote from: Crimson Wizard on Wed 23/06/2021 13:33:08
I think mac port should write a log? If you enable logging in config file, or from command line (if you can run this port from cmd line on your mac), then you may know more information on what is happening.
Posting this here for completeness even if we spoke on Discord.
The crash was generated by
System.SaveConfigToFile() which is in fact an API available only on 3.5.1, while I was using the Mac "wrapper" created by TheVolumeRemote with version 3.5.0 (downloaded here: https://www.adventuregamestudio.co.uk/forums/index.php?topic=47264.msg636631416#msg636631416).
In the meantime, I learned how to compile the game on Mac with the latest version of AGS starting from the source code. I will post a step-by-step guide soon, it's quite easy in the end.
Emabolo, wow, such a guide sounds great. Looking forward to it!
This is a small guide for all the people that would like to compile AGS and create a
macOS version of their AGS game starting from scratch. I'm posting this guide here, but if you think it should be somewhere else, let me know.
Consider that the easiest solution to create a mac OS version of your game is to use the pre-made wrapper created by TheVolumeRemote: https://www.adventuregamestudio.co.uk/forums/index.php?topic=47264.msg636631416#msg636631416
With this wrapper, you can simply copy your game assets into the Resources folder, and it's done.
But if you want, you can do it from scratch following the small guide below. The main advantage is that as soon as there is a new version of AGS, e.g., 3.5.1.8, you can build your game with the latest version of the engine without waiting for the new wrapper.
It's pretty easy if you have some familiarity with the Mac terminal. And you don't need to install 50GB of XCode, just CMake. See details in the spoiler below.
Spoiler
PRE-REQUISITES
Download and Install CMake
Download CMake from https://cmake.org/download/ - Choose "macOS 10.13 or later"
Copy the app to your Applications folder. Launch it.
Now open the Mac Terminal and type:
PATH="/Applications/CMake.app/Contents/bin":"$PATH"
Download and Install Xcode Command Line Tools
(not Xcode, just the command line tools).
Go here: https://developer.apple.com/download/all/?q=command%20line and choose a version, for example "Command Line Tools for Xcode 12.5.1"
Download the dmg and install it (unless you already have it, of course).
- Download a free app called Image2Icon
You will find it here https://img2icnsapp.com or on the Mac App Store.
NOW BUILD THE AGS APP:
- Download the latest version of the AGS source code.
Go here: https://github.com/adventuregamestudio/ags/releases
and download the file "Source Code (zip)"
Unzip the archive somewhere (for example /Users/yourname/src/)
You will obtain a folder like this:
/Users/yourname/src/ags-v.3.5.1.8
- Copy the game resources:
Delete all the files inside this folder "/Users/yourname/src/ags-v.3.5.1.8/OSX/Resources/"
Go to the Compiled/Data directory of your AGS game, and copy all the files you find there, to the folder you have emptied "/Users/yourname/src/ags-v.3.5.1.8/OSX/Resources/"
Create the game icon
Open Image2Icon, drag and drop a square image representing your game icon into the app, and choose "Export -> ICNS.
Call the file "ags.icns". Copy this file into "/Users/yourname/src/ags-v.3.5.1.8/OSX/Resources/"
- Build the game
in the terminal, enter the OSX folder:
"cd /Users/yourname/src/ags-v.3.5.1.8/OSX/"
then type:
cmake -DCMAKE_BUILD_TYPE=Release ..
this will take a while. Once it's done, type:
make
Final steps
If everything went well, you will have in the OSX folder a new app, called AGS.app
rename it with "mv AGS.app MyGame.app" (where "MyGame" is the name of your game, better not to use spaces)
- Enter MyGame.app/Contents/ and search for a file called Info.plist.
Edit it with a text editor, like Sublime text, and change a few lines,
CFBundleIdentifier = invent a unique id, for example: com.myname.mygame
CFBundleName = My Game
you can also change CFBundleVersion to add your game version and NSHumanReadableCopyright to specify the copyright.
- Try the game.
The game app (eg. MyGame.app) is inside the OSX folder. I suggest you zip it so that you are sure you will always keep the original version.
Then drag and drop MyGame.app somewhere else (eg. Desktop).
Double click the app to launch it.
DISTRIBUTING THE APPYou can simply upload to itch.io the ZIP file you created before.
Unfortunately, unless you are enrolled in the Apple Developer Program (99 eur/year) you won't be able to sign the app. This means when you distribute your game, people will receive several warnings.
You should instruct your users to do this:
- download the zip file
- extract the zip file and move the .app to Applications
- right-click the game icon in Applications and select Open. It will open a window with some buttons. If there is no "open" button, close the window, don't do anything.
- right click again on the game icon. This time you will see an open button.
In case I decide to pay for the Apple Developer program I will let you know how to sign the app :)
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!
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?
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 (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?
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.
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.
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. :/
There's a GUI?
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.
I installed CMake through Homebrew (http://brew.sh) 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 (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).
About M1, the command line terminal that's native, what output you get from uname -a ?
If I run uname -a I get the following result:
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
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:
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
file ./ags
Also, the CMake version would be useful...
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)
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:
./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. :-)
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.
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.
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.
Very sure.
https://github.com/renpy/renpy/issues/1326
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?
@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.
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.
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.
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!
@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...
The wrapper is the one TheVolumeRemote provided. The dylibs are present in the resource folder with the .ags file.
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/ .
Hi Dualnames, I've got a Mac running Big Sur 11.4, so happy to help out if you send me the files?
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:
QuoteJust 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?
I got it working guys!
Oooh, good news, congrats! Was it something MacOS-port related? I'm curious to hear what the issue was in the end?
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.
otool -L dylibnamehereorlocationifnotonthefolderthedylibisat
Will show dependencies.
install_name_tool -change old new file
Will change a dependency.
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?
Quote from: Dualnames on Thu 19/08/2021 04:19:33
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.
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.
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)
ARM native can only be directly uploaded to the APP store not gog, epic or steam.
Quote from: Dualnames on Thu 19/08/2021 07:44:20
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.
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.
Quote from: eri0o on Sat 03/07/2021 03:39:41
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:
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
file ./ags
Also, the CMake version would be useful...
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:
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!
@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?
Quote from: Dualnames on Thu 23/09/2021 10:45:35
I've been unable to compile it even in x86_64.
Could you post errors you are getting?
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.
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?
I watched this video on YouTube which seems to indicate there's development happening about this? I don't personally use the Steam AGS plugin so don't know how that would work, sorry!
https://www.youtube.com/watch?v=3AxkhWhSWDI&t=95s (https://www.youtube.com/watch?v=3AxkhWhSWDI&t=95s)
There is as of two days ago. The only thing that's troubling me is compiling an ags steam universal library lol.
(https://i.ibb.co/0MSXzgC/image.png)
Stopped the steam related issues. Now it's giving me agsclient related issues.
Took a while but i resolved it.
Hi All,
It took me a bit of messing about but I have successfully compiled the latest stable and latest alpha versions of the AGS MacOS Engine.
I have put the precompiled binaries and instructions on how I compiled them on my website so others can hopefully either just download the binaries or follow the instructions to compile for themselves.
I have videos and text instructions on my website https://anthonyirwin.com/adventure-game-studio-ags-macos-build/
Hope this helps people trying to get ags engine up and running on their mac.
Anthony
Quote from: anthonyirwin82 on Wed 02/02/2022 12:36:46
I have videos and text instructions on my website https://anthonyirwin.com/adventure-game-studio-ags-macos-build/
Hello.
There is an outdated information in these instructions, related to using game files:
You do not have to use
Windows files, but use files from Compiled/Data instead: these are raw game data without windows engine attached.
Renaming file to ac2game.dat is also not necessary. Older version of the mac port was searching for that file explicitly. Now it should be accepting any filename, iirc, but the convention is to have file called gamename.ags.
This is mentioned in the 3.5.1 readme here:
https://github.com/adventuregamestudio/ags/blob/release-3.5.1/OSX/README.md
Quote from: anthonyirwin82 on Wed 02/02/2022 12:36:46
I have videos and text instructions on my website https://anthonyirwin.com/adventure-game-studio-ags-macos-build/
The information and instructions above are absolutely fine, but here's also some of my own things I've noticed while working on the Steam/GOG Mac version of Zniw Adventure:
* if you wish to quickly (re)build your game *.app bundle, you can use the following script in the build directory with the CMakeList.txt file:
export BUILD=release
mkdir build_$BUILD
cd build_$BUILD
cmake -DCMAKE_BUILD_TYPE=$BUILD ..
make* to have a unique icon of your app bundle, drop an
"ags.icns" Mac icon file into the "Resources" folder of your bundle. You can set both the
version, name, main executable, and the icon of your bundle by editing the keys of the Info.plist file inside your *.app:
(https://i.imgur.com/kJUKuD0.png)
* if you actually wish to sign, notarize and staple your game (in case Apple Thanos-snaps all unsigned apps from existence one day, just like they completely dropped 32-bit apps support), you will need a valid Apple dev ID:
codesign --force -v --sign "Your developer ID (your provider ID)" --options runtime --entitlements Entitlements.plist GameName.app
ditto -c -k --sequesterRsrc --keepParent *app yourGame.zip
xcrun altool --notarize-app --primary-bundle-id "your.bundle.id" --username your@email.com --password AppleOneTimePasswordHere --asc-provider YourProviderID --file yourGame.zipAfter the notarization's done, you can verify your game, and staple it for offline use:
codesign --verify --verbose=4 YourGame.app
spctl --verbose=4 --assess --type execute YourGame.app
spctl -a -v YourGame.app
xcrun stapler staple -v YourGame.app
stapler validate YourGame.app
Additionally, if you do any changes to your game bundle (like a little patch, update, even a small change in the Resources directory), you
need to re-sign and re-notarize it again.
* if you wish to locally test your debug build with Steam/GOG dylibs, you need proper entitlements in your Entitlements.plist file (the one you use to sign the app), otherwise your game will crash and burn while trying to access Galaxy/Steam shared libs:
(https://i.imgur.com/wCVVKc7.png)
Thanks to everyone that provided extra details on my post I have updated the website info.
I will save the code signing information so when I get a developer certificate for building apps and code signing I will have the instructions.
I have built the latest versions of ags engine.
3.5.1-patch8 is a universal binary but I have only tested it on an intel machine.
3.6.0-alpha18 is an intel binary. I got errors compiling sdl2 when trying to do a universal build.
The download links are below:
https://anthonyirwin.com/wp-content/uploads/ags-macos-builds/AGS-3.5.1-patch8.app.zip
https://anthonyirwin.com/wp-content/uploads/ags-macos-builds/AGS-3.6.0-alpha18.app.zip
Instructions on how to use this are at https://anthonyirwin.com/adventure-game-studio-ags-macos-build/
For doing the universal build I just used the settings that Xcode gave for automatically updating the build target architectures instead of using what was in the make files provided by ags.
Quote from: anthonyirwin82 on Tue 08/02/2022 03:03:11
3.6.0-alpha18 is an intel binary. I got errors compiling sdl2 when trying to do a universal build.
Could you mention which errors did you get? Maybe we should look into this.
The errors occurred on the SLD_cpuinfo.h file.
I am not sure how to export the build errors or find a text version that I can copy and paste into a file.
I have included a screenshot of the errors below.
(https://anthonyirwin.com/wp-content/uploads/ags-macos-builds/sdl2-build-errors.png)
Can you use the regular makefile generator and build with make?
I checked sdl2 source code and no changes suggest changes in these particular flags that are specifically MacOS related as far as I can tell.
To clarify, if this is a bug and not something wrong in the environment it needs to be reported upstream, but I was able to load a Monterrey computer and build with CMake+make, which is why I asked.
I want to add what CrashPL (https://www.adventuregamestudio.co.uk/forums/index.php?topic=47264.msg636643289#msg636643289) describes up to before the codesign+notarization directly in AGS Editor at some point soon, by I lack an actual Mac computer with M1 to test (they are really really expensive in my country). The codesign+notarization then is left as an exercise for the reader - I mean, we probably could make a tool to just do those commands, erh, maybe.
Hi, is it possible to create a mac version of my game on Windows?
Edit: Forget the question. My friend will use Wine.
Hey, if some macOS dev keeps tabs with here, I am updating the Xcode project files for macOS in this pull request here (https://github.com/adventuregamestudio/ags/pull/1807).
It would be really useful if someone could run this in their machine and check if the steps added in README make sense and if they could review my changes as I am not familiar with Xcode. Thanks!
I added also instructions on how to build AGS using only the Makefile and handling dependencies through Homebrew. I adjusted the Makefile. This is intended only for locally running games, and not for porting (use either the CMake or Xcode build systems for that).
Updated the macOS port README here (https://github.com/adventuregamestudio/ags/tree/master/OSX).
I noticed in the previous posts on the signing topic it mentions the altool, but it's been deprecated in favour of the notarytool - more info in here (https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow). I may have an additional update to the macOS instructions to include a minimal guide on signing and notarization for app releases.
Hello everyone,
Thanks a lot to Anthony Irwin for building this Mac version, from what I saw so far, it work very well.
I just have a little problem with a game (Maniac Mansion Deluxe) that use AGSflashlight.dll, the game works fine except in rooms that should be dark.
Is anyone aware of a solution to fix that ?
Is it even possible without modifying the game ?
As LucasFanGames seems to not exist anymore.
I don't think so. I believe someone would have to make a Mac/Linux version of the plugin, and even then you might have to rebuild the game to link it properly with the new plugin.
Quote from: Snarky on Wed 14/06/2023 22:14:59I don't think so. I believe someone would have to make a Mac/Linux version of the plugin, and even then you might have to rebuild the game to link it properly with the new plugin.
Flashlight plugin have been rewritten many years ago by JJS, as a part of the initial engine ports. It is present in our repository: https://github.com/adventuregamestudio/ags/tree/master/Plugins
It's kept 100% script compatible, because it's used to run old games. It may not be 100% precise in behavior though, and I've never tested it myself.
The plugin may either be built standalone (*.dylib), or integrated with the engine if particular compilation flag is used (BUILTIN_PLUGINS).
It's possible to find out whether plugin is used at all at runtime, if you run the engine with "--log-stdout=main:all", it will print its attempt to hook up plugins or use built-in functions.
@aKro can you link the specific game you are having issue, with a way to download it
Thank you for your quick answers.
You can download my Mac version here :
http://hahd.fr/sub/ManiacMansionDeluxe.app.zip (http://hahd.fr/sub/ManiacMansionDeluxe.app.zip)
And the Windows version here :
https://archive.org/details/Maniac_Mansion_Deluxe_14 (https://archive.org/details/Maniac_Mansion_Deluxe_14)
Rooms that should be dark are for example, on the second floor, first door after passing thru the reinforced door or the basement.
Hi everybody,
I don't want to be accused of digging up this thread, what seems to be frowned upon on this forum but is it definitively impossible to fix Maniac Mansion Deluxe AGSflashlight.dll on Mac without rebuilding ?
Anyhow, thanks to everyone who looked at this problem.
And, sorry eri0o but because of your signature, one more is waiting for Future Flashback ;)
Quote from: aKro on Mon 18/09/2023 12:54:45I don't want to be accused of digging up this thread, what seems to be frowned upon on this forum but is it definitively impossible to fix Maniac Mansion Deluxe AGSflashlight.dll on Mac without rebuilding ?
Please elaborate, fix how?
AGSflashlight.dll itself cannot be used as is on Mac, because that's a Windows dynamic library, so it won't work ever without Windows emulation (like a virtual machine).
Therefore, the solution is to either:
- build a Mac library (*.dylib) with the same behavior
- build an engine with this plugin built-in.
@aKro I think our default is to include the built-in plugins, can you try the macOS binaries here: https://github.com/adventuregamestudio/ags/actions/runs/6209696836 ?
I realized I need to update the Xcode project again on master after miniz has been added, I will do a PR for it later.
---
I think if we assume we only support whatever is the latest version of macOS we could provide macOS binaries on release. The binary running in non-latest macOS would be limited by Xcode and non-specified by us in this case.
Quote from: aKro on Mon 18/09/2023 12:54:45I don't want to be accused of digging up this thread, what seems to be frowned upon on this forum but is it definitively impossible to fix Maniac Mansion Deluxe AGSflashlight.dll on Mac without rebuilding ?
Hello, sorry for the delayed answer, but I was not certain whether this problem is related to missing plugin or not.
Lately I've been testing Maniac Mansion Deluxe on Windows and found that Flashlight plugin does not work correctly either. It appeared that certain thing changed in the engine, breaking compatibility between it and this plugin.
It's now fixed in the latest 3.6.0 patch:
https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-0-patch-8/
(also in the latest 3.6.1 RC release)
On the topic of this thread awhole. I believe it should be closed (locked), and a new one started, with an up-to-date explanation of how to use mac port, and how to deploy your game for it (same as done with few other port-related threads).
This thread, and iOS, and the two ones remaining which contain very outdated information.
I can write something to kickstart a new topic. I guess the outline would be something like
- link to macOS Readme in main repository
- basic explanation on building from source but pointing to readme for most updated info
- a small and short overview on what an dir.app is and it's internal dirs and how the plist XML works, probably linking some Apple documentation.
- the AGS engine runtime short explanation and how to put it in the dir and point it as the startup thing in the plist
- marking things as executable (chmod) in macOS
- signing and notarization
- app icon
If anyone have any comments on this general outline, would want more detail in something or there's anything missing, please comment it here. I plan to write up on Sunday.
Building from Editor is the thing that interests users most. I think the post should first of all overview the situation, and explain that you cannot build for Mac from the Editor at the moment, so either you need to build Mac engine yourself on Mac machine or VM using Xcode, or get an engine built by someone else (that matches your game).
If there are two different routes, like, with embedding game files in some container, and just placing them near engine by hand, then both options should be explained.
We may update the post later if situation changes.
Adventure Game Studio has a macOS port. In this topic I will try to explain a bit of it. Feel free to ask to clarify topics.
If you want to build AGS engine source code, go to the macOS README (https://github.com/adventuregamestudio/ags/tree/master/OSX) in the main repository. If you have questions about it feel free to ask here.
If you want to package your game in a bundle so others can play on macOS, than read on as I will try to unpack and explain things here.
Application Bundle (the mygame.app)In macOS, a bundle is a directory with a standardized hierarchical structure that holds executable and resources.
There are other bundle types, but when delivering a macOS game we will want to build an Application Bundle (https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW13).
At minimum, your ags game application bundle will look like this
📁 MyGame.app/
📁 Contents/
📜 Info.plist
📁 MacOS/
☕ ags
📁 Resources/
📦 mygame.agsSo at top level we have a directory that has a name that ends in
.app. It also contains a runtime-configuration file called the information property list (
Info.plist), which is a plain-text xml file.
The
Info.plist will contain many entries, and the
CFBundleExecutable will point to the
☕ ags runtime, which is a binary file of the engine. The
☕ ags runtime must be marked executable (using
chmod +x ags), this isn't necessary, unless you made the Application Bundle in Windows and later transferred it to macOS. This means that you need to pack your Application Bundle using dmg, tar.gz or some method that preserves the executable bit - if you are delivering through a game store, some game stores like Steam will take care of this for you so you don't have to do anything, check their documentation.
Signing and NotarizationIf you try to distribute your macOS game to anyone, they will need to allow that specific game to execute in their computer through a few menu screens. This may be problematic. Ideally you should Sign and Notarize your game before distributing. You will need an Apple developer account for this.
imagine there's a text here that explains how to do this...
ok, tried to give a short write up of the things I had in my mind...
QuoteI think the post should first of all overview the situation, and explain that you cannot build for Mac from the Editor at the moment
Ahn, the steps for that are basically
- Release macOS binaries: A person noted it won't work for all macOS in existence, specially old versions, but I don't think this is relevant, it should work from the latest version to the old version supported by Xcode, which usually goes down to 6 versions. Yeah it moves fast but macOS updates are free, you get one per year. Building for older versions is way too much hassle as you will be working against Apple. This is the sole reason I haven't put macOS binaries in the release. If others agree with me this is ok for Apple users, we can release those.
- Create a macOS AGS Editor bundle: this is essentially the minimal thing that the editor needs to build macOS releases, I think a directory with the ags macOS binary is the only thing here. This directory could be the same place people will throw their plugins.
- Add macOS Editor Build Target: In my mind this would create a directory as an Application Bundle as described above, placing the game files under Resources and the macOS runtime and plugins in MacOS. We could also place plugins in the macOS standard PlugIns directory under Contents. Both should work fine (without code changes).
- Executable bit, notarization and signing: like the Linux build, the executable bit in ags runtime is an issue. But even if we solve it, I believe notarization and signing can only be done in a macOS computer, so the produced Application Bundle would not be usable until someone took it and adjusted it. It's also important that signing and notarization requires an Apple Developer account.
Quote from: eri0o on Sun 21/01/2024 13:19:20QuoteI think the post should first of all overview the situation, and explain that you cannot build for Mac from the Editor at the moment
Ahn, the steps for that are basically
I meant to have a simple paragraph at the top of the post, literally explaining the situation that:
AGS Editor cannot prepare game for Mac automatically at the moment. This may be changed in the future, until then this has to be done manually. Your options are:
1. Build engine yourself;
2. Use someone elses built engine;
3 ....?
And then go on with explaining each variant.
This is to make the situation clear for end-users from the start.
I think that's a somewhat negative way of putting it, Crimson Wizard.
The key thing to get across is that it's easy to make a Mac version of your game, even if it takes a couple of manual steps: you just need a generic, "blank" app package (with a pre-built version of the engine), and then drop the files created when you build the game into that.
For 90% of people it makes sense to use a pre-built app package rather than the more complicated process of building the engine for Mac, so that should be presented as option 1. (I've earlier argued that there should be official Mac engine builds hosted on github, which I still think is a good idea. In fact, why not also distribute them with the IDE? Then the only thing missing from automatically building for Mac is dropping the files into a copy of the archive/package on build.)
I think maybe as a first thing, if the macOS binary is added to releases, we could put a topic for people to test the thing. My only doubt is how many would test it as I have no clue how many people have a current macOS machine available.
Anyway, I didn't read CW as being negative, more as being practical. Just to lock this and put a new topic ASAP.
If someone has a macOS machine and would be willing to test things, message me or leave a message here and I will see what can be done. Also if people could try to parse the thing I wrote about Application Bundle, it would be nice, the concept of dir+info.plist is simple but for some reason looks mystical to a lot of people.
Well, wording may be changed to a more affirmative of course, but my only intent was to make it clear that, unlike other builds, you have to do certain things by hand.
I have a ready Mac VM (I think the version is called Catalina), but I am not a Mac user, and don't know much about it. I only tested changing game file in a precreated bundle and running the engine so far.