Some news! Doug Johnson is getting unlimited framerate support with interpolation into shape, here is a video of it (on a Pentium 75):

https://youtu.be/OESuf6yrAKY

Also crazii has fixed SBEMU compatibility on FastDoom, so it will be available on the next release:

https://youtu.be/P89Uu3-rIxA

mmm butter!

ViTi95 wrote on 2024-02-18, 21:41:

Some news! Doug Johnson is getting unlimited framerate support with interpolation into shape, here is a video of it (on a Pentiu […]
Show full quote

Some news! Doug Johnson is getting unlimited framerate support with interpolation into shape, here is a video of it (on a Pentium 75):

https://youtu.be/OESuf6yrAKY

Also crazii has fixed SBEMU compatibility on FastDoom, so it will be available on the next release:

https://youtu.be/P89Uu3-rIxA

Does this mean we have spare CPU cycles to add multiplayer support 😉

If I understand correctly, I think this is pretty much only relevant to running Doom on newer systems, and it's not going to help enough or at all to make it possible on older systems anyway.

Not sure how much utility a multiplayer fork of Fastdoom would be if you could only play it on a Pentium+ machine 🤷‍♂️

> only play it on a Pentium+ machine

id managed to do it on a 386, and FastDoom claims to be faster than the original. I get the idea of gaining speed by removing features and their associated code, but even if 100% of current speed gains were to have come from that (which is very much not the case), putting it back in and making it a compile time option shouldn't make you slower than the original.

First of all, I think you're confused about what this past update was about; it's not making anything faster per se, it's just removing the built-in framerate limit in the Doom Engine for newer, faster PCs that are able to take advantage of that. It's not giving more speed to slower older PCs. This means Pentium+ machines

elszgensa wrote on 2024-02-20, 07:22:

id managed to do it on a 386

"managed" is the operative word here. original Doom is a slideshow on a 386 even in low detail setting. you could get it to a moderately playable state if you reduce the viewport to a postage stamp, so ID was happy to say it was possible, but i don't think it was very fair of them

if you want to see a pretty good rundown of how well Doom plays on 386s and up check out this video https://www.youtube.com/watch?v=rZcAo4oUc4o

the results at 15:40 show that even with basically the fastest 486 using a VLB VGA card, you still aren't saturating Doom's built-in framerate cap

FastDoom claims to be faster than the original

it is a bit faster. You can now eek a playable game out of 386 with low detail settings

I'm not the author here, but I believe that removing multiplayer had something to do with that. It also seems as though you can try to implement it if you want to.

ViTi95 wrote on 2024-01-23, 10:22:

zuldan wrote on 2024-01-23, 07:51:

Any chance of multiplayer support being reinstated in the future? Would love to do a death match with 386’s.

Don't think so, we gained some fps after removing this feature, and the codebase underwent significant modifications following the removal of the multiplayer. Nevertheless, any developer can create a pull request to reintegrate this feature as an option if it doesn't make FastDoom slower.

The framerate limit removal will be selectable, not all PC can handle more than 35 fps. Similar to other ports, this will use the same 35 tick/second base with interpolated frames to mantain demo compatibility. This mode is also designed for fast 486s (100MHz+, VLB or PCI) and similar perfomance CPUs, like the Cyrix 5x86 or NexGen.

I downloaded doomu.wad and tried to run the EGA version on my 386SX with 8 mb RAM and an EGA card (using an EGA monitor).

I get past the initalization screen, then a ticking _ in the upper left of an otherwise black screen, and nothing happening no matter how long I wait.

What am I doing wrong?

EDIT: Okay, I ran fdsetup, removed soundblaster sound and started the game. This got me a bit further. To [here]. Loops on and on indefinately.

What EGA card do you have @boggit? Also how much VRAM does the card have? It's very weird, looks like the video initialization process is completely wrong on your system. I guess you're using FastDoom 0.9.8 and the fdoomega.exe executable am I right?

Apologies for the painfully novice nature of my post, but between the confusing GitHub site and the WAD install tutorials I have no idea what I'm doing, how to get the right files from GitHub or how to apply them to the Vanilla Doom folder/how to install them.

Could anyone please explain what steps I should take to download the essential files and apply them to the Doom folder? I have a 486 DX-2 66 and I am very curious to see this optimized version compared to the original. Thank you all in advance for your patience

Download the latest release from https://github.com/viti95/FastDoom/releases (might need to click on/expand "Assets"; pick the one file per release that doesn't say "source code"). Extract it into a new folder. Copy doom1.wad, doom.wad or doom2.wad from your existing Doom folder into this new one. Now, move this to a DOS environment of your choice (copy to a retro machine or into a VM, mount in DOSBox, whatever). Run fdsetup.exe to set up sound and inputs. Save, then quit the game that it launched (it's the "same as vanilla" version). Read the README.TXT to see what's what, then run whichever fd*.exe you want to try, e.g. fdoomega.exe if you want to run in EGA.

I was testing recent Fast DOOM releases and I've noticed PCM music. Since DOOM engine already has implemented PCM channel mixing for sound effects, adding MOD Tracker like music should be fairly simple. We don't even need MOD format, just some instrument samples for game MUS (MIDI) files.

The reason is that it would only take additional 200-400 KB data for instrument samples. It's possible to pick samples with public domain or other free license so they could be a part of standard release.

Same benefit as PCM music, ability to play music on PC Speaker, COVOX and other PCM-only devices. Of course software mixing requires additional CPU cycles, but usually only newer faster machines have problem with Audio devices in DOS.

https://youtu.be/afyCn6m2Qbc?t=76

Here's a video of DOOM running on Amiga, playing music on its 4-channel PCM Audio which lead to Mod Tracker music in the first place.

elszgensa wrote on 2024-03-15, 22:33:

Download the latest release from https://github.com/viti95/FastDoom/releases (might need to click on/expand "Assets"; pick the one file per release that doesn't say "source code"). Extract it into a new folder. Copy doom1.wad, doom.wad or doom2.wad from your existing Doom folder into this new one. Now, move this to a DOS environment of your choice (copy to a retro machine or into a VM, mount in DOSBox, whatever). Run fdsetup.exe to set up sound and inputs. Save, then quit the game that it launched (it's the "same as vanilla" version). Read the README.TXT to see what's what, then run whichever fd*.exe you want to try, e.g. fdoomega.exe if you want to run in EGA.

Thank you so much @elszgensa, concise and to the point, wish the WAD guides I've seen just had that info right from the start. Hit a bump due to the wrong demo message/1.9 version requirements but eventually noticed that in the readme.

My DX-2 66 paired with an ISA Trident 8900-CL and 16MB RAM managed 20fps on low detail with a full screen, felt quite fluid, I'll happily do a playthrough like that, no problem. I imagine that if I had a VLB capable system I could maybe squeeze up to 25fps or more? And that's without even shrinking the screen at all.

Congratulations @Viti95, a wonderful tribute to all of the 386/486 PCs that were actually around at the time, that type of context is so easy to forget. I have obviously no idea of how far you can still go towards optimizing it further, but in its current state people at the time would have been ecstatic with it, that's for sure. Thanks!

ishadow wrote on 2024-03-16, 19:10:

I was testing recent Fast DOOM releases and I've noticed PCM music. Since DOOM engine already has implemented PCM channel mixing for sound effects, adding MOD Tracker like music should be fairly simple. We don't even need MOD format, just some instrument samples for game MUS (MIDI) files.

The reason is that it would only take additional 200-400 KB data for instrument samples. It's possible to pick samples with public domain or other free license so they could be a part of standard release.

Same benefit as PCM music, ability to play music on PC Speaker, COVOX and other PCM-only devices. Of course software mixing requires additional CPU cycles, but usually only newer faster machines have problem with Audio devices in DOS.

Definitely doable, though I have to admit that sound coding is not my best. Even PCM music can be better, as I wasn't able to stream in realtime the music from the HDD, right now it is preloaded first in RAM.

Also coding time from my side is very low right now as caring for my family is taking some time, but will be better anytime soon.

andre_6 wrote on 2024-03-17, 17:00:

My DX-2 66 paired with an ISA Trident 8900-CL and 16MB RAM managed 20fps on low detail with a full screen, felt quite fluid, I'll happily do a playthrough like that, no problem. I imagine that if I had a VLB capable system I could maybe squeeze up to 25fps or more? And that's without even shrinking the screen at all.

Congratulations @Viti95, a wonderful tribute to all of the 386/486 PCs that were actually around at the time, that type of context is so easy to forget. I have obviously no idea of how far you can still go towards optimizing it further, but in its current state people at the time would have been ecstatic with it, that's for sure. Thanks!

Thanks andre_6 for your kind words 😊. Maybe you can try FDOOM13H.EXE, sometimes is a bit faster for high detail on ISA video cards. And yeah, VLB cards help a lot, but Doom is also quite intensive on the CPU, so if you upgrade the CPU (with an Intel Overdrive 100MHz for example), the fps will go higher for sure. As for the optimizations they are pretty much finished as it's becoming really hard to get some extra fps.

HI! i open a ticket in github too, i have a problem, maybe someone else can test

If i have softmpu loaded and select AWE32 music, fastdoom hangs at exit, and need to hard reset, same with emm386 or qemm, if i select other music type, sb, adlib, pcm, etc no problem at exist

I tested in a 486 dx4 and a Pentium 3, both AWE64 cards, same

thanks!

Time for a new release, FastDoom 0.9.9!

FastDoom 0.9.9

Changelog:

• Multiple optimizations (C, ASM) and code cleanup
• Disabled all cheats in Nightmare
• Removed IDSPIDPOPD cheat (IDCLIP is still available)
• Fixed snow while setting palette on slow VGA cards (via -fixDAC)
• Removed -nomonsters and -turbo command line parameters
• Native higher resolution modes available (thanks to Doug Johnson). New supported resolutions: 320x240, 512x384, 640x400, 640x480, 800x600, 1024x768, 1280x800, 1280x1024
• Fixed SBEMU support (thanks to Crazii)
• Refactored memory allocation, now all RAM available is used by default. Removed -ram command line parameter
• Better debugging and automatic CPU detection by Doug Johnson
• Source code has 8.3 file format again (thanks to efliks)
• VESA backbuffered modes now work on video cards without LFB
• Removed OpenWatcom IDE files (obsolete, not used)
• Upgraded build scripts, much faster compile times on Linux (again, thanks to Doug Johnson)

I've decided to make a new release as the changelog was getting big enough and the code seems to be pretty stable. This release doesn't include >35fps mode, as it's still a bit buggy and I prefer for it to be 100% perfect.

theelf wrote on 2024-03-18, 21:24:

HI! i open a ticket in github too, i have a problem, maybe someone else can test […]
Show full quote

HI! i open a ticket in github too, i have a problem, maybe someone else can test

If i have softmpu loaded and select AWE32 music, fastdoom hangs at exit, and need to hard reset, same with emm386 or qemm, if i select other music type, sb, adlib, pcm, etc no problem at exist

I tested in a 486 dx4 and a Pentium 3, both AWE64 cards, same

thanks!

I'll take a look, i'm very confident that native handling of the AWE32 hardware on the shutdown process is making it to crash:

1static void ShutdownMPU(
2    void)
3
4{
5    volatile DWORD dwCount;
6
7    for (dwCount = 0; dwCount < 0x2000; dwCount++)
8        ;
9    dwCount = 0x2000;
10    while (dwCount && inp(MPUPort(1)) & 0x40)
11        --dwCount;
12    outp(MPUPort(1), MPU_RESET_CMD);
13    for (dwCount = 0; dwCount < 0x2000; dwCount++)
14        ;
15    inp(MPUPort(0));
16
17    for (dwCount = 0; dwCount < 0x2000; dwCount++)
18        ;
19    dwCount = 0x2000;
20    while (dwCount && inp(MPUPort(1)) & 0x40)
21        --dwCount;
22    outp(MPUPort(1), MPU_RESET_CMD);
23    for (dwCount = 0; dwCount < 0x2000; dwCount++)
24        ;
25    inp(MPUPort(0));
26}

ViTi95 wrote on 2024-03-24, 19:00:

Time for a new release, FastDoom 0.9.9! […]
Show full quote

Time for a new release, FastDoom 0.9.9!

FastDoom 0.9.9

Changelog:

• Multiple optimizations (C, ASM) and code cleanup
• Disabled all cheats in Nightmare
• Removed IDSPIDPOPD cheat (IDCLIP is still available)
• Fixed snow while setting palette on slow VGA cards (via -fixDAC)
• Removed -nomonsters and -turbo command line parameters
• Native higher resolution modes available (thanks to Doug Johnson). New supported resolutions: 320x240, 512x384, 640x400, 640x480, 800x600, 1024x768, 1280x800, 1280x1024
• Fixed SBEMU support (thanks to Crazii)
• Refactored memory allocation, now all RAM available is used by default. Removed -ram command line parameter
• Better debugging and automatic CPU detection by Doug Johnson
• Source code has 8.3 file format again (thanks to efliks)
• VESA backbuffered modes now work on video cards without LFB
• Removed OpenWatcom IDE files (obsolete, not used)
• Upgraded build scripts, much faster compile times on Linux (again, thanks to Doug Johnson)

I've decided to make a new release as the changelog was getting big enough and the code seems to be pretty stable. This release doesn't include >35fps mode, as it's still a bit buggy and I prefer for it to be 100% perfect.

Cool stuff! Thank you for the release, ViTi95!
Curious to try 320x240 mode.
I was also hoping to see MIDI to COM output in the coming release. Do you still plan it?

ViTi95 wrote on 2024-03-24, 19:12:

I'll take a look, i'm very confident that native handling of the AWE32 hardware on the shutdown process is making it to crash: […]
Show full quote

theelf wrote on 2024-03-18, 21:24:

HI! i open a ticket in github too, i have a problem, maybe someone else can test […]
Show full quote

HI! i open a ticket in github too, i have a problem, maybe someone else can test

If i have softmpu loaded and select AWE32 music, fastdoom hangs at exit, and need to hard reset, same with emm386 or qemm, if i select other music type, sb, adlib, pcm, etc no problem at exist

I tested in a 486 dx4 and a Pentium 3, both AWE64 cards, same

thanks!

I'll take a look, i'm very confident that native handling of the AWE32 hardware on the shutdown process is making it to crash:

Copy code to clipboard

1static void ShutdownMPU(
2    void)
3
4{
5    volatile DWORD dwCount;
6
7    for (dwCount = 0; dwCount < 0x2000; dwCount++)
8        ;
9    dwCount = 0x2000;
10    while (dwCount && inp(MPUPort(1)) & 0x40)
11        --dwCount;
12    outp(MPUPort(1), MPU_RESET_CMD);
13    for (dwCount = 0; dwCount < 0x2000; dwCount++)
14        ;
15    inp(MPUPort(0));
16
17    for (dwCount = 0; dwCount < 0x2000; dwCount++)
18        ;
19    dwCount = 0x2000;
20    while (dwCount && inp(MPUPort(1)) & 0x40)
21        --dwCount;
22    outp(MPUPort(1), MPU_RESET_CMD);
23    for (dwCount = 0; dwCount < 0x2000; dwCount++)
24        ;
25    inp(MPUPort(0));
26}

thanks a lot, let me.know if you need more tests!

ViTi95 wrote on 2024-03-24, 19:00:

[*]Fixed SBEMU support (thanks to Crazii)

The Adlib volume is still super low for me, so I'm going to assume that's not related to the SBEMU support issue.