BTW, I've been experimenting with other music playback options in MBF, and Allegro can actually make use of Ultrasound patches and/or .sf2 format soundfonts using the DIGMID driver. I've got GUS patches installed in DOSBox as per these instructions, and I just selected DIGMID MIDI in the setup programme (even though it is not ticked as an available music device), and pointed the patches to the DEFAULT.CFG file inside the ULTRASND/MIDI/ directory.

I've not tried using soundfonts yet, but there's a PAT2DAT tool that should convert .sf2 files to a format usable by Allegro.

UPD: The music sounds different though, compared to how vanilla Doom plays it in DOSBox with actual Gravis Ultrasound emulation. I wonder if it can be brought closer to the DMX GUS sound?

Not pretending to be particularly helpful here (since I neve owner a GUS in the first place), but when you compare Doom sound be mindful of this: https://flaterco.com/kb/DOOM/DMXGUS/

One other thing to mention is that an easy way to get the patches and config (not the rest of ULTRASND stuff though) is from BFG edition, where they just lie around. I think these are vanilla, not the PPL ones, but if I remember correctly the config was different. There was a period when I was using timidity++ with Gravis patches as MIDI synth in Windows so was curious about it back then.

Also a question not related to sound playback: I have been experimenting with I_VGAVBE/I_VIDEO routines for other modes than 640x400/640x480/1280x1024 which I tried before, and found something strange. On my Intel mobo-integrated chip, while I can switch to 800x600, the output is total mess the moment the game renderer kicks in.

In DOSBox it's fine with the same setting, e.g.

Is this something of a limitation of the card? I don't think I saw problems when selecting 800x600 from Windows resolution list and such, and 1024x768 works just fine.

EDIT: Oh, never mind, actually fixed this in a way - the BPS parameter was not the same as screen width for this mode, so checking for this and doing line by line coppying did the trick. Don't know if that is remotelly useful for any other chips though.

I found a fork of MBF called MBF_SMN (by Sakitoshi) on github: https://github.com/Sakitoshi/mbf_sigil . The explicit goal seems to be to add support for Sigil (and some other wads) on top of MBF 2.04. I wanted to use MBF on DOS to play Sigil II so I hacked on some patches on top of it to support it - seems to work OK. Is anyone else using this fork or is everyone using a different patch for ep5/ep6 support?

dgondos wrote on 2023-12-16, 09:24:

I found a fork of MBF called MBF_SMN (by Sakitoshi) on github: https://github.com/Sakitoshi/mbf_sigil .

I remember it being mentioned here before, from the README.md it looks like this fork ditches gerwin's Allegro modifications for some reason:

Compiling To compile it you'll need allegro 3.0, djgpp and a pc running dos (dosbox is fine too). […]
Show full quote

Compiling
To compile it you'll need allegro 3.0, djgpp and a pc running dos (dosbox is fine too).

Changes
Added full support for episode 5: Sigil.
Sound card settings are read from allegro.cfg again.

If that is the case, one wonders why not use unmodified Allegro 3.12 instead?

dgondos wrote on 2023-12-16, 09:24:

I wanted to use MBF on DOS to play Sigil II so I hacked on some patches on top of it to support it - seems to work OK. Is anyone else using this fork or is everyone using a different patch for ep5/ep6 support?

I think @crvs version is the preferred one as it's changes are eventually getting merged into upstream. Sadly I don't know if this is indeed the latest code that is being reviewed, but it would be interesting to see if your PR would merge successfully if rebased on top of that. Also second concern over Allegro version used, even if for @gerwin's latest bugfixes.

dgondos wrote on 2023-12-16, 09:24:

I found a fork of MBF called MBF_SMN (by Sakitoshi) on github: https://github.com/Sakitoshi/mbf_sigil . The explicit goal seems to be to add support for Sigil (and some other wads) on top of MBF 2.04. I wanted to use MBF on DOS to play Sigil II so I hacked on some patches on top of it to support it - seems to work OK. Is anyone else using this fork or is everyone using a different patch for ep5/ep6 support?

Your PR may need several corrections:

• D_MAIN.C / D_DoomMain(): modifiedgame++ should be moved inside the loop, after D_AddFile() call. Otherwise it will increment just once when several WAD files were specified after a single -file key
• G_GAME.C: a global array pars[6][10] should be extended to [7][10] and {0} initializing value for a 6th episode added, otherwise loading Sigil II will result in writing behind its boundary in deh_procPars() and corrupt the memory; this may cause a Segmentation Violation on MBF start
• G_GAME.C / G_InitNew() contains a hardcoded range check: if (episode > 5) episode = 5;
  It could make sense to replace it with the following: if (episode > 4 + modifiedgame) episode = 4 + modifiedgame;

ludicrous_peridot wrote on 2023-12-17, 12:49:

I think @crvs version is the preferred one as it's changes are eventually getting merged into upstream. Sadly I don't know if this is indeed the latest code that is being reviewed, but it would be interesting to see if your PR would merge successfully if rebased on top of that. Also second concern over Allegro version used, even if for @gerwin's latest bugfixes.

