Doom on those kind of platforms is not Doom at all anymore.

I was thinking that if someone didn't tell me that Doom on the ZX spectrum was Doom on a ZX Spectrum, I might have guessed at it being a bad CGA conversion of Wolf3D on a 5150

xcomcmdr wrote on 2021-11-24, 07:07:

Doom on those kind of platforms is not Doom at all anymore.

I don't know, I really don't feel the Doom experience is as much about graphics as it is about the tight gameplay. I know a lot of people would have really appreciated the graphics modes of FastDoom back in the day for sure..

I was talking about gameplay / fun factor, it isn't there at all on the ZX Spectrum, Nintedo Game and Watch, calculators, and other vastly underpowered platforms.

xcomcmdr wrote on 2021-11-25, 10:13:

I was talking about gameplay / fun factor, it isn't there at all on the ZX Spectrum, Nintedo Game and Watch, calculators, and other vastly underpowered platforms.

To be fair (most of) those are not Doom ports..

now that kixs has shown me how to enable 0ws on my ISA Mach64 I have tried mode Y FDoom again instead of using FDoom13H.

Wow, big speed improvement! Previously I was getting 13.344 fps for demo3, now I'm getting 15.013!

I guess the Mach64 likes using mode Y with 0ws, as previously it was slightly slower with mode Y than with 13h.

@ViTi95 much earlier in the thread you mentioned that sound caused slowdowns due to caching issues. Have you managed to look at this again? It would be cool for sound to not cause a 1-2fps decrease in speed on slow systems!

I've tested various modes on my 386SX 25 MHz PC with Cirrus Logic 5402 SVGA ISA graphics.
With FDOOM. EXE (mode Y) as 100%, I've got such results:

FDOOM13H.EXE - 105.19%
FDOOMVBR.EXE - 104.96%
FDOOMVBD.EXE - 107.88% - although image was flickering.
FDOOMVBP.EXE - it crashed.

13H was the fastest one on Cirrus Logic 5402.

I've also did other tests based on the fastest DOOM13H. 100% is the value of test done on XMS only + latest VGA BIOS loaded via TSR for my card.

96.13% - on a 13H mode with stock BIOS of the CL 5402.
96.13% - on a latest VGA BIOS but with EMM386.EXE loaded.
120.33% - fast possible DOS config and with sounds disable. This is massive improvement! FPS jump from 21 to 25.

xcomcmdr wrote on 2021-11-24, 07:07:

Doom on those kind of platforms is not Doom at all anymore.

game and Watch still uses wads, just removes the textures out so it fits in the very limited ram, lag and FPS isn’t bad compared to systems in use at the time of dooms release.

ishadow wrote on 2021-11-26, 14:41:

I've tested various modes on my 386SX 25 MHz PC with Cirrus Logic 5402 SVGA ISA graphics. With FDOOM. EXE (mode Y) as 100%, I've […]
Show full quote

I've tested various modes on my 386SX 25 MHz PC with Cirrus Logic 5402 SVGA ISA graphics.
With FDOOM. EXE (mode Y) as 100%, I've got such results:

FDOOM13H.EXE - 105.19%
FDOOMVBR.EXE - 104.96%
FDOOMVBD.EXE - 107.88% - although image was flickering.
FDOOMVBP.EXE - it crashed.

13H was the fastest one on Cirrus Logic 5402.

I've also did other tests based on the fastest DOOM13H. 100% is the value of test done on XMS only + latest VGA BIOS loaded via TSR for my card.

96.13% - on a 13H mode with stock BIOS of the CL 5402.
96.13% - on a latest VGA BIOS but with EMM386.EXE loaded.
120.33% - fast possible DOS config and with sounds disable. This is massive improvement! FPS jump from 21 to 25.

