GZDoom 3.4.1 Released

[fakemai]

Ideally GZDoom's code is architecture-agnostic but if it moves to Vulkan-only it won't actually be used except on a few types of platforms, and very few will be 32-bit, which isn't necessarily true at the moment with OpenGL 3.3 as the baseline. Also I mostly linked the Dolphin article as an example of considered dropping of old hardware, and for the stat about mistaken 32-bit on 64-bit downloads which I believe to be the case with GZDoom as well. Otherwise, there's not so much making it hard to support, and the users downloading the wrong version probably aren't suffering too badly.

[Blzut3]

do you remember how long it took to make ZDoom work on it?

Not sure ZDoom is a great example? Maybe I'm just too young to remember an earlier effort but judging by rh-log, Randi made preliminary effort for a few months in 2006 to get ZDoom building on x64. Then nothing until I asked about it when I switched to 64-bit Linux on April 25th 2008. Had a fully functional 64-bit ZDoom by late May.

[Graf Zahl]

A few months sounds right. But now imagine typical game code - full of hacks to make things fast. That doesn't work that well if the size of some types changes.
So for a larger code base it may take some time until all kinks have been ironed out.

[Graf Zahl]

Ideally GZDoom's code is architecture-agnostic but if it moves to Vulkan-only it won't actually be used except on a few types of platforms, and very few will be 32-bit, which isn't necessarily true at the moment with OpenGL 3.3 as the baseline.

Uh, what?
Have you read the survey data I posted a few months ago?
And I can tell you, with the second survey things have gotten even clearer.

Right now the data says 80% of our users have a Vulkan compatible system and 10% mote that have a system that can run OpenGL at full specs. OpenGL 3.3 and less is roughly at 4%. Real 32 bit is also far below 10% and mostly concentrated at the low end of things.

These numbers for old versions are a lot lower than what we saw 4 months ago. In reality, OpenGL 3.3 is already a legacy platform, the only reason it is in no immediate danger of getting removed is that there are no critical features between GL 3.3 and GL 4.4 the engine depends on. The next evolutionary step is GL 4.5 and removing GL 3.3 support would also mean removing GL 4.4. support which would be more than a bit premature.

However, give it two more years and OpenGL support will only be needed to serve a very small minority, because those 20% who still run non-Vulkan compatible hardware (note that this is for GZDoom - the Steam survey paints even more dire numbers!) will get less and less over time and once their numbers becomes too small, OpenGL will simply fade into obscurity for modern software development - it'll remain as a legacy API for old professional software that is too complex to be rewritten, but for everything else I'd expect some Vulkan wrappers to appear that soften the API's roughness sufficiently to be workable by regular application programmers.

[fakemai]

I wasn't talking about that. I was simply making the point that even if GZDoom happens to build on exotic systems that aren't the typical x86/x86-64 or ARM, that it won't matter because that's about all you find Vulkan on, and in the case of x86 specifically, Vulkan support is likely to be marginal. I am definitely curious about how many will turn up in the current hardware survey.

[Graf Zahl]

You mean Vulkan on 32 bit systems? Very few, actually, considering how old these computers are. But some people still 32 bit Windows on 64 bit CPUs because for them running 16 bit stuff is more important than modern software. But those will inevitably have a rude awakening waiting for them in the future.

And regarding exotic systems: Those are not really important. What is important is to give those users who have a good system the best possible experience.

[Chris]

I think you are overgeneralizing from a few isolated occurences. Regarding 64 bit - do you remember how long it took to make ZDoom work on it?

I don't think I was really paying too much attention to ZDoom at that time. But as blzut3 says, basically a couple months of preliminary work in 2006, nothing for almost 2 years, then a month in 2008. Not bad for a single person being in charge of a large project that's worked on as a hobby. Sure a modern game code base will be bigger and messier, but it would also be handled by a team of paid engineers. If they're slower to deliver than a publisher deems acceptable, they're out of a job; a volunteer project leader doesn't have that hanging over their head to force results.

It's often not easy to transition older existing code bases to the new architecture. That all takes some time and especially in the early years of 64 bit systems there wasn't much to be gained from making 64 bit software because a) 32 bit was still a significant chunk of the market and b) it also ran without problems on all 64 bit systems. So obviously the transition was made gradually.

