The level timer gets reset to zero when loading a save. So if you save just before the exit switch, then exit, you get one time. But if you reload that game, then immediately exit, you get a time of a few seconds ... Verified in plain DOS, under NTVDM, and in DOSBox so I'm pretty confident it's a bug with the game, and should be fixed if anyone's still maintaining it.

Hey Lee!, good to see you signed in to vogons and dropped by here! We communicated briefly some months ago. I don't think I mentioned that here.So Welcome, and thank you as well. I can only appreciate the efforts and skill you put in this great game back in 1997..99. Of course the Doom source moved in many directions after that, but it seems like MBF was the best port still supporting DOS. So it really fits the timeless niche that is Vogons.

mbf wrote:If you're ever in a conundrum, I'd be glad to help.

That is kind of you. The ToDo list is on the previous page... No, just kidding.

koverhbarc wrote:I'm confused - is the last supposed to be a reply to me? As indicated the bug is new.

Don't think so. But the leveltime bug is now fixed (upload no. 15). I was the one who broke leveltime saving back then in 2014 so it is only fair I fixed it. Thanks for reporting it. Maybe this also fixed the demo recording differences mentioned in the ToDo list?

Is this the real Lee? Thanks to you for all your work, i was one of the MBF players back then. I'm just a poor guy with a modest hacky port or two, what i'd like to do now is re-add some limits but in an optioned and controlled way (already did with distance sprite culling by dpJudas one of the GZDoom guys) for performance. I'd like to add next wall culling with distance (drawsegs) but i don't know how.

gerwin wrote:Don't think so. But the leveltime bug is now fixed (upload no. 15). I was the one who broke leveltime saving back then in 2014 so it is only fair I fixed it. Thanks for reporting it. Maybe this also fixed the demo recording differences mentioned in the ToDo list?

Upload no. 16 is available:-Made changes in WSS.C sound driver, to prevent tweaks meant for CS4232 sound chip being applied to a similar OPL3SAx sound chip. Also disabled one tweak entirely for all WSS cards.-Made changes in MPU.C music driver, to prevent lockup when using the older SB16 MPU together with SB16 Digital section. Also made this driver follow the guidelines better, with more status checks.Edit - Upload no. 17 is available:-Setup.exe: Scrolling font spacing fix. -Stereo no longer reversed in relation to setup ('sep' in i_sound.c). Edit - Upload no. 18 is available:-Setup.exe: Display detected DSP version for Sound Blaster cards.-Sound Blaster Pro driver reverses back the reversed stereo of the hardware (allegro: sound.c + sb.c). -Made changes in SB.C digital sound driver, mainly to handle unexpected MPU-401 interrupts with SB16.(PS: to minimize hanging midi notes with SB16: lower the digital sample rate tot 22 or even 11 kHz)-Setup.exe: bugfix: 22 kHz sample rate was not properly selectable in the dialog.

In my testing this resolves the SB16 issues reported by Jolaes76 + mOBSCENE and the WSS issue reported by clueless1. Tested with SBPro CT1600 and SB16 CT2290+CT2940. Tested with WSS+SBPro compatible YMF719(aka OPL3SAx or Audician) and CS4232.

A technical note on the possible lockup with the Sound Blaster 16 cards, when using digital effects together with the build in MPU-401 Midi interface.This is a problem also found in other games. As discussed earlier the patch SBMPU401.EXE (inside waveptch.exe) offered by Creative prevents such lockup. Basically, what "SBMPU401 /E" does is is write 0Bh to undocumented mixer register 83h. "SBMPU401 /D" reverses this by writing 0Fh to the same register. My tests indicate that the /E register tweak prevents unexpected interrupts on the SB IRQ; these are ones that contain the MPU tag (100b). Digital sound interrupts keep coming, as they are necessary. The distinction of interrupt types can be made because SB16 introduced mixer register 82h, which informs on the type of interrupt that was given. But AFAIK the MPU should not send interrupts in UART mode to begin with. MBF now filters out and acknowledges any interrupts not tagged 'digital effect 8/16bit' and that works well. SBMPU401 is no longer needed for this game.

Heads up on the MBF dog part - Nash's making a GPL friendly version. Keep an eye out

Voodoo2s aren't 100mhz stockGeforce256 isn't released as a beta on New Years '99 under the Quadro brandDOS gaming isn't a bilinear 320x200 16:10DOS PCs aren't better than the MacintoshDOSBox is not for running Windows 9xSGL != Glide

Why should it? MMX's only really practical for exotic sound code which would be out of the scope of a maintenance fork.

Voodoo2s aren't 100mhz stockGeforce256 isn't released as a beta on New Years '99 under the Quadro brandDOS gaming isn't a bilinear 320x200 16:10DOS PCs aren't better than the MacintoshDOSBox is not for running Windows 9xSGL != Glide

Gerwin, the guys on doomworld said you could help me with building your MBF on DOS, I'll be using DOS Box, what I have to set up to build it? Also help me with Boom 2.02 building.I have the latest DJGPP.

While you can compile Doom MBF with the latest DJGPP, using my precompiled liballeg.a, I advise against it now. These 1997 DJGPP related packages work best: bnu27b.zip, djdev201.zip, gcc2723b.zip, mak3791b.zip, txi390b.zip.

OPTIONAL: With the above you can also compile Allegro 3.0 with my modifications. You cannot compile Allegro 3.0 with the latest DJGPP. The MBF204 source package does not contain the complete Allegro 3.0 source, just the files that were modified. These can be copied over a regular Allegro 3.0. Compiling Modified Allegro will create the Doom themed setup.exe.

Doom MBF source has no dependencies besides a precompiled 'Modified' Allegro 3.0. This consists of just two files: DJGPP97\include\allegro.h and DJGPP97\lib\liballeg.a. They are included in the source package for convenience.

The MBF204 source package contains _MAKE.BAT which does what the name suggests. But as it is, it expects the compiler in this folder C:\DOSAPP\DJGPP97\ and the MBF source in this subfolder: C:\DOSAPP\DJGPP97\_MBF\

Boom will compile in a similar way, but has not been adapted to, or tested with, my modified Allegro 3.0, and should be compiled with regular Allegro 3.0 libraries.

PS. I do not use DosBox myself to compile things with DJGPP, but Window XP or Windows 98/DOS 7.0.