MrFlibble wrote:

Thanks! I did not realize that the programme required a particular version of Allegro to compile.

About all Doom DOS source ports use v3.0, or v3.12 at most. Doom MBF 2.04 should work with stock v3.0 too, but Sound Blaster Pro and especially Adlib support is improved in my modded v3.0.
Glad the compile is succesful now.

MrFlibble wrote:

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?

I noticed these comments too, but my memory is currently failing to make out what I was describing there, and wheter or not it was fixed. AFAIK there are no instabilities with the current release.
Cannot illustrate any noticable differences in a 1997 versus a 2014 compiler setup for this program.. It is weighing the many bugfixes of 2014 packages to the tried and tested 1997 packages. Note that GCC 2.7 does have a slightly different syntax for the compiler options.

@keropi
It is on my todo list now. Was thinking: Maybe sufficient FPS can be gained by using pixel doubling (horizontal or vertical) in 640x400 mode.

Question: How would 320x400 look good being a completely wrong aspect ratio?

Not too bad actually. Terra Nova : Strike Force Centauri also used that resolution as its higher res solution.

@gerwin
nice to hear it's in the plans to add some resolution stuff , can't wait 😀

@dr_st
also Quake and Blood support 320x400 , you can check it there

Tried it with FreeDoom on Boxer. Smooth as molasses.

Then tried it with HACX IWAD. Failed on startup.

I also tried Chex Quest, but it reported a missing header.

The original Chex Quest and not CQ3 and NOT the modified idgames/ release? That should work since it's technically a modified Ultimate Doom iwad.

HACX might still work as its original pwad-for-doom2 form.

Oddbrother wrote:

Then tried it with HACX IWAD. Failed on startup.

MBF does not recognize HACX.WAD as a valid IWAD because it only contains 21 maps. MBF expects the Doom II IWAD to have at least 30 maps (which is the German release that omits Wolfenstein 3-D levels). Because of how the algorithm of IWAD detection in MBF works, it gets confused and thinks HACX.WAD is a Doom IWAD, hence complaining it can't find E1M9.

That's not all though. HacX v1.2 in its original form will not work with MBF anyway. If you try to load it as a PWAD, it will crash as soon as you try to start the game or the demo playback starts, with a "Segmentation Violation" error message. It turns out that HACX.WAD was compiled according to ZDoom standards, and misses REJECT lumps. This issue is discussed in detail here:
http://www.doomworld.com/vb/source-ports/6121 … nd-prboom-2-02/

I have used ZenNode to rebuild the REJECT lumps, and with this fix HACX.WAD works fine with MBF. Blzut3 says the issue will be addressed with HacX v1.3.

BTW gerwin, I have noticed that in vanilla DOSBox v0.74, aspect correction does not work properly with MBF even at 320x200 resolution. I expected the issue to only occur at high resolution, as for 320x200 it was fixed since v0.72 (according to this thread). I have tried running MBF with the -stdvid parameter but the issue still persists.

MrFlibble wrote:

BTW gerwin, I have noticed that in vanilla DOSBox v0.74, aspect correction does not work properly with MBF even at 320x200 resolution. I expected the issue to only occur at high resolution, as for 320x200 it was fixed since v0.72 (according to this thread). I have tried running MBF with the -stdvid parameter but the issue still persists.

That would be really odd, as I would not now how to break such a thing. I just tested it, and all video modes render to a 640x467 image when 'aspect=true' in Dosbox 0.74. So it seems to work fine here?

FYI, the aspect ratio of 400-line VESA modes is fixed in DOSBox SVN (320x200 is a 400-line mode due to line doubling), and MBF uses VESA modes if I'm not mistaken.

Yes,
One of the last changes to MBF 2.04 was the use of VESA mode 320x200 when listed as supported in the VESA BIOS. Usually mode 150h. As this mode allows page flipping, and is more compatible+faster then Mode-X*. It also means that in that case MBF will prefer VESA 320x200 above mode 13h. One can verify which mode is used by MBF by enabling the option "Show frame rate + mode indicator".

*Mode-X may be faster then VESA when using planar buffering, but since that is not the case in MBF: VESA is faster here.

gerwin wrote:

One can verify which mode is used by MBF by enabling the option "Show frame rate + mode indicator".

I've just tried running MBF with several IWADs with the -stdvid parameter, and the mode displayed is 150h anyway. Is there any way to force the use of the standard 13h mode?

ripsaw8080 wrote:

FYI, the aspect ratio of 400-line VESA modes is fixed in DOSBox SVN (320x200 is a 400-line mode due to line doubling)

Thanks, did not know that. I mostly use SVN Daum, which has dealt with the issue quite a while ago.

MrFlibble wrote:

I've just tried running MBF with several IWADs with the -stdvid parameter, and the mode displayed is 150h anyway. Is there any way to force the use of the standard 13h mode?

It is all intentional. 150h is the '-stdvid' when available. '-Stdvid' was meant to select equal visual detail level for benchmarking, not to revert to 13h just because (Though maybe Quake does it that way). I will have to add another parameter to the program for this, as a workaround. Or the DosBox team has to release their v0.75 Edition. 😉

DOSBox has VGA machine types with no built-in VESA support, so perhaps MBF will fall back on mode 13h when using those.

Any updates on the semi-highres modes? Or summer kicked in and coding needs a rest? 🤣

The other time I looked at the source to see if a quick hack would do for semi-highres, but the changes were spread in a dozen or so files. So I need a good afternoon or evening to make it proper. At the end of august my real life responsibilities should ease a bit.

awesome, looking forward to test this when it comes out 😀
thanks for the update gerwin!

Finally managed to work on MBF a little, for the first time this year.
There is a low detail mode now, currently only invoked by parameter -lowdet.
Keropi, how much FPS gain does this bring on your system? On a 486 it is about 10%.

is there a new build available? should I timedemo my 233mmx?

Yes please, using -lowdet. Upload no. 10 is available since today.

OK here is what I get:
"-timedemo demo3 -lowdet" = 89.7 fps
"-timedemo demo3" = 75.4 fps