Was it made gradually? That's been kind of my point... for developers that had a strong console market (most of them), it wasn't gradual at all. They kept releasing 32-bit-only on PC even when they were doing preparation work to be 64-bit-ready with the next consoles, then when the new consoles released their PC releases became 64-bit-only and 32-bit was dropped like a hot potato. There wasn't a period where they released both 32-bit and 64-bit on PC and gradually moved over to 64-bit-only (only developers with a PC focus did that, like Epic and id).

One other thing to note is that when a new console generation launches, many publishers continue supporting the old generation console for a while in addition to the new one as the install base builds up (at least for certain titles, like the yearly flagship shooter or sportsball game). Yet for the PC versions, only the new generation/64-bit version of games got brought over once those consoles released; they didn't bother also bringing the 32-bit version over because the number of 32-bit gaming PCs was already that low when they started releasing 64-bit versions. So is it really the case that PC gaming went from "not worth making a 64-bit version at all, even as a future-proof option, because 32-bit was too significant" to "not worth making a 32-bit version at all, even as a low-end option, because 64-bit is so dominant"? There was never a point where 32-bit was still somewhat significant while 64-bit could also be a benefit? Consider too that WoW initially released a 64-bit client in early 2012, mere months after Skyrim's 32-bit-only release. An MMO that focuses on low-end systems was getting a 64-bit client before a number of other "higher-end" PC games. And as of this month, WoW is discontinuing the 32-bit client; so about 6 years where they supported both 32-bit and 64-bit, which roughly fits the behavior of other PC-focused developers (albeit delayed due to being an MMO and focusing on low-end systems).

Of course it takes time to internally transition code bases to 64-bit. But my point is many developers/publishers waited on the 64-bit consoles before releasing 64-bit PC versions, rather than waiting for 64-bit gaming PCs to get a foothold.

But in the end it's hard to say what was the main driving force here because the bit-ness transition happened nearly simultaneously on both consoles and PCs.

I wouldn't say the transition happened nearly simultaneously, since PCs don't transition the same way consoles do. PCs change gradually, a smooth scale between low-end and high-end systems (while 32-bit didn't become insignificant then, 64-bit uptake starting with Windows Vista also wasn't insignificant). Consoles transition at set points; the current system stays relevant until the new one releases, then the now-old one is phased out for the now-current one to take over. It's a lot less smooth of a transition for console hardware, it's either the old hardware being actively phased out or the new/current hardware, no in-between (the XB1X and PS4Pro are abnormalities in this regard; it's the first time where the consoles saw a notable update while requiring continued support of the older systems).

Sorry, but here I disagree. Having developed an OpenGL based engine myself I experienced first hand how bad some of these drivers were - and how bad the OpenGL specs were. People were using it where they had to but up until GL 4.2 it all was a major clusterfuck of bad decisions that held it back. And even after 4.2 it was economically safer to go the D3D route on Windows if you wanted proper support on Intel and AMD.

Fair enough. Still, it seems odd to me to not even play with the possibility of what you could get from OpenGL via an extension or two on top of what's already there for porting purposes. Even if D3D was the only official renderer on Windows, leaving OpenGL as an undocumented dev option for devs to play around with potential future hardware capabilities doesn't seem to be that big of a leap, given the code is largely platform agnostic. It would also help the quality of the ports by having another platform to test the OpenGL render code on (echoes of the reasons why Carmack liked writing portable code and tested on platforms they never officially supported).

[Graf Zahl]

So is it really the case that PC gaming went from "not worth making a 64-bit version at all, even as a future-proof option, because 32-bit was too significant" to "not worth making a 32-bit version at all, even as a low-end option, because 64-bit is so dominant"? There was never a point where 32-bit was still somewhat significant while 64-bit could also be a benefit?

See it this way: ZDoom never had an official 64 bit Windows release. And the last ZDoom version was released in 2016. The thing is, if the game needs to run in 32 bit anyway there is very little point going the extra mile to do a 64 bit version. So for most publishers it simply went like "32 bit as long as we get away with it". Doing both a 32 and 64 bit version requires more development and more testing time and that'd be a pointless expense unless you need both working anyway.

Fair enough. Still, it seems odd to me to not even play with the possibility of what you could get from OpenGL via an extension or two on top of what's already there for porting purposes. Even if D3D was the only official renderer on Windows, leaving OpenGL as an undocumented dev option for devs to play around with potential future hardware capabilities doesn't seem to be that big of a leap, given the code is largely platform agnostic. It would also help the quality of the ports by having another platform to test the OpenGL render code on (echoes of the reasons why Carmack liked writing portable code and tested on platforms they never officially supported).

Here again the money factor plays a major rule. What would the developers have gotten from developing an OpenGL Windows version? It probably would have cost more than it was worth.

[Chris]

The thing is, if the game needs to run in 32 bit anyway there is very little point going the extra mile to do a 64 bit version. So for most publishers it simply went like "32 bit as long as we get away with it". Doing both a 32 and 64 bit version requires more development and more testing time and that'd be a pointless expense unless you need both working anyway.

Which is my point. When most developers focused on the aging consoles, and their PC versions merely keeping parity with console releases, there was little incentive to utilize 64-bit (or D3D10/11) since the competition wasn't. That's in stark contrast to the late 90s and early 2000s where there was a veritable arms race in the PC space and developers tried utilizing the latest hardware to one-up other developers. In the mid-2000s that basically stopped. Blame OpenGL for really fumbling the 3.0 release, blame Vista for low sales. But ultimately, with the 360's generation developers stopped trying to out-do each other using the latest PC hardware even when it started gaining traction again (Vista really improved from its service packs I've been told, and Windows 7 saw quicker and broader adoption than Vista), and that continued until the now-current console generation started and more recent PC hardware was necessary to maintain console parity. Whether another hardware arms race will start, or if developers have settled into remaining in-step with consoles, is yet to really be seen, but I haven't seen any indication of the former.

