Sure 😀 I'll edit this post in a few minutes.

EDIT: 36,487fps with "external cache" disabled. Otherwise usual doombench settings (screensize scaled down one notch, -nosound)

Thanks! I didn't realize cache could make a 20% difference, that's huge. I might have to reconsider soldering on sockets for cache on this board 😀

Having any kind of cache it's really important for DOOM, as it is really bandwidth hungry. For example all sine and cosine calculations are made via precalculated tables that are stored in memory, rather than calculating those functions using the cpu or the fpu. Also all the textures to be rendered are also stored in memory. That's why 386s are much slower than 486s, just because they don't have L1 cache. Also it's important to have a fast video card with a fast bus (VLB at least for HQ mode).

As a quality-of-life improvement, is there a way to render enemies and items at a higher quality than the walls? At potato quality, enemies (particularly when somewhat far away) can see the player and attack, but the player can't fight back because the enemy is indistinguishable from the environment. If the enemies could be rendered at original resolution, they would dramatically stand out from the environment, making it MUCH easier to play, but would still only occupy a tiny fraction of the total pixels on screen. It might have a negligible performance impact for a huge gain in playability.

maybe a new mode "--half-potato" ?

I love the idea, but it isn't an easy thing to develop. The main code shares a unique variable (detailshift) to set how to render the whole scene, including the columns, the spans and the sprites. I forced rendering the sprites with the HQ column renderer while in potato mode, and this is what happened:

https://youtu.be/dZqwt1kjXTE

Looking at that video, one curious thing to me is that the vertical strips of sprites are not all the same width. Some are 1 pixel wide, some are 2, and some appear to be 3. Not an expert on the Doom engine myself, but don't the spans also need to be rendered at original quality, not just the strips?

Potato mode works by selecting all four VGA bitplanes to be written at once. This quadruples the current pixel in width. It seems that the sprites are only written to bitplane one. Hence only one stripe is visible. For the rest of the sprites to appear you would need to cycle through all bitplanes while rendering the sprites. Not sure if this is simply disabled in potato mode. Also switching bitplanes is expensive.

Cool. I'm interested to see how this runs on my retro computer, a 486SLC2/50 with 512K Chips and Tech VGA and no L2 cache.

Cool. Finally got around to trying this out. It's no miracle, but it does seem perceptibly faster. It runs acceptably on low quality visual mode, maximized with HUD and with no sound. I haven't benched it, but I'm guessing it runs around 10 FPS on average, with smooth playback in corridors and occasional severe drops. Given the 486SLC2/50 is around the performance of a 386/40 cache system, I'm happy with the result. I haven't had to play with potato mode, turn the floor and sky off, or try other tweaks.

I know a lot of people would not consider this playable, but I think the game was designed so it could still be fun to play and easy to frag at very minimal frame rates and detail levels. Stuttery low-res Doom just feels like Doom of youth, back when a 486DX2/66 was a new mid-range multimedia machine and many people were still relatively lucky to have a faster 386 and 4MB RAM when their friends maybe had 286s or 386SX/16s and had to settle for Duke Nukem 1 for their violence fix.

I managed to see 30 FPS on the ticker in 0.6 on my cacheless 386DX/25, in that stupid computer maze part of E1M2. I was basically staring at a wall with nothing around me, but still, that was neat. Nice job!

I run with -potato -lowsound -flatsurfaces -nomelt, 2 sound channel mixing & full-screen with the status bar. It gets around 13FPS in the benchmark demo PhilsComputerLab uses on those settings.

...that said, I pulled the machine apart to upgrade it to a 486 now. I'm fine with 13FPS but Potato mode is pretty hard to look at. 😜 (I wanted a 486 for other stuff too.)

Can i ask does it work with just the doom1.wad the shareware version?
If i buy the gog games doom II can i use its wad. Just having a little trouble running it on real 386/40
Thanks

vacatedboat wrote on 2020-08-31, 21:58:

Can i ask does it work with just the doom1.wad the shareware version?
If i buy the gog games doom II can i use its wad. Just having a little trouble running it on real 386/40
Thanks

The Ultimate Doom version works both with Doom.wad and Doom2.wad.

Btw, I did some more tests with 0.5 and 0.6:

1Doom 1.9            28.63 fps
2FastDoom/486 0.5    31.50 fps
3FastDoom/486 0.6    32.47 fps
4
5Doom 1.9            31.98 fps
6FastDoom/486 0.5    37.27 fps
7FastDoom/486 0.6    38.50 fps

These are two different configs. The former one is Shuttle HOT-419 and Cyrix 486DX2-66, the latter is 486SH (SiS461 chipset) and AMD 486SX2-66. Both had the same Paradise S3 Trio64 VLB VGA (my new find), some RAM (16 and 8MiB respectively), and a CT2810 Vibra16.

But I had serious problems. There was no music on the SB, okay, fine, at least I can't accuse you of bias against the GUS. But the real bother came when I tried to actually play a bit because 0.6 couldn't load saved games. Not even its own, let alone anything made with 0.5. IIRC it worked fine in 0.5.

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

-----

@alvaro84 i'll check the CT2810 Vibra16 support, I tried FastDoom with my Vibra16XV (a real pain in the ass sound card) and it was working both sound and music. How do you initialize the sound card? And what is your base port/IRQ/DMA configuration?

@radiounix @xjas try the parameter "-flattersurfaces", it gives a good speedup even on low mode. Although is difficult to get good framerates without external cache. Doom depends a lot in lookup tables to get Sines, Tangent and Cosines calculations, and those are stored in RAM memory. Also all the textures are stored in RAM memory. That's why it's so important to have big external caches with Doom, RAM access it's really slow in 386/486 pc's, and the cache fixes that problem. That's why the 486s are much faster than the 386s, having fast integrated L1 cache makes the difference.

Ooh, nice! I'm gonna have to try NUTS.WAD 😉

Just upgraded my CPU.
DX2-66: 43,023fps
POD-83: 58,764fps

Quick video with the new video options menu 😁

https://youtu.be/GtnNAvJc8MM

@shock___ that is a 36% performance uplift from a 25% increase in MHz, not bad! I'll be getting 1Mb L2 cache for my testbench, and see how fast it is compared to having only 256Kb.

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

Does it work with DOOM2 WADS? I am about to start playing that again.

kolderman wrote on 2020-09-15, 21:58:

Does it work with DOOM2 WADS? I am about to start playing that again.

It should, but i cannot garantee 100% compatibility. If you find any WAD that causes troubles please add an Issue in the GitHub proyect (https://github.com/viti95/fastdoom/issues).