Blog

As some of you may have noticed on Discord, QZDoom devbuilds have begun to roll out recently.

These contain a selected 'batch' of features that have been merged into QZDoom for testing, and they certainly could use it. The sooner they're tested, the sooner bugs can be culled and the feature can be certified as ready for GZDoom itself.

Since they're in batches, not all of them have been pulled in yet to ensure QZDoom can keep up with changes made by GZDoom. This post will continuously be updated with information pertaining to what features are in and how they work.
-----
***NOTICE***
Please bear in mind, QZDoom is an experimental testing ground. Therefor, changes to anything can happen at any given time with each new DRD build being released. This is much more volatile and can certainly break the new features.

I will post updates when something changes and detail all you need to know.
-----
Here is what's in so far:

• Feature: Sprite Offsets
• Feature: ViewAngles (Part 1)
• Feature: PSPF_PLAYERTRANSLATED Overlay flag
• Feature: clearscope Index()
• Feature: ClearPlayerClasses and SetSlot override
• Bugfix: Install soundfonts and WOPL/WOPN banks

Spoiler: New Features Guide

---

Here is a detailed guide on how each new feature works.
-----
Sprite Offsets
Adds 1 Vector2 variable and 1 function to Actor.

A_SpriteOffset(double ox = 0.0, double oy = 0.0)
Offsets the sprite of an actor by the specified values.

Positive X values shift to the right, Y shifts down. Vice versa for negative values.
-----
ViewAngles (Part 1)
Adds 3 variables to PlayerPawn and PlayerInfo.
Adds 1 virtual function to PlayerPawn.

The variables are ViewAngle, ViewPitch and ViewRoll. These are simply offsets to the player's actual angle/pitch/roll and they do not affect aim. They also do not affect overlays.

The function CalcView() is responsible for transferring the three variables automatically to the playerinfo struct.

NOTE: The playerpawn's variables are merely for transference purposes so if a camera switch occurs, the view angles are remembered. It's the struct's variables that actually change the angles.
-----
PSPF_PLAYERTRANSLATED Overlay Flag
A flag for A_OverlayFlags, used to colorize the player's overlay/weapon sprites based on the user's color settings. For the ZScript savvy, this is known as bPlayerTranslated flag inside of the psprite class.
-----
Clearscope Index()
For the ZScript savvy, the Index() functions in Sector, SectorPortal, Line and Side structs have been given clearscope.
-----
SetSlot and ClearPlayerClasses Override
Introduces a new menu option for SetSlot and ClearPlayerClasses. If enabled, the default behavior applies: keyconf will wipe out all player classes and weapon slot settings. Otherwise, it will only clear out vanilla IWAD player classes, and keep all weapons assigned in keyconf.

If you find any issues or bugs, please make sure to include [QZDoom] in the title of the bug report for clarity.

Roughly 2000 users have reported by now, here's the first preliminary results, in parentheses the numbers from 3.5.0 with roughly 2000 users:

79% (67%) use Vulkan compatible hardware.
11% (17%) use hardware which can run OpenGL with all features enabled but cannot run Vulkan.
10.6% (12.6%) use legacy hardware which requires fallback solutions in the renderer and only has limited support for some features.

1.3% (3.3%) use a real 32 bit system.
Mac numbers are not representative yet due to delayed availability of the binary.
5.7% (6.3%) use Linux.

69% use a system with 4 CPU cores and more - among the Vulkan compatible systems this is 82%.

The big things are obvious:

First, 32 bit systems are clearly on their way out. They have massively decreased since last year, but unlike last year where they started weak but picked up a bit as more numbers came in, this time the opposite happened: They started weak but only got weaker day after day. The writing on the wall is very clear. 32 Bit is dying - and dying fast. Projecting into the future I think we can assume that after the coming Christmas season it will drop even further into irrelevance as more old computers get retired. With this in mind, the current plan is to continue support until the end of the year, but then discontinuing it and adding some features incompatible with 32 bit that have been requested - the biggest one being 64 bit integer support in the VM, meaning there will only be 64 bit builds being made for all platforms from next year on. So far there have been no reports from 32 bit Linux systems, it has only been Windows and judging from the configurations, it is nearly all ancient systems from at least 8 years ago.

These numbers are very much in line with what Steam's hardware survey had been indicating all along.

The second thing is legacy graphics hardware support. Again, the trend is very clear: Old graphics cards are disappearing fast, and what is even worse, all manufacturers have already deprecated their non-Vulkan supporting hardware, no longer providing driver updates for it. Although the current numbers are still far too high to even think about discontinuing OpenGL, it is very clear that support for such hardware in general is evaporating a lot faster than the user share here declines. It is only a matter of time until operating system support for such hardware will get bad enough to force it out of the market. I think the final decision here will not be made by declining user share but by external factors forcing us to move on in the not so distant future. It's not that I expect OpenGL to disappear, but the legacy hardware to get squeezed out at which point supporting a legacy API becomes pointless.


