FastDoom: DOS Vanilla Doom optimized for 386/486 processors

[Optimus]

7 hours ago, viti95 said:

Interesting WAD, i'll try some benchmarks on both my 386 and 486. I think your 386 is limited by the low amount of RAM, 4Mb will cause the game to stutter while loading and unloading assets from HDD. That's why enabling/disabling SmartDrive causes the performance to change. SmartDrive uses part of the RAM to cache data from the HDD, and that results in less memory available for Doom (which itself caches all the data). It also uses more cpu cycles while loading from the HDD.

 

I actually have 8MB on my 386, but good point about smartdrive

[Maes]

Well, nobody in their right mind would attempt to run Doom AND SmartDrv with just 4 MB of RAM. That being said, there were some cases (relatively small or not very resource-heavy WADs) where using SMARTDRV would actually speed up loading, by keeping in RAM resources that Doom's cache management system would unload even if there wasn't any imminent RAM pressure. It also allowed DOOM to shut down and restart pretty quickly, which could be useful if you were going through a bunch of crappy 1994 PWADs or recording demos. Of course you needed e.g. 8 MB to do that for stuff that would run "just OK" with 4 MB.

[Redneckerz]

@viti95 Found you another port of interest, EmbeddedDoom (EmDoom). A port for memory strapped systems.

 

Specifically this commit.

 

You may also want to look at FBDoom and DoomGeneric for ports that purely go to the Framebuffer and making porting easier. Also: MicroDoom, a ChocoDoom port that actually removes features so you can check out what is needed and what not.

[drfrag]

WOW! Everything is in one commit titled "This is what I've been working with. Most changes are in." He could have named it just "My stuff".

[viti95]

8 minutes ago, drfrag said:

WOW! Everything is in one commit titled "This is what I've been working with. Most changes are in." He could have named it just "My stuff". 

 

LOL Best commit ever, no doubts.

 

Thanks for the info @Redneckerz!! I'll check how fbDoom works, as i'm implementing a VGA Mode 13h renderer. It's nearly done but there are some bugs that i need to fix (specially the V_CopyRect and melting functions as there is no multiple screens in Mode 13h).

[viti95]

New release (FastDoom 0.66) !!

 

- Savegames are working again (broken in 0.6). Still not compatible with vanilla doom savegames, but at least it's working (latest version with compatible savegames is 0.5).
- Potato detail mode is now selectable from the options menu. Also it's selectable by pressing F5 ingame.
- Support for unlimited sprites. Doom II MAP30 now doesn't crash if there are too many enemies. Also NUTS.WAD is partially working (albeit your 386 won't be doing 144 fps 🤣).
- Experimental new uncapped fps mode. Enabled with "-uncapped". It has rendering problems and won't interpolate movement between frames. It allows you to see how "fast" can be your pc in realtime.
- Added "-forcePQ", "-forceLQ" and "-forceHQ" parameters. It allows setting the video detail quality from command line. Useful for benchmarks.
- More internal optimizations.

 

Grab it here! https://github.com/viti95/FastDoom/releases/tag/0.66

Edited September 3, 2020 by viti95

[Wagi]

Curious, since you've managed to make the sprites unlimited, did you also update the sprite sorting algorithm as well? The one in vanilla Doom is a basically a selection sort --- pretty much the slowest algorithm possible. I'll be the first to admit I don't know if it actually is faster than a "better" algorithm when there are 128 or fewer vissprites though.

[viti95]

@Wagi the sorting algorithm is merge sort, as the implementation for unlimited sprites it's the same as MBF. I've changed the memory allocation to use the internal zone memory, rather than the outside malloc memory.

 

The performance it's about the same for low amount of sprites, but it's much faster when the number of sprites is high.

[fabian]

Actually, Vanilla's sorting algorithm isn't *that* bad if the sprites are already pre-sorted to a certain degree - which they are, because sprites are added by subsector. However, I have entirely replaced it with the system's native qsort() algorithm in Crispy Doom.

[Maes]

Heh, that reminds me of a tricky question in an old CS book -where Alice claimed that her Selection Sort algorithm was faster than Bob's quick sort algorithm, and the trick question was to determine how and when this could be possible.

 

On shitty old computers with a joke of a cache and an OS that doesn't have lightweight function calls, coupled with a low number of elements, this can certainly be the case -the "break even" point may be surprisingly high.

[viti95]

Quick video with the new video options menu :D

 

 

[taufan99]

Nice job putting the options on the menu!

[viti95]

Time for a new release!! FastDoom 0.666

 

