A thread to discuss migration to Allegro 4.4.3, and GME 0.6.
I'll add more later.
Printable View
A thread to discuss migration to Allegro 4.4.3, and GME 0.6.
I'll add more later.
Here are the main questions I have about the switch:
1. What are the main API changes in version 4.4? What changes have to be made to the ZC/ZQ code itself to get it to work with 4.4 (I've been told it's just a dozen lines or so)?
2. What is needed to get the sound libraries to work with allegro 4.4? Will the existing libraries Just Work when linked against 4.4?
3. What is the problem with GME? My understanding is that it was a library independent of Allegro?
To get allegro 4.4 working, I just needed to write replacements for the functions that were hacked onto ZC's version of allegro 4.2:
https://github.com/gwx/ZeldaClassic/...leg_compat.cpp
https://github.com/gwx/ZeldaClassic/...alleg_compat.h
I stuck the include in zc_alleg.h and it worked fine.
Also I needed to add this line here or zquest would corrupt ag.cfg:
https://github.com/gwx/ZeldaClassic/...186f20cf93125a
Quick question: Does your allegro 4.4 build fix the alt-tab fullscreen crash, or any other fullscreen bug for that matter?
I'm running on linux and haven't had any of those issues in the first place. I gave the files to Zoria, and he mentioned something of that nature, though.
Edit: With regards to the sound, I appear to be having the same issue as over here: http://www.armageddongames.net/showt...th-allegro-cfg
I got the same issue when I tried a 4.2 version I found by searching through old debian packages, so I think it's an artifact of how allegro was built. That post is from a while ago. Maybe you guys already fixed it somehow, and remember what to do?
From the linked thread it sounds like the problem is with ALSA (which does get used for me also, when I build Allegro using default settings on Ubuntu). It doesn't seem to be related to 4.2 vs 4.4.
Good question. I think ZoriaRPG uses Windows? Does alt-tabbing out of fullscreen work for you?Quote:
Quick question: Does your allegro 4.4 build fix the alt-tab fullscreen crash, or any other fullscreen bug for that matter?
I'm still interested in the answer to this question. Will the existing sound libraries link against 4.4 unmodified? What is the issue with GME?Quote:
2. What is needed to get the sound libraries to work with allegro 4.4? Will the existing libraries Just Work when linked against 4.4?
The Allegro 4.4 build does fix most of the fullscreen bugs on Win 10. Fullscreen opens with no complaints. If you alt+tab, it doesn't crash, but when you alt+tab back, the graphics are squished, and you need to exit and reenter fullscreen to fix it. That could be from one of the ag.cfg settings, or something else though.Quote:
Originally Posted by Gleeok
Other than that, and the issue with me using dynamic libs, it works in fullscreen seemingly flawlessly, which is why I asked others to test it, but apparently I forgot to static link the bastards, which means starting over with allegro and the libs, and rebuilding them, just to see if that is the cause of the audio crash, which from what I can tell, stems from NSFs.
Now that the repositories are sorted out, I'm interested in making this a top priority, especially if as you say it fixes the Windows crash issues.
I'm still unclear on the relationship between the sound libraries and Allegro 4.4. Is there a compatibility issue with GME? Or is that an unrelated topic?
I am (figuratively) literally scratching my head as to why a packfile routine would affect a config file write. All packfile_password("") should do is effectively set the global packfile password to a zero-length string. ....?Quote:
Originally Posted by Grayswandir
[edit] Oh, right allegro 4.4. That must be a bug they introduced since 4.2. Sneaky little buggers.
Maybe they changed the config file to use the global packfile password (if set)?
EDIT: This does seem to be the case. flush_config uses pack_fopen to do its file IO, which inherits the current global packfile password at the time the file is opened.
So I managed to get ZC to compile against Allegro 4.4 and run (https://github.com/ArmageddonGames/Z...ree/DD/alleg44). The good news is that ZoriaRPG is correct; the fullscreen crash is gone, though there is screen corruption once you alt-tab back. The fixes he lists also are indeed all that is needed to get the existing code to compile, though unfortuantely getting Allegro 4.4 to compile out of the box is a somewhat painful process (some of the stdint fixes had to be put back into the Allegro headers, etc). Allegro 4.4 also requires DirectX, which has to be installed before you can compile the library, and is incorrectly configured to try to use the DirectDraw, which has been removed from DirectX.
I'll grabthat package and the binaries and do some further tests. Just saw that the bins are in fact, there.Quote:
Originally Posted by DarkDragon
I'm wondering if the distortion is an artefact of stuff that has been plugged in to 'fix' 'bugs'. There was a lot of ag42 workaround silliness in the past, rather than lib udating, and no-one wanted to believe me when I said (over a year ago now) that many of the allegro issues were sorted on the library side.
I need to know what in ZC/ZQ is used to try to remedy the other keypress issues, loss of focus, and such; as I suspect those issues are likely also resolved, but that our 'fixes' will prevent noticing this.
They should already be in the DD/alleg44 branch of the repository. Libs are in /libs/win32* and dlls in /bin/win32.
Aye, I saw them about 10 seconds after I posted, so I went in and edited the post while you ninja'd me.Quote:
Originally Posted by DarkDragon
I'm guessing the underlying fullscreen issue never got fixed before they dropped allegro4 support in lieu of allegro5; they just patched the crash.
I honestly don't remember how the keyboard bugs got fixed. That was a very, very long time ago, and there were more than one of them. ;) What is the specific issue?
Quote:
Originally Posted by Gleeok
When ZC has been running for a while, it ignores keypresses that are not bound to buttons. For example, if you press F6, the Yes/No dialogue requires mouse input... Pressing 'Y' fails to work. Likewise ZQuest has had similar issues with hotkeys when it runs for a while.
In 2.50.2 I noticed a separate issues, where keys become "stuck": the left key keeps repeating, for instance, after I've let go of the key. This happens rarely (once per hour, maybe). Has anyone else noticed this? Is it related to Allegro's key bug, or is it internal to our code?
Looking into things more, it seems that when fullscreen programs are sent to the background, all video memory is purged; it wouldn't surprise me at all if the problem is on our end, where we're not properly reallocating and populating the video buffers when we get focus back.Quote:
Originally Posted by Gleeok
I'll look into the problem in detail once I've got the Allegro 4.4 transition squared away.
I looked more into the full screen crash bug, and there are two separate issues:
- a race condition inside Allegro that can it to crash outright;
- Allegro does not restore the screen buffer to the proper color depth, for reasons I don't fully understand.
I tried replacing the system direct draw library with the version at https://github.com/narzoul/DDrawCompat/issues, but while it fixed the alt-tab issue, it garbles NSF playback. Go figure.
One possible fix is to switch to windowed mode before alt-tabbing on windows, and the restore full screen mode when switching back. I will test if this works.
@Gleeok , does the code in branch DD/alleg44 compile for you, and in particular, does it link against the precompiled Allegro 4.4 libraries?
I'm wondering if it will Just Work, or if your compiler will complain since the libraries were compiled on my newer version of Windows and MSVC.
Ooooh. So DirectDraw caused audio issues for you with NSFs, did it? That seems rather similar to what I ran into, which is a reason that I had advised upping our GME libs in the process, however I did not relate it to DX8--I related it to ag 4.4. Did the updated DirectX8 SDK fix both of the above graphical issues?Quote:
Originally Posted by DarkDragon
Have you looked into GME 0.6 yet? I'm uncertain how 'drop-in' friendly it will be, but I think it's something that we essentially need to do. I'm not so keen on shifting to another sound lib, as GME supports so many formats, and is rather accurate at replicating the system sounds for its supported platforms. The sad fact is that ZC is running on libs that are out of date, not only in perspective of modern programmes, but also heavily out-of-date within their own branches.
I can only imagine how many issues we could have resolved by fixing that long ago.
I haven't looked at GME. You think a newer version will fix some of the audio problems? I haven't experienced any artifacts on Windows 10, but I get no MIDIs on Ubuntu (even after trying Saffith's suggestion.)
I fixed the problem by 1) patching Allegro's handling of focus switching and 2) modifying the ZC code to reset the screen state whenever it is running in full screen mode on windows and receives focus.
The problem is that Microsoft dropped support of DirectDraw ages ago, so that ddraw.lib isn't even in the DirectX SDK. Instead when ZC uses direct draw, it gets old versions of the library included in Windows only for legacy programs, filtered through God knows how many layers of compatibility layers.
Oh, you didn't mean the problem I thought you meant, I guess. You have samplesoundset/patches.dat in place, right?Quote:
Originally Posted by DarkDragon
I'm pretty sure the MIDI handling hasn't changed for 4.4.
MIDI handling should be the same, although I know that they did internalise some audio stuff (alogg, being one thing that is now in-built).Quote:
Originally Posted by Saffith
Quote:
Originally Posted by DarkDragon
It very well may resolve the audio issues, but I have not done enough research to give any definitive answer.
Change Log for GME through 0.6.1
Here's the latest repo and info:
https://bitbucket.org/mpyne/game-music-emu/wiki/Home
https://bitbucket.org/mpyne/game-music-emu/downloads
Note that Blargg is not the lead developer these days, so his own website is also very outdated. Use the above links for the latest stuff, if you want to compare it, and check any of the logs.
Older changes, through v0.5.2 were maintained here: http://www.slack.net/~ant/libs/audio.html
For reference, we use 0.2.0 at present.
If you guys are feeling confident about allegro4.4 then what about changing the CreateWindowEx() function to allow applications (eg; ZC not ZQ) to set window resizing so users that have fulscreen problems can just maximize ZC? I already added the part that lets the ZC window be any resolution > 320x240 so it /should be only 2 more steps... I think...
And in wndprocCode:if (resizable)
win32Style |= WS_THICKFRAME | WS_MAXIMIZEBOX;
Code:// Resize event
case WM_SIZE :
{
if(wParam != SIZE_MINIMIZED)
{
windowRect ={ 0, 0, LOWORD(lParam), HIWORD(lParam) };
}
break;
}
I can give it a try.
Doesn't Allegro need to somewhere destroy and recreate the DirectDraw surface after resizing, though?
Please be certain that anything that you want to do to accomplish this is more than yet-another-allegro-hack. I'm not sold on a maximised display working properly, or even being something that enough users want, to justify the potential problems. Mostly, because the entire reason that the fullscreen crowd uses fullscreen, is to avoid looking at visual distractions, such as the menu bar.Quote:
Originally Posted by Gleeok
If we do this sort of thing, we should render a backdrop bitmap (black), and render the zc bitmap to it, scaling until one of the dimensions strikes the edge of the background bitmap. Thus, preserving the aspect ratio of the main ZC screen, whilst scaling it up and providing a border.
That way, you don't need to worry about creating and destroying the main system bitmap, too. Only the main window bitmap need be regenerated, and the playfield can be scaled to it. Essentially, make this an option that only works with the new double-blitting.
Does the new double-blitting work for you in fullscreen? If so, there may not be a need for a maximized-window workaround.
Yep, you're right. I knew I was forgetting something.Quote:
Originally Posted by DarkDragon
It absolutely does. No more colour issues, no notable slowdown yet. I need to try some heavily scripted quests, and enable some cheats, to see if anything bad happens.Quote:
Originally Posted by DarkDragon
My guess, is that the hardware bitmap as 8--bit simply isn't possible with modern GPUs. The colour table was probably being corrupted, by allegro, trying to write an 8-bit depth plane bitmap in ahrdware, versus a native bitmap in hardware, and a converted memory blit.
We need to try this on Linux and MaxOSX builds--and aye, I will get 'round to those. I need to pick up one or two Apple laptops, and then see what issues we have. Unless @Saffith wants to share his VM image, so that I can run everything from one system. I'll buy some tools to ensure that we pack our files in a 'legal' way for 10.12, too.
grayswandir has tested on Linux and it seems to work for him as well.