FastDoom: DOS Vanilla Doom optimized for 386/486 processors

@ReaperAA I knew you weren't kidding when you said nukeykt is a freak! I also like the Sega Saturn shadow mode which makes the spectres look clearer.

Also, those flat surfaces make it look a bit like SNES DOOM. Maybe... hmm? ;)

20 minutes ago, InDOOMnesia said:

Also, those flat surfaces make it look a bit like SNES DOOM. Maybe... hmm? ;)

*wink* *wink* ;)

45 minutes ago, InDOOMnesia said:

@ReaperAA I knew you weren't kidding when you said nukeykt is a freak!

Ahh... From what I have read so far, FastDoom is made by someone called "viti95". Though it is a fork of PCDoom by "nukeykt"

(Of course Nuke is still a freak regardless of this fact)

34 minutes ago, ReaperAA said:

Ahh... From what I have read so far, FastDoom is made by someone called "viti95". Though it is a fork of PCDoom by "nukeykt"

(Of course Nuke is still a freak regardless of this fact)

Ah damn, should've paid more attention earlier.

(Yeah, that still stands, of course).
Also, this video seems even closer to SNES DOOM in term of resemblance.

This is absolutely amazing! I love newer software running better on old hardware. How well does it run on a real 386 vs even a basic 486?

1 hour ago, InDOOMnesia said:

Ah damn, should've paid more attention earlier.

(Yeah, that still stands, of course).
Also, this video seems even closer to SNES DOOM in term of resemblance.

 

Yeah, thats the port running on a FPGA with a 486 core, in POTATO mode and flat shading on. That's how it will look in those settings.

Which looks pretty convincing, to say the least. But really, its more about the low end PC performance - Going from 19 to 25 FPS is a very sizeable boost, and it still looks like Doom, unlike Fraggle's MiniWad.

EDIT: Perhaps this is also useful for GBA Doom? @Doomhack
 

18 minutes ago, Kroc said:

This is absolutely amazing! I love newer software running better on old hardware. How well does it run on a real 386 vs even a basic 486?

That i'd love to know aswell. Seperate binaries are provided for both 386 and 486, but i am curious how a 38 does in POTATO, flat shading and flat sky modes.

That's not a real 486 but a low performance 486 core on a FPGA and performance is equivalent to a 386DX.

I am finding this weirdly attractive if only for the fact I can make Doom look like Wolf3D.

Speaking of which, I am curious if this may be able to achieve 60FPS sometime soon, as viti95 is still aiming to improve its overall speed with any possible means.

These optimizations are not only useful in a technical sense, but are implemented very artfully, imo. This has appeal beyond just for those looking to run Doom on hardware older than most of us are. Fantastic work!

Hey, it's only 26 years too late :-)

Edit: OK, just for the sake of posing an actual question: does this achieve faster speed only by sacrificing visuals, or does it include optimizations that would make it faster even in "normal" rendering mode vs vanilla? E.g. Boom's Hash Table replacing the simple lump searching routine was claimed to be 3x as fast, but other things prevented Boom from being faster overall on older hardware. How does FastDoom fare, in this respect?

25 minutes ago, Maes said:

Hey, it's only 26 years too late :-)

 

Edit: OK, just for the sake of posing an actual question: does this achieve faster speed only by sacrificing visuals, or does it include optimizations that would make it faster even in "normal" rendering mode vs vanilla? E.g. Boom's Hash Table replacing the simple lump searching routine was claimed to be 3x as fast, but other things prevented Boom from being faster overall on older hardware. How does FastDoom fare, in this respect?

It does include several optimizations beyond limiting visuals, resulting in a smaller executable. However, some of the optimizations are done in C instead of asm, sometimes intentional, sometimes because the author mentions not liking asm in general.

So it definitely does do some under-the-hood optimizations aswell :)

Also crossposting from the Doom Pictures thread, Here is Back To Saturn X E1 running on FastDoom, 486 binary, -potato mode with -flatsurfaces and -flatsky on:

I guess only firing it up on a real 486-class PC and doing a timedemo vs vanilla will answer that question, then. I might just be able to do that this weekend ;-)

12 minutes ago, Maes said:

I guess only firing it up on a real 486-class PC and doing a timedemo vs vanilla will answer that question, then. I might just be able to do that this weekend ;-)

IF you have a 386 processor aswell, please test that out aswell! FastDoom has a binary for that, and i wonder how that runs in potato.

11 minutes ago, Redneckerz said:

IF you have a 386 processor aswell, please test that out aswell! FastDoom has a binary for that, and i wonder how that runs in potato.

