FastDoom: DOS Vanilla Doom optimized for 386/486 processors

[Darkcrafter07]

The VESA modes rock, though I'd only stick with 640x400 one because it looks crisp enough, runs fastests and keeps 4:3 ratio, if only there was 1280x800 mode (640x400*2). Btw, I noticed that all these VESA modes look pretty different from the vanilla version, the diminished lights are way too bright.

 

Seems this just made me want to fire up my 2.4ghz celeron machine but I'm not sure if I had a proper DOS VESA 2.0 driver that would work with FX5500 128mb, could you suggest any?

 

It's a bit of an offtop here but the original Quake executable probably supports my video card out of the box as it detects NVIDIA VESA card and there's plenty resolution options are available, would have been very cool to inject the drivers in the exe, that's a very much to ask though.

[viti95]

@Darkcrafter07 can you post a screenshot of regular FDOOM.EXE and any of the VESA modes? Nvidia FX VESA support is fairly good, so it shouldn't need any TSR VESA fix.

[Darkcrafter07]

@viti95, I only tested it in PCem but really eager to get that old pc out on the light and fire it up. Btw, do you mean those VESA exe's will run without any driver out of the box? I'll get to see it!

[Darkcrafter07]

Upd: I made a video on testing it all out thoroughly and comparing against other games of the time like Duke3D and Quake in VESA modes.
 

 

[Frenkel]

On 1/14/2024 at 8:38 PM, viti95 said:

I've uploaded a new test build with the new VESA modes. There will likely be some bugs, so please feel free to report them.

 

https://www.doomworld.com/forum/post/1301624

[viti95]

4 hours ago, Frenkel said:

 

https://www.doomworld.com/forum/post/1301624

 

Yup, confirmed this also happens on FastDoom (only noticeable on higher resolutions) 😅

[viti95]

I've uploaded a new bugfixing test release (just VESA HighRes fixes). Also I've added support for banked VESA 320x200 direct rendering.

 

https://github.com/viti95/FastDoom/releases/tag/0.9.9_test2

 

 

[Darkcrafter07]

@viti95, do you have any clue why duke3d, quake and quake 2 dos worked with my fx 5500 in vesa modes without any drivers installed while fdoom vesa modes required a driver, which I don't have?

Edited January 24 by Darkcrafter07

[viti95]

18 hours ago, Darkcrafter07 said:

@viti95, do you have any clue why duke3d, quake and quake 2 dos worked with my fx 5500 in vesa modes without any drivers installed while fdoom vesa modes required a driver, which I don't have?

 

FastDoom VESA modes don't require any driver, just VESA 2.0 support. Only cards without native VESA 2.0 support require a TSR like UniVBE (like older Cirrus Logic or S3 cards). Maybe there is some kind of bug on FastDoom and is not detecting properly Nvidia FX VESA modes. I have one of those cards, so I can do testing with it.

Edited January 25 by viti95

[viti95]

