Blog

First results from the 4.11.0 survey
Posted by Graf Zahl on 30 September 2023 at 17:16
65 Comments

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 recent trend, as evidenced by the last two surveys, persists. While there is a marginal contraction in overall OpenGL usage, the notable shift is the near abandonment of the high end of OpenGL, leaving predominantly ultra-low-performance integrated chipsets in this space. Concurrently, the adoption of high-end graphics hardware has plateaued. Although there is a discernible increase in specifications within this segment (e.g., RTX rising from 20% to 25%), it comes at the expense of the high-end GTX segment, with minimal migration observed from the mid-range.

Conversely, the oldest still-supported GPUs exhibit a gradual decline, being replaced by relatively modest upgrades only two or three years more recent.

At present, it appears that there are two distinct and mutually exclusive user groups at both ends of the spectrum: those with robust computer systems consistently opt for upgrades, while users with low-spec systems tend to persevere until a breakdown prompts the acquisition of another low-end system. Consequently, a significant market shift seems unlikely in the foreseeable future. Notably, the performance of Intel’s low-end CPUs remains unsatisfactory.

It is evident that the prevailing market dynamics necessitate a departure from allowing OpenGL to dictate the engine’s roadmap. Given the ongoing advancements in vkDoom, a division becomes inevitable. This entails the seamless progression of the modern Vulkan backend, free from constraints, while concurrently managing the remaining OpenGL hardware through a legacy fork. The latter will solely receive game-side updates, with the render backend features frozen, and default to using GLES.

Introducing the Staging Branch

Posted by Rachael on 27 September 2023 at 15:58
0 Comments

Greetings, everyone!

We’ve recently implemented a revised merge policy for pull requests to expedite their progress through our testing pipeline. It’s worth noting that untested pull requests may occasionally find their way into the master branch, potentially introducing unstable code into our testing environment.

For those utilizing GZDoom as an upstream, we strongly recommend switching to the “staging” branch. This branch serves as the basis for releases and experiences less frequent updates compared to the master branch. We synchronize it when we have confidence in the stability of the master branch and consider it safe for inclusion in an official release.

The primary objective of this adjustment is to facilitate a quicker turnaround for pull requests.

However, it’s crucial to keep in mind that our team is relatively small, and despite our efforts to expedite the merging process, we may not be able to address every pull request as promptly as desired. Testing each submission takes time, typically spanning a few days, and managing an influx of pull requests simultaneously can considerably impede our progress. Therefore, when submitting a pull request, please consider its urgency and the impact of its inclusion on our workflow. Your understanding and cooperation are greatly appreciated.

Naming the textures for the Build games

Posted by Graf Zahl on 1 January 2023 at 17:38
7 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.

GZDoom 4.9.0 survey – the final rundown

Posted by Graf Zahl 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

In summary, several significant developments have prompted a reassessment of our approach:

Decline in Non-Vulkan Capable Hardware Usage: We’ve witnessed a substantial decrease, approximately 40%, in the use of non-Vulkan capable hardware, particularly among higher-end devices like Geforce GTX 550 and above. Notably, NVidia’s share in this category has dropped to less than 10%, with only half exhibiting satisfactory performance. Given these shifts, the future of OpenGL support requires serious reconsideration. Approximately 95% of this hardware is better suited for the GLES backend, featuring optimizations tailored for low-end systems. Consequently, upcoming changes will prioritize GLES and Vulkan in the startup code, with the full GL backend relegated to a fallback option.
Evolution of macOS Landscape: On macOS, the Intel segment is diminishing, while the ARM segment, particularly on M1, is experiencing disproportionate growth. However, OpenGL performance on M1 is deemed nearly useless. Performance tests on Intel-based Macs indicate that Vulkan/MoltenVK achieves comparable performance to OpenGL. Considering the dwindling number of Mac users on non-Metal capable hardware (less than 0.1% of the total user base), the next GZDoom release will discontinue OpenGL support on macOS. Instead, it will exclusively provide the Vulkan/MoltenVK backend utilizing the native Metal API.
Windows 7 Decline: While Windows 7 is undergoing rapid decline, it currently has no immediate consequences. However, users should anticipate potential regressions in situations where optimizations are required for modern operating systems that do not seamlessly support legacy configurations.

These strategic adjustments aim to align our support with the evolving hardware and software landscape, ensuring optimal performance and compatibility for the majority of our user base.

