Bug for FDOOM2 (486) - start up Map01, kill some zombiemen on the stairs. Take out chainsaw and saw away. Bulletpuffs will appear in mid air when standing on/near a corpse.
Also music support for Gravis UltraSound appears to be broken.

shock__ wrote on 2020-09-16, 20:07:

Bug for FDOOM2 (486) - start up Map01, kill some zombiemen on the stairs. Take out chainsaw and saw away. Bulletpuffs will appear in mid air when standing on/near a corpse.
Also music support for Gravis UltraSound appears to be broken.

I tested it and the problem is not with chainsaw and zombiemen, but with chainsaw and any stairs (use the chainsaw near any wall and it will show the bulletpuffs). Punch it's not affected by this bug. I tracked back this bug to version 0.66 and upwards, so i will try to fix it in the next version. It also seems to be only a visual problem.

Anyway thanks for reporting this bug!

Forgot to post this, I made some benchmarks with FastDoom 0.666 in one of my testbenchs.

FastDoom 386 build, Doom shareware 1.9 WAD, Demo3, default fullscreen + hud.
CPU: Cyrix CX486 33Mhz (8Kb L1 WB)
Mainboard: CH 498B (512Kb L2 WB)
RAM: 32Mb EDO
Video card: Generic S3 805i VLB (1Mb)
Sound card: None
I/O card: Generic IDE ISA
HDD: Generic CompactFlash 256Mb

Main conclusions:

• FastDoom 0.666 is 20% faster in high quality, and 28% faster in low quality compared to Doom shareware 1.9 (fullscreen + hud)
• FastDoom low quality is ~1.7 times faster than FastDoom high quality (fullscreen + hud)
• FastDoom Potato quality is ~2.5 times faster than FastDoom high quality (fullscreen + hud)
• Flatter surfaces isn't faster compared to flat surfaces with low quality and high quality. Flat surfaces gives 20% extra performance in low quality, and 17% in high quality. Flatter surfaces is faster with potato quality, giving 26% extra performance.
• Reduced screen size gives an important boost
• The other visual optimizations have minimal impact in performance

New Release! FastDoom 0.7 Release Candidate 1

I've made this release as a release candidate due to the inability to test all the new features and optimizations with real hardware. Your help would be highly appreciated 😁

https://github.com/viti95/FastDoom/releases/tag/0.7_RC1

