Blog

This has been coming up in Discord a lot and probably should be addressed here, too.



Versions prior to 4.14.0 had a backward compatibility for older ZScript versions that became problematic later on. In particular, type checking was not fully enforced when accessing one type as another.



This technically was patched but the patch was version-gated. Unfortunately more people were starting to discover ways that this could be exploited, and it eventually led to a vulnerability proof of concept being developed.



This created a conflict between two guiding goals of the source port: Maintaining backward compatibility, and keeping GZDoom in a state that would make most people feel like it is generally safe to use (i.e. vulnerabilities like this patched out).



In general, most people do not want to get their computers infected with malware just by downloading and installing a mod for a game, and there is often the expectation that mods cannot do that (or, you at least generally assume that it's too difficult to exploit for it to be worthwhile). GZDoom's community is vast, and while we have not directly seen malware being distributed in the form of GZDoom mods, there have been increasing concerns over this being a potential attack vector, and it likely would set a bad precedent to wait until one appeared, so it was decided that it had to be patched out.



So - some mods broke with the 4.14.0 update, unfortunately, and that was something we could not avoid. The goal of keeping GZDoom safe won out over maintaining backwards compatibility. While this doesn't prevent potential issues if a mod includes its own executable files, running them is ultimately your choice. If you double-click that .exe, you already understand that the GZDoom developers have no control over what happens next.



It goes without saying - update your GZDoom!

Since the project is no longer maintained by its original author, eventually GZDoom's IWAD detection for it will be removed.



If you maintain a fork for wadsmoosh please output it as "your_fork.ipk3" (not .pk3) and add a custom iwadinfo.txt file to its output. You can use some variant of the following:




Feel free to change the above settings and give it your own flair. You can probably even add a custom startup screen and music if you're feeling creative.

We now have 2000 survey reports so it is time for a first summary.



Here's the most interesting numbers:



25.4% use a Geforce RTX card

20.9% use a Geforce GTX960 or better

5.6% use an AMD Radeon RX high end card



8.1% use an Intel UHD with Vulkan compatibility, a further 6-7% use other low end hardware

7.6% use hardware that requires OpenGL and has no Vulkan support, of this 0.4% are performant enough to run the full GL backend



2.5% use Macs, 2.2% on ARM, 0.3% on x64. (The Mac version was the last one released so this will probably increase.)

12% use Linux

1.5% use the Steam Deck





The trend that has shown in the last two surveys has continued. OpenGL usage in general has shrunk but not much - but what did happen is that the high end of OpenGL has nearly been entirely vacated (the numbers are so small that a single report results in wild fluctuations), what is left here is ultra low performance integrated chipsets. At the same time, uptake for high end graphics hardware has stopped. We can see that within the segment the specs increase (RTX went from 20% to 25%, this was the only segment with actual growth but it all came at the cost of the high end GTX segment) but we see virtually no migration from the mid range to here. On the other hand we see the oldest still supported GPUs slowly decline but they seem to be replaced with equally weak ones only two or three years more recent.



The only conclusion that can be drawn by now is that we got two mutually exclusive groups at both ends - those with good computers will continuously upgrade them and those with low spec systems will tend to ride them out until they break and then get another low end system again, so I do not see the market shift in any meaningful way for the foreseeable future. What Intel puts into their low end CPUs is still pathetic.



The only thing I can say with certainty is that the current market situation makes it impossible to let OpenGL continue to dictate the engine's roadmap. With all the work being done on vkDoom a split is inevitable, so that the modern Vulkan backend can continue unencumbered and the remaining OpenGL hardware can be serviced by a legacy fork only receiving the game-side changes but have the render backend feature frozen, also using GLES as default.

Hello everyone!



We have recently changed our merge policy on pull requests in order to hopefully help them move a little quicker through our testing process. Untested PR's may sometimes get into the master branch and we may be testing unstable code here, too.



If you are using GZDoom as an upstream, it is strongly encouraged to use the "staging" branch, instead. This branch is where releases will be built from, and isn't updated as often as the master branch; rather, it is sync'd when we have some confidence with what is in the master branch and feel it is safe to put into an official release at some point.



This is mainly to allow us to move pull requests faster.



Please don't forget though, that as a team we are only few, and we cannot get to absolutely every pull request as quick as we'd like. This is because even if we do start merging more of them, they still do ultimately need to be tested over the course of a few days, and we can't do too many at once doing that. So hitting the repo with too many pull requests at once will still slow things down considerably; when making a submission please take into consideration how much do you really need it.

As part of our long term roadmap for Raze a new UDMF-like map format is part of the plan.

There's one problem with this, though: Build has no texture names - only numbers, which does not mix that well with UDMF.



So my idea was to ask the community to help out here and name these textures.



Here's the link https://docs.google.com/spreadsheets/d/ ... sp=sharing



The important thing here is that there is no need to name all the sprite rotations which make up the bulk of the texture set. What we need is proper names for those textures that can be put on walls, floors, ceilings and deorative sprites.



If anybody is willing to help, just ask for access to the linked spreadsheet. It currently has lists set up for Duke Nukem 3D, Redneck Rampage and Redneck Rampage Rides Again.

The lists for RR and RRRA are currently identical but need cleanup because everything is mixed together, many textures only have generic names and no consideration is made for places where they differ. The other games will be set up later, but for them the available lists are a lot less complete so more work is needed.



What we need is the following info:



A suggested name if the texture contains something useful. If you want to suggest a better name than the existing one, feel free to do so.

A note that it is empty, if not defined.

A note that it is part of a sprite animation, if so, but no name.

Now that the survey is closed and I had time to crunch the available numbers, here's some more detailed results than usual.



The following breakdown was made with 15400 reports overall:



First the hardware breakdown:



43.3% are using an NVidia high end card, meaning a Geforce GTX 970 or better.

7.2% use a comparable AMD card

2.8% use an oder generation high end NVidia card, meaning Geforce GTX 670 or better

1.8% use an Apple M1/M2

------------------------------

55.1% use modern hardware with good or excellent performance.



8.7% use mid range hardware that may not have sufficient performance for using postprocessing effects

27.5% use low end hardware that nomially supports Vulkan - these are mostly older laptops.

------------------------------



8.7% uses non-Vulkan capable hardware - this was roughly at 10% most of the time during my initial reports but i made a mistake there and erroneously excluded some entry level Geforces from Vulkan that actually do support it. With this being corrected, non-Vulkan capable hardware dropped significantly below 10%.



Now the operation system breakdown:



82.1% use Windows 10 or Windows 11

3.8% use Windows 7 or Windows 8.

4 users (not percent!) used Windows on ARM, one of thse in a VM on a Mac.



1.6% use a Mac with Intel CPU

1.8% use a Mac with ARM CPU



10.5% use Linux





So, what does this all mean?

First, we have seen a very steep drop in use of non-Vulkan capable hardware. This was around 15% last year, so this segment shed roughly 40% of its user base - but the interesting thing here that it is mostly the higher end, i.e. Geforce GTX 550 and up, that are responsible for the drop. This segment of the user base has virtually evaporated by now, leaving mostly Intel powered systems. NVidia now stands at less than 10% of non-Vulkan capable hardware, and only half of this features some decent performance.



With this and the performance characteristics of the remaining hardware considered the future of OpenGL support needs some serious reconsideration.95% of this hardware is better served by the GLES backend with its low end specific optimizations.

This situation will be addressed by reworking the startup code to prefer GLES and Vulkan and demote the full GL backend to a fallback option, so that it can still be used in case one of the others does not work. In general, though, it should be clear that OpenGL's days are numbered.



More importantly, though, the situation on macOS now is that the Intel segment is shrinking while the ARM segment is disproportionately growing. On M1, however, OpenGL is close to useless - and performance tests on Intel based Macs generally show that Vulkan/MoltenVK tends to have roughly the same performance as OpenGL. Furthermore, the number of Mac users on non-Metal capable hardware is so low (low double digits, less than 0.1% of the total user base) that this does not warrant keeping support alive. As such, the next GZDoom release will drop OpenGL support on macOS and from now on only provide the Vulkan/MoltenVK backend using the native Metal API.



Windows 7 is also dropping rapidly. This has no immediate consequences, but expect regressions to occur in cases where we have to consider better support on modern OSs that do not filter back well.

Hi Everyone,



I'm Mitch, one of the Raze developers. There's an old bug reported here whereby if a mod adjusts the player's angles in any way, it forces interpolation for the player for one tic. For those sensitive to input lag, this basically forces the mouse input to 30Hz which can be noticable.



I've attempted to address this in PR #1854 in a similar way to how we address this in Raze, but because GZDoom is used far greater than Raze, I can't test every mod and every scenario.



It'd be great if people could test this with their favourite mods, with multiplayer games etc and ensure that this causes no changes or breaks that require attention. The fix is only applied for single player games as you simply cannot do this kind of stuff for multiplayer or demos.



If there's any problems, please let me know here, and please be kind as I don't know GZDoom as well as I know Raze so it's a best effort attempt to submit a fix for a engine I'm less familiar with.



Thanks!

We now have 1000 survey reports so I think it is time for a first summary.



Here's the most interesting numbers, in parentheses the numbers from 4.7.0 with roughly 1300 users:



90% (85%) use Vulkan compatible hardware. This can be further divided into 65% on modern upper mid range to high end hardware and 25% low end to mid range.

4% (5.6%) use hardware which can run OpenGL with all features enabled but cannot run Vulkan. Note that this only considers theoretical support. Only 0.5% have hardware that is actually capable performance wise.

6% (9.1%) use legacy hardware which requires fallback solutions in the renderer and only has limited support for some features.





85% (75%) use a system with 4 CPU cores and more - among the Vulkan compatible systems this is 90% (82 %).



Currently Linux sits at 19%, macOS at 3.6%. The numbers were even higher before the download page was updated, so I expect them to shrink further. Over half of the reported Macs are ARM models already.



The numbers here are a bit weird in the low end segment. The lower mid range which includes all high end hardware of the last pre-Vulkan generation of hardware virtually imploded - the mentioned 0.5% is a mere 5 users reporting such hardware. 4 of these 5 users were early reporters so in the last two days only one single person reported such a system. Oddly enough the extreme low end has seen virtually no decline at all - the drop in OpenGL-only hardware almost exclusively came from the better hardware of this segment being on decline.

The same could also be witnessed at the lower end of Vulkan hardware. The vast majority of users these days uses a Geforce 960 or better (including AMD equivalents.)

So the trend that was already observable with 4.7 has continued with the user base getting ever more divided into two very distinct groups whose hardware has little to nothing in common.



User share of Windows 7/8 has dropped to 4.5% (18%), roughly 50/50 between owners of Vulkan compatible hardware and older setups.



I concluded the 4.7 survey with the following statement:

"Interestingly, the situation with CPU cores has not changed much at the low end. At the high end we are starting to see that many systems now come with 8 or even 16 cores, but the low end is virtually unchanged. So essentially we have the same situation as with graphics hardware - a large, fast moving group that frequently updates their systems and a slowly declining group of holdouts with old systems.

All this combined looks like there is a certain group of users which desperately holds on to their extremely outdated systems while everybody around them is updating their computers.

If this trend continues we may soon have a situation where the overwhelming majority of users has a system supporting modern render APIs but the remaining part of the user base cannot even use the OpenGL renderer with all features enabled. I am not sure yet how such a situation may play out - hopefully it gets mitigated by Windows 11 forcing a lot of users to upgrade and flood the second hand market with their Windows-11-incompatible systems, which then in return may drive out more of the truly ancient ones."



So here we are, one year later. I was actually hoping that Windows 11 and the drop in graphics hardware prices would bring some change - but apparently it did not. What we see instead is an increasing vacation of the middle ground while the size of the lowest end has only marginally declined over the last 3 years. This is actually becoming a serious problem by now because the need to support this segment is impeding the future development of the engine for modern hardware as most of our users own. We need two totally incompatible graphics APIs and two totally incompatible ways to use the APIs to serve both sides well - essentially meaning we need two different engines. Yes, there will be changes, we are currently evaluating our options.

A few days ago I had to temporarily revert a PR in master. Now that this got addressed I decided to eliminate the revert commit and do a force push to allow proper attribution of the changes later. The branch was reset by one single commit that had been present for a few days only. Please make sure that your next pull gets applied properly.

Over the last two months we have been refactoring Raze to work with floating point numbers internally instead of fixed point.

We are now at the stage where we can do the first round of public tests.



Here's the first test version:

https://drive.google.com/file/d/19PkWZc ... sp=sharing



What we primarily need is people to test the engine for bugs. As this was a substantial rewrite there will most certainly be bugs in here, so do not use this version for normal play, it's not ready for that yet.

If you encounter a bug, please report it here at the forum - we do not want to fill the Github bug tracker with all this noise from a public test.



If you want to do more and have some experience with C++ and git, there's another way in which you can help:

For most of these bugs we need to find the commit where the bug originates so that we can inject the fix in place. The normal method to do this is to bisect the work branch until we find the relevant commit. As this can be a very time consuming task, we could really use some help here - we do not expect anyone to actually analyze and fix the code - it's fully sufficient to find the commit and post its commit message. Please do not post the commit hash, as this branch will frequently be rebased which invalidates the hash.