The closest I have to that is a 486SLC -essentially a 486 constrained on a 386 motherboard, which now that I think about it should be the only test rig. TBQH I don't see much utility in the potato mode -most "hard to run" maps back in the day weren't particularly visually stunning, even though flooding with 100s of sprites or super-complex architecture would slow things down.

What really bogged a map down was the complexity of its BSP tree, its size and the number of active thinkers (a badly built or missing REJECT lump would make things worse), regardless of what was actually in view. Such a map would be super-slow right from the start, even if you started in a closed room facing the wall. Unless a map had super-complex visuals coupled with a super-simple game/map state, optimizing the renderer alone (which most of FastDoom's optimization seem to be about) won't do much good. But we'll see. However I recall that resorting to low-detail mode didn't help matters much in those maps, as the bottleneck was to be found elsewhere.

wasn't there a guy on here that wanted to run doom on 1mb?

I think it's a cool project and the author is spanish like me. You could include the GitHub link in the first post.

I had a 386 but i sold it, those are very hard to find nowadays. It should run well fullscreen but that would look as bad as regular low detail with half view size, still somewhat playable tough. There are several optimizations and according to the author it's 15% faster than regular vanilla Doom without visual sacrifices.

The potato mode is made in ASM, i guess he means it's very hard to code in ASM and those routines are hard to understand. The ultra low detail brings massive performance improvements on 386 class hardware, a 486 is fast enough to run fullscreen in low detail even with an isa card.

 I proposed a 3x1 low detail mode, that should still be faster while looking way better but made in C. I don't know the performance difference with the C version but it doesn't copy anything, i've actually looked at the code now. ZDoom copied the pixels and i dunno why so it was slow. I mention that becouse i added a 3x2 low detail mode to ZDoom LE. I could try to do a 3x1 mode in C (useless in RUDE) but someone could suck the code for DOS. BTW there's a classic version of Russian Doom running in DOS.

What i dislike about this project is that when the author deems something it's not "essential" he deletes the related code. For instance he removed gamma correction which is important to play on CRTs and the port targets old hardware. He also removed network and joystick support, i doubt all those removals bring a real performance benefit.

Edit: the cyrix 486SLC was actually a 386 class cpu with internal cache so it was faster.

I don't think that a 3x mode will help much. For once, with 2x and 4x you can abuse the VGA hardware to actually save work, if you have a planar mode - with 3x all you really save is the multiplications when projecting the flats - you still have to render each of the 3 pixels separately. The main point of low detail mode was to reduce the number of graphics memory accesses, because those were one of the major bottlenecks in the 90's.

And I have to agree about the author's philosophy. Removal of features "just because" will ultimately doom the project, in particular gamma correction. The monitors I had in the 90's were far too dark without it.

Glad that the port nukes the Y mouse movement; that shit makes Doom's controller scheme worse.

The source port is impressive however.

May be but i don't see why. Quoting the game engine black book:

Quote

With direct access to the VGA banks, "low detail mode" is a completely free optimization without the need to write the same pixel column twice, since the VGA mask is set up to write the same pixel to two banks simultaneously.

Can't i write the same pixel "to three banks" at the same time? I only see pointers there BTW. I think mode 13h (chunky) would have been faster on most machines but main memory access was slow on 386s and low detail was much faster using Mode X (planar).

Then there are commits such as "Who needs error codes? :D (Doom executable now weights 10Kb less)".

30 minutes ago, drfrag said:

Can't i write the same pixel "to three banks" at the same time?

No, you can't, at least not consistently. Because if you have 4 banks, the first pixel goes to bank 0,1,2, the second one to 3,0,1, the third one to 2,3,0 and so on. You constantly need to switch your layout to achieve it, and for rendering flats it'd be deadly because they get drawn horizontally so it has to be changed for every single pixel.

There are many internal inefficiencies in the non-pixel-writing parts of the renderer as well. I recall that even doing something as simple as turning left from the start of E4M2 resulted in an incredible depth of BSP recursive calls, 10 or more. Rewriting e.g. the BSP traversal code to be non-recursive could save quite a bit of function call overheads.

As Graf might say that's slim pickens for any modern CPU, but we're really talking about squeezing the last drips of power from a 386 or 486 class CPU with little or even no cache...

2 hours ago, Maes said:

 

The closest I have to that is a 486SLC -essentially a 486 constrained on a 386 motherboard, which now that I think about it should be the only test rig. TBQH I don't see much utility in the potato mode -most "hard to run" maps back in the day weren't particularly visually stunning, even though flooding with 100s of sprites or super-complex architecture would slow things down.

This is why i feel this should be tested with vanilla WAD sets that actually push the engine quite a bit - BTSX, for one. Lets see how those wad sets improve on these processors.
 

2 hours ago, Maes said:

What really bogged a map down was the complexity of its BSP tree, its size and the number of active thinkers (a badly built or missing REJECT lump would make things worse), regardless of what was actually in view. Such a map would be super-slow right from the start, even if you started in a closed room facing the wall. Unless a map had super-complex visuals coupled with a super-simple game/map state, optimizing the renderer alone (which most of FastDoom's optimization seem to be about) won't do much good. But we'll see. However I recall that resorting to low-detail mode didn't help matters much in those maps, as the bottleneck was to be found elsewhere.

It could be interesting to set up what the biggest bottlenecks on low end hardware is, and perhaps get the author here for feedback? Additionally, AMD's 586 could be looked into - Its a very fast 486 core at 133 Mhz, one of the fastest 486 cores around.
 

2 hours ago, BBQgiraffe said:

wasn't there a guy on here that wanted to run doom on 1mb?

There is, but that concerns reducing the complexity of nodes and sectors to fit within a floppy. AFAIK, FastDoom does not actually reduce the actual building blocks of a levels - It simply either reduces detail, culls it (parameter -near), or outright disables it (Flat sky/surfaces). 

2 hours ago, drfrag said:

I think it's a cool project and the author is spanish like me. You could include the GitHub link in the first post.

Its there under Downloads. :)

2 hours ago, drfrag said:

I had a 386 but i sold it, those are very hard to find nowadays. It should run well fullscreen but that would look as bad as regular low detail with half view size, still somewhat playable tough. There are several optimizations and according to the author it's 15% faster than regular vanilla Doom without visual sacrifices.

The potato mode is made in ASM, i guess he means it's very hard to code in ASM and those routines are hard to understand. The ultra low detail brings massive performance improvements on 386 class hardware, a 486 is fast enough to run fullscreen in low detail even with an isa card.

Good point you are mentioning - FastDoom is also faster than regular Doom without any visual degradation, so for those who do want purist DOS Doom, they can get better performance aswell.

It will be interesting to see how much improvements the 386 binary gets when done in potato mode and flatsurfaces/sky. If in ASM, that will likely have a rather positive networth :)