The third important thing for GZDooom is the number of installed CPU cores. Right now, 70% of all users and 82% of users with Vulkan compatible hardware have 4 or more cores, meaning that for the Vulkan backend multithreaded optimizations are definitely a viable option.

Last, but not least, Windows 10 currently has a user share of 75%, Windows 7+8 together have 13%. This won't have any impact on GZDoom itself, because GZDoom does not use any post-Windows 7 features for anything, but should be a clear warning sign to Windows 7 holdouts: The system is disappearing from the market A LOT quicker than Windows XP when it reached the end of its life!

I recently installed Visual Studio 2019 and found out that it only supports compiling for Windows XP via legacy toolsets from older compilers. Yes, that is correct: Microsoft has finally dropped XP support from their current line of compiler tools.

This has an important implication: Going forward and using newer C++ language features in the source means that none of these will be backported to work with the XP compatible toolset.

Checking the database from the 3.5 survey. The survey contains 31480 distinct users not requiring the vintage build.
Of these 31480 users there were 41 users on Windows XP, meaning we are left with roughly 0.13% of our users on Windows XP.

Under these circumstances there is little point to continue XP support, the user base is simply too small to justify shutting ourselves off from future C++ versions and having to install a large package of legacy build tools and SDKs, so with the next release Windows XP support will be dropped from the official releases and no attempts will be made anymore to keep the code compatible with such older toolsets.

GZDoom is in the transition of its localized string handling right now.
The goal is to have the language resources in a place where it can be edited by external contributors that do not use the GZDoom Github project directly - they are hosted on Google Docs so that anyone with interest to contribute can request access to edit.

In the future the language.enu lump will no longer exist, instead, all texts will be read from a spreadsheet file within gzdoom.pk3 which is periodically updated from the public versions mentioned above.

This has a few implications on how text content needs to be handled - editing the language files within the GZDoom project is no longer possible because they no longer represent the master version of the text resources. For pull requests this means that they have to do a minor bit of added work to get the newly added strings to where they belong: Instead of editing language.enu, the new texts will have to be added to the PR as a comment, outside the actual changeset so that if the PR gets merged they can be added to the spreadsheet easily.

Please note that since the text data in the Github repo is not the master resource, any alteration of it by a PR needs to be rejected without exception.

I finally managed to export all language content to a spreadsheet. Here are links to a couple of Google spreadsheets.

https://docs.google.com/spreadsheets/d/ ... sp=sharing (Engine)
https://docs.google.com/spreadsheets/d/ ... sp=sharing (Game)

My hopes are that there's some interest here to help fill in some gaps.
If you want to contribute, please continue reading.

This Google spreadsheet will serve as the master text list for GZDoom in the future. What gets in here will get into the next release.
Any contributions should be submitted in spreadsheet form and formatted so that they can be easily copied into this master list.

This means, you should download this sheet, and depending on whether you want to complete an existing language or add a new one, either edit the column for your language or add a new one. If you start working on something please post a quick note here.
Alternatively you may ask to get write access to this one. For that, please send me a PM.

Also, please make intermediate submissions of your work if parts are complete so it can be reviewed by other users.

If someone is interested in contributing some graphics work but not actually translating, there are still some characters to be added to the fonts.
Here's a spreadsheet with the current status:

https://docs.google.com/spreadsheets/d/ ... sp=sharing

Disregarding Chex Quest's BigFont which is already being worked on, the entries marked red are missing for the current set of languages, and the ones marked orange are missing for languages that are currently being translated. Yellow ones would be an extra, but right now no language requiring these characters has seen any work. All other colors mark characters that won't be needed or are already done.

People using the git repo to self compile or those using devbuilds may have noticed that the binaries from the master branch have become somewhat unstable.

This was the result of some bad refactoring that turned out harder to fix than expected.
Unfortunately there is no easy solution to fix this code on short notice. It would require a lot of time to straighten things out so in order to get back a stable master branch I decided to roll back the abovementioned refactoring and then reconstruct a new branch, only containing the clean commits.
But due to the extent of the changes - we are talking about 140 commits here from which 50 had to be re-applied this cannot be done without actually resetting master to a different branch in the repo.

This means that everybody working directly with the repo will have to do a rebase of master, once the changeover has been made. I have to apologize for this but the alternative would be a prolonged period of extreme instability that would be detrimental to the project itself.

Roughly 2000 users have reported by now, here's the first preliminary results:

67% use Vulkan compatible hardware
17% use hardware which can run OpenGL with all features enabled
12.6% can run the modern render path (i.e. they are OpenGL 3.3 compatible)
3.4% run the legacy (OpenGL 2.x) render path.

