Blog

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
https://docs.google.com/spreadsheets/d/ ... sp=sharing

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.

I already posted a few numbers on the news thread, but I am certain that some people may be very interested about the results.
We now hit the number of 900 distinct users reporting, so here's a quick rundown of the interesting stuff:

6 users reported using Windows XP - that's actually a lot lower than we would have expected!

85 users have reported data for the software renderer.
870 users have reported data for the hardware renderer.

13 users run the software renderer on a 32 bit system.
14 users run the software renderer with the 32 bit EXE on a 64 bit system (An important note to these: The 64 bit software renderer is considerably faster on your system!)

39 users run the hardware renderer on a 32 bit system.
98 users run the hardware renderer with the 32 bit EXE on a 64 bit system (If you do so, we'd appreciate some feedback. If there is a performance issue, please update the graphics driver.)

49 users run the hardware renderer in legacy (OpenGL 2.0) mode
287 users run the hardware renderer on OpenGL 3.x and 4.x capable hardware
534 users run the hardware renderer on Vulkan capable hardware. (The number may be higher, because there is no easy way to detect Vulkan support on Intel graphics, it can only be done quickly on NVidia and AMD.)

3 users run the software renderer without the hardware accelerated 2D elements
0 users run the software renderer on ancient cards which only support Shader Model 1.4

Needless to say, the biggest surprise here is that the vast majority of 32 bit downloads is actually being used on 64 bit systems. Anyone doing this should really reconsider, and if there's legitimate performance issues, try to solve them. The 64 bit version should run significantly better on such a system, if that system is properly working.

I am making this post to point to some potential breaking changes I had to make in order to fix this feature.

Recently I decided to fix the mess that is 'RenderStyle "Shaded"' (a.k.a. alpha textures)
For those who do not know, this is the style which gets used for blood and scorch mark decals.

A long standing problem with this style has been its poor and inconsistent implementation. Depending on what type of texture was passed and what renderer was active it either worked or did not - in an entirely unintuitive manner. The original software renderer's implementation never went beyond the barest necessities to make shaded decals work, and this never got changed when the feature was extended to a true render style.

The OpenGL hardware renderer has always been able to handle this properly for grayscale textures and produced ok results for other non-paletted textures. It was merely ok for those, because for true color textures the red channel was mapped to alpha, which not only is not the brightest one (that'd be green) and it'd produce bad results for anything with low red content.
The same hasn't been true for the software renderer. This style only worked there correctly when using either IMGZ or grayscale PNGs that got tagged with a custom 'alPh' chunk.
It got even worse with paletted formats like Doom patches. In this case it completely ignored the colors and treated the image's content as a grayscale ramp, but did not consider that the texture manager remaps color 0 to reserve that index for transparency.

Needless to say, with something this inconsistent and seemingly broken by design, the feature was basically reduced to its original use case, i.e. shaded decals and crosshairs and never got beyond that.

I always stayed away from fixing this because I knew that a) it would be a lot of work and b) might have an impact on older mods that depend on the broken semantics here.
Fixing this to behave in a sane fashion would inevitably break any old mod that uses a Doom patch for a decal, unless some countermeasures were implemented.

I finally did some checks of available mods to see what I am up against by checking the entire /idgames content for use of undefined side effects of the old implementation.
The result of this was: roughly 140 patch textures were used for decals over the years, the most recent ones dating back to 2011 and two IMGZ textures that use this format for a color texture.
The most important affected mod is Beautiful Doom whose decals got reused by several other mods, making proper treatment for these a necessity.
The major part of the rest of these 140 textures comes from two mods (njol.wad, njbgpabh.pk3) which merely reused some old, already existing data. Aside from these three mods and the reused Beautiful Doom content, there were only 5-10 affected graphics.

With this amount it was doable to implement a checklist for the affected textures and then fix all those design problems here, which is what I did over the last week.
With the rewritten code, render style "shaded" will now always mean 'take the grayscale value of each pixel and use it as alpha with the current stencil/fill color'.

This implies some important changes to how textures behave:
1) IMGZ will from now on be treated as a grayscale-only format and be considered deprecated. Please discontinue using this format if you still use this for anything else but decals and crosshairs!
2) Doom patches will always be treated as a paletted image, even when being used as an alpha texture. This means that any mod still using such patches (aside from the known ones from Beautiful Doom) will display broken shaded decals! Again, please discontinue using patches for shaded decals, if you still do this.
3) It is no longer necessary to tag alpha PNGs with an 'alPh' chunk. In fact, this will not be checked for anymore by the texture manager.
4) If an image works as alpha texture in one renderer it will now work in all. All those crosshairs from Project Brutality, for example, that were broken with OpenGL 2.0 will now be displayed correctly. So no more trouble with badly prepared graphics that depend on how the renderers implement the feature

So how to deal with this:

1) If you make decals, use a graphics format that gives you full control over the colors like PNG - although JPG may also be an alternative for larger decals now.
2) Known images that use a format incorrectly will be flagged through a list of MD5 hashes to switch from color to grayscale (for patches) or from grayscale to color (for IMGZ.)
3) If you find some old mods with broken decals, please make a bug report pointing to that file. They will be added to the internal exception list then.
4) Note that 3) only applies for released mods as of March 2018! To consider adding something to the exception list, there must be some public link to the file. We cannot and will not extend this list beyond what is needed for backwards compatibility. For WIP you will have to switch to PNGs.

While some people may cry foul over some old feature being altered in a way that might affect a few mods let's not forget one thing:
Due to the messy and inconsistent implementation I have found far, far more decals in /idgames that were plain and simply broken because modders did not properly adhere to the very specific limitations. So by removing those limitations it can be expected that in future mods there will be less bad definitions.

In the end the choice was to do the lesser of two evils. Either keep the feature broken and mostly useless forever or fix it and deal with some potential issues in a very small number of old mods. Most mods using decals were made long after PNG became the image format of choice for ZDoom modding and will not be affected. In fact, a few mods that did not use the feature properly may now even work better than before.