So why DX12 and not Vulkan? It's time for MS to start helping the industry instead of proliferating lock-in and complicating things for engine developers.
Sometimes I just wish Valve* would pop up and announce: 'oh so HL3 is coming out soon, and it will be a Steam Linux exclusive for the first 6 months.' While not likely, something like that would be a really interesting gauge of how likely genuine Linux adoption could be...
* I use Valve due to their apparent Linux push with SteamOS (what's the go with that btw!?)
According to the Stack Overflow developer survey, the percent of developers using Windows dropped below 50%. Nobody actually likes using Windows (except for a few Stockholm syndrome sufferers and zealots who drink the MSDN kool-aid), it's just that people are forced to use it due to third-party application support like video games. It seems like every week there's a new article on how Windows 10 is shit for users, whether it's spying on them with telemetry, serving unwanted ads, or reseting user settings after forced updates.
Windows is such an anti-brand that they couldn't even get customers to buy a Windows phone after a $500 million advertising campaign.
> Adding a new rendering backend to a games engine is a trivial task
You keep saying this, but it remains false. If it would have been so trivial, studios wouldn't have hard time adding such backends and wouldn't need to hire third party porting experts when they decide to do it. You can see how long it takes major engines like Unreal to make a fully functional backend (since features added to such engines are publicly communicated). It's very clear it's not trivial at all.
And MS and Co. obviously do all they can to keep this difficult, that's the main idea of their lock-in which they designed to tax developers with.
What's bad though, is your justification of this practice.
It's trivial in the sense that it's low technical risk. I've not worked in the games for a while. At one company with an inhouse engine the rendering backend was initially DirectX9 written mostly by one person. He then implemented the Xbox360 backend. Another person did the backend for PS3 (OpenGL based). Don't have the exact timings it was ten years ago, but after the initial material, geometry lighting pipeline was done (and that's independent from the backend), the engine guy was never on the critical path.
They added Wii, DirectX10, iOS and Android backends while I was there. None of these were ever considered risky and none had more than one person working on it. Each console/platform has it's own quirks in how to optimise the scene for rendering but the having something rendering on screen is pretty much trivial once you have the machinery in place.
I can't speak for Epic, they are making an engine for every possible game and every possible rendering scene which is a harder problem than what we were doing. But the rendering backend isn't the hard part.
> It's trivial in the sense that it's low technical risk.
The problem is not in the risk, but simply in the cost itself. It's an extra tax to pay. However quality can also suffer, see below.
> I can't speak for Epic, they are making an engine for every possible game and every possible rendering scene which is a harder problem than what we were doing. But the rendering backend isn't the hard part.
The story of Everspace illustrates my point. They were bitten by multiple issues in OpenGL backend of UE4, and it took Epic a long time to fix some of them. Their resources are limited, and they are more focused on more widespread backends obviously. Which is exactly the result lock-in proponents are trying to achieve.
Sure, there is effort involved, but from my point of view it's a small one (a couple of man months on a project with 50+ coders). I'm going to have to make adjustments between the platforms because the hardware is different. Even on a DirectX PC, you can often have a lot of differences between the rendering scene for Nvidia, AMD and Integrated Intel gpus.
Don't know exactly what issues Everspace had with the UE4, but you want to have a fun night go out with some Epic licensees and get them to tell you war stories of issues they have had when they tried to do something which Epic hadn't done in their games. You're paying Epic for the "battle testing" and often they didn't fight those battles.
Part of the reason I left the games industry is that once you work at studio with an internal engine it is extremely frustrating to work on AAA games without the freedom to walk over to the engine programmer and get them to move the engine closer to what you need.
> Part of the reason I left the games industry is that once you work at studio with an internal engine it is extremely frustrating to work on AAA games without the freedom to walk over to the engine programmer and get them to move the engine closer to what you need.
Internal engines also on average are less cross platform. Simply because big publishers and shareholders don't want these very expenses that creep into development because of lock-in. That's why many Linux releases for such games use source or binary wrappers, rather than proper native rendering to begin with. This highlights my point above.
I disagree with the characterisation that internal engines are less cross platform because of lock-in, the big publishers don't care about lock-in. It's not part of the calculus in deciding whether to support a platform or not.
A port of a game is more than changing the low-level APIs used to control the hardware. It's the hardware of the platfrom the decides the complexity of producing the port.
Linux is a special case because it's the same hardware as a the Windows. Your market is people who want to play the game but aren't dual booting. Most of the issues with producing your port are going to come down to driver incompatibilities and the fact that every Linux system is set up a little bit differently (the reason Blizzard never released their native Linux WoW client[1]). It's not a big market and there are loads of edge cases.
For big publishers and AAA development, they're not looking to break even or make a small profit. They need to see multiples of return on their money or they aren't going to do it. Using a shim is cheap and doesn't hurt sales enough to matter to them.
I'm looking at publishers who do release Linux games using internal engines. Most of them use binary or source wrapping. Only a minority are implementing proper native rendering in those engines. And I bet it's based on cost considerations like I said above. How would you explain it otherwise?
And I'm sure that cost plays a role when small market is evaluated. The higher is the cost, the less likely such publisher is to care, because prospects of profits are also reduced. So it goes back to my point. Lock-in proponents like MS and Co. benefit from lock-in in slowing down competition growth.
I agree that cost is a consideration of doing the port. From my experience what renderering API is used at the bottom is a very small factor in that cost calculation.
I think where we disagree is that I don't think of the lower level API as being much of a lock in. The better graphic programmers I know have pretty extensive experience of the various flavors of DirectX and OpenGL. The general principles are the same and good programmers move between them easily.
> I think where we disagree is that I don't think of the lower level API as being much of a lock in.
Lock-in here doesn't mean they have no technical means of implementing other graphics backends, it means that implementation is hard.
A lot of common middleware supports Linux just fine. It's graphics that's usually the biggest hurdle. People have expertise to address it, but it's still a tax to pay. And different distros support is a very minor thing in comparison.
If graphics is not the biggest issue, what is then in your opinion?
> If graphics is not the biggest issue, what is then in your opinion?
Graphics is the biggest issue, but the issue isn't at the API level. It's in the driver and hardware differences below that layer.
The "tax" as you call it, comes mostly from the hardware drivers leaking through the abstraction. Part of this is AAA game developers fault since they are attempting to use all the GPU with edge-case tricks to eke out more performance.
And you keep not understanding how game's industry works.
Make yourself an IGDA member, attend GDC, go to Independent Games Festival, network with people there and see how many would actually share your opinion.
Facts speak for themselves. Your "how it works" can't argue with reality. It took Unreal more than a year to add Vulkan backend. And the work isn't even fully complete:
1 - Adding a new rendering backend to a games engine is a trivial task, when compared to the pile of features a game engine needs to support. I did not said it was a trivial task by itself alone.
2 - Check how many in the industry actually care about your 3D API freedom goals. Even Carmack now rather likes DX, in spite of his earlier opinions.
3 - Every big fish and major indie studios are using Unreal, Unity, CryEngine, Xenko, Ogre3D, Cocos2d-X, or whatever else rocks their boat.
If you are happy playing D. Quixote, by all means keep doing it.
Game studios won't change their culture just because of some guys having HN and Reddit 3D API flamewars.
All you said, doesn't change the fact that it's a substantial effort. Whether it's easier than other features is irrelevant to the point above. It's hard overall.
So it's an extra cost for developers who need to spend time on it, and it's exactly the cost MS and other lock-in freaks are benefiting from, since it's increasing the difficulty of releasing cross platform games (one more difficult thing to address). The higher is the difficulty, the more is the likelihood of some games remaining exclusives, which is exactly what lock-in freaks want.
And if you claim that this difficulty is offloaded from most game developers to third party engine developers, it's still a problem. Longer development periods, more bugs, harder support all that contributes to some not making cross platform releases as well.
There are no two ways about it, lock-in is evil, and your justification of it is very fishy (you must be working for one of the lock-in pushers).
> Experience about reality, how people in the industry think, what those people actually consider as project costs.
I trust more the experience of those who actually work on games porting, and explain relevant difficulties they encounter. And no one says it's trivial. On the contrary, they say that rendering is the hardest part, and the most costly one to port. So it's very clear, that lock-in proponents who are against cross platform gaming (MS and Co) are benefiting from this hurdle and strengthen it by pushing their APIs.
Ryan Gordon, which makes a living porting AAA games to Linux since Loki Games days.
Someone that would actually loose this source of income if you had what you wish for, thus be forced to search for other kind of consulting services in the games industry.
Again, not understanding the industry works, plain demagogy.
When a games developer sees a 3D API manual for the first time, their first thought is "What cool games can I achieve with it?" not "Is it portable?".
> Someone that would actually loose this source of income
He can find what to do, working in engine development directly.
So far you were engaging in demagoguery about how trivial porting is and justification of lock-in, even when facts to the contrary were shown to you directly. I see no point in taking your word on it, against those who are actually known to be working in this field.
> When a games developer sees a 3D API manual for the first time, their first thought is "What cool games can I achieve with it?"
Until their publisher or shareholder knocks on their heads and stops their cross platform releases because of costs of using more APIs. Goal (of lock-in supporters) achieved.
You mean you left Linux for .Net. Visual Studio is just an IDE and C++ is cross-platform last I checked.
You appear to be speaking on behalf of all/Windows developers. Perhaps not 'most' think that way? What is your evidence other than your stated status and related anecdotes?
Why should we care what AAA studios care about? Should we be happy they've continued to push DX as default?
What do you do when DX doesn't provide what is needed for a game? Too bad? Fight with MS?
Overall, shouldn't we want gamers to enjoy the games being developed as widely as possible on a range of platforms? It's a little lazy to just fall back on the old catch-22 of 'no market' because 'no games' because 'no market...'
> the percent of developers using Windows dropped below 50%.
Yeah, not sure how is this relevant. Developers are not your average CoD, LoL, WoW etc.. players.
I'm not trying to defend anything as I don't even use Windows myself, it's just that from a business point of view making sure DX and "gaming" in general is locked to Windows makes absolutely 100% sense as again - most gamers do not care if they have to use Windows or not, they just want to play games.
This is exactly the problem. Gamers are paying for Windows, just to play games, because the free options aren't usable, because of DX.
They're not choosing Windows because it does X or Y better or because it's a consciously preferred choice, they're choosing it because it's the option they get by default and because it keeps being reinforced through support of proprietary systems like DX.
Though only anecdotes, I sure do see a lot of comments around people willing to support/use Linux if not for lack of games/particular apps. As you state, gamers don't care what OS they use as long as it works. And well, Linux is free and works, it's just not well enough supported because of the chicken and egg of no market size vs no products available so no market size. I.e. if AAA games were developed with full Linux support, gamers wouldn't care if you gave them Linux as default instead, would they?
What would Microsoft have to gain? Absolutely nothing. What do consumers gain. A hell of a lot.
That's why it's foolish to assume Microsoft will change their ways somewhere down the line. The point is that it is us, the users that should be choosing alternatives and not celebrating vendor lock-in.
That's not a justification for being lock-in jerks. Would you appreciate using ActiveX instead of HTML? We are lucky, MS didn't succeed with the above.
In Satya's Microsoft, it's pretty much guaranteed that DirectX is going to go the route of .NET and be largely open and multi-platform. I almost bet within a year, we'll get a Hacker News article with just that announcement...
How exactly this would benefit Microsoft? They thrive on lock-in DX provide and actively use it to move people on Windows 10. It's just like they benefit from overly complicated Office formats.
And needless to say that exactly with Satya Nadella they started Windows S where you can't use any API other than D3D.
They opened dotnet because they wanted to get it on server-side since Windows have very limited exposure on that market. But even today .NET still not multi-platforms in term of UI and for that reason a lot of Windows-specific .NET software wasn't ported. And it's already more than 3 years after release of dotnet core.