2 hours ago, drfrag said:

BTW there's a classic version of Russian Doom running in DOS.

Yeah :) - I have been testing it out here and there for Julia regarding its heap size setting - 64 MB is easily the highest of vanilla DOS (Doom32 does 32 MB). It actually is limited to 56 MB that can be allocated there however - Supposely this is how it should work, but reading into the extender used (DOS32a), that should not be the case.

Regarding removal of features - The author definitely has a few that go beyond the optimization and more into the minimalist territories, but this is why i'd love to have the author hang around here :)

Another point of interest -a super-slow map would be super-slow even with the renderer disabled completely (e.g. by turning on the automap), so it's really good old Amdahl's law at work. Even with a renderer that executed in one or zero CPU cycles, some maps from back then will remain unplayable.

Culling graphics like textures and flats will also only be fully effective if calls to the WAD lumps/resource management system are fully culled as well. Why e.g. swapping textures/flats in and out of memory if you are not gonna draw them?

1 hour ago, Graf Zahl said:

No, you can't

Now i see it, obviously i can't. It would be possible only in linear mode. I had a 486 with an extremely slow trident isa card and Boom was much faster there, still didn't cut it for big view sizes tough.

Swap in the SNES Doom status bar and I'm in. It's too jarring with that fancy, schmancy high-res one. 

Any way to make it so that the -flatsurfaces flats still have depth lighting? It seems like it shouldn't add too much CPU time because it would only have to recalculate the color once per drawspan call, and possibly less than that.

Also, I recall there being a lot of cachedheight/etc arrays that get written to. I know a lot of that might be wasting CPU time if you're not actually drawing the flats (honestly with viewbob I think it might actually be a waste of time even under normal circumstances). Is that stuff being skipped with -flatsurfaces?

Wow, that's great news!

I was wondering for some times, if anybody every tried to make a Doom port for DOS that it's more playable in 386 (even if with loss of detail). I was playing with this idea on my mind, but great that someone is already doing it. I am definitely trying this on my 386 (DX at 40mhz, fastest ISA Tseng Labs card) and will compare with the original Doom. It was barely playable and with smaller window and lowres before. I do remember 486 was doing ok with old Doom. But the real fun is if it will be more playable on a good 386.

Reduced effects like the flat surfaces are great, but would it be good in the future to have them in the options menu in game, so that one can switch on and off to compare speeds without need to rerun Doom with other command line options? I am doing this a lot on my OptiDoom 3DO port.

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