What would the developers have gotten from developing an OpenGL Windows version? It probably would have cost more than it was worth.

They wouldn't need to develop an OpenGL Windows version. They'd develop an OpenGL renderer for ports that needed it, and build it on Windows too. The Windows-specific code to set up OpenGL would be very minimal, the wgl code to initialize the window's pixel format, and the vast majority of the renderer code would be platform-agnostic. Sure you may run into problems using it on Windows, but that could very easily indicate problems hiding on the other systems that would be better to catch now instead of being stung by it later. That's the benefit of having portable code.

[Graf Zahl]

I still say that it's not just the consoles. The main problem after D3D9 was that D3D versions became coupled with Windows versions. You cannot release a D3D10 game when most users still have Winodws XP and it took several years until Win 7 became widespread enough that it could be targeted.

As for arms races, I don't think they will happen for other reasons: Right now all the added rendering power will be needed to do 4K rendering so that will easily cost an entire generation of graphics hardware.

[quote}

They wouldn't need to develop an OpenGL Windows version. They'd develop an OpenGL renderer for ports that needed it, and build it on Windows too. The Windows-specific code to set up OpenGL would be very minimal, the wgl code to initialize the window's pixel format, and the vast majority of the renderer code would be platform-agnostic. Sure you may run into problems using it on Windows, but that could very easily indicate problems hiding on the other systems that would be better to catch now instead of being stung by it later. That's the benefit of having portable code.

Not if there's no target audience. Remember: This only constitutes 10% of the market and only idealists would be willing to do the added expense. Mac has been a shitty gaming platform forever because Apple has always been late with new developments (and they never updated OpenGL to its first good version with modern rendering support, which was 4.3) and Linux is not quite the shining light of robust drivers either.

[Cacodemon345]

You mean Vulkan on 32 bit systems? Very few, actually, considering how old these computers are. But some people still 32 bit Windows on 64 bit CPUs because for them running 16 bit stuff is more important than modern software. But those will inevitably have a rude awakening waiting for them in the future.

What kind of rude awakening though?

[Graf Zahl]

Stuff stopping working? As 32 bit OSs fade into oblivion, less and less developers will care about 32 bit support.