3.3% use a real 32 bit system.
There really was 1% of users which only ran the legacy build on modern hardware!
2.7% use a Mac
6.3% use Linux
3.3% used a real 32 bit system
5 users reported Windows XP

So what does this mean?
Obviously for Mac and Linux the numbers are still too small to make any conclusions why they have changed.

Overall, Vulkan capability went from 57% to 67% in a mere 4 months! I think this trend is more than obvious.
Non-Vulkan but modern OpenGL-capable cards went from 34% to 29%, unfortunately this wasn't split like here in the old survey so it's hard to say how this really developed.
This is even more obvious for real legacy hardware which was nearly halved in user share over the last couple of months.

I believe the trend this shows is very evident: The legacy segments are declining rapidly. I am quite certain that, if we do another survey at the beginning of 2019, after this year's Christmas business has run its course, that OpenGL 2.x will have been reduced to a little more than background noise, and this should be a clear warning to anyone still running such hardware: Support for this will end rather sooner than later. The same may be true for 32 bit. This has also nearly shrunk in half over the last 4 months.

I think dpJudas had the best explanation in the previous thread, so to prevent this from getting lost, I am reposting it here:

dpJudas wrote:

Sgt. Shivers wrote:Just wondering, why can't the screen be scaled with the options menu anymore? Is there something stopping the window being set for size with the new system or is it just temporarily being taken away while the resolutions are put back in?

The old video list was removed for several reasons:

1) The list was queried from the display driver. A concept utterly obsolete and in practice a hard-coded list in the display driver. Legacy resolutions like 1024x768, 800x600, which all were incorrect as the hardware doesn't actually support any of those resolutions. Modern display technology only supports one resolution as they aren't CRT displays.

2) Asking the typical user about the full screen resolution is bad UI as the answer in 99.95% of all cases is.. the actual monitor resolution. Why do you think modern newer games just ask you if it should be fullscreen + a scale factor. Apparently not only are we idiots based on the feedback, the entire gaming industry seems to be so!

3) The code was very old, included broken obsolete concepts like the LB modes that no longer made sense (the general scaling system in GZDoom handles this via other settings for a while now). It also conflicted with #2 as it required the user to make a pointless obscure decision for the majority of users.

4) The newer scaling code actually supports selecting specific resolutions. This made the old video selection code redundant. The list of options currently is pretty small, but it is trivialto add more to that list.

5) OpenGL doesn't support exclusive full screen mode changes. What we had was always a hack. Due to #3 it meant any user that selected full screen would get their desktop icons rearranged. That really sucked!

Half the feedback currently seems to come from people that have no idea what scaling features GZDoom actually has, nor puts much consideration into why we are trying to adjust the menu in the first place.

It seems like we could use some way to specify specific windowed geometry sizes, as apparently some used that feature in the old video list. That's more or less the only useful conclusions I've been able to draw from this so far.

It should be noted that plans are in place to have vid_setmode make a comeback in the newer devbuilds, but it is yet to be fully implemented on Mac and Linux.

If you use Raspberry Pi, please note the following with the 3.4.x releases:

With the 2D refactor, running in pure software mode simply is not playable on the Pi, anymore. However it will continue to be supported because running it on the VideoCore4 GPU chipset works, for now. Please note that Pi boards that are revisioned 2 or 3 are the only ones currently supported - you can run GZDoom on a Pi 1 but you must make some compile tweaks and it is not officially supported right now. (In other words - you're on your own!)

I should mention that none of this is officially supported by the Raspberry Pi Foundation as of yet - as is repeatedly said, "do this at your own risk" - the drivers for VC4 are still being perfected as of this writing. No one but you (not me, not the rest of the GZDoom team, not the Raspberry Pi foundation, not your distro's distributor, and not your seller) takes any responsibility, should anything go wrong if you follow these instructions.

To activate it - first, make a backup copy of your /boot/ folder and store it somewhere safe. This contains configuration settings as well as your current firmware.

Then, you must do the following (assuming you have a Debian variant - Raspbian has these tools pre-installed):

Code: Select all • Expand view

sudo apt-get install rpi-update raspi-config

Let the packages install, then run:

Code: Select all • Expand view

sudo rpi-update

This will update the firmware (and the kernel) that you are currently running, and will install new drivers.

You must reboot. Then you can run:

Code: Select all • Expand view

sudo raspi-config

This will allow you to configure hardware acceleration. Note that for now, I've only gotten "fake KMS" to work - use "full KMS" at your own risk!

You may be required to reconfigure your monitor or television's characteristics using "sudo nano /boot/config.txt" after doing these commands.

Be aware that running X11 with any acceleration at all is glitchy - but it is most definitely usable and errors are rarely fatal. (Most of the worst ones have been solved, even recently)

Note that 3.4.x will be the last mainline series that will run on the VideoCore4 chipset. More details will be coming in the future for alternatives that will be available.

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.