There have been some discussions lately on the forum about how difficult it is to run GZDoom on old hardware.
You might think - "Doom is an old game. All I ever need is Doom." That's fine. Doom can run on old systems. But not GZDoom. The point of GZDoom is to run Doom on modern hardware, using modern rendering techniques that are more efficient on modern computers. It turns out that in many cases, the techniques that are best suited for modern computers are ill suited for, or even entirely incompatible with, old hardware. And inversely, optimizations that made sense on old computers can be counter-productive on modern hardware.
"But I shouldn't need a computer that runs Crysis 5 just to run Doom!" - and you'd be right. If you want to just play Doom on a system that could run the original, "vanilla" engine, then you can still do so and just play Doom with its original engine. If you want, however, to play modern GZDoom mods that push the Doom engine far beyond its original limits while enabling all sorts of effects that the original doom.exe never offered, then you have to realize that your old computer cannot do that. It cannot do that with GZDoom, just like it cannot do that with the original doom.exe. One important thing that needs to be remembered here is that the entire level setup of Doom is extremely hostile towards how modern graphics hardware works. Modern hardware can work best with large meshes that are being processed with a single draw call. Doom is the complete opposite of that: It is rare that a single draw call contains more than 10 vertices but there can be tens of thousands of them on modern and very detailed levels. This will lead to even seemingly 'primitive looking' data requiring more processing time than modern games which have been optimized for the hardware. That is part of why GZDoom can be slower than some of those newer games.
The vast majority of users who use GZDoom nowadays have computers that are at least capable of running games from the ~2012 era (i.e. capable of supporting OpenGL 4.x), and some possibly even newer than that. It would be a disservice to keep catering to users that use systems which are much older than that. Not to mention, it creates a whole lot of code bloat and makes the source tree much bigger than it needs to be. In some cases, keeping support for old hardware in can even make it impossible to implement features for newer hardware because the necessary approaches are mutually incompatible.
Basically what it comes down to is this: Doom is a 1993 game. If you want to run Doom on your 1993 system - by all means, go right ahead. But don't expect a source port that is being coded for modern computers to keep running on that same 1993 system. Times change, people get rid of those old systems, and they want something new. That's what GZDoom is.
Keep in mind that basically all hardware being manufactured in the last 5 years will be capable of running GZDoom with all effects enabled - performance issues nonwithstanding. It will also be capable of running with all non-postprocessing effects enabled on all non-integrated graphics hardware from the last 10 years and on a basic setting for even older systems. The software renderer with the Direct3D backend contains support for hardware up to 14 years of age.
So when we say things like "DirectDraw" is deprecated - that literally means, DirectDraw is going to be removed from the code base soon. If you do not have at least semi-decent pixel shader capable graphics card from 2003 or later, you will have to either keep using an older version of GZDoom, or perhaps look into ZDoom-LE ("Legacy Edition"), which is made specifically for outdated hardware but which, obviously, does not offer the more modern features that you will find in recent versions of GZDoom.
Here are some examples of some enhancements that were made to benefit modern computers, but unfortunately, could not be done likewise for older computers:
- TrueColor renderer was created for hardware-accelerated back-ends, not DirectDraw, where it likely would have run very poorly on modern systems.
- OpenGL 1.x support was dropped during GZDoom's 1.8.x series, and inherently kept out during the later 2.x series, due to severe maintenance overhead in the source code. Several features GZDoom depends on are only available on GL 2.x hardware and working around them is not easy.
- Features get dropped on OpenGL 2.x hardware, for the same reasons. It should also be considered that most effects that were previously done on 2.x hardware but have been dropped require texture duplication because without shader access they cannot be manipulated at real time. An example for this would be the invulnerability effect that has been replaced in both Doom and Heretic with a less faithful but far less resource intensive workaround. On GL 3.x hardware the proper effect can be done with the original texture and a special shader.
- In order to use C++ version 11, which increased source code readability and flexibility, support for Visual Studio 2005 had to be dropped. As a result, Windows 9x is no longer officially supported.
- SSE2-supporting CPU's are now required, because the true-color renderer runs very poorly without it and making the code compatible with older hardware would have involved some serious maintenance headache for a very small number of old systems.
- Assembly instructions were removed from the software renderer because the implementation details of this code made it impossible to use with multithreaded rendering. In general the performance advantage over C++ code compiled with a modern C++ compiler was very slim at best and negative at worst. The downside, of course, is, that on old single-core systems the non-assembly implementation will be slower.
- The "optimized" column rendering, which took advantage of a quirk in older CPU's that provided more efficient memory access, had been removed, again for source code readability - it more than doubled the size of the render code - but the main reason was that it provided no advantage whatsoever anymore on modern hardware - in fact it was slower or at best the same performance as the "unoptimized" version on any machine less than 10 years old it got tested on.