GZDoom 4.7.0 released

[grahf78]

I am a little disappointed that the PR for automap thickness wasn't merged for this one, but great release overall.

[Redneckerz]

One of the biggest port releases of this year and especially so for GZDoom. MBF21 support is huge, but including the GLES renderer is aswell, making GZDoom-GLES now an archived port. Good thing this is now a switchable renderer and GZDoom now is more than capable for low end systems.

This would be great to test on Radeon 9xxx, (A 2002 9700 Pro would be class!) Geforce 6xx and lower and what have you.

Monumental release, thanks Graf and team for kicking it up.

[Graf Zahl]

On a Geforce 550 the full renderer works better, you need something a bit older. When asking for some benchmarks we got good results with GLES for one Geforce 8800 and several Intel HD 4xxx GPUs, but anything more recent showed clear advantages on full OpenGL, and no hardware supporting Vulkan profited in any way from it.

Which is what we actually expected.

[Redneckerz]

On a Geforce 550 the full renderer works better, you need something a bit older. When asking for some benchmarks we got good results with GLES for one Geforce 8800 and several Intel HD 4xxx GPUs, but anything more recent showed clear advantages on full OpenGL, and no hardware supporting Vulkan profited in any way from it.

Which is what we actually expected.

That's what i'd be going for, indeed. Either at about a high end Geforce 7900 or something that has modern OpenGL support but is too slow to actively use it, like something like a Geforce 210 (or 610).

All those very low wattage and low power chips would likely benefit from GLES.

[Graf Zahl]

Geforce 7900 will probably run like utter shit - provided that it runs. Both Geforce 6xxx and 7xxx series suffered from very, very poor shader processing, and even the GLES version heavily depends on shaders to do all the work.

That's not even considering that these cards have virtually disappeared entirely by now, they are simply far too old.

[Kizoky]

wish I still had that ATI Radeon HD 3650 around :S

Great release btw!

[KynikossDragonn]

Intel Iris Pro 580 still runs great regardless if I pick OpenGL or Vulkan. I don't think there'd be a point to me picking OpenGL ES in that regard, but the only other thing I play that uses OpenGL ES is Cruelty Squad. (and that's because Godot Engine only runs in OpenGL ES)

[Graf Zahl]

If you can run Vulkan there is no point using GLES. It's for hardware that has issues with the full GL backend and does not support Vulkan.

[Graf Zahl]

Here's some first trend of the survey:

Pre Vulkan hardware currently is at ~13 %. This is down from 22% two years ago. But what's surprising here is that the higher end of this segment has shrunk a lot more than the really old stuff. While in 2018 roughly 60% of this old hardware ran on systems with full GL feature support, this number shrank to 52% in 2019 and now is at less than 40%. The same trend can be seen with older generations of Vulkan compatible hardware. Their numbers have also shrunk severely.

32 bit is too low numbers to make out any trend so far. But all the genuine reports in this segment hint at truly old hardware, so nobody running 32 bit Windows on a newer system deliberately. It's all ancient graphics hardware from the time when 32 bit OSs were still being sold preinstalled.

Windows 7+8 share combined is at roughly 10%, down from 13% two years ago. Since we do not make a distinction here I cannot tell how many of these are using the unsupported-by-Microsoft Win 7, though.


So, overall all numbers so far point at some really weird development:

We essentially get two groups of users, a large one keeping their systems up to date and running both modern software and hardware, and a smaller one which continues to run their ancient stuff until the bitter end. The middle ground between these groups seems to thin out ever more to eventually disappear completely and the gap between both groups ever more widens.
It really takes no rocket science to predict that as time goes by these will be impossible to support with one set of code, as the requirements will diverge ever more as time advances - especially with Windows 11's release on the horizon.

It's not time for it yet, but I won't rule out that in the future we may do a split between GZDoom-GL and GZDoom-Vulkan, so that the Vulkan backend won't be limited by the requirements of OpenGL anymore which makes a lot of the potential multithreading very hard to pull off.

[ClessxAlghazanth]

Sorry for the (probably) obvious question , but the latest devbuild pre-216 at https://devbuilds.drdteam.org/gzdoom/ released today (23rd) is created after official 4.7.0 release and contains the light attenuation fix , right ?

I'm asking this because the file I downloaded says 4.6.9999.0 in the title

Maybe I'm just thinking too much

Best regards

[Graf Zahl]

The only post 4.7 fix so far has been an autoload problem. It says 4.6.9999 because the corresponding tag isn't there yet.

[Rachael]

Sorry for the (probably) obvious question , but the latest devbuild pre-216 at https://devbuilds.drdteam.org/gzdoom/ released today (23rd) is created after official 4.7.0 release and contains the light attenuation fix , right ?

I'm asking this because the file I downloaded says 4.6.9999.0 in the title

Maybe I'm just thinking too much

Best regards

The light attenuation fix was part of the official release. If it is still not working, please make a new bug report.

[theleo_ua]

hud models: add nullptr check for psprites without caller.

Look up HUD models by referencing the psprite's caller, rather than player's ReadyWeapon.

dim depleted inventory items in all games, not just Strife.

Could you please explain, what this means and what benefits?

BTW, here's something interesting: Of all the 34 reports so far, not a single one is for hardware not capable of Vulkan, and the only one for 32 bit was my own test call...

For me, it's interesting how many people use win7

[theleo_ua]

It's not time for it yet, but I won't rule out that in the future we may do a split between GZDoom-GL and GZDoom-Vulkan, so that the Vulkan backend won't be limited by the requirements of OpenGL anymore which makes a lot of the potential multithreading very hard to pull off.

Is it possible to fix memory overflow crashes and glitches in future (for vulkan)? I still not use vulkan renderer because 2GB of VRAM is not enough, crashes and glitches appear

[Graf Zahl]

The big problem is that NVidia's driver does not properly report out of memory errors, so whatever is needed here - I cannot even test it because the driver screws up!