Messages

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

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.

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.

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!

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 

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?

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.