ViTi95 wrote on 2022-12-16, 09:33:

While developing optimizations for Potato mode i've just discovered a bug that I think it hasn't been documented and exists sinc […]
Show full quote

While developing optimizations for Potato mode i've just discovered a bug that I think it hasn't been documented and exists since... 1994 (!!) It just happens that Heretic has a rendering bug on R_DrawSpan (which is ASM optimized and it's much faster compared to Doom R_DrawSpan). It basically renders the first pixel twice and then continues rendering the rest without issues. It's hard to find on a 320x200 resolution, but it becames very obvious on FastDoom's potato mode (80x200):

Here is the bug on Heretic:
heretic_002_double.pngheretic_002_zoom.png

And here is the same bug on FastDoom's Potato mode:
dos4gw_000_double.pngdos4gw_000_zoom.png

Right now, the bug has been fixed and these are some performance numbers:

FastDoom 0.9.1: 27.632 fps
FastDoom 0.9.2: 33.860 fps

This is 22% faster, on a 386DX-40 (Ultimate Doom timedemo demo3, fullscreen+HUD and no sound). And here is the cool thing, the same optimization will be applied for low detail and high detail modes on Mode Y, so expect performance uplift on the next release 😁

rmay635703 wrote on 2022-12-10, 04:38:

Doom on CGA without 16bit x86 support is a travesty
Harris 286-25 🙁 no doom

Yeah I know, as is already been said, is very hard to port Doom to 16-bit only instruction set. Maybe some crazy developer (and more experienced than me) could achieve this. Or make Wolfenstein 3D Hercules/CGA/EGA compatible 😏

22% is an outstanding result! Congrats!

FastDoom 0.9.2 is released!

Changelog:

- New video mode, IBM CGA 80x100 "512 color" mode with composite output (available for old and new IBM CGA cards)
- Optimized R_DrawColumnPotato and R_DrawSpanPotato for Potato mode in FDOOM.EXE, up to 22% more FPS
- Optimized R_DrawColumnLow for Low detail in FDOOM.EXE, up to 10% more FPS
- Optimized R_DrawColumn for High detail in FDOOM.EXE, up to 10% more FPS
- FDOOMEGA.EXE now uses same thechnique as FDOOME14.EXE but with full 16 colors, so FDOOME14.EXE has been removed as is not needed anymore (and now FDOOMEGA.EXE is much faster)
- Huge video code refactor, much easier to create and mantain new video modes (no changes in terms of performance)
- Removed VGA 80x100 and EGA 80x86 text modes. Too slow on real hardware, they required lot's of VRAM reads which are very slow
- Removed EGA 160x100 text mode. Other EGA video modes offer much better quality, and have better aspect ratio
- Removed 136 pseudo-color modes, as CGA modes have been superseeded with better ones, same for EGA/VGA
- Minor optimizations here and there

https://github.com/viti95/FastDoom/releases/tag/0.9.2

This just keeps getting more awesome. Congrats on the bug fix, that must have been a satisfying moment!

A couple issues here. I couldn't get the sound working in 0.9.2 for either the CGA512 or regular FDOOM. I went back and tested 0.9.1 and the sound is fine. I tested with the most recent Staging, SVN and ECE.

Also, I couldn't get the composite output to work in SVN or ECE. Staging it worked fine. Composite output works totally fine with any other period CGA games I've tried (Tass Times in Tonetown for example) and with Planet X 3 using ECE and SVN.

I don't mind using Staging at all, but I can't get the sound working. Any ideas?

I've rebuilt and reuploaded the executables, those are working on my 486 without music/sound issues. I think I messed up the upload (first time doing the whole process on linux, earlier releases were done with windows). Please check if that has fixed the problem. About composite mode, my CGA card still doesn't output composite video, so the only way I had to test it was using dosbox-staging. I'll try on SVN and ECE to debug what's wrong on those emulators.

I noticed viewsize bugs in FDOOMEGA (possibly others) as if the viewport's shifted up some 16 pixels

I got the sound working in Staging. I had to go into the config and turn off the filters for soundblaster and opl. I'm not sure why that worked, but it did. They were set to default, so that should have been the same as regular DOSBox, but it made a difference for some reason. I wish I had more time to troubleshoot, I'll try tomorrow.

leileilol wrote on 2022-12-21, 02:06:

I noticed viewsize bugs in FDOOMEGA (possibly others) as if the viewport's shifted up some 16 pixels

I've found the bug and fixed it, now the viewport should be ok on backbuffered modes. Thanks for reporting it!!

ViTi95 wrote on 2022-12-21, 09:37:

leileilol wrote on 2022-12-21, 02:06:

I noticed viewsize bugs in FDOOMEGA (possibly others) as if the viewport's shifted up some 16 pixels

I've found the bug and fixed it, now the viewport should be ok on backbuffered modes. Thanks for reporting it!!

Hi! thanks a lot

i tested yesterday new version and i confirm the big speed up

My timedemo1 went from 37.7 to 42.3fps amazing!!!

I will test new version tonight

I have a small question, it supposed mode 13h is faster than regular?

because in my computer, DX4-75 CL5428 VLB, all test i did 13h is slower

thanks

I'm thinking this release probably made Doom very playable on a DX33? I wish I had that on my PC at the time 😁

theelf wrote on 2022-12-21, 13:37:

I have a small question, it supposed mode 13h is faster than regular?

Yes, especially if vsync isn't enabled on faster computers. While mode Y is slow by default, it has some advantages such as page flipping (faster than vsync) in the case of DOOM to eliminate tearing.

I've done some benchmarking and the fastest mode is VBE2 Direct, followed by 13h and lastly Mode Y, although I haven't compared the latest release. Use VBE2 Direct mode whenever possible, it uses the Heretic rendering functions and writes directly on VRAM. It's the best combination possible, it avoids rendering on RAM (which is slow on 386/486 processors), and also avoids calling OUT instructions to set the plane in Mode Y for each X position (which are also very slow). It also supports triple buffering so it doesn't require VSync to avoid tearing. Cirrus Logic VLB cards are supported using SciTech Display Doctor 5.3a, the only issue is that those cards have the "16Mb limit" problem.

I'm still trying to optimize R_DrawSpan and R_DrawSpanLow for mode Y, I'm pretty sure extra performance can be obtained.

EDIT: I'm pretty sure Mode Y is faster than Mode 13h on your 486DX4 75MHz due to the slower 25MHz bus

ViTi95 wrote on 2022-12-21, 14:48:

I've done some benchmarking and the fastest mode is VBE2 Direct, followed by 13h and lastly Mode Y, although I haven't compared the latest release. Use VBE2 Direct mode whenever possible, it uses the Heretic rendering functions and writes directly on VRAM. It's the best combination possible, it avoids rendering on RAM (which is slow on 386/486 processors), and also avoids calling OUT instructions to set the plane in Mode Y for each X position (which are also very slow). It also supports triple buffering so it doesn't require VSync to avoid tearing. Cirrus Logic VLB cards are supported using SciTech Display Doctor 5.3a, the only issue is that those cards have the "16Mb limit" problem.

I'm still trying to optimize R_DrawSpan and R_DrawSpanLow for mode Y, I'm pretty sure extra performance can be obtained.

EDIT: I'm pretty sure Mode Y is faster than Mode 13h on your 486DX4 75MHz due to the slower 25MHz bus

Hi, tanks for reply

Sadly CL-GD5424 card not support vesa LFB, SDD say LFB is not supported i dont know if there is some fix?, then FDOOMVBD is not working. Real mode vesa version works, but is even slower than 13h

I tested SDD 5.3 and 6.7 even if i force LFB on, fastdoom not work

Im very VERY happy with regular mode Y fastdoom, but of course any tips for get extra fps are welcome jaja

How much RAM do you have in your 486? Cirrus Logic cards cannot map it's VRAM above the first 16Mb, so it's required to have less than 16Mb to be able to map the linear framebuffer of the video card. I use mine with 12Mb of RAM (8+4), as SDD refuses to enable the LFB with 16Mb. Maybe that's the issue, although I haven't tested a GD5424, I only own a GD5426 and a GD5428.

ViTi95 wrote on 2022-12-21, 22:44:

How much RAM do you have in your 486? Cirrus Logic cards cannot map it's VRAM above the first 16Mb, so it's required to have less than 16Mb to be able to map the linear framebuffer of the video card. I use mine with 12Mb of RAM (8+4), as SDD refuses to enable the LFB with 16Mb. Maybe that's the issue, although I haven't tested a GD5424, I only own a GD5426 and a GD5428.

mm... i have 16mb ram... ok Im not home right now, tomorrow i will check with 8mb and tell you

thanks for tip!!

ViTi95 wrote on 2022-12-21, 22:44:

How much RAM do you have in your 486? Cirrus Logic cards cannot map it's VRAM above the first 16Mb, so it's required to have less than 16Mb to be able to map the linear framebuffer of the video card. I use mine with 12Mb of RAM (8+4), as SDD refuses to enable the LFB with 16Mb. Maybe that's the issue, although I haven't tested a GD5424, I only own a GD5426 and a GD5428.

I never knew this.. This is a really weird limitation. I have 16MB in my PS/1 with an onboard 542x, should I be worried? SMH..

Most motherboards from that period have bios option to open/reserve 15-16MB ISA addressing window for this very reason.

rasz_pl wrote on 2022-12-22, 07:25:

Most motherboards from that period have bios option to open/reserve 15-16MB ISA addressing window for this very reason.

Not my PS/1 IIRC.. I'll check.

appiah4 wrote on 2022-12-22, 07:18:

ViTi95 wrote on 2022-12-21, 22:44:

How much RAM do you have in your 486? Cirrus Logic cards cannot map it's VRAM above the first 16Mb, so it's required to have less than 16Mb to be able to map the linear framebuffer of the video card. I use mine with 12Mb of RAM (8+4), as SDD refuses to enable the LFB with 16Mb. Maybe that's the issue, although I haven't tested a GD5424, I only own a GD5426 and a GD5428.

I never knew this.. This is a really weird limitation. I have 16MB in my PS/1 with an onboard 542x, should I be worried? SMH..

I think this limitation comes from the ISA addressing limits, it has a 24-bit addressing space (16Mb). Cirrus Logic modified it's IC design for the ISA bus to work on the VLB in the most simple way. The addressing space is the same, not upgraded to 32-bits, and the 32-bits transfers are done as 2x16 bits transfers (that's why transfer speed is the same using 16-bit transfers or 32-bit transfers) . Cirrus Logic VLB cards are faster just because of the faster bus, jumping from 8.33MHz to 33+MHz is a huge leap.

ViTi95 wrote on 2022-12-21, 22:44:

How much RAM do you have in your 486? Cirrus Logic cards cannot map it's VRAM above the first 16Mb, so it's required to have less than 16Mb to be able to map the linear framebuffer of the video card. I use mine with 12Mb of RAM (8+4), as SDD refuses to enable the LFB with 16Mb. Maybe that's the issue, although I haven't tested a GD5424, I only own a GD5426 and a GD5428.

Hi! i tested with 8MB and sadly LFB is not supported on the 5424, i tested SDD5.3 and SDD6.7, both same, fastdoom show one second of screen then hang with black screen

Anyways, i want to say thank you again!!! is amazing the difference

Doom Shareware 1.9

doom -timedemo demo3 -nosound = 30.02fps

Fastdoom 0.9.1

doom -dimedemo demo3 -nosound = 37.9fps

Fastdoom 0.9.2

doom -dimedemo demo3 -nosound = 42.2fps

BUT!! i dont know if 0.9.2 benmchmark is OK since the demo never finish, at almost the end of demo doom guy kill two soldiers before enter elevator. In 0.9.2 only kill one, fail second, and demo do strange thing jaja