FastDoom: DOS Vanilla Doom optimized for 386/486 processors

[drfrag]

I believe that mode Y was better for low detail mode and 386 cpus, on many isa cards such as Trident it was much slower than 13h. Linear should be faster on most configurations.

[viti95]

Mode Y is faster with 386 and cacheless systems as the ram on those systems is really slow, so it's faster to write directly to the video card rather than write to system memory and then copy the backbuffer to the video ram. Also Mode Y has some tricks that Mode 13h doesn't. Mainly, it has access to the full 256Kb of VRAM, multiple video pages and some operations are faster, as it allows writing 2 or 4 bytes at the same time with a single write to the VRAM. This allows rendering full screen at 160x200 or 80x200 requiring much less write operations. Also it allows copying 4 bytes from VRAM to VRAM with a single read and write operation. I tried to use this trick to save memory storing the Doom fonts in the VRAM, but it was difficult and slower with some video cards (read operations are very slow in most circunstances).

 

The cons are that it requires to change the planes to write to pixels depending on the column, and that is an OUTP instruction per each column draw, and multiple OUTP per span drawn (except for the 80x200 resolution). The OUTP instructions are really slow, and some video cards doesn't like it at all (for example the Rendition Verite and the Cyrix MediaGX). That problem doesn't exist with the Mode 13h, as the VRAM is directly mapped in memory. With fast 486 and Pentium cpu's the Mode 13h should be faster, but only with the high detail modes.

 

There is a pretty good explanation of what is possible to do with VGA Mode X (and Mode Y) by Fabien Sanglard https://fabiensanglard.net/another_world_polygons_PC_DOS/

Edited April 19, 2021 by viti95

[zokum]

Switching to mode Y made sense if it sped up the game on the slower machines. On faster machines the performance was most likely high enough anyways. Supporting different rendering methods was most likely too much work and too much risk.

Carmack learned from his 'mistakes' and Quake had decent support for all kinds of mode X and VESA modes. Having hired Abrash probably helped a lot.

[zokum]

14 hours ago, Gez said:

Doom used Mode 13h in early development, and switched to Mode Y for better performances on low-end systems. Heretic had higher system requirements since it was released later than Doom.

I think the reality is that Heretic was forked off of a Doom codebase that still used mode 13h.

[Maes]

2 minutes ago, zokum said:

 On faster machines the performance was most likely high enough anyways.
 

Supporting different rendering methods was most likely too much work and too much risk.

No it was not, it was never enough (performance), sadly :-/

 

As for risk...well, they did tinker around with the doomed (pardon the pun) HiColor mode rendering in the alphas...

[Gez]

4 hours ago, zokum said:

I think the reality is that Heretic was forked off of a Doom codebase that still used mode 13h.

Doom v1.2 uses Mode 13h?

[viti95]

2 hours ago, Gez said:

Doom v1.2 uses Mode 13h?

 

I'm pretty sure that no, I did reverse engineering on the executables from Doom 1.0 onwards, and all are using Mode Y. I have my doubts on the Doom press relase beta, but I haven't done yet proper reverse engineering on that one.

[xttl]

Press beta uses regular mode 13h, but 0.99 and everything onwards is using unchained mode.

 

Press beta using regular 13h is a bit weird because IIRC alphas 0.4 and 0.5 use unchained mode.

 

0.2 uses 13h, so they went from 13h to unchained to 13h to back to unchained again.

 

[Gez]

The version seen in "A Visit to id Software" also use 13h, judging from the HOM behavior in the E1M4 segment (cf wiki edits by @nukeykt and @Linguica).

[xttl]

12 minutes ago, Gez said:

The version seen in "A Visit to id Software" also use 13h, judging from the HOM behavior in the E1M4 segment

 

Yes, that version is from between the press beta and 0.99 I believe.

 

I just checked all four alphas and 0.4 & 0.5 indeed are using unchained mode just as I remember, as is 0.3 which I wasn't sure about.

[SaladBadger]

WRT heretic being forked, while the engine code does mostly resemble 1.2, it's weirdly interesting to note that the texture mapper in heretic more strongly resembles the PRB one, using a large unrolled loop with a table of branches into it to draw less pixels, rather than the self modifying code that Doom itself uses. PRB's debug symbols explicitly mention linear.asm so it's probably the same source, just pruned of low detail drawers. I suspect id kept around a lot of the mode 13h stuff used in the PRB and the heretic source ended up making use of it.

