I think i need to apologise to @viTi95 for my post this morning - i think my instability issues are now caused by hardware, not the latest fdoom release. the issue seems to be some faulty dip ram i added to the amiga recently. i noticed that other stuff running on the bridgeboard now wasnt stable - removing the dips seems to have fixed this, and indeed fdoom runs fine. fdoom13h appearsto have given me an approx 6-7% fps boost too, which is great 😀 more benchmarking tomorrow.

noticed that if i run FDOOMBWC.EXE -file mode16.wad it appears even better looking.

i think also is good option to turn on lightamplification visor (to be alway turned on) so it removes shadows and will look as Wolf3d or catacomb3d or hover tank 3d. (idbeholdl ) (but always on) it makes better looking on BWC and EGA,
the CGA is ugly =((( but i think nothing possible to do here except composite.

also dithering is a very good thing, its possible to do dithering for CGA and EGA? with dobling resolution? (by doubling resolution we have 2x2 matrix of 5 grades) if possible to use eve higher resolution that it leads to more dithering grades of colors.

also is good idea on look how called "3d" games released before doom works , looks like.

probably for each video mode is also good to make optimized palette as for EGA a MODE16.WAD

Thanks =) as always good release =)

It's possible to apply dithering to EGA 640x200 mode, as the ordered dithering 2x2 reduces the resolution in half (effective resolution would be 320x100, same happens for the CGA 640x200 B&W). I'm still trying to find an ordered dithering implementation for color modes, as the one I used for Hercules and monochrome CGA only worked for monochrome output. But I think there is a mayor problem for this mode, most ISA 8-bit EGA cards are painfully slow, even for the 320x200 mode, it will be even worse for the 640x200 mode (twice data to be transfered to the vram per frame). Regarding palettes, the new release tries to load an specific WAD for each video mode, so feel free to create an optimized one (I'm still trying to create one optimized for monochrome and 4 color modes).

1#ifdef MODE_EGA
2    D_AddFile("mode16.wad");
3#endif
4#if defined(MODE_T25) || defined(MODE_T50)
5    D_AddFile("modetxt.wad");
6#endif
7#if defined(MODE_CGA_BW) || defined(MODE_HERC)
8    D_AddFile("modebw.wad");
9#endif
10#ifdef MODE_CGA
11    D_AddFile("mode4.wad");
12#endif

@trixter no worries, I also have that problem with my own hardware, it's a pretty common situation.

Benchmarks for my bridgeboard Vortex GoldenGate TI486SXLC at 50mhz (8k cache, 16bit external bus) in an Amiga 3000D. All tested with one level of green border. Machine has an ATI Mach64 ISA, SB AWE64 ISA, 16MB 60ns ram, 512MB IDE DOM.
Common FDoom parameters are -mono -fps -saturn -near -melt. Ultimate Doom WAD, timedemo demo3

Regular Doom = 9.215 fps
Regular Doom -nosound = 10.727

FDoom 0.8 = 12.357
FDoom 0.8 -nosound = 13.454

FDoom 0.81 = 12.210
FDoom 0.81 -nosound = 13.276

FDoom13H = 12.270
FDoom13H -lowsound -8bitsound = 12.275
FDoom13H -nosound = 13.372
FDoom13H -nosound -ram = 13.368

---------------------
version 0.8 is actually slightly faster for me than 0.81 and 0.81 13H, which seems a little odd.

These figures above were taken when the bridgeboard is launched from the Amiga Workbench, and this creates an overhead.

Booted from no startup-sequence improves bridgeboard performance:

Regular Doom -nosound = 9.542
FDoom 0.8 -nosound = 14.156
FDoom 0.81 = 12.340
FDoom 0.81 -nosound = 13.473
FDoom13H = 13.044
FDoom13H -lowsound -8bitsound = 13.205
FDoom13H -nosound = 14.380
FDoom13H -nosound with full screen inc HUD = 12.390
Finally, FDoom13H -lowsound -8bitsound with full screen inc HUD = 11.314
Weird now that the 13H is faster than normal!

Is alternate checkerboard dithering on alternate frames a viable option? Heard some things use that for good speed and perceptual visual quality. i.e. a single frame capture looks awful, but the human eye thinks it looks better when it sees several frames a second.

I'm kinda waiting for someone to break out a Harris 25Mhz 286 and see how it runs with 386 emulation 🤣 (That was a thing I swear, ran it myself before)

So @viTi95, do you think sound performance can be improved? It seems to reduce fps by 10-15% at the moment

Do you have any example or implementation @BitWrangler? I haven't tested that kind of dithering implementation, I guess it's possible to implement but framerate is very variable in Doom when the cpu isn't fast enough, don't know how would that look.

I'm still waiting for someone to port Doom to 16-bit x86 code (the SNES version of Doom uses a Super FX 2 that executes 16-bit code at 21 MHz) 🤣

@trixster the sound code is very intensive, i've been trying to optimize it but the Apogee Sound System is already very well optimized (even with assembly hand crafted code). I'm still learning how it works, to add support for new sound cards and to try to minimize it's impact in performance. The main problem is that all sound cards sends an IRQ to receive more sound data, and that IRQ processsing is what reduces the performance.

ViTi95 wrote on 2021-05-28, 19:33:

Do you have any example or implementation @BitWrangler? I haven't tested that kind of dithering implementation, I guess it's possible to implement but framerate is very variable in Doom when the cpu isn't fast enough, don't know how would that look.

Right, dips low on slower systems, according to NASA we'd want framerates over 20fps https://humanfactors.arc.nasa.gov/publication … igan_spie93.pdf
maybe a thing for "slowdoom" to look like high color at 30fps locked framerate on fast systems.

Another crazy idea: Modern games use Dynamic resolution scaling (DRS) and Variable Rate Shading (VRS).
FastDoom could have a mode where it monitors frame render times and dynamically switches between full, half and quarter resolution detail modes to keep FPS above certain number, like for example 20 (or configurable).

Another crazy idea: Modern games use Dynamic resolution scaling

That's possible due to deferred rendering and overall long rendering pipeline. That stuff must be heavily buffered.

TIGA support for texturing?

rasz_pl wrote on 2021-05-29, 03:40:

Another crazy idea: Modern games use Dynamic resolution scaling (DRS) and Variable Rate Shading (VRS).
FastDoom could have a mode where it monitors frame render times and dynamically switches between full, half and quarter resolution detail modes to keep FPS above certain number, like for example 20 (or configurable).

Some games like Indycar Racing were able to change graphics details ingame if the framerate was too slow or high enough, so it's possible to implement something similar for FastDoom. The only problem here it's that the resolution change makes some processing that takes a bit of time to execute, so the resolution change has to be optimized first so the resolution changes don't slowdown the game.

mrau wrote on 2021-05-29, 20:50:

TIGA support for texturing?

That would be awesome, but there are several problems here. TIGA wasn't a standard, every company developed their own drivers and SDKs, so adding support for every card would be very complex. Another big problem is that Dosbox nor PCEm emulate any TIGA card, and I don't have one of those cards (I wish I had one). Maybe it's possible to do something similar with the IBM 8514 standard, I do have one ATI Mach 8 and a Mach 32 that support that mode. But for now i'm dedicated to implement VBE 2.0 support.

ViTi95 wrote on 2021-05-30, 01:59:

TIGA wasn't a standard, every company developed their own drivers and SDKs, so adding support for every card would be very complex. Another big problem is that Dosbox nor PCEm emulate any TIGA card, and I don't have one of those cards (I wish I had one).

ok thats a showstopper; sorry about the misinfo - was under impression that TI was defining this as standard

ViTi95 wrote on 2021-05-30, 01:59:

Maybe it's possible to do something similar with the IBM 8514 standard, I do have one ATI Mach 8 and a Mach 32 that support that mode.

sounds interesting; line, fill, bitblt - that might speed up drawing the osd possibly? not sure about other elements though; it does not handle low res per se seemingly, there are clones which are not register compatible and there is no memory mapping in the standard - that last one might hurt? can bitblt be applied for texturing? im not sure ; et4000 supposedly supports this- that's many potential users; maybe aim at functionality common for mach32 and et4000? - these are faster and more sophisticated than the standard demands and user base is wide

ViTi95 wrote on 2021-05-30, 01:59:

But for now i'm dedicated to implement VBE 2.0 support.

hi res? or linear frame buffer modes? vbe2 is quite a bit more modern than most doom dedicated pcs

last resort - a microcontroller well available on the market, some memory and a propeller chip; if the toys don't satisfy, make ones own?

vbe2 is quite a bit more modern than most doom dedicated pcs

That standard was released before The Ultimate Doom (1995).

The idea of the VBE 2.0 support is to support only 320x200 at 8 bits, both banked and linear modes. This mode is flicker free compared to mode 13h, and in some cases could be faster. I think 486 processors with VLB or PCI bus can benefit from this. I've got it working but it's unstable, and sometimes the system just crash or don't even start. Any help would be greatly appreciated.

https://github.com/viti95/FastDoom/commits/VBE2

EDIT: i've done a simple benchmark with a Pentium III 550 and an ATI Rage II PCI:

• Mode 13h: 177.133 fps
• Mode VBE2: 300.277 fps (69.5% faster)

https://www.youtube.com/watch?v=kRwPVBd2kkw

mrau wrote on 2021-05-30, 13:03:

sounds interesting; line, fill, bitblt - that might speed up drawing the osd possibly? not sure about other elements though; it does not handle low res per se seemingly, there are clones which are not register compatible and there is no memory mapping in the standard - that last one might hurt? can bitblt be applied for texturing? im not sure ; et4000 supposedly supports this- that's many potential users; maybe aim at functionality common for mach32 and et4000? - these are faster and more sophisticated than the standard demands and user base is wide

I'll investigate how that mode works and what is doable, fill function can be used for rendering without textures (flat visplanes for example) and BitBLT can be used for rendering the status bar and the messages. Texture mapping requires dedicated hardware, I don't think it can be done with BitBLT functions. Maybe some one can prove me wrong!

I think 486 processors with VLB or PCI bus can benefit from this.

From my observations with Quake, there is some benefit.

i'll just say - your mastery of the compiler is far beyond anything i could offer so any support would be limited;
tried to decipher your last 2 VBE commits and i do not see anything that could be causing this but then my understanding is far from complete

it does not say in bug report if this is a specific branch or what; from description just lockup - so either waiting on hardware state or some loop that does not end?
it does not match hardware description either - sound canvas not present in machine from report so a hang is possible always?

i just hope it will occur in dosbox, but i need to switch my linux distro first;

ViTi95 wrote on 2021-05-30, 16:07:

VBE 2.0 .....in some cases could be faster.

https://www.youtube.com/watch?v=7PjA6PfyWW8

1 fps difference on fast 486, where is that speed coming from? I looked at the code and you are doing everything (well, almost, the code on github looks older, no I_FULLSCRN/I_FULLVIEW/I_STATBAR for vesa yet, but I imagine its the same) just like in 13h, except initializing VGA with VESA call?
Is CopyDWords simply faster when the destination is vesavideoptr versus 0xA0000?

btw have you tried rendering directly into 0xA0000/vesavideoptr? how much slower was that?

thats 9 fps on that vid; the new modes are seemingly handled better on the hardware - maybe lack of some features makes them easier to handle in the newer mode? does scrolling work like on 13h?

btw is there any graphics card that will do the copying from buffer to screen for us?

Just checked the new release, and the crash on MAP15 in Freed∞m persists. Interestingly, with the default Mode X binary the game just froze with the music still playing normally, while in Mode 13h it crashed to a screenful of text gibberish with music/sound a garbled mess.