• Renamed executable to FDOOM.EXE / FDOOM2.EXE
• Added all FastDoom display options and sound options in the options menu (only screen size option is saved, next versions will fix this)
• Added "-reverseStereo" command line option to reverse Left/Right stereo speakers. Your Sound Blaster PRO will love this.
• Added "-size |screensize|" command line option to force screen size. Values allowed are 3 to 11, being 3 the smallest possible, 10 full screen with HUD and 11 the biggest, fullscreen without HUD.
• Added "-logTimedemo" option to save the benchmark result onto the file "bench.txt". With this it's possible to run multiple FastDoom benchmarks in a batch and save the results in a single text file. Requires "-timedemo".
• Removed "-cdrom" command line option.
• Fixed bug that made some sprites look corrupted (depending on screen size, only FastDoom 0.66).
• More engine code optimizations.
   

Download it here: https://github.com/viti95/FastDoom/releases/tag/0.666

[Redneckerz]

2 minutes ago, viti95 said:

Time for a new release!! FastDoom 0.666

 

• Renamed executable to FDOOM.EXE / FDOOM2.EXE

Whilst i get why, isnt Final Doom'''s executable called FDOOM.EXE already?

2 minutes ago, viti95 said:

• Added all FastDoom display options and sound options in the options menu (only screen size option is saved, next versions will fix this)
• Added "-reverseStereo" command line option to reverse Left/Right stereo speakers. Your Sound Blaster PRO will love this.
• Added "-size |screensize|" command line option to force screen size. Values allowed are 3 to 11, being 3 the smallest possible, 10 full screen with HUD and 11 the biggest, fullscreen without HUD.
• Added "-logTimedemo" option to save the benchmark result onto the file "bench.txt". With this it's possible to run multiple FastDoom benchmarks in a batch and save the results in a single text file. Requires "-timedemo".
• Removed "-cdrom" command line option.
• Fixed bug that made some sprites look corrupted (depending on screen size, only FastDoom 0.66).
• More engine code optimizations.
   

Download it here: https://github.com/viti95/FastDoom/releases/tag/0.666

Bolded parts are sexy, other parts are epic.

 

Overall release is brilliant.

[Maes]

16 hours ago, Redneckerz said:

Whilst i get why, isnt Final Doom'''s executable called FDOOM.EXE already?

 

Which part of it, exactly? At least in the DOS replay release I own, they are called TNT.EXE and PLUTONIA.EXE respectively.

[Redneckerz]

1 hour ago, Maes said:

 

Which part of it, exactly? At least in the DOS replay release I own, they are called TNT.EXE and PLUTONIA.EXE respectively.

I remember looking this up as to why TNT and Plutonia were given their own exe names. This is actually not as commonly referenced as one would think! :)

 

Could it be the difference between the Anthology and stock FDOOM?

 

If not, then a mea culpa on my end is in order. Given how Doom and Doom2 are named it makes a lot of logistical sense to have it called FDOOM in the first place.

[nukeykt]

https://doomwiki.org/wiki/DOOM2.EXE#Final_Doom

[Redneckerz]

3 hours ago, nukeykt said:

https://doomwiki.org/wiki/DOOM2.EXE#Final_Doom

Drats. A mea culpa it is then!

[viti95]

I've done some benchmarks with the demo3 from Doom shareware 1.9 and these are the results. The testbench has this specs:

 

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

[EpicTyphlosion]

Hate to bump this thread, but has anything new been added or changed?

[Redneckerz]

37 minutes ago, EpicTyphlosion said:

Hate to bump this thread, but has anything new been added or changed?

The author will post whenever a new release is ready (He is in this thread). :)

[viti95]

2 hours ago, EpicTyphlosion said:

Hate to bump this thread, but has anything new been added or changed?

 

Well i've been very busy this month, but i'm making some progress with FastDoom. For now the changes for FastDoom 0.7 are these:

