ThomasAdam wrote:Having already started to look into this, it's not so much a port, as it is a complete rewrite. That's important to note, because there's very few similarities between Allegro4 and Allegro5.
That said, what interests me about Allegro5 is the backend parts. On Windows, there's the use of its native GUI stuff, and on !Windows, you can use GTK. QT is questionable at this point; B-em is written in C, not C++.
It is per this example: https://github.com/liballeg/allegro5/bl ... /ex_menu.c -- that the possibilities of having a non-modal menu are realised, which would then be platform-agnostic, AIUI.
But, getting to that point isn't a small amount of work. I should really push what I have to Github; I've been a little busy with $LIFE -- sorry, chaps. There are other changes with Allegro5 that I've not looked into yet, but from what I've been seeing thus far, I think there's sill enough of the things we're making use in Allegro4 that are available in Allegro5 -- and by that, I mean all of the video rendering, etc.
I am quoting the whole of Thomas's post because it was originally in another thread.
On the question of how different they are I did find https://wiki.allegro.cc/index.php?title ... m_A4_to_A5.
The Allegro 4 main loop example we have in B-Em - in the OS-specific module there is a loop that calls main_run(). That checks fcount to see if a frame update is due and if so runs m6502_exec and a bunch of other stuff and, if not, does a wait(1). So, to implement the change to event-driven isn't it a case of putting a call to main_run(), with the checking if fcount removed, as the action in response to an event of type ALLEGRO_EVENT_TIMER?
The hairy piece of code is video_poll in video.c so the big thing is whether the format of Allegro bitmaps have changed in a way that means this would have to be changed much. Certainly this is the module in B-Em I least understand.
Did you discover any other differences? I assume linux-gui.c would need to be updated too.