Allegro 4.0 is showing its age, and upgrading to Allegro 5.0 may be almost as painful as switching to SDL. Has the feasibility of an SDL port already been assessed/discussed?
Printable View
Allegro 4.0 is showing its age, and upgrading to Allegro 5.0 may be almost as painful as switching to SDL. Has the feasibility of an SDL port already been assessed/discussed?
It's difficult. Allegro's pretty deeply ingrained.
The biggest issue is the GUI; ZQuest needs to be completely rewritten to remove it. It's not really amenable to any sort of wrapper code, and I haven't found an adequate replacement yet. ASEprite's my best hope at this point, but it will require upgrading to 4.4, and even that's a bit of a hassle. In the meantime, I've been writing a new GUI library from scratch. That's actually going fairly well, but it's still a long way from good enough.
We'd also need a new packfile handler. That's a pain, but it's doable; the format is documented, and it doesn't seem to be too complex.
Aside from that, there's mainly the fix class (which shouldn't be hard to separate out) and the obvious audio, video, and event stuff. The bitmap and palette stuff, in particular, is spread all over the place. It's all going to be a lot of work.
Is your GUI library also heavily reliant on Allegro? Or would it be easy to swap in an SDL back-end?
I'm actually building it with SDL, but it should be easy to swap in Allegro. Just a renderer class, a font class, input translation... I think that's everything, at least for now.
Saffith, what changes are there between allegro 4.2 and 4.4 that are such a hassle; or is it the internal ag4 mods?
I was actually planning on working on a migration to 4.4, as I had previously mentioned, but life got in the way, and other stalling occurred.
Allegro itself, and some of the libraries that depend on it. Build environments need updated, the makefile needs updated, everything needs tested to make sure stuff didn't break for whatever reason. It's not unreasonably difficult, but it's not trivial.
I had thought that a lot of the changes in the trunk were there to simplify the transition to another back-end (SDL, allegro5) at some point. It's a little sad that we're back at square one in the allegro4 department, but TBH I wasn't expecting much. This (and lack of time) is kind of why I decided to not contribute to any kind of major refactoring effort. :(
There's still this: https://github.com/kazzmir/allegro4-to-5 but it looks like it's not being worked on any longer.
What about using the GUI code from allegro4/gui.c. It's only one file and you don't have to change any of the GUI code in ZC or ZQ. Just fix the rendering. Maybe the same thing with the packfile code from allegro4 and fix up all the errors and dependencies?
I think the pack files are a red herring (worst case it is easy enough to write a small external library that is tasked with decoding packfiles). From glancing though the code, my biggest concern is that the GUI code (including the "jwin" stuff built on top of Allegro's GUI code) may rely on all manner of poorly-documented quirks inside of Allegro's graphics and IO code, so that it's not clear how easy it would be to wrap the Allegro API.
There's also the sound system, but at least somebody has already gone to the trouble of firewalling the sound code into its own library. I haven't checked carefully but I think SDL_mixer supports most of the features we currently have.
Not trivia, surely. I believe that we have some modifications to allegro in place too.Quote:
Originally Posted by Saffith
One thing I'll note is that our allegro version cannot call rotate_sprite_trans(). I've been running some tests, and it seems that ag4 has newer drawing functions that I plan to use, that aren't in our package ?!
I'm unsure if draw_bitmap_ex will work at present.