GZDoom 3.4.1 Released

[fakemai]

I think GZDoom still works on Windows XP which has a terrible 64-bit edition, so you'd need it there, but I'm betting that there's a lot of users downloading it erroneously (REDACTED, it was the other way around, vintage only comes in 32-bit, modern is both 32-bit and 64-bit). This also bit the devs of the emulator Dolphin, where the costs of maintaining a 32-bit version were a lot higher, so they eventually dropped it.

[Graf Zahl]

@Rachael: Can you correct the image? It cuts off the last digit of the 64 bit download counter.
@Cacodemon345: Some people still are on 32 bit systems, but the question is valid because the 3.5. survey again shows that most 32 bit downloads get used on 64 bit systems. My guess is that this is users who run some 32 bit postprocessing plugin or something else that does not work with 64 bit software.
Well, I can guarantee that this won't be a deciding factor once the time comes to discontinue 32 bit. And I have no plans making Vulkan 32 bit compatible.

[Cacodemon345]

My guess is that there are FAR more 64-bit users?

[Graf Zahl]

This also bit the devs of the emulator Dolphin, where the costs of maintaining a 32-bit version were a lot higher, so they eventually dropped it.

Interesting article that highlights lots of the problems with legacy support. I think I write a blog about it because this should be required reading for all users of old hardware!
BTW, that article links to another one about D3D9, which roughly speaks the same language.

[Graf Zahl]

My guess is that there are FAR more 64-bit users?

Yes, here's the numbers from the last survey:

85% use 64 bit on a 64 bit system
10% use 32 bit on a 64 bit system. (This one's odd, I'd appreciate if some of these users can tell us why.)
6% use 32 bit on a 32 bit system
(duplicate reports bring this above 100%)

For the current one, it's a bit trickier, because we only have a 32 bit legacy build but there's a few users of 64 bit systems running such ancient graphics hardware. But the general trend of some users running 32 bit only on a 64 bit system is still evident.

And the long term roadmap should be clear: 32 bit and Windows XP along with it are on the chopping block. This will only be maintained as long as it doesn't cause any extra work and the percentage of real 32 bit systems remains significant enough. And I make absolutely no provisions on Vulkan to keep the code compatible with 32 bit.

[Gez]

I had a computer with Vista 32 on it several years ago and I would probably still be using it if it didn't die from spilled teacup. I think it's with Windows 7 that 64 bit really became mainstream. I believe upgrades made from within the system also kept the architecture? Now any new computer will have a 64-bit system so the proportion of 32-bit should steadily decrease.

Keep in mind that during the transition period, many people deliberately preferred 32 over 64 for compatibility reasons, many early Windows games had old Windows 16-bit installers and Windows 64 couldn't (and still cannot) run them. Nowadays this isn't a problem anymore (you can find these games repackaged on GOG.com) and most new games are now in 64-bit exclusively to be able to use more memory. You can take Skyrim as an example: original release in 2011 was 32-bit, 2016 rerelease is 64-bit. That tells you that seven years ago, 32-bit systems were still a large part of the mainstream gaming computers.

[Graf Zahl]

I believe upgrades made from within the system also kept the architecture?

Yes. This would have been the perfect opportunity for Microsoft to get 32 bit out of the market but they only offered to upgrade a 32 bit OS to the 32 bit version of Windows 10.

[Chris]

That tells you that seven years ago, 32-bit systems were still a large part of the mainstream gaming computers.

