What's up for GZDoom after running the survey?

[Graf Zahl]

If you have been asking yourself, what's in store after having gotten some info about the installed hardware base of our users, here you will find some answers.

The most important thing is, that 6% of our users are still using OpenGL 2 hardware, so for the time being support for that is safe. Don't expect support for new features, though, because that will focus on modern graphics hardware as is owned by the vast majority of GZDoom users.

Things are more interesting on the software renderer. The survey has only 17 out of 5700 users reporting use of the pure software renderer. 5 of these are on Linux which currently suffers from too high hardware requirements for its hardware accelerated 2D for software rendering.
The numbers also showed clearly that the vast majority of software renderer users have hardware that is good enough to run the hardware renderer. The amount of users where the reported data about hardware rendering support is not clear enough is roughly 1% of all reporting users, but extrapolating from the rest of the data it should be a safe assumption that roughly 75% of these do have good enough hardware.

To summarise the above two points, it means that only a tiny fraction of significantly less than 1% may be running the software renderer on hardware old enough to not support OpenGL 2.0.

For those few in this group, I'm sorry to say, but that low number does not justify keeping support for a feature that has serious implications on code maintainability, so for the 3.4 release the backend code for the software renderer will be cleaned up and consolidated. The minimum requirement for GZDoom in both software and hardware rendering mode will now be OpenGL 2.0.
The SWGL, DirectDraw and Direct3D backends will be removed and all hardware access for software rendering be provided by the hardware renderer.
This means that instead of 4 render backends with wildly differing feature sets there will only be one, which will greatly simplify work when adding new features. An added advantage of such a setup is that the renderers can be switched live during gameplay without the need to restart the engine. A working branch for this can be found on the Github repo, it's not complete yet but should work on OpenGL 3.3+ hardware. Making this work on OpenGL 2 is still under development.

[Caligari87]

Headfirst into the future with the power of statistics, nice. I feel for the minority of users that will be affected by the renderer removal, but its exciting to see GZDoom moving forward. Thanks Graf (and all the devs) for your transparency.

[Major Cooke]

To be fair, GZDoom's been hanging back for a good long while now. I for one welcome our new rendering overlords with plenty of upcoming goodies like Vulkan.

[_mental_]

I’ve pushed bunch of fixes for non-Windows platforms. It will be cool if Linux users would play with 2D_Refactor branch.
There is one warning left without a fix. I’m no familiar with that code to decide what FRawPageTexture::CopyTrueColorPixels() function should return, 0 or -1.

[Cacodemon345]

Headfirst into the future with the power of statistics, nice. I feel for the minority of users that will be affected by the renderer removal, but its exciting to see GZDoom moving forward. Thanks Graf (and all the devs) for your transparency.

I think that minority of the people will either go for SW-rendered OpenGL which would be painfully slow or end up buying a new hardware.
I honestly don't see a point in the SW renderer now, because both it and OpenGL renderer requires at least OpenGL 2.0.
Even then, it was a nice survey. Thanks.

[Kinsie]

I honestly don't see a point in the SW renderer now, because both it and OpenGL renderer requires at least OpenGL 2.0.

There are a number of visual tricks from the old days that, at least at this exact moment in history, the hardware renderer can't properly reproduce.

[Cacodemon345]

I honestly don't see a point in the SW renderer now, because both it and OpenGL renderer requires at least OpenGL 2.0.

There are a number of visual tricks from the old days that, at least at this exact moment in history, the hardware renderer can't properly reproduce.

GZDoom is now using a 32-bit software renderer. I use OpenGL most of the time, so I can't really say if they still work or not.

[Graf Zahl]

The general rule of thumb should be: If you know a map with a render hack the hardware renderer does not support, post a link. Many times the entire thing can be handled by adding a compatibility setting, see the recent handling of that one Perdition's Gate map.

@Cacodemon345: While for me the software renderer holds little interest, there's no denying that 8.5% of our users are actually using it, that's more than OpenGL 2.x and the vast majority of them are using modern computers. None of these people will experience problems by this change, but I am fully aware that the D3D renderer supported some hardware that does not have an OpenGL 2 driver. But the current numbers do not suggest that these are many - quite the opposite.

Of course OpenGL 2 will eventually suffer the same fate as the D3D and DDraw backends - it's old, it's crusty and it stands in the way. And the number of users is declining. Once it has declined enough, this stuff will be tossed, that's a given.

[SanyaWaffles]

I prefer to see GZDoom move forward and not stay in the past with archaic hardware and software requirements, so this is a welcome change.

And being able to switch renderers is something I've always wanted to see... so woohoo.

[_mental_]

The general rule of thumb should be: If you know a map with a render hack the hardware renderer does not support, post a link. Many times the entire thing can be handled by adding a compatibility setting, see the recent handling of that one Perdition's Gate map.

Among famous WADs there are MAP01 of Suspended in Dusk (hanging container trick) and MAP01 of Alien Vendetta (deep slime pool trick).
I could give exact map locations but I'm pretty sure these examples are nothing new to you.

[Kinsie]

The one I usually think of is the impressively hacky fake 3D floor at the end of Kama Sutra (Note: Titlepic is NSFW) MAP01. The hardware renderer makes a valiant attempt at the top, but breaks down trying to deal with the bottom.



Kind of a hardcore edge case, though, and it doesn't effect gameplay, so I'm not really sure if there's a good way of dealing with it outside of using compat flags to inject 3D floors into the map or something unpleasant like that.

[Graf Zahl]

For my personal copy I fixed that map with a 3D floor. I'll have to see if I can do that through compatibility.txt, but it probably requires some more features in there.
Actually, maybe it's a good idea to implement some compatibility ZScript that is more flexible in altering map data than a static text lump.

Aside from that I'll start a thread in Bugs where broken maps can be posted.

[_mental_]

Actually, maybe it's a good idea to implement some compatibility ZScript that is more flexible in altering map data than a static text lump.

I was thinking about the same because our level compatibility domain specific language is getting more and more complex.
The idea is to start with conversion of simple cases and to move step by step toward complete replacement of compatibility.txt with ZScript based solution.
I'll try to take a close look at this soon.

EDIT: Pushed a very basic proof of concept to ZScriptLevelCompat branch.

[Graf Zahl]

This goes in the right direction but for the sake of optimization I'd do it a bit differently:

Instead of passing the hash as a string, let's pass it as a name. That has two advantages:

1. It can be determined up front if a map has a compat entry. If the name lookup in native code fails, we already know that there cannot be any because otherwise the compiler would have created a name for the given string and not even start the script.
2. script side comparisons are faster and the code can be written as switch/case instead of 'if /else if / else'.

[_mental_]

I wanted to make these changes myself today but you already did it. So I'll continue to work on scriptification of other compatibility options.