Feedback desired for PR #1854 to improve mouse handling while playing mods that adjust angles

Posted by mjr4077au on 2 December 2022 at 09:47
1 Comment

Hello Everyone,

I’m Mitch, one of the Raze developers. I’d like to bring your attention to an old bug that has been reported, concerning a situation where, if a mod adjusts the player’s angles, it triggers interpolation for the player for one tic. This issue introduces a noticeable input lag, effectively limiting mouse input to 30Hz, which may impact those sensitive to input responsiveness.

In an effort to address this, I’ve submitted a pull request (#1854) employing a solution similar to what we’ve successfully implemented in Raze. However, given the widespread use of GZDoom compared to Raze, I’m unable to test every mod and scenario.

I kindly request the community’s assistance in testing this fix with your favorite mods and multiplayer games to ensure it introduces no unintended changes or issues that require attention. It’s essential to note that this fix is exclusively applied to single-player games, as implementing such changes for multiplayer or demos is impractical.

Should you encounter any problems, please provide feedback here. I appreciate your understanding, and please bear in mind that my familiarity with GZDoom is not as extensive as with Raze, so this fix represents a best-effort attempt to contribute to an engine I’m less acquainted with.

Thank you!

First results from the 4.9.0 survey

Posted by Graf Zahl 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.

Note: rebase of master

Posted by Graf Zahl on 14 October 2022 at 05:14
1 Comment

Certainly, I understand the importance of ensuring proper attribution for changes. It seems you had to temporarily revert a pull request in the master branch, and now that the issue has been addressed, you’ve decided to eliminate the revert commit and perform a force push. The branch has been reset by a single commit that was present for only a few days.

I’ll make sure that the next pull request is applied properly to preserve the correct history and attribution for the changes. If there are any specific instructions or considerations you’d like me to keep in mind during the pull, please let me know.

Raze Floating point version – help needed

Posted by Graf Zahl on 6 October 2022 at 17:54
4 Comments

Greetings Community,

Over the past two months, we’ve undergone a substantial refactoring of Raze, transitioning to utilize floating-point numbers internally instead of fixed point. We’ve now reached a stage where we’re ready to initiate the first round of public tests.

Our primary request is for individuals to actively test the engine for bugs. Given the scale of this rewrite, it’s highly likely that bugs may surface. Therefore, we advise against using this version for regular gameplay, as it’s not yet deemed ready for that purpose.

Should you encounter any bugs during testing, we kindly ask that you report them on the forum. To maintain clarity in our Github bug tracker, we prefer to avoid inundating it with the noise generated during a public test.

For those with experience in C++ and git, there’s an additional opportunity to contribute:

Many of the reported bugs will necessitate identifying the commit where the issue originated to implement a fix. The standard procedure involves bisecting the work branch until the relevant commit is pinpointed. Recognizing that this can be a time-consuming task, we would greatly appreciate any assistance. It’s important to note that we don’t expect individuals to delve into code analysis and fixes; simply finding the commit and posting its commit message would be immensely beneficial. We kindly request that you refrain from posting the commit hash, as this branch will undergo frequent rebasing, rendering the hash invalid.

Your participation, whether through testing or assisting with bug identification, is crucial at this stage. We look forward to collectively enhancing the stability and performance of Raze. Thank you for your valuable support!

Upcoming forced reset of masrter branch on Raze

Posted by Graf Zahl 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 rep

The [imgur] tag

Posted by Rachael on 10 August 2022 at 07:44
1 Comment

Greetings,

I hope you’ve had a chance to notice the recent changes to the forums. If not, well, that’s a mystery in itself!

One notable adjustment relates to the flexibility of the [imgur] tag. In the previous version of the forum software, users could optionally specify links with or without “https://i.” for imgur images. However, due to the forum update, I had to make a choice between the two options. The focus of the imgur tag’s functionality has always been the “Copy” button that floats over the image, and it does not produce the “i.” part in its link.

Consequently, every post has undergone a reparser, which means some old imgur links may no longer work. If you come across such links and suspect that the post author may not be active or won’t be returning soon, please report the post and ask a moderator to address it. The same goes for any admin/moderator posts that require updating.

However, if a user is active, we encourage them to update their posts themselves. We prefer not to modify posts if the user is available to make the necessary adjustments.

Thank you for your understanding and cooperation during this transition. If you have any further questions or concerns, feel free to reach out.