FDOOMVBD requires a Linear Frame Buffer, which almost 100% ISA cards doesn't provide, that's why it flickers. You need a VLB, PCI or AGP card for this mode to work correctly. FDOOMVBP uses Protected Mode extensions, lot's of video cards don't implement these functions, and UNIVBE directly crashes with this mode (don't know exactly why). Only some modern VESA 2.0/3.0 video cards support it correctly.

trixster wrote on 2021-11-25, 10:31:

now that kixs has shown me how to enable 0ws on my ISA Mach64 I have tried mode Y FDoom again instead of using FDoom13H. […]
Show full quote

now that kixs has shown me how to enable 0ws on my ISA Mach64 I have tried mode Y FDoom again instead of using FDoom13H.

Wow, big speed improvement! Previously I was getting 13.344 fps for demo3, now I'm getting 15.013!

I guess the Mach64 likes using mode Y with 0ws, as previously it was slightly slower with mode Y than with 13h.

@ViTi95 much earlier in the thread you mentioned that sound caused slowdowns due to caching issues. Have you managed to look at this again? It would be cool for sound to not cause a 1-2fps decrease in speed on slow systems!

The sound code was reworked, now it doesn't trash the sound cache every X seconds. This way it forces the used sound data to stay in memory, avoiding those hiccups. But the first time a sound is used there is a little decrease, since it has to load the sound.

ishadow wrote on 2021-11-26, 14:41:

386SX 25 MHz PC with Cirrus Logic 5402 SVGA ISA graphics.
FPS jump from 21 to 25.

wait, 20 fps on SX 25MHz? is that in post stamp sized window?

rasz_pl wrote on 2021-11-26, 23:58:

wait, 20 fps on SX 25MHz? is that in post stamp sized window?

I don't remember exact settings, but I've chosen rather small window, so the tests didn't take too long. FPS was irrelevant anyway since I was curious about difference in performance for various modes.

Also Fast DOOM makes the biggest difference on 386SX machines. These CPUs could run DOOM, but it was barely playable. Now you can get 15+ FPS with potato mode at quite large window.

For comparison, my 386SX scored 10.179 FPS in demo1 from Ultimate DOOM at full screen with status bar in potato mode without sound, but with floor textures enabled.
With smallest window and everything set to low or disabled it scored 29.147.
Original DOOM gets 12 FPS in smallest window, low detail and no sound.

You can see that Fast DOOM makes a huge difference for 386 SX. It gives a lot of options. You can play at a window reduced by few steps at 1x1 pixels if you disable floor textures. You play with all the details in potato mode and you can even play at 20+ fps with window that is still significantly larger than post stamp.

By shrinking rendered window you move around what part of codebase is actually stressed and % you post are non comparable to anything else, unless also measured at same settings and window size.

rasz_pl wrote on 2021-11-28, 02:25:

By shrinking rendered window you move around what part of codebase is actually stressed and % you post are non comparable to anything else, unless also measured at same settings and window size.

Every % test was done in same settings. I've chosen smaller window, because timedemo draws every frame and full screen tests would take 10+ minutes on 386SX machine.

I managed to get FDoomVBR working with this ISA ATI Mach64.

M64VBE v2.21 didnt seem to set up VBE2.0 correctly and FDoomVBR wouldnt load, however using an older version M64vbe v1.04 works ok.

-timedemo demo3 -nosound -nomouse -ram, full resolution with one level of green border:

FDoom 14.227 fps
FDoomVBR 14.493
FDoom13H 13.389

VBP doesnt work, the display just garbles with loads of weird characters.

VBD immediately complains "Program too big to fit in memory". This is with aperture both tried at enabled and disabled with M64VBE, and by trying the system with just 8MB and then with 16MB ram. There is not an option in this bios for "Memory Hole At 15M-16M"

Here are the results for my 486 DX2 66 with VLB TGUI9400Cxi, -nosound -nomouse -ram, full resolution with normal HUD:

Doom 29.617
FDoom 35.257
FDoomVBR 42.040
FDoomVBD 39.435
FDoom13H 37.010

Also tried Univbe 5.3 - that enables me to run FdoomVBR too, but FDoomVBD again complains that the program is too big to fit. LFB is toggled on.

I've been thinking lately to remove FDoomVBP mode, as it's very problematic with many many cards and doesn't provide enough boost (and in most cases is even slower). UniVBE crashes with this mode, and multiple native VESA 2.0 cards don't support it anyway.

@trixster can you share the LFB address, the DOS memory layout and the FDoomVBD error? I'm pretty interested in getting FDoomVBD running with compatible ISA cards. Also you can try it without the "-ram" option? Maybe the ISA ATI Mach64 could work fine on the 486DX2.

Hi!

How do I find the LFB address?

Is the dos memory layout just displayed using the mem /c command?

I have tried it without using the -ram command, no improvement. I’ve also tried the machine using with and without emm386 and with and without EMS ram.

The VBD error is simply "Program too big to fit in memory" as soon as I try and execute FDoomVBD from dos. FDoom does not get as far as getting to the doom initialisation screen, the error message appears in dos immediately after pressing enter.

If I remember correctly Scitech Display Doctor 6.53 displays LFB address after startup.
http://vogonsdrivers.com/getfile.php?fileid=346

I think this amiga bridgeboard pc bios is unable to work with the LFB (aperture) on this ATI Mach 64, to be honest. Even though M64VBE says it's enabling the aperture, M64Diag then always says the aperture is disabled.

If I get time to dismantle the 486 I'll try the ATI in that, but that's quite a big job at the moment!

ishadow wrote on 2021-11-27, 22:38:

You can see that Fast DOOM makes a huge difference for 386 SX. It gives a lot of options. You can play at a window reduced by few steps at 1x1 pixels if you disable floor textures. You play with all the details in potato mode and you can even play at 20+ fps with window that is still significantly larger than post stamp.

Any area that has a lot of moving platforms (eg. E2M3) destroys the FPS when it is in the player line-of-sight, as the CPU needs to calculate all of the platforms - this was on my 386SX-40. Any situation for where there's a lot of active monster AI (eg. HR2FINAL.WAD MAP32) will also destroy the FPS, but that's an unavoidable situation - I can still see sub-30 FPS on a 500Mhz Coppermine Pentium III with that specific map, but I use that map with a tool-assisted UV-max demo purely for benchmarking.