What's up for GZDoom after running the survey?

Here, developers communicate stuff that does not go onto the main News section or the front page of the site.
[Dev Blog] [Development Builds] [Git Change Log]

Moderator: Developers

What's up for GZDoom after running the survey?

Postby Graf Zahl » Sat Apr 07, 2018 4:50 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: What's up for GZDoom after running the survey?

Postby Caligari87 » Sat Apr 07, 2018 7:35 pm

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.

8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: What's up for GZDoom after running the survey?

Postby Major Cooke » Sat Apr 07, 2018 11:53 pm

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.
User avatar
Major Cooke
The road to Hell is paved in the carrion she leaves behind.
 
Joined: 28 Jan 2007
Discord: Major Cooke#0846

Re: What's up for GZDoom after running the survey?

Postby _mental_ » Sun Apr 08, 2018 6:07 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: What's up for GZDoom after running the survey?

Postby Cacodemon345 » Sun Apr 08, 2018 8:57 am

Caligari87 wrote: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.

8-)

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.
Cacodemon345
 
Joined: 22 Dec 2017
Discord: Cacodemon345#9151

Re: What's up for GZDoom after running the survey?

Postby Kinsie » Sun Apr 08, 2018 10:53 am

Cacodemon345 wrote: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.
User avatar
Kinsie
A Concept Utterly Obsolete
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: What's up for GZDoom after running the survey?

Postby Cacodemon345 » Sun Apr 08, 2018 11:07 am

Kinsie wrote:
Cacodemon345 wrote: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.
Cacodemon345
 
Joined: 22 Dec 2017
Discord: Cacodemon345#9151

Re: What's up for GZDoom after running the survey?

Postby Graf Zahl » Sun Apr 08, 2018 11:30 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: What's up for GZDoom after running the survey?

Postby SanyaWaffles » Sun Apr 08, 2018 8:48 pm

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. :D
User avatar
SanyaWaffles
Ice Bear Charges Extra
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles

Re: What's up for GZDoom after running the survey?

Postby _mental_ » Mon Apr 09, 2018 2:22 am

Graf Zahl wrote: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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: What's up for GZDoom after running the survey?

Postby Kinsie » Mon Apr 09, 2018 5:59 am

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.

ImageImage

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.
User avatar
Kinsie
A Concept Utterly Obsolete
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: What's up for GZDoom after running the survey?

Postby Graf Zahl » Mon Apr 09, 2018 7:09 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: What's up for GZDoom after running the survey?

Postby _mental_ » Mon Apr 09, 2018 8:30 am

Graf Zahl wrote: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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: What's up for GZDoom after running the survey?

Postby Graf Zahl » Mon Apr 09, 2018 1:45 pm

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'.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: What's up for GZDoom after running the survey?

Postby _mental_ » Tue Apr 10, 2018 2:55 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Next

Return to Developer Blog

Who is online

Users browsing this forum: No registered users and 0 guests