[viti95]

Another comparison, this time a Neoware Capio 600 (Cyrix MediaGX 300MHz):

• Mode Y: 24,273 fps
• Mode 13h: 64,345 fps (265% faster)

The difference in gameplay is insane, this SoC really hates the Mode Y. Even without L2 cache, the performance is really good with the Mode 13h. BTW this is using the linear.asm functions R_DrawColumn and R_DrawSpan. I think the Heretic and the PRB ones are exactly the same. They are a little bit faster compared to the C version, but not much. Also they increase the executable size A LOT.

 

 

Edited April 23, 2021 by viti95

[xX_Lol6_Xx]

No dehacked support?

[Redneckerz]

3 hours ago, Lol 6 said:

No dehacked support?

No. Read back the previous page. Viti95 has not explored DeHacked much, so i gave some pointers.

 

Besides, DeHacked might introduce performance degradations since FastDoom's binary differs from stock.

[xttl]

I'd say the biggest impact from including a DHE parser would be slightly increased memory requirements (whether you are going to use the parser or not). Performance shouldn't be affected noticeably.

 

Old DOS Boom's DeHackEd parser would probably be less work to integrate than the one from Chocolate Doom, but it is also not as good.

 

Simply updating DOS DHE to support FastDoom binaries is not a very good idea because FastDoom is still being developed so it's a moving target.

[viti95]

More updates, FastDoom running in CGA 320x200 (4 colors, mode 4). I've changed the palette so it's not using the eye-melting default palette. I still have to optimize the backbuffer to vram conversion function. This is running on a 486DX-50 and a Trident Paradise 8-bit ISA card.

 

 

[zokum]

21 hours ago, viti95 said:

More updates, FastDoom running in CGA 320x200 (4 colors, mode 4). I've changed the palette so it's not using the eye-melting default palette. I still have to optimize the backbuffer to vram conversion function. This is running on a 486DX-50 and a Trident Paradise 8-bit ISA card.

 

Can you change the palette mid-rendering? You could have different colors for the status bar. On real CGA hardware you can change the palette a bit, maybe some other combinations of colors would be better? Although I think the default red-brown-green-black is probably optimal. Other color schemes might work better on the intermissions screens and credits.

Have you considered having some sort of specialized algorithm to convert the textures into CGA color textures? Apply dithering and various filtering for an optimal conversion. It would only be a one-time operation when loading a map. Hand tuned graphics would probably look more pleasing.

[viti95]

I guess it's possible to change the palette mid-rendering, as everything is stored in the backbuffer first, and then processed and converted to the CGA vram in a single pass. It's know it's possible to change the palette per scanline, but I don't know how much performance will be lost with that palette changes. The card I'm using barely gets 20 fps with a fast Pentium III, and around 12 fps with a 486DX-50.

 

I considered to create new colormaps adapted to 2-bit and 4-bit color modes, that would speed up the rendering with these low color modes (avoiding the color conversions). The main problem here is the time available to develop FastDoom, for me it's quite limited and for now having the basic rendering implemented it's a primary task (EGA 320x200 16 colors will follow next).

Edited April 30, 2021 by viti95

[zokum]

I was thinking about something on the way to the shop. Doom textures are typically ~16k for a 128*128 in 8bpp. In 2bpp they would take up a lot less memory. How about upscaling the textures and apply dithering to them to simulate the missing color gradients? You could scale it up to 256*256 and with 2bpp and use the same amount of memory as the original texture. With 4 pixels to simulate 1 pixels, you can probably approximate the original textures a lot better.

Closeups of textures would look better. You might have to use only the corner pixels of the 4 to avoid moire effects when viewed from afar. The scaling algorithm should take this into account. Leave the top corner pixel as in the original conversion and the other 3 for dithering.

[viti95]

I've also implemented EGA 320x200 16 colors mode, it's slower than CGA due to the chunky to planar conversion. My Trident Paradise PEGA-1A does some funky things to the sound card in my Pentium III, still don't why, maybe it's too slow. There is also some color problems that I have to fix, writing each plane at a time is fast but creates color artifacts when the video card is slow.

 

https://www.youtube.com/watch?v=TZp-Gnwm8_8

 

And maybe i'll add Hercules video card support, having a backbuffer simplifies developing new modes a lot.

