Upgrade to allegro 5 #774
Merged
Upgrade to allegro 5 #774
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
connorjclark
force-pushed
the
allegro5
branch
3 times, most recently
from
78c9a97 to
2a00242
Compare
|
Very cool! The Allegro Legacy API emulation as a workaround for update difficulties is some ingenious lateral thinking and a great start to a ZC project so ambitious it was long called impossible. I hope you succeed! How much easier would your work make porting ZC to a libretro core for use in RetroArch and other programs? |
connorjclark
force-pushed
the
allegro5
branch
3 times, most recently
from
4331e56 to
d61115d
Compare
Learned that allegro 5 provides double buffering by design (al_flip_display manages a front and back buffer). And that apparently doing "triple buffering" manually is no longer a good idea with modern graphics drivers. Practically, that means: - can remove various options controlling triple/double buffering - can delete TB_Handler - updatescr can delete the "page flipping" stuff it does, and just draw directly to the screen good resource on double/triple buffering: https://gamedev.stackexchange.com/questions/82318/what-problem-does-double-or-triple-buffering-solve-in-modern-games
a5 rendering thread is reading from it. Been looking at this bug today. Very nice that it happens for Levels cset (new gui), but not Main cset (old gui), which gave me something to compare against while debugging. It _seems_ only the new gui system will modify the hardware screen while the a5 rendering thread is trying to read from it (crash!), and the old gui doesn't, but I wasn't able to fully figure out why. One thing I did notice is that the new gui will send a MSG_DRAW event a lot more than the old one, which results in `draw_cset_proc` being called every frame vs just once. Perhaps the issue exists with the old gui too, but with this excessive re-rendering it's far more likely to happen in the new gui (without locks). I added a lock for the screen around the drawing in `dialog_proc` and it fixed the crash and flickering. but it'll still flicker when the mouse is held down (lol) and it is noticeable laggier than the old gui. Still needs more work, but at least it shouldn't crash now. Hopefully we can figure out a way to avoid all those extra MSG_DRAWs?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR replaces allegro 4 with allegro 5, without actually modifying any of the a4 api calls.
You can download a build here: release
The "Files Changed" tab is pretty rough because of the number of deletions and renames, and unfortunately GH is really laggy with so many changes. It's only the second commit that is super large (the one that replaces allegro for allegro-legacy folder), so a good option is to just view the diffs in two parts:
Benefits of this PR:
To do that, it uses Allegro Legacy, which was nearly a drop-in replacement (I discovered a few bugs which had to be fixed)
Allegro-Legacy emulates the a4 api layer with calls to a5, and seems to do it pretty well. Thanks @NewCreature!
Because Allegro-Legacy provides all the symbols that a4 did, the pre-built a4 addon libraries will continue to just work.
The Allegro-Legacy project is committed to source, and replaces the allegro folder (although you'll see a bunch of renames in the source history because allegro-legacy copied the a4 project).
The files in
allegro-legacy/src/a5are the "glue layer" between a4 and a5. In that folder, you will find code that start new threads for particular concerns, each with their own event queue.a5_system.cis what glues it all together: it creates an a4 System driver which implements the old a4 interfaces using new a5 stuff.Allegro5 is not commited directly to source, instead it is built from source as a CMake dependency.
I also included a simple allegro 5 example project for purposes of testing, perhaps it'll be useful for simply confirming your local dev environment works on a basic level.
What this PR does NOT do:
Some misc. stuff:
and wanted to verify that I was setting things up to make compiling with emscripten possible
From what I could tell, there is no impact on performace.