ludicrous_peridot wrote on 2023-11-26, 14:32:

That said - DMXOPL likely uses the same secondary instrument tricks of GENMIDI format as Vanilla Doom does, and implementing those is very difficult in current version of Allegro - well, at least for me 😉 . The result is that with DMX and MUSLib/MUSPlay more OPL chip channels are used than there are channels in the source MIDI, and there's nice polyphony to the sound which Allegro version is lacking.

I wonder if it might be possible to hook in APODMX into MBF somehow to achieve closer sound/music fidelity, or at least incorporate the code responsible for OPL music playback into the modified Allegro library?

Seeing as how gerwin has already used the Adlib driver from Duke Nukem 3D -- which I think is part of the Apogee Sound System as well (and APODMX is a DMX stand-in built upon the ASS) -- that would actually make some sense, it seems.

gerwin wrote on 2023-11-11, 19:13:

Originally MBF used the Allegro build-in Midi-to-FM conversion table. The table is found in "Allegro\src\djgpp\fm_instr.h". When Allegro is build into its library form, this table is hardcoded in there. For the MBF 2.04 project I changed the fm_instr.h table to the Doom1 values.
For example the first line:
{ 0x00, 0x30, 0x14, 0x00, 0xf0, 0xf1, 0xf3, 0xf4, 0x01, 0x01, 0x0a, 0, 0, 0 }, // Acoustic Grand

For the sake of curiosity, I have tried to copy instrument patches from DMXOPL 1.11 into fm_instr.h, by initially comparing your table to the original Doom GENMIDI values. It turns out that I have correctly deduced in my previous post that all values are exactly the same except "Note offset 1" and Modulator 1's "Key Scale Level" parameters (I'm giving here their names as defined by OPL3BankEditor), which are set to 0 for all instruments both in the fm_instr.h table and in MBF_D2GM.IBK.

However, and here's the weird part, when I converted the DMXOPL instruments to the fm_instr.h table while setting Note offset 1 and Key Scale Level for all of them to 0, I still got the resulting music sounding off, just like with my initial IBK conversion attempts. Yet if I used OPL3BankEditor to convert the GENMIDI lump from Doom to IBK and loaded it with MBF's setup, it would sound the same as the original internal sounds from your fm_instr.h table, suggesting that maybe these two values which are set to 0 are actually hardcoded elsewhere? I can think of no other explanation for this oddity ATM.

I mentioned the secondary instruments and more polyphony last time - and while I do not insist this is the main reason DMX and customized Allegro I posted sound different - I had this "horrible idea" of pulling this off with Allegro, and I tried to hear what comes out of it. So sharing the binary to see what you folks think about the updated sound.

I apologize for not providing an actual MBF build, but it would take me some time to backport the changes attached into the "motherport", so I cut the corners here a little bit.

With this build the differences are apparent in Doom II D_READ_M, but I think I can hear Doom intro jingle and D_E1M2 sound nicer... although I could be hearing things at this stage (which is also why I am sharing the EXE).

Also attaching MBF 2.0.4 build. Listening to that made me realize tunes stop sounding right after going for the second loop and on, so will check what's up with that.
EDIT: loops good now
EDIT-EDIT: removing obsolete EXE; check @MrFlibble 's post below.

Cool, thanks! Could you please share the code as well?

Here's my attempt to merge your Tartar code that you posted earlier with MBF code, but I've not tested the looping part. I also think that the music sounds a bit louder and more clear in the build that you posted above.

UPD 2023/12/08: Removed outdated build, newer versions are in posts below.

Yes, sure. I attached the *.C files I have updated for MBF above with the EXE, and both EXE-s and MIDI.C have been updated with the looping fix recently.
I have noticed a difference in volume between Tartar and MBF; don't know why it is there.

Updated Hexen port builds should also be up if you are interested. UPD: Talking about Hexen port, since source MIDI files have been published earlier this year that come from Kevin Schilder himself, and have the versions (supposedly) adjusted for FM playback, I also made a small add-on with those specific tunes to check out how they sound compared to GM versions included in the game.

ludicrous_peridot wrote on 2023-12-02, 08:20:

