Blog

I just made a final change to the newly added ZScript sound API for unlimited sound channels:

A_StartSound had two boolean parameters that are now folded into the flag word.
- the looping flag is identical with passing 'CHANF_LOOP|CHANF_NOSTOP', so now these two flags need to be set instead. There's a convenience definition of CHANF_LOOPING that does this with one value
- the local flag must now be specifed as CHANF_LOCAL.

As a result of this change, all code from the last two weeks that used A_StartSound needs to be reviewed! If optional parameters are omitted this is very likely to produce incorrect results without a compiler error!
In addition, all internal code still using A_PlaySound has been converted to A_StartSound and A_PlaySound officially been deprecated.

To verify the extent of how some engine features have been used by mods I need to get hold on all projects currently featured in the Projects section of the forum.
There's just one huge problem here: It's over 5000 threads that need checking, I simply cannot do this alone.

So I just set up a private cloud storage where these things can be uploaded. If someone is interested in helping me out, here's the procedure:

1) get the login info for the cloud storage I set up, I'll send them via PM to interested persons.
2) Once set up ask for a range of threads to check. To make things manageable, ranges are thread titles in alphabetic order, you can arrange the forum display for that by going to the bottom of the page, select "Sort by", set it to "Subject" and "Ascending". I will generally hand out ranges by the first letter, e.g. "Get everything starting with 'H" from the "Levels" forum.
3) Download everything that has actual content and is not hosted on /idgames. Since I can batch download from /idgames without issues I do not need anything hosted there.
4) Upload to the cloud storage I provide.

I think if I can get help from maybe 10 people we can handle all those 5000 threads in a few days, I already started with the levels forum and will continue on it.

The main reason for this undertaking is that I really would like to fix the texture scaling feature, but have no good numbers of how many mods depend on ZDoom's old per-texel-panning feature that needs to be disabled for the feature to be fixed. The content on /idgames depending on it is virtually non-existent and could be handled with compatibility patches but many high profile mods are not present there.

Also, if someone knows of mods on ModDB that may need checking, those are of course also appreciated.

Status (green done, yellow claimed, red, to do):

Levels: complete
Gameplay mods: 0ABCDEFGHIJKLMNOPQRSTUVWXYZ
TCs etc.: 0ABCDEFGHIJKLMNOPQRSTUVWXYZ
Resources: 0ABCDEFGHIJKLMNOPQRSTUVWXYZ
Graphics/Audio patches: 0ABCDEFGHIJKLMNOPQRSTUVWXYZ (only graphics patches needed!)

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 and 1 flag to Actor. Expands A_SetAngle/Pitch/Roll with a new flag.

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 flag is +ABSVIEWANGLES for actors, which makes the camera treat view angles as an absolute instead of an offset.

A_SetAngle/Pitch/Roll's new flag is SPF_VIEW. Including this will modify the view property instead of the actual angle/pitch/roll that it's modifying.

So if you want to modify the offset itself, you just do this:

Code: Select all • Expand view

A_SetPitch(viewpitch - 2, SPF_VIEW)

-----
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.