I wouldn't use that as a metric, since Skyrim was mainly targeted at old consoles (well, technically it was targeted at the new consoles, but ended up being kept back due to the XB360's generation still shambling on for a while yet), with the PC version purposely keeping parity and not taking advantage of gaming PCs, much to the ire of PC gamers (the original Skyrim release had quite low system requirements, the 64-bit budget-oriented system I bought around 2007/8 isn't far from the recommended specs; and this from a developer known for not well optimized games). It wasn't until the Special Edition was released that the game simultaneously got a 64-bit PC release at the same time as releases for the "next gen" consoles.

An interesting thing to note is that even though the original Skyrim is 32-bit, its minimum requirements was a dual-core 2ghz processor. As far as I've found, there was only one 32-bit dual-core processor, Intel's Core Duo (not the Core 2 Duo), which ran at 1.83ghz and was apparently a mobile-only processor. Google tells me AMD's Opteron was their first dual-core processor and was also 64-bit. So the game essentially required a 64-bit CPU for PC, despite being a 32-bit executable.

[Graf Zahl]

We should not forget that porting 32 bit code to 64 bit is not a problem-free transition. If they got 32 bit console code it made little sense to spend more time sanitizing it, when 32 bit was working fine. Besides, the limiting factor was not CPUs but Windows installations and back then 32 bit was still quite widespread.

[Rachael]

Wow, I really screwed the pooch on that one. Sorry everyone.

This is a better image, done correctly.

[Chris]

We should not forget that porting 32 bit code to 64 bit is not a problem-free transition. If they got 32 bit console code it made little sense to spend more time sanitizing it, when 32 bit was working fine. Besides, the limiting factor was not CPUs but Windows installations and back then 32 bit was still quite widespread.

Back then, they once mentioned they were considering waiting for the next gen consoles, but decided not to because they were still a ways away (this at a time when the 360 generation was already in a long-overdue decrepit state). More recently with the release of the Special Edition, they said much of the work had already been done with the original game and there wasn't that much more to do to finish it up and get it out. Putting 2 and 2 together, it's apparent they were all but ready to go for a next gen target, but didn't simply because the new consoles were delayed.

If you look at the trends, it's obvious many game developers follow the capabilities of consoles, not gaming PCs. For instance D3D11 was introduced with Windows 7, in late 2009 or so, but it wasn't until the XB1 was released in 2013 that almost everyone immediately started using it. Prior to that, most games were exclusively D3D9, even though D3D10 had been available since Vista in late 2006/early 2007 (so over 6 years without ever touching D3D10, but within 4 years they jump all over D3D11). To say nothing of OpenGL, which doesn't have OS-locked versions (there's nothing preventing use of D3D10 or D3D11 level capabilities on Windows XP). Even now, D3D12 is starting to see use despite being recently introduced with Win10, because console hardware is already capable of handling it (even the Switch can handle Vulkan, I believe).

Of course there are exceptions to developers focusing on consoles, but BGS is not among them. So using those games as a measuring stick for gaming PCs won't give an accurate perception.

[Graf Zahl]

I think you are completely missing the real reasons here.
Why not D3D10? Simple: XP did not support it! You need to have some critical mass of potential users to justify the work. And Vista did not go down particularly well, remember?
So yes, the game industry skipped that iteration because it would have been suicide.
Why was D3D11 only adopted after 4 years of Windows 7? Actually the same reason: They had to wait until the market share was high enough to justify the work. I guess if D3D11 has been backported to XP and Vista we'd have seen more titles earlier. And the same thing repeated nearly identically with D3D12. Again users of older Windows versions were left out, meaning that the gaming industry had little interest jumping onto the bandwagon right away. Now some serious uptake can finally be witnessed, again several years after its start. But it remains to be seen whether the studios choose D3D12 or Vulkan, or build upon a third party engine which probably supports both.

To sum it up: To support a new graphics hardware generation there first needs to be some market share of that new hardware and of operating systems supporting said hardware. It's a complete waste of money to write a modern rendering backend for something that has - let's say - 20% market share.
And once they finally decide to jump in there's a lot of lead time until the product is ready. You cannot expect some new API seeing some real use right after its release.

Regarding OpenGL, the reasons are different: For many, many years Intel's and AMD's drivers had serious issues - so serious that few dared to go that route.

[Chris]

I think you are completely missing the real reasons here.
Why not D3D10? Simple: XP did not support it! You need to have some critical mass of potential users to justify the work. And Vista did not go down particularly well, remember?
So yes, the game industry skipped that iteration because it would have been suicide.
Why was D3D11 only adopted after 4 years of Windows 7? Actually the same reason: They had to wait until the market share was high enough to justify the work. I guess if D3D11 has been backported to XP and Vista we'd have seen more titles earlier.

Convenient that D3D11 and 64-bit PCs hit high enough market share for everyone to latch on to right when the new consoles dropped.

