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.
Blog
Introducing the Staging Branch
- Posted by on 27 September 2023 at 15:58
- 0 Comments
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.
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.
Naming the textures for the Build games
- Posted by on 1 January 2023 at 17:38
- 6 Comments
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.
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.
GZDoom 4.9.0 survey - the final rundown
- Posted by on 18 December 2022 at 09:50
- 36 Comments
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.
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.
Feedback desired for PR #1854 to improve mouse handling while playing mods that adjust angles
- Posted by on 2 December 2022 at 09:47
- 1 Comment
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!
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!
First results from the 4.9.0 survey
- Posted by on 9 November 2022 at 07:22
- 28 Comments
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.
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.
Note: rebase of master
- Posted by on 14 October 2022 at 05:14
- 1 Comment
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.
Raze Floating point version - help needed
- Posted by on 6 October 2022 at 17:54
- 4 Comments
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.
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.
Upcoming forced reset of masrter branch on Raze
- Posted by on 25 August 2022 at 20:22
- 8 Comments
I will do a force push on Raze's master to eliminate a serious issue with the recent work on the data types. This sits far too deep to remove by other means.
If you work with the repo, please be aware of the necessary steps to adjust your local repo.
If you work with the repo, please be aware of the necessary steps to adjust your local repo.
The [imgur] tag
- Posted by on 10 August 2022 at 07:44
- 1 Comment
I hope by now you've noticed that the forums have changed a little bit. You didn't? How'd you manage that?
Anyway - one of the things that had to be changed in the update was the flexibility of the [imgur] tag. In the older version of the forum software it was possible to allow you to optionally specify https://[i.]imgur.com/<whatever> - where you can add the [i.], or don't.
Well the focus of the imgur tag's functionality has always been the "Copy" button that floats over the image. It does not produce the "i." part in its link.
The forum update has forced me to choose one or the other, it no longer allows me to support both. Since the copy button does not produce the "i." that means I went without.
Every post has been run through a reparser so some old imgur links will no longer work. If you suspect that the author of that post has not been around and won't be active anytime soon, simply report the post and ask a moderator to fix it. If you see any admin/mod's post that needs updating, feel free to use report for that too.
But if a user is active, please have them update the post themselves. We'd prefer not to touch their post if they can do it themselves.
Anyway - one of the things that had to be changed in the update was the flexibility of the [imgur] tag. In the older version of the forum software it was possible to allow you to optionally specify https://[i.]imgur.com/<whatever> - where you can add the [i.], or don't.
Well the focus of the imgur tag's functionality has always been the "Copy" button that floats over the image. It does not produce the "i." part in its link.
The forum update has forced me to choose one or the other, it no longer allows me to support both. Since the copy button does not produce the "i." that means I went without.
Every post has been run through a reparser so some old imgur links will no longer work. If you suspect that the author of that post has not been around and won't be active anytime soon, simply report the post and ask a moderator to fix it. If you see any admin/mod's post that needs updating, feel free to use report for that too.
But if a user is active, please have them update the post themselves. We'd prefer not to touch their post if they can do it themselves.