[Blzut3]

48 minutes ago, viti95 said:

And maybe i'll add Hercules video card support, having a backbuffer simplifies developing new modes a lot.

This would actually be quite interesting if it could support dual head.  It does seem to be kind of hard to get the right hardware combo to get working, but given that there's not a whole lot of software for it would be pretty cool.

[viti95]

FastDoom already supports dual head mode but only for development purposes (only text on the monochrome screen).

[viti95]

And finally Hercules Graphics Card is supported. The original resolution of 320x200 is upscaled to 640x400, and then dithered using ordered dithering with a 4x4 Bayer matrix. I tried to implement a Sierra Lite dithering, but was too slow (although it looked incredible). My MCE2VGA doesn't support this mode very well, I will try next time with my IBM 5151.

 

 

[Redneckerz]

Something totally baller would be TIGA support. Early accelerated graphics that need a VGA card. They were used for CAD stuff.

 

Thing is, TIGA drivers aren't universal. You need specifics. And sometimes they have co-processors that do geometry. Geekdot hosts a lot of TIGA related stuff, as does this Tumblr blog.

 

There is a SDK, but like i said, it's baller. TIGADoom would be a typical "Because we can" Idea.

[viti95]

 

Doom on an IBM 5151 doesn't look that bad :D

Edited May 6, 2021 by viti95

[VGA]

That's pretty cool! Like permanent nightvision!

[roboticmehdi2]

Hi, nice project! Thank you for this.

 

When I start fdoom (0.8) with doom.wad and select New Game, it freezes, on dosbox.

 

Is this a bug or I am doing something wrong?

 

Anyway, here's what I did:

 

First started a new game from fdoomt25, and saved a game in some map.

 

Then from fdoom, instead of new game, I loaded the saved game, then I can warp to any map using cheat, and it works this way.

 

Edit: new game doesn't freeze with doom1.wad or doom2.wad or doomu.wad (ultimate doom), only with doom.wad(registered).

Edited May 8, 2021 by roboticmehdi2

[viti95]

@roboticmehdi2 What version of doom.wad are you using? I think the IWAD filename is wrong, FastDoom 0.8 requires them to be this way:

• DOOM.WAD -> DOOM Registered (3 episodes)
• DOOM1.WAD -> DOOM Shareware (1 episode)
• DOOMU.WAD -> Ultimate DOOM (4 episodes)
• DOOM2.WAD -> DOOM II
• PLUTONIA.WAD -> Final DOOM The Plutonia Experiment
• TNT.WAD -> Final DOOM TNT Evilution

If the problem persists i'm pretty sure I made some mistake unifying the all the executables onto a single one (and will fix for the next version).

 

[Blzut3]

On 5/6/2021 at 10:59 AM, viti95 said:

 

Doom on an IBM 5151 doesn't look that bad :D

Man, Doom is so burned into my brain I can still see a full color image in there. XD

 

Honestly I didn't expect dithering to look that good.  Now even more curious if it would be technically feasible to support -left/-right on a single machine using dual head?  Before I figured maybe it would only be useful for throwing the automap up or something like that.  I think in dual head the Hercules card has limited resolution?  Or is that only the case when paired with CGA?

[roboticmehdi2]

12 minutes ago, viti95 said:

@roboticmehdi2 What version of doom.wad are you using? I think the IWAD filename is wrong, FastDoom 0.8 requires them to be this way:

• DOOM.WAD -> DOOM Registered (3 episodes)
• DOOM1.WAD -> DOOM Shareware (1 episode)
• DOOMU.WAD -> Ultimate DOOM (4 episodes)
• DOOM2.WAD -> DOOM II
• PLUTONIA.WAD -> Final DOOM The Plutonia Experiment
• TNT.WAD -> Final DOOM TNT Evilution

If the problem persists i'm pretty sure I made some mistake unifying the all the executables onto a single one (and will fix for the next version).

 

 

it's DOOM.WAD -> DOOM Registered (3 episodes) and I am sure it's not corrupt, sha1: 7742.........CBD

 

NEW GAME freezes, LOAD GAME works fine.

 

Edit: Also tried doom2.wad, works fine. Only doom.wad freezes with new game.

 

Edit2: ultimate doom also works fine, doesn't freeze when NEW GAME is selected.

Edited May 8, 2021 by roboticmehdi2