• Added Stereo OPL2, OPL3 and Stereo OPL3 music support (Adlib uses basic OPL2, Sound Blaster tries to detect the best possible option)
• Added Disney Sound Source (also Tandy Sound Source) sound support. You have to manually set "snd_sfxdevice" variable in the "default.cfg" file to 12 (Disney Sound Source) or 13 (Tandy Sound Source). There are three new command line options to force the parallel port in case auto-initialization process doesn't work ("-LPT1" -> port 3bc, "-LPT2" -> port 378, "-LPT3" -> port 278). COVOX / LPT DAC is not supported.
• Fixed Gravis Ultrasound music support
• Added profiling support in the makefile (Intel Pentium processor required)
• Added option that forces 8 bit audio mixing instead of 16 bit (-8bitsound)
• Fixed potato invisible column renderer (issue #2)
• Fixed chainsaw incorrect behaviour (issue #9)
• Fixed all items respawn when loading a savegame (issue #10)
• Fixed Arch-Vile fire spawned at the wrong location (original Vanilla Doom blatant error)
• Fixed Chaingun makes two sounds firing single bullet (another Vanilla Doom error, fixed as there is no multiplayer support)
• Fixed invulnerability sky colormap
• Removed IDMYPOS cheat
• Added VSYNC support (-vsync)
• Added new command line parameters that disable some optimizations (bypassing the saved configuration, made for benchmarking): -normalsurfaces, -normalsky, -normalshadows, -normalsprites, -stereo, -melt, -capped, -novsync, -nofps.
• All new options finally are saved in default.cfg
• As always added more optimizations (mostly ASM optimized multiplications, divisions and modulo, faster screen melting code, faster cheats detection, optimized sound code, faster potato mode [thanks @Optimus6128 !!])

Sounds promising! I'll do some benchmarks with the same system again 😀

I ran a series of timedemos again, and they've improved quite a bit since v0.6. It's running above 40FPS now!

I never tested 0.666 so I don't know which release gave the biggest speed boost. If you want to know, I can test 0.666 as well.

System: Am486 DX4 120MHz, no L2, 16MB, Tseng ET4000/W32 1MB VLB, ESS ES1869

Fastdoom 0.7-RC1, 386 exe, real mode, no driver TSRs, with audio:
demo1: 1461 realtics (40.484 fps)
demo2: 1879 realtics (43.358 fps)
demo2: 2928 realtics (46.088 fps)

---

Fastdoom 0.7-RC1, 486 exe, real mode, no driver TSRs, with audio:
demo1: 1470 realtics (40.356 fps)
demo2: 1884 realtics (43.300 fps)
demo3: 2933 realtics (46.048 fps)

Thanks @HandOfFate for testing! 0.7 RC1 it's nearly 16% faster on average compared to 0.6, which makes me really happy. I should update the github readme with new results, can you run the demos again with Vanilla Doom? I want to see how much faster is FastDoom compared to Vanilla Doom.

Sure, no problem. v1.9 of non-ultimate Doom?

With the same configuration / WAD that you are using to test FastDoom, it's better an apples to apples comparison 😁

I got the numbers. Ultimate Doom v1.9 in the same environment (no TSR, real mode, with audio):

demo1: 1753 realtics
demo2: 2249
demo3: 3467

That means that FastDoom is 16~17% faster on this machine. Very impressive 😀

ViTi95 wrote on 2020-10-23, 09:51:

• As always added more optimizations (mostly ASM optimized multiplications, divisions and modulo, faster screen melting code, faster cheats detection, optimized sound code, faster potato mode [thanks @Optimus6128 !!])

Just curious - are the ASM-optimized math routines supposed to produce exactly the same results as the originals, or are they like the -ffast-math compiler optimization? As in, same mathematical operation, but potentially different results due to floating-point operations being re-ordered, division approximation by reciprocals, etc.

LightStruk wrote on 2020-11-02, 03:01:

As in, same mathematical operation, but potentially different results due to floating-point operations being re-ordered, division approximation by reciprocals, etc.

I don't think there are any floating-point operations in DOOM at all, are there?

LightStruk wrote on 2020-11-02, 03:01:

ViTi95 wrote on 2020-10-23, 09:51:

• As always added more optimizations (mostly ASM optimized multiplications, divisions and modulo, faster screen melting code, faster cheats detection, optimized sound code, faster potato mode [thanks @Optimus6128 !!])

Just curious - are the ASM-optimized math routines supposed to produce exactly the same results as the originals, or are they like the -ffast-math compiler optimization? As in, same mathematical operation, but potentially different results due to floating-point operations being re-ordered, division approximation by reciprocals, etc.

Yes, those ASM optimizations are supposed to produce exact same results, as they are generated with GCC (-O3 -march=<i386, i486>) via GodBolt (for example, https://godbolt.org/z/7e8be7) and then backported to OpenWatcom ASM. OpenWatcom base code is really old, and doesn't have implemented some cool optimizations that GCC has.

The main problem with Vanilla Doom sourcecode is that it isn't possible to use GCC to generate the executable, because the rendering functions (R_DrawColumn, R_DrawSpan, ...) and a big part of the Apogee Sound System are generated with TASM, and GCC doesn't support the OBJ files generated with it.

dr_st wrote on 2020-11-02, 06:23:

I don't think there are any floating-point operations in DOOM at all, are there?

You're right, there isn't any floating-point operation in Doom, just fixed-point and arithmetic math.

Damn, that's some hardcore coding !

New release, FastDoom 0.7 Release Candidate 2. Minor changes, mostly bugfixes.

• Fixed some command line parameters not working as expected
• Vsync option now is stored correctly
• Faster melting screen
• Faster flat drawing functions (unrolling by 4)
• More ingame code optimizations
• Fixed issue #14 (Cacodemons bites instakill, even with IDDQD enabled, only happened in FastDoom 0.7 RC1)

https://github.com/viti95/FastDoom/releases/tag/0.7_RC2

FastDoom 0.7!

Full changelog:

• Added Stereo OPL2, OPL3 and Stereo OPL3 music support (Adlib uses basic OPL2, Sound Blaster tries to detect the best possible option)
• Added Disney Sound Source (also Tandy Sound Source) sound support. You have to manually set "snd_sfxdevice" variable in the "default.cfg" file to 12 (Disney Sound Source) or 13 (Tandy Sound Source). There are three new command line options to force the parallel port in case auto-initialization process doesn't work ("-LPT1" -> port 3bc, "-LPT2" -> port 378, "-LPT3" -> port 278). COVOX / LPT DAC is not supported.
• Fixed Gravis Ultrasound music support
• Added profiling support in the makefile (Intel Pentium processor required)
• Added option that forces 8 bit audio mixing instead of 16 bit (-8bitsound
• Fixed potato invisible column renderer (issue #2)
• Fixed chainsaw incorrect behaviour (issue #9)
• Fixed all items respawn when loading a savegame (issue #10)
• Fixed Arch-Vile fire spawned at the wrong location (original Vanilla Doom blatant error)
• Fixed Chaingun makes two sounds firing single bullet (another Vanilla Doom error, fixed as there is no multiplayer support)
• Fixed invulnerability sky colormap
• Fixed issue #14 (Cacodemons can instakill you with a single bite in 0.7 RC1, even with god mode)
• Fixed issue #16 (Video garbage being drawn outside the game window area, only in 0.7 RC2)
• Fixed some command line parameters not working as expected
• Removed IDMYPOS cheat
• Added VSYNC support (-vsync)
• Added new command line parameters that disable some optimizations (bypassing the saved configuration, made for benchmarking): -normalsurfaces, -normalsky, -normalshadows, -normalsprites, -stereo, -melt, -capped, -novsync, -nofps.
• All new options finally are saved in default.cfg
• As always added more optimizations (mostly ASM optimized multiplications, divisions and modulo, faster screen melting code, faster cheats detection, optimized sound code, faster potato mode [thanks @Optimus6128 !!], faster melting screen, faster flat drawing functions)

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

Neat ... went from exactly 1000 tics to 976 tics on my POD100 system.

Thank you for the new release, I did some testing with different 486 cpus just to check the performance versus the vanilla doom, here are the results:

Nemo1985 wrote on 2020-12-04, 11:34:

Thank you for the new release, I did some testing with different 486 cpus just to check the performance versus the vanilla doom, here are the results:
image_2020-12-04_12-32-42.png

Wow thanks for testing, i'm curious of what hardware specs and configuration did you use for the benchmarks.

ViTi95 wrote on 2020-12-04, 11:59:

Nemo1985 wrote on 2020-12-04, 11:34:

Thank you for the new release, I did some testing with different 486 cpus just to check the performance versus the vanilla doom, here are the results:
image_2020-12-04_12-32-42.png

Wow thanks for testing, i'm curious of what hardware specs and configuration did you use for the benchmarks.

I used a Biostar-MB-8433UUD rev 2 with the feipoa modified bios optimizations, 32mb of ram and a pci Virge DX 4mb, the videocard is overkill but on 486 I usually look for such situation to check the raw cpu performance.
As OS I used Dos 7 with minimal configuration.