True, but i was kinda listing the figures for where the API is the best native option i guess.
Vulkan runs anywhere but you don’t NEED to run vulkan on Windows 10 because DX12 exists and the native development tools likely target it.
Whereas on Windows 7 and Linux you have to target Vulkan to get an advanced low level API - hence i counted vulkan’s “share” as in the 50% mark even though it “can” run anywhere almost (even mac via moltenVK shim).
But yeah definitely MS playing games in order to kill it.
As to game devs - if they can target 80% of the market with half the effort they will.
WoW has millions of players who stick around for years on-end. It’s a very old game with low system requirements, so it’s reasonable to expect more WoW players stayed on Windows 7 than Steam members as a whole.
nefarious or not it has some heavy implications. microsoft was holding out on windows 7-8 users in order to push/ force windows 10 adoptions.( no good)
they could have done this before DX12 was officially launched as windows 10 only and reported to be impossible to implement on 7-8. now that vulkan and dxvk is taking off in full swing and showing a swing in the numbers they are horrified. so they are eating there own words to try and retain users and hope to increase adoption of 10 when 7 is end of life.
Which is why it makes sense that they were paid by a party like Blizzard. Yes, Windows 7 is end of life come Jan 2020, but you can extend that life by paying Microsoft for support.
Also they’ve said NOT ALL of DX12 is backported. I believe this further supports my theory that Blizzard found it cheaper to pay Microsoft to backport some of the features of DX12 to get that performance boost in WoW without much effort on their end. As well as save money by not having to support two entirely different graphics APIs.
I guarantee you that “that amount of work” = change build target, recompile and upload to windows update.
If you think that microsoft hasn’t got DX12 full of IFDEFs from the start in order to build on platforms back to Windows 7 or maybe even earlier… i think you’d be shocked if you were to look at the code.
Developers would have that shit scattered everywhere as appropriate during the development of DX12 as you never know what shenanigans Marketing will get up to.
It would be a recompile, nothing more. If that. The hooks may even be in most of the code to do platform detection at run-time already, it just maybe merely needs to be pushed by MS for the relevant OS platforms.
Ditto for things like Windows on ARM. You can bet that there are still parallel builds going on even for stuff like WIndows server and other as yet unreleased products. Just like Apple are probably still maintaining macOS builds for newer PowerPC CPUs, along with ARM, etc.
Sorry, but you don’t know what the hell you’re talking about.
Releasing dormant code isn’t just flipping a switch. There’s an entire release battery, lots of testing, lots of talking with AMD and nVidia to ensure they support it on Win7 drivers (they could have #ifdef WIN10 enableSupport() #endif), and so on.
Of course, could also be that Microsoft just said “fuck it, we want Win7 to be an instable piece of crap anyhow” and just released it too.
I’m sorry but if you think Microsoft hasn’t been testing against Windows 7 all this time you’re likely mistaken.
I guarantee you that DX12 would have been ready for release on Windows 7 on day 1, it simply wasn’t due to political reasons.
If that’s not the case then Microsoft management are brain dead retarded (for limiting their options in case a situation such as this arose where Win10 didn’t take off as hard as expected and they need Windows 7 to keep market share against linux, especially after the Windows 8 disaster), and despite my hatred for the company, this is simply not the case.
They’re very business savvy and play the strategic long game for the most part. You don’t get and maintain a desktop monopoly for 30 years by being business-retarded.
DX12 is an iteration on the DX code-base which stretches back to Windows 95
It will be full if IFDEFs going back to 1995 or earlier. no i’m not saying DX12 will run on Windows 95, but relatively small changes would be required back to Vista.
There is not a massive difference between the low level display subsystem on Windows 7 and Windows 10. The big shift to user mode display driver(s) happened in Vista. And there are bugs found in current windows platforms (including the display subsystem) that stretch back 10, 15 or 25 years in some instances. This is not all new code.
testing your applications against all the products you currently have in the marketplace, especially when your new platform has taken 4+ years to struggle to 50% market penetration is just sound business sense.
They didn’t “try and get DX12 working on Win7”. It would have been running on Windows 7 internally from the start.
Apple for example had OS X running on intel since before 10.0, on Pentium 4s (Just like you can bet they have macOS running internally on ARM right now, and have done for years). Apple’s development team is a lot smaller than Microsoft’s, back then they had far less money, and maintaining a complete OS port to a different arch is a lot more work than simply testing your display API can compile and run on your previous (but still in use, en-masse) platform.
As a major software house that runs 80-90% of the world’s desktops, you plan for contingencies.
Yes. And the display code of Windows is not handled primarily by Microsoft, but by nVidia/AMD/Intel. MIcrosoft provides low level APIs but the implementation is hijacked by drivers.
This sounds like a good idea in theory. In practice, like I said, I have worked on several projects like this - and they always cost the company tens to hundreds of millions of dollars.
Not because the implementation engineers had to handle a lot of bugs, but because the test engineers had to make sure every little fiddly corner case was covered.
Look at it this way. Let’s say an approach like this generate 40 bugs for uncovered edge cases. Let’s say 25 of these are deemed important enough to be fixed.
Each bug will take somewhere between 4-120 hours for a team of engineers to handle. Let’s say the average is 30 hours.
Let us assume one engineer costs the company around $100 an hour.
25 bugs times 30 times 100 is, already, 75 000 USD. This is just the tip of the iceberg.
Now include delays, include bugs introduced due to bugfixes, etc. and you’re up to 200 000 USD to get this code ready to run.
But this is just the actual development cost. Now throw in test systems. Easily 5-10 times the cost. Take in two test engineers. And so on. It easily grows to 5-10 million USD for an “almost ready” feature like this.
And that’s just internally, then you need to set up meetings with other companies to make sure they support this feature set in their drivers, et cetera, which means managers costing $500 an hour have to be paid. And so on.
So, this can easily end up in the hundreds of millions range. And hey, if MS wishes to spend that much money no problem with me. But that means they are spending a whole lot of money to make sure they may backport stuff to old, outdated systems.
So, no… This is not “just” flipping a switch. It costs a lot of money.
This does not makes sense to me as the easiest solution to that approach is using open standards that work everywhere. If applied to the game as a whole they would also be able to market it on other platforms than windows.
I’m far from a Microsoft fanboy and love open standards, but I just read this as business. What’s cheaper? World of Warcraft is already using DX12. The engineering hours have been spent, getting it to run on a limited version of DX12 for Windows 7 is probably a lot cheaper and easier for them then completely switching to something like Vulkan. I would assume Blizzard has dozens if not hundreds of programmers that are familiar with DirectX, switching to Vulkan would require training all these software engineers or hiring new ones.
So, you think the low level driver parts that AMD and Nvidia and intel write are so different that they can’t be ported (trivially, and may even not even need a recompile because they do run-time checks to see which DX version they are running against) to DX12 on Win7?
Yet, most of the low level driver code is the same between Windows and LINUX inside them?
You’re quoting an amount of $75,000 and then in the same post saying “a lot of money”. To microsoft, who is still paying a million dollars a day to the EU (from memory - for bundling IE with Windows) since like… 1998… it is not a lot of money.
I still say you are massively over-estimating costs. You are assuming a dead code-base that was never continued and has to be back ported and made to work. I am not. I am saying that it is likely development (at least build testing against 7) never stopped. Windows 7 is still currently under bug-fix support and still will be (if you pay) for another 3 years. The Windows 7 code-base is not “dormant”, and i guarantee that DX (inc v12) is still compiled against it. Just not released to the public. Until now.