This can be easily integrated into my latest published sources, if anyone wishes - feel free to do it.

I turned modifiedgame into an integer rather than a boolean to count the amount of PWADs requested by the user. It's used later to handle the restriction on max number of episodes. This still isn't great because we don't do any checks on whether those PWADs are Sigil & Sigil II - so it basically means that we assume that if you load two PWADs then one will be EP5 and the other EP6. Previously we assumed that any new PWAD will be EP5. If I understand correctly the way they solved this in prboom is they just set the max number of episodes to a high number (7) and they no longer check if the user requests an episode which is between 4 and 7 but doesn't map to a real episode in a loaded wad.

This in general sounds like a terrible hack.

One would argue why the heck Sigil and Sigil 2 even take place of E5 and E6. Is it because of Romero's hubris? Maybe. Well, too late to change that.

I wonder if there is a way to dynamically check, early enough in the game loop, whether lumps E5M1 and/or E6M1 have been loaded (from whatever WAD). And if so, present the proper prompts, and configure whatever else is required.

How does Ultimate Doom EXE determine whether it's running with Ultimate Doom or Registered Doom? I suppose it must be some godawful harcoded test on the WAD size.

Thanks everyone for the feedback! I updated the PR with your suggestions 😀 I also fixed an issue where the spacing between Sigil and Sigil II on the episode selection screen looked awkward due to the taller height of the Sigil episode text graphics compared to the default.

ludicrous_peridot wrote on 2023-12-17, 12:49:

dgondos wrote on 2023-12-16, 09:24:

I wanted to use MBF on DOS to play Sigil II so I hacked on some patches on top of it to support it - seems to work OK. Is anyone else using this fork or is everyone using a different patch for ep5/ep6 support?

I think @crvs version is the preferred one as it's changes are eventually getting merged into upstream. Sadly I don't know if this is indeed the latest code that is being reviewed, but it would be interesting to see if your PR would merge successfully if rebased on top of that. Also second concern over Allegro version used, even if for @gerwin's latest bugfixes.

That's a good idea, I can have a look at that.

crvs wrote on 2023-12-18, 06:17:

Your PR may need several corrections: […]
Show full quote

dgondos wrote on 2023-12-16, 09:24:

I found a fork of MBF called MBF_SMN (by Sakitoshi) on github: https://github.com/Sakitoshi/mbf_sigil . The explicit goal seems to be to add support for Sigil (and some other wads) on top of MBF 2.04. I wanted to use MBF on DOS to play Sigil II so I hacked on some patches on top of it to support it - seems to work OK. Is anyone else using this fork or is everyone using a different patch for ep5/ep6 support?

Your PR may need several corrections:

• D_MAIN.C / D_DoomMain(): modifiedgame++ should be moved inside the loop, after D_AddFile() call. Otherwise it will increment just once when several WAD files were specified after a single -file key
• G_GAME.C: a global array pars[6][10] should be extended to [7][10] and {0} initializing value for a 6th episode added, otherwise loading Sigil II will result in writing behind its boundary in deh_procPars() and corrupt the memory; this may cause a Segmentation Violation on MBF start
• G_GAME.C / G_InitNew() contains a hardcoded range check: if (episode > 5) episode = 5;
  It could make sense to replace it with the following: if (episode > 4 + modifiedgame) episode = 4 + modifiedgame;

Thanks! Agreed with all of those points, fixed them in the PR now 😀

dr_st wrote on 2023-12-18, 09:44:

I turned modifiedgame into an integer rather than a boolean to count the amount of PWADs requested by the user. It's used later to handle the restriction on max number of episodes. This still isn't great because we don't do any checks on whether those PWADs are Sigil & Sigil II - so it basically means that we assume that if you load two PWADs then one will be EP5 and the other EP6. Previously we assumed that any new PWAD will be EP5. If I understand correctly the way they solved this in prboom is they just set the max number of episodes to a high number (7) and they no longer check if the user requests an episode which is between 4 and 7 but doesn't map to a real episode in a loaded wad.

This in general sounds like a terrible hack.

I wonder if there is a way to dynamically check, early enough in the game loop, whether lumps E5M1 and/or E6M1 have been loaded (from whatever WAD). And if so, present the proper prompts, and configure whatever else is required.

I had a look at this and yes, that should work. I have a prototype patch which checks whether lumps named "E5M1" or "E6M1" exist and modifies the "gamemission" (official mission packs which are packaged as pwads like master levels, no rest for the living, etc.) to set it to Sigil/Sigil 2. We can also use something less specific like a global "maxepisode" flag or something like that which will support other PWADs as well that use episodes 5+. Basically, this `modifiedgame` flag is only used for these purposes:

- Check for IWAD integrity in the case of registered doom => we don't need to modify this check
- For retail (ultimate) doom cap the episode number to some max expected value => This is done in G_InitNew, which is called way after setting up the PWADs. So this can be changed to use our new flags.
- In WI_drawStats() to check whether or not to display par times => No problem here to use our flags.