• Added Stereo OPL2, OPL3 and Stereo OPL3 music support
• Added Disney Sound Source (also Tandy Sound Source) sound support
• Fixed Gravis Ultrasound music support
• Added profiling support in the makefile (Intel Pentium processor required)
• Added option that forces 8 bit audio mixing instead 16 bit (-8bitsound)
• Bugfix for potato invisible column renderer (issue #2 https://github.com/viti95/FastDoom/issues/2)
• Bugfix for chainsaw incorrect behaviour (issue #9 https://github.com/viti95/FastDoom/issues/9)
• 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)
• As always added more optimizations (mostly ASM optimized multiplications, divisions and modulo, faster screen melting code, faster cheats detection)

I don't know when it will be released, as I don't have access to all my retro hardware due to COVID-19 lockdown. PCEM allows me to test some things but real hardware is another story, never trust an emulator. I asked for help in the Vogons forum for sound devices testing, you can grab an early release candidate there: https://www.vogons.org/viewtopic.php?f=62&t=76971

 

@EpicTyphlosion you can check the source code commit log (https://github.com/viti95/FastDoom/commits/master), it's updated whenever I make a change to the code :D

[viti95]

Hi everyone! I'm running low of ideas for the project lately, what would you like me to implement in FastDoom? I'd love to hear your ideas :D

[taufan99]

19 minutes ago, viti95 said:

Hi everyone! I'm running low of ideas for the project lately, what would you like me to implement in FastDoom? I'd love to hear your ideas :D

Something like EDGE's Wolf3D mode which disables all flat heights to make all maps feel sorta Wolf3D-esque maybe? Is it feasible? ;)

[Dark Pulse]

5 hours ago, viti95 said:

Hi everyone! I'm running low of ideas for the project lately, what would you like me to implement in FastDoom? I'd love to hear your ideas :D

Possibly Boom support and/or limit raising? I tried skimming the thread but I don't see any real mention of those, unless I missed it. Doom Wiki doesn't mention it either (though it does mention being derived from MBF and Crispy Doom in part).

 

It's not exactly a speed-oriented feature, but it will make more WADs playable, and will definitely help test just how fast you can get some really complex maps to render on old DOS rigs :)

[Redneckerz]

1 hour ago, Dark Pulse said:

Possibly Boom support and/or limit raising? I tried skimming the thread but I don't see any real mention of those, unless I missed it. Doom Wiki doesn't mention it either (though it does mention being derived from MBF and Crispy Doom in part).

Some optimizations are. The compatibility is not.

 

FastDoom is as Vanilla as it can be. It just inherits some optimizations courtesy of those ports.

[Optimus]

Just a question and a guess for optimization as I was recently trying the latest version.

 

First I notice that when you switch to flatter surfaces, these can be sometimes slower than shaded flat surfaces. When I display the fps and looking through the zig zag floor near the acid on E1M1 for example, the flatter surfaces can be a bit slower. Now I have a guess about that. First of all,. it's a good trick that the flatter surfaces will skip the process of converting vertical visplanes to horizontal. They will directly draw vertical lines instead. But I think the loss is because you have to OUT for switching the mode-x bank each column. And maybe the horizontal renderer would switch less times than this. Not sure about how to fix this easily. I have some ideas and was trying to compile FastDoom on my PC to try things but forgot it.

 

But I think that the same thing is happening with the potato mode. Unless I am mistaken and you have fixed this somewhere, looking at planar.asm in R_DrawColumnPotato_ there is mov edx,SC_INDEX+1: out dx,al every column. Now there might be less overhead on the potato mode as the columns are much fewer. But have you thought that in the potato mode you don't need to change banks more than once per frame? Since every pixel (even from walls, floors/ceilings/sprites/etc) is the first bank pixel scaled 4 times, you could do this OUT once in the beginning of the Doom frame and never have to do it again at least for this mode? I think potato mode could be even faster just with this change.

 

I've just noticed that and I could have tried it myself, but since I am busy with other coding projects and you need something to work on, that could be an obvious optimization if I am right the mode-x bank switching is happening more than once per frame on potato mode, while unecessary.

[VGA]

On 8/4/2020 at 3:05 AM, Lila Feuer said:

You've no idea how happy this makes me.

-flatsurfaces -flatsky -flatshadow -potato -mono -lowsound, pair with adlib music playback and the default 3 sound channels for extra SIZZLE

This picture makes me feel that turbonerd Bill Gates may walk into frame holding a muthafucking shotgun ...

[viti95]

@InDOOMnesia Didn't know the exitence of that mode, I tested it and well it was fun and weird at the same time (some levels can't be completed as it hides some switches visually). I'll look how it's implemented, and maybe add if it isn't complex.

 

@Dark Pulse For now i'm increasing some limits that doesn't affect performance, for example vissprites are now unlimited. I've got also ready unlimited visplane rendering, but the implementation is a little bit slower, so I haven't added it to the main release. I also think limit removal is good, as it makes more WADs playable (maybe SIGIL)

 

@Optimus You're right, in high and low detail the Flat visplane rendering is a little bit faster than Flatter visplane rendering. I modified Flat rendering so it writes 4 pixels at once whenever possible, and the details (first and last pixels from the span) are rendered using the original detail. It's much faster, as the bottleneck comes usually from writing to video memory even if it's needed to calculate the visplanes. The main problem with Flatter visplane rendering is that is not possible to use the 4 pixel writing, that's why it's only faster in Potato mode. Also you're right about omitting the OUTP call in Potato mode, as it's always the same plane (columns and visplanes). The only thing I have to check it's the fuzzy column renderer, because it modifies VGA registers to read the pixels. If this is possible, it will save much cycles as each OUTP wastes 16 cycles with 486 cpu's and 10 cycles with 386 cpu's.

[viti95]

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 :D

 

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 @Optimus !!])