I do very much believe if the new consoles had been released a year or two earlier, support would've picked up much quicker regardless of any changes to the PC gaming ecosystem. It's relevant to note that UT2004, released in early/mid 2004, came with both 32-bit and 64-bit executables on PC. Skyrim, released over 7 years later in late 2011, came as 32-bit only on PC despite the developer having done work internally to get it ready for the future 64-bit consoles (work that was only put on hold when they realized the new consoles were still a couple years out, not because PCs weren't ready). If my budget PC could handle a game released 3 years later, that game isn't targeting a gaming PC.

Sure, there's certainly an argument to be made about being exclusively 64-bit or exclusively D3D10/11 in the early years, but these games were exclusively 32-bit D3D9 for years. And now with the new consoles, they're exclusively 64-bit D3D11 (or D3D12 or Vulkan). Where was the transition period for PCs?

Regarding OpenGL, the reasons are different: For many, many years Intel's and AMD's drivers had serious issues - so serious that few dared to go that route.

They only had serious issues because few games actually used them. id Software staunchly supported OpenGL even through its darkest times and showed it can work if they work with the hardware vendors. Individual developers could be in contact with the hardware vendors to ensure their games work, and in doing so would've raised the general quality of the drivers. Further, any ports for OSX, iOS, Android, and Linux required OpenGL, and OpenGL was also available for PS3 while D3D was not. So really, unless you were exclusively XBox and/or Windows, you were likely supporting OpenGL in some fashion anyway.

[Blzut3]

And the long term roadmap should be clear: 32 bit and Windows XP along with it are on the chopping block. This will only be maintained as long as it doesn't cause any extra work and the percentage of real 32 bit systems remains significant enough. And I make absolutely no provisions on Vulkan to keep the code compatible with 32 bit.

While the real answer is "have a native ARM port" do keep in mind that ARM Windows devices can run 32-bit x86 binaries, but not 64-bit. While I would understand why one might want to discontinue official 32-bit binaries I'm not sure I understand why one wouldn't keep 32-bit compatibility since the only thing it can do is point out where poor code was written. At least I can't say I've ever run into an issue where the arch was the problem.

[Graf Zahl]

I think you are completely missing the real reasons here.
Why not D3D10? Simple: XP did not support it! You need to have some critical mass of potential users to justify the work. And Vista did not go down particularly well, remember?
So yes, the game industry skipped that iteration because it would have been suicide.
Why was D3D11 only adopted after 4 years of Windows 7? Actually the same reason: They had to wait until the market share was high enough to justify the work. I guess if D3D11 has been backported to XP and Vista we'd have seen more titles earlier.

Convenient that D3D11 and 64-bit PCs hit high enough market share for everyone to latch on to right when the new consoles dropped.

I do very much believe if the new consoles had been released a year or two earlier, support would've picked up much quicker regardless of any changes to the PC gaming ecosystem. It's relevant to note that UT2004, released in early/mid 2004, came with both 32-bit and 64-bit executables on PC. Skyrim, released over 7 years later in late 2011, came as 32-bit only on PC despite the developer having done work internally to get it ready for the future 64-bit consoles (work that was only put on hold when they realized the new consoles were still a couple years out, not because PCs weren't ready). If my budget PC could handle a game released 3 years later, that game isn't targeting a gaming PC.

Sure, there's certainly an argument to be made about being exclusively 64-bit or exclusively D3D10/11 in the early years, but these games were exclusively 32-bit D3D9 for years. And now with the new consoles, they're exclusively 64-bit D3D11 (or D3D12 or Vulkan). Where was the transition period for PCs?

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? 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. Sure, when 64 bit consoles stated to show up it was necessary to make the existing code compatible with it so it may have accelerated the transition. However, that hardly matters here. If you want to sell PC games you have to target the hardware that's in the market. And if that's still 32 bit to a large degree you cannot make 64 bit software. 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.

They only had serious issues because few games actually used them. id Software staunchly supported OpenGL even through its darkest times and showed it can work if they work with the hardware vendors. Individual developers could be in contact with the hardware vendors to ensure their games work, and in doing so would've raised the general quality of the drivers. Further, any ports for OSX, iOS, Android, and Linux required OpenGL, and OpenGL was also available for PS3 while D3D was not. So really, unless you were exclusively XBox and/or Windows, you were likely supporting OpenGL in some fashion anyway.

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.