Some testing of new 1280x800 resolution with 4x pixel scaling (aspect ratio is not right as the display 16:9, but it's pixel perfect)

 

[MrFlibble]

Looks very sleek!

[viti95]

10 hours ago, MrFlibble said:

Looks very sleek!

 

 

SBEMU now partially works with FastDoom, OPL music crashes but Sound Blaster sound is working fine.

Edited January 30 by viti95

[Dark Pulse]

On 1/11/2024 at 10:36 AM, Individualised said:

Old, but the texture warping in PS1 Doom is due to that version using a hardware renderer rather than the Doom software renderer. I think SNES Doom's texture warping is probably a bug in that version as I'm not quite sure why it would have been done there otherwise, because as far as I know it is completely software rendered and only uses the SuperFX's blitting functions rather than its hardware acceleration.

Old, but absolutely false. It's the other way around - SNES Doom is rendered completely on the SuperFX, and then the final frames are sent to the SNES to display.

 

The SNES wouldn't have a prayer of rendering it on the CPU.

[Individualised]

1 minute ago, Dark Pulse said:

Old, but absolutely false. It's the other way around - SNES Doom is rendered completely on the SuperFX, and then the final frames are sent to the SNES to display.

 

The SNES wouldn't have a prayer of rendering it on the CPU.

I meant software rendered on the SuperFX; remember the SuperFX is an entire CPU of its own. As far as I know, the SuperFX's polygon rendering capabilities are not used at all in SNES Doom, but I could be wrong.

[Dark Pulse]

9 minutes ago, Individualised said:

I meant software rendered on the SuperFX; remember the SuperFX is an entire CPU of its own. As far as I know, the SuperFX's polygon rendering capabilities are not used at all in SNES Doom, but I could be wrong.

You're quite wrong on that, yes.

 

The SuperFX is not a dedicated piece of graphics hardware, true, but it is basically programmed to act like one - it draws polygons to a framebuffer that is in RAM, and every so often, that framebuffer-in-RAM is DMA'd to the main SNES video memory, which then displays it.

 

For all intents and purposes, you could say that it is a graphics accelerator, as that's all the commercial games ever programmed the chip to do - accelerate 3D and 2D drawing. It was never used as a general-purpose CPU, even though technically it could have been.

Edited January 30 by Dark Pulse

[Individualised]

4 minutes ago, Dark Pulse said:

You're quite wrong on that, yes.

 

The SuperFX is not a dedicated piece of graphics hardware, true, but it is basically programmed to act like one - it draws polygons to a framebuffer that is in RAM, and every so often, that framebuffer-in-RAM is DMA'd to the main SNES video memory, which then displays it.

 

For all intents and purposes, you could say that it is a graphics accelerator, as that's all the commercial games ever programmed the chip to do - accelerate 3D and 2D drawing.

Doesn't SNES Doom run the majority of its game logic on the SuperFX?

 

The SuperFX does have dedicated hardware for drawing polygons, based on Randy Linden's breakdown of the renderer I do not think it is being used here.

 

This is where the SNESdev wiki having SuperFX documentation would really help...

 

EDIT: I'm wrong about the SuperFX having polygon hardware it seems. My bad.

Edited January 30 by Individualised

[Dark Pulse]

9 hours ago, Individualised said:

Doesn't SNES Doom run the majority of its game logic on the SuperFX?

 

The SuperFX does have dedicated hardware for drawing polygons, based on Randy Linden's breakdown of the renderer I do not think it is being used here.

 

This is where the SNESdev wiki having SuperFX documentation would really help...

 

EDIT: I'm wrong about the SuperFX having polygon hardware it seems. My bad.

The game is pretty much entirely run on the SuperFX, if memory serves. All the SNES does is get the image the SuperFX outputs, and handle the controller I/O.

[viti95]

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

 

 

 

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

 

 

 

[slowfade]

Awesome! Great work guys! It'll be like 100 fps with -potato?

[viti95]

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.

[Darkcrafter07]

That's very nice. I like FDOOM13H.EXE the most of the collection, if only opl playback code was taken from chocolate doom and "buffered" for more optimization, cause all exes you compiled could have a better opl music sounding.

 

The VESA mode exe's in PCem are still buggy, the sector lighting model is prboom alike, e.g. too bright. The gameplay bugs are the most interesting ones, just like if I was playing a multiplayer game and a server had a lag, so it messes up the game, periodically but this only affects VESA exe's

 

320x240, 512x384, 640x480, 800x600 resolutions, all except 640x400 suck - cause they mess up the graphics as it gets upscaled with a wrong aspect ratio and looks horrible. Would a custom graphical wad with images adopted to these resolutions fix the issue?

 

Why did you remove -nomonsters and -turbo commands? Why did you disable cheats in nightmare, maybe I prefer playing it so, cheats and infinitely long maps, while listening to some podcast and pondering?

 

The FPS has increased by a tad bit - good job. The CPUs under 100MHz slow down the music playback and I have a strong impression that the same thing happens to the gameplay as well - this is a really bad part about it; the only way to fix this is by utilizing a -nosound flag. Sorry, I don't have a PC with a CPU slower than 2.4GHz P4 to give it a check.

 

But man, even that FDOOM13H.EXE would make you a millionaire be it released in 94, as it's 2 to almost 3 times faster than any Vanilla. John Carmack should really find out about this port, as it would make him more money back in the day as if more people with weaker computers purchased the game. AFAIK, Heretic was working in 13h mode and the game performs much better than Doom, why didn't iD implement it to Doom then? Also the other optimizations you contributed are amazing.

[viti95]

3 hours ago, Darkcrafter07 said:

That's very nice. I like FDOOM13H.EXE the most of the collection, if only opl playback code was taken from chocolate doom and "buffered" for more optimization, cause all exes you compiled could have a better opl music sounding.

 

Yeah OPL music is still not perfect, the volume is too low and a bit different from what DMX produces.

 

3 hours ago, Darkcrafter07 said:

320x240, 512x384, 640x480, 800x600 resolutions, all except 640x400 suck - cause they mess up the graphics as it gets upscaled with a wrong aspect ratio and looks horrible. Would a custom graphical wad with images adopted to these resolutions fix the issue?

 

Both 640x400 (x2) and 1280x800 (x4) don't suffer from aspect ratio distortion. This is due to how the engine works, with corrected aspect ratio graphics the final image would be fine

 

3 hours ago, Darkcrafter07 said:

Why did you remove -nomonsters and -turbo commands?

 

Both cases are optimizations. Removing the turbo command allowed us to have a fixed value for movement, which enabled further optimizations in P_MovePlayer and G_BuildTiccmd. Removing the nomonsters command lets the maps load a bit faster, something a bit frustrating on slow 386 cpus.

 

3 hours ago, Darkcrafter07 said:

But man, even that FDOOM13H.EXE would make you a millionaire be it released in 94, as it's 2 to almost 3 times faster than any Vanilla. John Carmack should really find out about this port, as it would make him more money back in the day as if more people with weaker computers purchased the game. AFAIK, Heretic was working in 13h mode and the game performs much better than Doom, why didn't iD implement it to Doom then? Also the other optimizations you contributed are amazing.

 

The pre-release beta of Doom used mode 13h, and I think Carmack changed it to Mode Y in order to have better performance on slower systems with the low detail mode (in a very short time, which is mindblowing). I really wonder why they didn't enabled a "potato" mode, because it's free from hardware perspective (VGA optimization), and the code was pretty much ready for it. Raven Software did an impressive work optimizing the original mode 13h routines.

[viti95]

3 hours ago, Darkcrafter07 said:

Why did you disable cheats in nightmare?

 

The cheats I disabled in nightmare mode are IDDT and IDCLIP, all other cheats were already disabled on vanilla Doom. I didn't notice that those cheats were available in nightmare until I rewrote cheat code handling. I find this a bug in the code, as many other small bugs due to Doom being developed in a very short span of time. No cheats in Nightmare means no cheats at all in nightmare.

[MrFlibble]

3 hours ago, viti95 said:

IDDT and IDCLIP

These two sound more like debug modes than direct cheating, so maybe they were left in because of that?

 

Speaking of VGA mode 13h, I'm noticing screen tearing with it when playing in DOSBox (not just Heretic, but other FPS games like Descent or Eradicator), but much less so when I use 86box. I suppose this is a DOSBox inaccuracy and playing on an actual CRT would not have visible screen tearing as well? (because Mode X does not have any screen tearing at all in DOSBox or otherwise)

[viti95]

Tearing on mode 13h is a side effect of only having 1 video page available (Doom mode Y uses 3). The only way to avoid tearing on mode 13h is to have vsync enabled. On real hardware is very visible.

[MrFlibble]

Interesting! I've not played anything on a CRT for a very long time, but I sure do not remember pronounced tearing on that CRT than I used to have in the early-mid 2000s when I played the original vanilla Doom and other games like Duke3D without any emulation. Maybe I did not pay much attention to that back then though.

Edited March 25 by MrFlibble

[Redneckerz]

I really wonder how Vanilla-heavy WADS now play with this iteration on a 486.

[deathz0r]

7 hours ago, viti95 said:

Both cases are optimizations. Removing the turbo command allowed us to have a fixed value for movement, which enabled further optimizations in P_MovePlayer and G_BuildTiccmd. Removing the nomonsters command lets the maps load a bit faster, something a bit frustrating on slow 386 cpus.

Unfortunately, it breaks every single NoMo demo that exists on the DSDA archive. Stroller demos (which use -turbo 50) appear to be unaffected from testing a few of them.

[Darkcrafter07]

John Carmack once said it in the 30 years doom chat with Romero that making more demanding games was more rewarding, as people spending more money to spin the whole industry. It could have been a reason they dropped further doom engine optimizations and mode 13h as more and more people were getting faster computers. There is another factor that could have led to such behavior - Doom has been a benchmark and it made people proud about their FPS digits. You know, it's the same thing that happens now with people buying hardware to outperform their neighbors in the FPS zone. Doom like a progress driver. Then Quake came out and they almost forgot about it, the time Q2 came out playing Doom was not a problem at all I believe.

[viti95]

1 hour ago, deathz0r said:

Unfortunately, it breaks every single NoMo demo that exists on the DSDA archive. Stroller demos (which use -turbo 50) appear to be unaffected from testing a few of them.

 

I've found a bug that caused some demos to desync, I've uploaded the bugfix on the same release. Maybe this fixes the NoMo demos?