What kind of system did you need to run doom95 at 640x480?

Zdoom on a pentium 166 can't break 12fps at 320x200x8. Doom95 at the same resolution is a constant 35 fps, but not 640x480 (Not surprised, I had the same experience back in the day). Just curious what kind of specs you'd need for it to be smooth on iwad levels?

A simple extrapolation compared to vanilla Doom (with a Pentium 66 guaranteeing 35 fps constant fps at vanilla resolution), would yield a pentium 266 for 640x480 (4 times the resolution), by taking into account the overhead of running Windows 95 vs DOS.

Probably you can make do with a bit less (200 or 233 MHz, also it might work better with a Cyrix or AMD CPU, which were better at integer performance than Intel's, at frequency parity, which is really what you want for Doom).

A lot will depend also on how much cache you have (L3 cache on those old mobos could be upgraded up to 512K!), what kind of RAM (e.g. EDO) and how much of it (way more than 8 MB would be better), and even the videocard (even for plain frame-buffer operations, not all were equally good). Windowed vs full-screen mode may also make a huge difference.

As far as I can remember, it was running fine in Intel Celeron 300 MHz.

Maes said:

A simple extrapolation compared to vanilla Doom (with a Pentium 66 guaranteeing 35 fps constant fps at vanilla resolution), would yield a pentium 266 for 640x480 (4 times the resolution), by taking into account the overhead of running Windows 95 vs DOS.

I have a question related to this, as you've probably noticed, I've been doing a lot of running doom on old hardware, mostly to see how it performs. Just say I have a pc that runs zdoom fine at 640x480. If I then run it at 1280x960, again 4x the resolution, is that comparable with running it at 640x480 on a cpu that's 4x slower?

invictius said:

I have a question related to this, as you've probably noticed, I've been doing a lot of running doom on old hardware, mostly to see how it performs. Just say I have a pc that runs zdoom fine at 640x480. If I then run it at 1280x960, again 4x the resolution, is that comparable with running it at 640x480 on a cpu that's 4x slower?

Let's assume that running logic and sounds needs a small fraction of CPU power (5-10% cpu is a reasonable real-world upper limit). So the overall performance depends mostly on rendering.
Modern source ports as ZDoom, are using techniques and optimizations to run fast in high resolutions. One example is to draw columns horizontally taking notice of continously same color pixels (ie color is not recalced in every pixel). As a result, obtaining the same performance in [N x resolution] needs less cpu than [N x cpu].


On the other hand, if you're talking about OpenGL rendering, it's all about the graphic card.

invictius said:

Zdoom on a pentium 166 can't break 12fps at 320x200x8.

ZDoom on a Pentium 166 did way more than 12 fps. I remember being able to go at least to 640x480 before stuff became a chore. on my 233MHz Pentium MMX I could bump it all the way to 800x600 with no problems.

Of course, I'm talking about the old v1 of ZDoom, and v2.0.63a.

invictius said:

I have a question related to this, as you've probably noticed, I've been doing a lot of running doom on old hardware, mostly to see how it performs. Just say I have a pc that runs zdoom fine at 640x480. If I then run it at 1280x960, again 4x the resolution, is that comparable with running it at 640x480 on a cpu that's 4x slower?

Depends on what you mean by "slower". Most of the operations in Doom were cache-bound. If you wanted a speed increase, you needed to get some L2 Cache on that board. 256KB at the very least.

This is true with a lot of older programs. The more L2 cache you have, the better the system runs as a whole.

There are many variables here, such as which particular ZDoom version we're talking about and on which OS. An older one might work better on older hardware, or some particular ones might have bottlenecks (an infamous, vexing bug that affected older ZDoom versions was that loading PWADs under Windows 98 at least resulted in a noticeable slowdown regardless of complexity or type of PWAD. Just the fact that you loaded a PWAD caused the slowdown).

As for scalability to even higher resolutions, the argument remains valid only until some other limit is hit: there's not only CPU to contend with, but also RAM and, most importantly for rendering, video RAM and bus speed.

Vanilla Doom mostly ran on ISA bus systems, and due to the mode of accessing the VGA< it's actually bottlenecked to a maximum theoretical 240 or so FPS, regardless of CPU power.

By using non-DOS ports, non-DOS OSes and PCI or AGP video cards (and appropriate support from the OS), the limit obviously rose, but by going 4x the resolution, it can easily be "choked" once again. It's an endless arms race.

So if you take a Pentium 233 MMX with a conventional PCI card and force it to run at 4x SVGA resolution (so 1280 x 960), now you need to update 43008000 pixels a second (with an 8-bit canvas). Even if somehow you overclocked the CPU to theoretically keep up, other subsystems will begin to act as bottlenecks.

Moving that much data every second through a motherboard of that age with the chipsets and drivers of the time is seriously gonna trash the cache, mangle the memory bus, and use more than 1/3rd of the PCI bus's theoretical bandwidth (133 MB/sec), assuming the chipsets can even keep up. And then you have to leave some room for the OS, disk access, sound etc. Everything will have to work just perfectly.

I can't remember what other hardware I had in my first pc, but it ran on a "P90" (90mhz pentium). I don't remember doom95 being slow, but I also didn't use it much because iirc the sound was really strange, plus it was just faster to use the vanilla command line than the doom95 GUI frontend. Perhaps I used the in-engine screen size adjustment and that's why I dont remember it being slow?

Maes said:

So if you take a Pentium 233 MMX with a conventional PCI card and force it to run at 4x SVGA resolution (so 1280 x 960), now you need to update 43008000 pixels a second (with an 8-bit canvas). Even if somehow you overclocked the CPU to theoretically keep up, other subsystems will begin to act as bottlenecks.

Moving that much data every second through a motherboard of that age with the chipsets and drivers of the time is seriously gonna trash the cache, mangle the memory bus, and use more than 1/3rd of the PCI bus's theoretical bandwidth (133 MB/sec), assuming the chipsets can even keep up. And then you have to leave some room for the OS, disk access, sound etc. Everything will have to work just perfectly.

You make it sound much worse than it really is. The canvas uses the same 1.2 MB of memory over and over again. In Vanilla Doom, that includes never reading from video memory, which means it could use write combining. That it in turn means it can be done without affecting the caches at all. If ZDoom of that age did translucent stuff, then it would be using a system memory buffer of 1.2 MB and a DMA transfer to video memory.

dpJudas said:

You make it sound much worse than it really is. The canvas uses the same 1.2 MB of memory over and over again.

Still, that amount of memory is larger than all the L1, L2 and L3 caches combined in that sort of system (heh, remember the days when there actually was on-board L3 cache memory?). So messing with a raster at those high resolutions, even for one fame, pretty much obliterates the cache.

dpJudas said:

In Vanilla Doom, that includes never reading from video memory, which means it could use write combining. That it in turn means it can be done without affecting the caches at all.

Again, that's heavily dependent on the capabilities of the mobo's chipset and its CMOS settings. There was a lot of tweaking one could do with the classic AMIBIOS, but not all mobos had the same potential and not all systems were finetuned for max performance by default.

dpJudas said:

If ZDoom of that age did translucent stuff, then it would be using a system memory buffer of 1.2 MB and a DMA transfer to video memory.

Well, nobody suggested that in addition to all that overhead/bandwidth, the CPU should also do PIO to the video card, that'd be ultra-lame. But still, it would be a lot of bandwidth to deal with, and after a certain point, the use of a graphics accelerator would be pretty much mandatory. N.B., I'm not saying the average system would be technically incapable of functioning at such high resolutions: only that it would be quite the stress test for below average/inferior setups (which were the majority).

Maes said:

Still, that amount of memory is larger than all the L1, L2 and L3 caches combined in that sort of system (heh, remember the days when there actually was on-board L3 cache memory?). So messing with a raster at those high resolutions, even for one fame, pretty much obliterates the cache.

Well, the CPU mentioned in the thread has 512 KB of L2 cache. 800x600 is 468 KB, 640x480 is 300 KB. Also keep in mind the frame buffer pixels are accessed exactly once per frame (maybe twice with masked stuff), while the textures are being read continuously over and over again. There is also no reading ever from the FB. Some cache designs would make it keep the textures in cache.

I don't know how much that will affect cache usage, especially not a CPU of that age. But my CPU has 8 MB of cache and the QZDoom true color renderer uses a 8 MB frame buffer for 1920x1080. When I pump that up to 3840x2160 (4K) it needs a 32 MB buffer and the frame rate more or less becomes exactly 1/4 of what it was at 1080p. That is, the cache being too small doesn't seem to affect it much. Of course, different generation CPU and bus, so apples and oranges, but still.

Maes said:

Again, that's heavily dependent on the capabilities of the mobo's chipset and its CMOS settings. There was a lot of tweaking one could do with the classic AMIBIOS, but not all mobos had the same potential and not all systems were finetuned for max performance by default.

True. But if we extend the assumption to be that the user runs Windows, has his mobo drivers installed, and ZDoom uses DirectDraw. Then the odds of both write combining video memory (cache only contains textures then) and DMA transfers being available and used gets significantly higher.