Additionally I checked as well and couldn't find any code between the beginning of D_DoomMain and where the PWADs are read that would need to be changed for Sigil/Sigil 2 (with the possible exception of the game title and version on the DOS text-mode loading screen, which I guess Romero would prefer to keep as "DOOM Registered Startup" / "The Ultimate DOOM Startup" for the Sigils), so I think it would be possible to use the flags throughout the codebase to replace the specific checks for episode numbers.

Btw, do you guys know if anyone looked at implementing MAPINFO support? It might not be that complex to partially support just the top most frequently used properties from the format. Might make a lot more PWADs playable in MBF.

dr_st wrote on 2023-12-18, 09:44:

How does Ultimate Doom EXE determine whether it's running with Ultimate Doom or Registered Doom? I suppose it must be some godawful harcoded test on the WAD size.

This fork by Sakitoshi does use WAD size / filename / checksum to determine which "gamemission" is loaded, but for differentiating between IWADs (registered/ultimate doom/TNT/plutonia/etc.) it's using a combination of filename checks and pre-scanning the IWAD header for map names. The latter looks like code from the original MBF from '98.

I would suggest checking still that the code brings you back to the correct map from E6M9 (posted that on DW SIGIL II thread).

dgondos wrote on 2023-12-20, 10:27:

This fork by Sakitoshi does use WAD size / filename / checksum to determine which "gamemission" is loaded, but for differentiating between IWADs (registered/ultimate doom/TNT/plutonia/etc.) it's using a combination of filename checks and pre-scanning the IWAD header for map names. The latter looks like code from the original MBF from '98.

Yes, that's likely original MBF code. IIRC it looks for lump names that start with E4 to differentiate between Registered and Ultimate.

Recently I installed FreeDOS in 86Box and tried out both MBF and Tartar on an emulated 486DX2. (Speed wise, MBF works fine but Tartar is slowish.) Previously I mentioned that OPL music sounds much louder in vanilla Doom compared to MBF when playing in DOSBox, but in 86Box the default volume in both MBF and Tartar is so low that I cannot hear any music at all unless I crank it up to the max. Conversely, vanilla Doom OPL music sounds fine with the default volume -- maybe a bit soft, but I can definitely hear it.

I went back to MBF v2.03 and tried it out in 86Box as well, and OPL music is again not audible at all with the default volume level. So I guess this all goes back to the original Allegro settings used. I wonder if the volume level can be brought closer to how the vanilla sounds?

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!

Nothing new, but I have posted the changes here in what I hope is a much more agreeable format.

ludicrous_peridot wrote on 2024-01-18, 22:08:

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!

Nothing new, but I have posted the changes here in what I hope is a much more agreeable format.

Thanks for sharing!

I have downloaded the code and recompiled the library from the new code, there are a few bytes that are different between this and the earlier version that I had compiled. Have you improved something in the meantime?

Not as much improved as "experimented" really. I think the difference to the library binary comes from what's been changed outside of MIDI.*/ADLIB.*, i.e. :

- twice the number of max MIDI tracks supported
- reverted OPL timbres from those derived from closed source/commercial ones coming from id/DMX (I haven't removed them from source code, but have removed harmless SETUP.C though, which is a mixup on my part 🙁 )
- probably useless but also hopefully harmess relaxed check that seems to come froom that recent period when I moved my rig to 16-bit sound.

The changes come in as just one commit, which may be confusing, but I tried to document all that one is getting in the README.

I've recompiled MBF with secondary instruments support with the new version of the library and it seems that it now ignores the GENMIDI lump and instead uses the internal timbres? At least, I have tried loading Freed∞m ultimate IWAD, which has a pretty lame internal GENMIDI, with and without DMXOPL.WAD, and I can hear no difference whatsoever.

I had not altered anything in MBF code though, perhaps I should have done something to accommodate the Allegro changes.

Hmmm... I will check and revert, but just to be sure - when you mention no MBF code changes, does that mean no MBF code changes on top of this, or on top of original Gerwin's code?

ludicrous_peridot wrote on 2024-02-06, 21:14:

Hmmm... I will check and revert, but just to be sure - when you mention no MBF code changes, does that mean no MBF code changes on top of this, or on top of original Gerwin's code?

On top of my previously compiled build with the earlier version of your library. I might double-check everything again (recompile the new version of the library just in case?).

Hey, sorry the library misbehaves for you. On my end I have rebuilt clean from shared source and linked with "my previously compiled build" of MBF, again clean. Everything worked as intended. Sharing the diff of the MBF source I run from the original code just in case.

Alright, I have recompiled the library afresh and made sure the MBF code is right, everything seems to work right now.

I have a question though, when the setup programme is exited, the screen fades out slowly, but then there is a brief flash of what appears to be the distorted background image with wrong palette. I think that previous versions of the setup did not have this issue. Do you know what causes it and how to fix?