Just tested it, 640x400 was improved! I am now getting min 28fps and max 32 in the start areas that were ~24fps before 😁
So if there is room for some speed tweaks then I don't see why I couldn't reach the golden 35fps 🤣
Upload no. 7 is available since past weekend.
The main new thing are the protected mode variants of VESA functions bank-switching and page-flipping. The speed improvement is not impressive though, 1% at most. In past uploads the hires wait for retrace option may have been reversed, taking a toll on FPS while one thinks it was off. It is now working as it should be.
Below some Shareware Timedemo 3 scores.
MBF 2.04 On a Pentium MMX 200MHz :
(Voodoo 3 AGP or S3 Virge PCI+S3VBE20, ALi 5 mainboard at 66MHz FSB)
640x400, no border, PageFlipped = 35,9 FPS
320x200, 'stdvid' = 110,6 FPS
Duke 3D seems to do around 40 to 60 FPS in 640x400 (hard to decide on an average)
MBF 2.04 On a VIA C3 Nehemiah, running at half speed 9.0x66 = 600MHz:
(Voodoo 3 AGP or Geforce 2MX AGP, i440BX mainboard, Write-combining for LFB)
640x400, no border = 71,7 FPS
640x400, no border, PageFlipped = 71,6 FPS
640x400, no border, PageFlipped, WaitRetrace = 54,0 FPS (normally timedemo disables Waitretrace)
640x400, no border, 'nolfb' = 44,6 FPS
Duke 3D seems to do around 60 to 65 FPS in 640x400 (hard to decide on an average)
Quake needs the system to be at 9.0x133=1200MHz to get similar frame rates in 640x480.
I don't get these Duke 3D framerates on the Pentium MMX. They should be around 30..35. And if Duke 3D is so slick then why does it fall behind in the VIA C3 benchmarks?
Some things I worked on, but which failed to make it in the upload:
- Tried compiler optimize options for 586 and Pentium: gave just a half percent increase in frame rate.
- Tried to convert and import the original Adlib OPL timbres: That part succeeded, but the allegro adlib.c driver does not work well with it; it sounds worse then the default timbres. To be continued?
--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul
wrote:- Tried to convert and import the original Adlib OPL timbres: That part succeeded, but the allegro adlib.c driver does not work well with it; it sounds worse then the default timbres. To be continued?
What about disregarding Allegro for FM music completely and port code out of Chocolate Doom? Not for its OPL emulation core but for its direct port writing instead. Maybe it'll be a bit faster from less reliance on Allegro's internal timer being processed (I had Boom's allegro midi playback in Engoo before and it shot the engine down to a very slow 17fps for some reason)
Thanks for the tip, I will take a look there. In addition the Duke 3D source comes with its adlib driver code.
Fortunately I did not get such a framerate decrease with the Allegro Midi and FM drivers. Sticking to Allegro 3.0 on purpose. I don't need the sound recording support of 3.12 and later; needless overhead.
All these MBF benchmark values are with Sound + Midi music btw.
--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul
There was indeed a bug in Allegro Adlib.c that messed up the FM timbres! Surprisingly it was found and fixed relatively quickly, I am not that knowledgable in all these Adlib specifics. So:
MBF upload no.8 features almost authentic FM music. 😀
The Drum-timbres are still stock Allegro. Part of the percussion data format used by the Adlib driver differs from the Doom soundbank format. No idea yet on how to translate these parameters properly... On the other hand, FM Percussion is always a compromise.
Edit: upload no.8-B is there with a Doom-themed Setup.exe.
Edit: upload no.9 is there, with more work done on the Adlib driver and FM timbres. Both GM and Drums now sound pretty much indiscernible from the original Doom. Thanks to MUSlib for the lookup tables. Like in Doom, drums are used as normal fixed-pitch instruments now, This means a change from six-channel+drums rhythm-mode to nine-channel melodic mode.
--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul
Anyone still have a valid download link for 2.04?
One from Oct 2014
I Forgot to update the links in this topic after relocating the files to a slightly different server address. It works again.
--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul
Much appreciated!
Is this better than Chocolate? Because if I want to go retro and mod-less on Doom, that's what I'm currently using.
The only reason for the existence of MBF 2.04 is that it is a native DOS game, which can run on hardware from the 90's. It will also run inside DosBox of course.
Chocolate Doom, zDoom etc. do not consider DOS or 90's hardware as a target platform anymore. Often windows 95/98 is unsupported already.
--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul
Ah, I get it. I thought MBF worked on anything you threw at it. Including hardware after 90's.
Thanks, will definitely give this a spin 😀.
wrote:Ah, I get it. I thought MBF worked on anything you threw at it. Including hardware after 90's.
It was tested to run reasonably well on hardware from 2012 from within Windows XP 32-bit, just that one has to put up with the XP Sound Blaster emulation.
However, It cannot function in a x64 OS. Not without using the DosBox emulator or similar. This goes for all DJGPP Dos programs.
--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul
Understood. Good work, love how some people still do software for good ol' DOS. 😀
wrote:Chocolate Doom, zDoom etc. do not consider DOS or 90's hardware as a target platform anymore.
It's a shame too. When I brought up d_detail being useful to compensate for the float-heavy overhead FmodEx had, that got removed. Not long after there's been a lot of performance-eating bloat in the actor code added and then the loading window became unreadable
wrote:This weekend I managed to find two bugs that prevented the code to cooperate with newer compiler versions. It now compiles a reliable exe with DJGPP packages from 2014. There seems to be no speed benefit though...
The latest version of the code available via the link in the OP gives lots of errors in i_video.c:
The DJGPP version used is the latest available from the official website:
djdev203.zip
bnu225b.zip
csdpmi7b.zip
gcc473b.zip
mak3791b.zip
txi412b.zip
all422a.zip
This happens both in DOSBox and in FreeDOS.
I notice "all422a.zip" there, but that won't work with this game. Doom MBF uses a modded/fixed Allegro 3.0 for sound. A minute ago I uploaded the source again, now containing this precompiled Allegro 3.0 Library for convenience. (Allegro 3.0 is picky about the compiler version: without that precompiled library, one would need a '1997' compiler setup just for that.)
Besides the described Allegro Library, the latest binary of Doom MBF 2.04 was compiled with this:
Though MBF 2.04 itself is not picky about the version of these packages.
--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul
Thanks! I did not realize that the programme required a particular version of Allegro to compile.
In the meantime I found this thread and set up GCC 2.7 with the rest of the 1997 package (BTW, all required files can be found at mirrors like this one), which compiled allegro 3.0 (the regular version), and also compiled MBF.
Is there any difference in what version of the compiler to use? It is mentioned in the makefile that GCC 2.7 "can also mess up MBF in hires, but very rarely". Does this mean that another version is more preferable and will result in a more stable executable?
Is it possible to add a screenmode like 320x400 or something? Something mid-"highres".
I upgraded my p1 build from 200->233mmx and I don't get a solid 35fps in game (didn't timedemo it, just E1M1 fluctuates from 28~33fps) with 640x400 (that looks awesome btw). A 320x400 would look good too and not that demanding... can it be added?
