Since yesterday I updated the package:
"Upload no. 002: v2.04 had broken the savegame functionality, now fixed (g_game.c)"

I tried the official "No Rest for the Living" Xbox-Arcade Doom II addon with both MBF and the original Doom II exe. Using the command line parameters "-iwad doom2.wad -file nerve.wad".
Surprisingly even Doom II loads the maps, but it has visual corruption in complex scenes and tends to crash. MBF runs NRFTL without problems so far!
Framerate is rather low on a 486 (100MHz Cx5x86) in stock video mode. For the screenshot the game was switched to 640x400, showing a part of Map 'MAS04'. Obviously the amount of detail in this addon far exceeds the stock iwads.

awesome!!! I will try it on my p1 pc!
have you considered integrating the GM fixes (if possible) ? Doom engine - sound driver hacking

Nice!
Btw, I know it's supposed to be 'squeezed' back to 4:3 ratio, but native 640x400 (well, 320x200 too) actually looks great in full-screen with 16:10 monitors (1280x800, 1920x1200, 2560x1600).

Have you tried BTSX on it?

Thanks for the feedback!

keropi wrote:

have you considered integrating the GM fixes (if possible) ?

Doom Source Ports come without the original 'DMX' sound code, and any of its quirks.

archsan wrote:

Btw, I know it's supposed to be 'squeezed' back to 4:3 ratio, but native 640x400 (well, 320x200 too) actually looks great in full-screen with 16:10 monitors (1280x800, 1920x1200, 2560x1600).

OK.
By the way. I found some cards do not support 640x400: intel graphics in particular. In that case MBF 2.04 switches to 640x480 instead, with black bars. Also looks bit stretched, but it is better then nothing.
At some stage I implemented a stretch_blit to 800x600 and 1024x768, but this part was removed. A monitor with scaling options is a better solution. Ideally MBF is modified so it renders to custom resolutions directly, but that takes effort, and will make the engine less 'lean and mean'. There is always the Eternity Engine when MBF does not suffice.

leileilol wrote:

Have you tried BTSX on it?

Just tried it like this: "MBF.EXE -iwad doom2.wad -file btsx_e1.wad -dehlump btsx_e1.deh". As far as I can see everything is working.

just tested it 😀
I had to run setup.exe to config my SB16 and MPU401-AT. Changing values in-game did not work for me. After setup was used everything was OK.
It plays flawlessly with normal resolution, however high-res only maxes at ~24fps on my setup (p200mmx , agp riva128zx) so it's not useable for me. The detail difference is huge though , it's a shame...
great work gerwin! keep it up, DOS needs some advanced ports!

I suppose a resolution of 400x300 or 512x384 would be a good middle ground for socket 7. Doom Legacy v1.41 for DOS supports these resolutions. IIRC It requires a VESA 3.0 capable card, or Univbe 6.
What is the result of running the included Bench.bat?
On my Pentium II the parameter -noasm helps the framerate a little, wheras on a 486 it is better left stock.

well, the riva vga has a vbe3 bios... the game does hit 35fps when you reduce the window a couple of times (with the status bar visible) , but I imagine it will struggle on more detailed levels, only tested it in the 1st one.
Benchmark gives me 107.7fps (3836 gameticks / 1247 realtics) , noasm didn't do anything noticeable for me.

A few days ago I read this part from Ken Silverman on his Build engine development (Build.txt):

5/1/95 - Optimized horizontal line assembly code so it doesn't use the awful SHLD instruction any more. This is a good speed improvement for Pentiums only.

The MBF horizontal line assembly still uses SHLD!?... I now replaced it with different instructions. There is currently no assembled Pentium 1 system here for testing, but on a Pentium II the FPS increased by 20% 😀. 486 performance remains unchanged.
Keropi, Please try to bench the latest version (upload no. 3).

got the new package, benchmark fps went to 110.1 this time ,640x400 still lingers at ~24fps
seems I need a beefier cpu 🤣 🤣 🤣

edit: how about a 320x400 screenmode?

Would the 'optimized' column assembly drawing funcs from Zdoom do anything?

I think Randy could allow the use of it for the GPL if asked since it's nothing specific to the restrictive licensed stuff in the engine...

keropi wrote:

got the new package, benchmark fps went to 110.1 this time ,640x400 still lingers at ~24fps
seems I need a beefier cpu 🤣 🤣 🤣

Maybe. A Pentium Pro/II or VIA C3 with write combining enabled is the thing to have for 640x400 and up.
But on socket 7, I am not sure what one can expect from this Doom Port or similar games in 640x400. Would Duke Nukem 3D or Quake do better? (In Duke3d use the cheatcode DNRATE).
Eventually I could compile a version with mtune=i586 instead of mtune=i486, and put together a socket 7 system myself to do some testing.

keropi wrote:

edit: how about a 320x400 screenmode?

That is an interesting suggestion. It does not look that much better then 320x200, on the other hand it may be a relatively easy task to add it to the game. It is like hires in the vertical component only. The mode is part of VBE 2.0 AFAIK.

leileilol wrote:

Would the 'optimized' column assembly drawing funcs from Zdoom do anything? I think Randy could allow the use of it for the GPL if asked since it's nothing specific to the restrictive licensed stuff in the engine...

When looking at the ZDoom assembler file, one unfortunate thing is that it is in MASM sytax. For AT&T syntax every line has to be converted. I would like to know if it is actually faster on a 486/Pentium before going to the trouble of conversion...

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...

gerwin wrote:

When looking at the ZDoom assembler file, one unfortunate thing is that it is in MASM sytax.

The 1.21 source should be NASM.

DN3D performs better for me in 640x480 (no 640x400 mode in it), lowest I saw was 31fps , I would say that average it achieves 40fps. In some points in the 1st level the framerate hits 90+ fps

Quake1 1.08 with sound enabled gives me 16.6fps in timedemo1

Will have to check what makes Duke 3D do better, or if there is resource wasting in the MBF code somewhere.

Upload no.4. is there now: Most if not all video access rewritten (i_vgavbe.c), except for the assembler files. Video access now totally independant of the Allegro library, which is still there for sound. This works way more reliable on the systems and emulators I have here. As for speed, that was not the main goal of the rewrite, but it certainly is not slower.

It is now compiled with newer software. One side effect is a message in window 98 about memory. But this is fixed by setting the mbf.exe DPMI memory to 16MB or something.

@leileilol, You are right NASM. Still not AT&T, but usable. Will look at it later.

keropi wrote:

DN3D performs better for me in 640x480 (no 640x400 mode in it), lowest I saw was 31fps , I would say that average it achieves 40fps. In some points in the 1st level the framerate hits 90+ fps

Quake1 1.08 with sound enabled gives me 16.6fps in timedemo1

You can actually do 640x400 in DN3D by editing one of the config files. Gemini mentions it in on Episode 89 of ADG. http://www.pixelships.com/adg/ep0089.html

Yesterday I replaced a Voodoo 3 with some Nvidia Geforce cards for testing: It showed that page-flipping was malfunctioning with the NVidia BIOS: the display was not smooth and frame rate was stuck at 24 FPS. Rewrote the sections responsible and it is now fixed, among other things.

I forgot to mention another side effect of the new compiler: Delete the MBF.cfg from the older version, as the key mapping has changed.

^ awesome, I'll give it a test later and report back 😀

Excellent work Gerwin! Many thanks! Would like to try this in DOS 8.0 (or Windows ME).