Yes, sure. I attached the *.C files I have updated for MBF above with the EXE, and both EXE-s and MIDI.C have been updated with the looping fix recently.
I have noticed a difference in volume between Tartar and MBF; don't know why it is there.

Thanks a lot!!!

ludicrous_peridot wrote on 2023-12-02, 08:20:

Updated Hexen port builds should also be up if you are interested.

That sounds cool!

Do you have any plans for Heretic?

Another important bug: in one of these versions (The DMX OPL version, I think), the Gamma Correction is glitched and doesn't lighten the screen. I thought it was a problem with how the program interfaces with my ATI All-In-Wonder Pro, but it doesn't work on my ATI Radeon 9000 either.

T-Squared wrote on 2023-12-08, 09:21:

Another important bug: in one of these versions (The DMX OPL version, I think), the Gamma Correction is glitched and doesn't lighten the screen.

I can confirm this after testing in DOSBox, but this only appears to happen with ludicrous_peridot's build and should not be actually related to the DMX OPL support. I built a modified MBF version to run Harmony Compatible with ludicrous_peridot's Allegro library and sound code (but otherwise it was from gerwin's codebase) and gamma correction works as intended.

Here's a build I just made, with the same sound code and Nash's libre helper dogs. Gamma correction works fine for me.

UPD: Please see the fixed version in the post below.

MrFlibble wrote on 2023-12-08, 16:07:

I can confirm this after testing in DOSBox, but this only appears to happen with ludicrous_peridot's build and should not be actually related to the DMX OPL support.

Guilty as charged 😀 I do not version my MBF code on the DOS drive, and previous modifications to tinker with Doom 1.1-style darker colors unintentionally leaked in. Thanks, @MrFlibble for posting an updated build.

EDIT: Actually, @MrFlibble, any chance you could check that you recent Allegro builds have been rebuilt with -DFM_SECONDARY compiler flag in the Makefile for Allegro? I listened to the MBF_OPL build uploaded and have a slight doubt about that.

ludicrous_peridot wrote on 2023-12-08, 23:53:

EDIT: Actually, @MrFlibble, any chance you could check that you recent Allegro builds have been rebuilt with -DFM_SECONDARY compiler flag in the Makefile for Allegro? I listened to the MBF_OPL build uploaded and have a slight doubt about that.

Yes, I did have the flag on. Duh, I had it on only for compiling MBF, not the library. My bad.

UPD: I recompiled the library and looks like it did the trick.

I'm keeping the rest of the original post for reference:

Awesome! I am removing the faulty gamma build then to avoid any further confusion.

@gerwin Hi! Would it be possible to maybe add SIGIL II support in and release an updated build with the latest changes? SIGIL II is designed to run as a 6th episode and currently the error when running it is that it can't find the 5th one.

Hey @Burrito78, apologies if this is an obvious thing to ask, but if you load both Sigil (ep 5) and then SIGIL II, could that fix the issue? Sigil II was build in a way to make it possible to load with Sigil 1 anyway, so this seems to be the creator's intention.

Also, if you are in a mood to explore other solutions, Tartar has support for Sigil and Sigil II, even though starting the game with current released requires a bit of command line typing.

ludicrous_peridot wrote on 2023-12-10, 11:59:

Hey @Burrito78, apologies if this is an obvious thing to ask, but if you load both Sigil (ep 5) and then SIGIL II, could that fix the issue? Sigil II was build in a way to make it possible to load with Sigil 1 anyway, so this seems to be the creator's intention.

Also, if you are in a mood to explore other solutions, Tartar has support for Sigil and Sigil II, even though starting the game with current released requires a bit of command line typing.

Hi, thanks for the hints. Starting MBF using both SIGIL.WAD and SIGIL_II.WAD does indeed work but it only displays the 5th episode in the menu when starting a new game.

Tartar did work, thanks for the hint. I hope in the future it can be possible to start either SIGIL or SIGIL II without having to restart Doom with different command line parameters because of the SHIM loading. At least that is how I understood it that this is the current limitation.

Hey, thanks for trying out. The "sigil 2" command has both 5th and 6th episodes supported, even though the command itself is somewhat lengthy. So you can just save that as, say sigil.bat, and use for playing both episodes without bothering about savegame management and such.

The instructions seem to be ambiguous, so I'll update those.

ludicrous_peridot wrote on 2023-12-09, 17:14:

Awesome! I am removing the faulty gamma build then to avoid any further confusion.

Today I was playing a bit with the supposedly correct build that I provided above and discovered something odd.

It seems that the music loops as it should when I play Doom Shareware or Freedoom Phase 1, but in Doom II or Freedoom Phase 2, the music breaks on the second loop and some instruments still go missing.

Could this be somehow related to the code exception in gerwin's version that would load MBF_D2GM.IBK to emulate the difference between GENMIDI lumps in Doom 1 & 2? I did comment out the IBK loading code as you suggested here, but perhaps there is something else I should've done to make Doom II work as intended? I tried to find any clues in the code of i_sound.c, but I couldn't figure it out.

Hmm... instruments disappearing for tracks on the second loop and so forth when secondary instruments are loaded was a bug in my original submitted MIDI.C... Since you have apparently rebuilt liballegro with the latest source files (I have re-attached them in the above posts after having fixed the bug), this is strange.

The code works for all MUS-format music tracks regardless of the game, but not for MIDI-format, thus Doom or Doom II should not be different really, but there could be tracks without secondary instrument in them, or IWAD-s/PWAD-s with MIDI-s (TNT.WAD from Unity Port, if I am not mistaken) where this would not occur even before the bugfix.

ludicrous_peridot wrote on 2023-12-11, 13:05:

Hmm... instruments disappearing for tracks on the second loop and so forth when secondary instruments are loaded was a bug in my original submitted MIDI.C... Since you have apparently rebuilt liballegro with the latest source files (I have re-attached them in the above posts after having fixed the bug), this is strange.

I'll re-download the files and try to recompile the library once again.

BTW, I was wrong, Freedoom Phase 1 is also affected, which proves my Doom II-specific theory wrong. I wonder why Doom Shareware works fine though.

UPD: I get this now. I did not realise that your loop fix involved changing MIDI.C, which you updated in a different post than the one where you attached your MBF version w/ secondary instruments. I must have downloaded MIDI.C before the fix, so my Allegro library indeed does not include it.

ludicrous_peridot wrote on 2023-12-11, 13:05:

The code works for all MUS-format music tracks regardless of the game, but not for MIDI-format, thus Doom or Doom II should not be different really, but there could be tracks without secondary instrument in them, or IWAD-s/PWAD-s with MIDI-s (TNT.WAD from Unity Port, if I am not mistaken) where this would not occur even before the bugfix.

This must be why I did not notice the problem with Harmony Compatible for DOS, as it uses MIDIs instead of MUS files.

Third time's the charm then? 😉

Apologies for the convoluted way to deliver the changes, I imagine a patch/diff file done against the _MBF tree would have worked much better!
Also, to clarify - the secondary instruments support has been coded so that it's triggered only when
- OPL music is explicitly configured (don't think setting music card to -1 in allegro config will trigger it, even if allegro resolves this to, say, SB)
- Music is in MUS format
- GENMIDI lump was found and passed on to Allegro by the engine
...while most of this was in principle a deliberate choice on my part (e.g. not doing MIDI format), the whole thing is at the moment more of demo material, and the changes to liballegro are only limited to allow for that. (E.g. to the extent that providing OP2 to Allegro via filename as opposed to providing a "lump" would not result in secondary instruments kicking in). I personally think, finalizing this should wait until more feedback arrives, or @gerwin considers if this is something suitable for inclusion with "MBF Allegro".

ludicrous_peridot wrote on 2023-12-11, 13:42:

Apologies for the convoluted way to deliver the changes, I imagine a patch/diff file done against the _MBF tree would have worked much better!

No worries, it was fun to discover things on my own, via trial and error.

I've attached the updated build to my previous post. I ran a quick test with MAP01 from Doom II and everything seems to work fine. The archive also includes all the updated code for both MBF and your version of Allegro.

Thanks again for sharing your developments for the port!

UPD: I have recompiled the Harmony Compatible version and, taking into account what you said about secondary instruments only working with MUS files, used MIDI2MUS to convert Harmony soundtrack and tried the game with these MUS files instead of MIDI, with very noticeable secondary instruments and generally much better sound quality overall.