Have you tried FastDoom's VGA version?

(and yes, sticking a et4000 with a P3 is a paradox of the extremes)

I didn't even know that FastDoom was a thing. I looked it up and it's very interesting and I'll have to check it out.

Doom uses a tweaked mode called mode X (or mode Y since the resolution is 320x200) which is planar while Quake uses regular mode 13h which is linear. Linear mode is faster than planar mode because in planar mode there is possible overhead when switching between planes and some video cards can't handle it fast enough.

Heretic and Hexen also uses regular mode 13h despite using the same engine as Doom.

How is I that Doom can run slow but Quake is fast? What are the mitigating factors that cause Doom to lag behind?

Doom vs Heretic VGA performance difference

And yes, FastDoom VGA mode will dramatically improve performance.

Mode X has some tradeoffs and back then it made sense but the rules has changed by the time Quake was released. The main reason Carmack used it on Doom was to provide page flipping support (normal v-sync is expensive) as I noticed screen tearing on Heretic and Hexen when turning around while that doesn't happen on Doom.

Haven't checked FastDoom to see whether it uses the tweaked mode or the regular mode 13h.

Edit: I checked FastDoom and it is a very promising port with multiple video modes.

Gmlb256 wrote on 2021-08-10, 12:25:

Mode X has some tradeoffs and back then it made sense

Thats also what Abrash was theorizing in some post Doom/mode Y writeup (faster fills by playing with latches faster than rendering to ram then copy). FastDoom disproves this, leaves universal Vsync as the only practical reason for mode y.

In this scenario the CPU is plenty fast. What then is responsible for Mode X being slow? Is it the Tseng ET4000 or the ISA bus?

I'm not familiar with ISA graphics cards. Is it normal for them to struggle with Doom?

Is it possible to summarize the Tseng ET4000 on the ISA bus as "unusually slow" at Doom, "unusually fast" at Quake, or simply "average" overall.

Kahenraz wrote on 2021-08-11, 16:23:

In this scenario the CPU is plenty fast. What then is responsible for Mode X being slow? Is it the Tseng ET4000 or the ISA bus?

I'm not familiar with ISA graphics cards. Is it normal for them to struggle with Doom?

Is it possible to summarize the Tseng ET4000 on the ISA bus as "unusually slow" at Doom, "unusually fast" at Quake, or simply "average" overall.

I don't have any ISA video card to confirm this but I get similar results (fast in regular mode 13h but slow in mode X) from my old computers. The Tseng ET4000 is one of the fastest ISA video card but the ISA bus is very slow compared to VLB, PCI, AGP and PCI-E due to having a low bandwidth.

I/O wait states may have also an effect on the performance of the ISA video card.

Doom performance scales from data bus speed, if CPU is not primary bottleneck. It's simple as that. Even 486 will get some boost if you just overclock ISA, VLB or PCI bus. Therefore, you need PCIe 16x to achieve really high numbers in timedemo. I'm not joking.

Kahenraz wrote on 2021-08-11, 16:23:

In this scenario the CPU is plenty fast. What then is responsible for Mode X being slow? Is it the Tseng ET4000 or the ISA bus?

The original VGA design is based on an 8-bit bus interface. That design is unable to take 16-bit write cycles. It is easy to build a slightly enhanced VGA design that can take 16-bit cycles in text mode (odd/even addressing) and in standard 256-color mode (chain-4 addressing), but difficult to build a slightly enhanced VGA design that can take 16-bit cycles in Mode X. Furthermore, in Mode X a 16-bit write cycle would set the color of two pixels which are not neighbouring, but separated by 3 pixels inbetween that can't get accessed at the same time. So it might be inconvenient to use 16-bit video memory access at all in Mode X. I don't know what classic DOOM does, but if it does byte writes to VGA memory, and especially if the mainboard adds extra waitstates to 8-bit cycles that can not be cancelled using the 0WS signal, performance will be poor.

If I remember correctly, I experimented with writing a tiny 3D enigne at a feature level between slightly above Wolf3D that gathered the parameters for all 320 columns on the screen and then rendered 4 lines at the same time, so it could write to the memory using 32-bit cycles maximizing the efficiency of posted writ buffering on a 486DX50 with an ET4000AX graphics card. That engine got stalled on rendering performance, not on the ISA bus. But as this is years ago, I might mix up what hardware I had in use during that experiment. If my recollection is correct, the ET4000AX should be able to take 16-bit writes in Mode X at good performance, though.

Afaik doom does a lot of byte accesses, not to mention reads back from VGA to do transparency. Try fastdoom, it does all the cool tricks to avoid bottlenecks.

There are multiple reasons that make Doom slower on ISA cards compared to Quake on fast systems. The main difference on how both render the scene, is that Doom renders everything directly in the video card, while Quake uses a backbuffer in RAM memory and then copies that backbuffer to the video card. These are my guesses:

• The use of Mode Y requires to change planes while rendering the scene, that is an additional OUT instruction to be called to the video card for every column. This is even worse for visplanes, as each line of the visplane requires multiple OUT instructions to be called (one for each pixel in high detail mode). For some video cards this is a really slow operation (Rendition Veritè, Cyrix MediaGX,...)
• The memory writes to video card in Mode Y are 8bit wide, while using a backbuffer allows up to 32bit wide writes.
• The way Doom renders the scene is very optimized (columns and visplanes don't overlap) but sprites and transparent walls are rendered after the whole scene is rendered. This overlap requires more data to be written to the video card than it really needs to (and ISA bus is WAY slower than the main ram, even on 486 processors)
• Transparent objects in Doom requires reading from the VRAM in Mode Y, which is an insanely slow operation. Quake doesn't have this problem as it doesn't use that algorithm.

I think Doom benefits from Mode Y on slow processors, as it allows writing two pixels with a single 8bit operation for the low detail mode, and avoids using the main memory on 386 processors (again a very slow operation). Also page-flipping is good as it avoids screen flickering and doesn't require vsync.

ViTi95 wrote on 2021-08-17, 10:09:

Quake doesn't have this problem as it doesn't use that algorithm.

Well, it doesn't have that problem after v1.06 😀
Once upon a time Quake had a 'fadescreen' function for the menu background that would brown it with a video read per pixel with a small [256] lookup table. By the time Johnc had started to write WinQuake though, this had to be taken out for performance reasons (DirectDraw's vram reading performance is horrendous), leading it to be replaced with a black stipple since 1.07.

Hexen II on the other hand.... 🤣 they'll pop that whole screen into the translucency table regardless of resolution. <1FPS at 800x600+ on 1997 computers yay!

Some of the video modes that are on DOS Quake uses the tweaked mode such as 360x480 and you can set a 320x200 mode that exactly uses mode Y through the console.

The horrendously slow transparency effect also happens in older versions of Quake when using a VESA video mode, especially on high resolutions.