AGS engine Mac OS X port

[s_d]

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.

[Sslaxx]

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.

[Joseph DiPerla]

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.

[Crimson Wizard]

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.

[Joseph DiPerla]

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!

[JanetC]

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!

[s_d]

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!

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?

[Crimson Wizard]

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.

[s_d]

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.

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 

[Crimson Wizard]

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?

[s_d]

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!

[Crimson Wizard]

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.

[s_d]

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.

[Crimson Wizard]

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 .

[JanetC]

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?

[Joseph DiPerla]

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.

[Crimson Wizard]

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 .

[Joseph DiPerla]

Is JJS doing that or are the Allegro people going to do that?

[Crimson Wizard]

Is JJS doing that or are the Allegro people going to do that?

Wadjet Eye people do that.

[subspark]

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