Hacker News new | ask | show | jobs
by frik 3438 days ago
Oh they are still working on DirectX 12.

Microsoft has the tendency to downside and almost stop development after reaching near monopoly of a niche. Everyone remembers the Internet Explorer 6 years, it took years and Firefox reaching 25% market share to continue development of IE7. The same with DirectX: DirectX 9 was too successful, and OpenGL supported was limited to OpenGL 1 in WinXP and onwards (only tricks like bootstrapping allows OpenGL2+ on Win). DirectX 9 was around for many years. When OpenGL 3 and 4 came around, Microsoft restarted development of DirectX 10. DirectX 11 was merely a maintenance release. When the new AMD API (now Vulcan) came along, Microsoft restarted development with DirectX 12. Nowadays 99.9% of all new games are DirectX10/11 or Vulcan and support Win7+ and are usually available over Steam and/or GoG. And PlayStation 4 is very successful worldwide. XBoxOne is mainly successful in US and has little presents worldwide, Microsoft even stopped announcing sales two years ago - it's that bad. Nor are there any new exclusive games to speak of, PS4 has dozends of exclusive games, Win7+ has millions of exclusive games. Win10 Store is a complete desaster, worst software ever and hardly anyone would use it to buy games, if there are far better alternatives like Steam and GoG. Is DirectX 12 still a thing?

5 comments

Regardless of urban legends, game consoles have their own graphic APIs.

PlayStation 4 doesn't use OpenGL either, rather LibCGM.

From all other PlayStations, including the portable ones, only the PlayStation 3 did support a mixture of OpenGL 1.0 + NVidia's Cg for shaders in addition to their actual graphics API. Almost no one ever bother with it, other than creating game prototypes.

Nintendo Switch has adopted Vulkan, but it remains to be seen if it will be any more successful on the market than Wii U was. None of the other Nintendo consoles do support OpenGL, rather they have an OpenGL-like API, GX and GX2.

Actually if it wasn't for Apple's adoption of OpenGL ES 1.0 for the iPhone, the first hardware support after Nokia's N95, it wouldn't probably ever taken off on the mobile devices.

Revisit this topic when graphics APIs lock-in age will come to an end.
Middleware has already settled that question several years ago, only FOSS advocates without experience in the games industry keep wishing for a different outcome.
Nothing is settled, until the tax of supporting multiple APIs exist. Don't imagine it comes for free. The price is paid, whether it's in the middleware or not. You pay this tax in various ways, from slower progress of game engines, to more bugs in your games. And it clearly demonstrates the intent. Those who push this tax on developers don't want faster progress and higher quality. They want lock-in.
Like I said, without experience in the games industry.

That is not how professional game developers see it, attending a few GDC would help to understand this.

Or if you don't want to pay for a ticket, there are plenty of talks available for free at GDC Vault.

> That is not how professional game developers see it, attending a few GDC would help to understand this.

Do you wish to enlighten the HN community with the perspective you keep teasing? Or should we assume it's simply a narrative you wish to support?

Many companies have invested a lot of money into building various types of middleware as far as I understand it. But no matter how you slice it if you want to support multiple graphics APIs you do have to pay a tax in doing the QA and possibly custom development for each one.

I'm not sure how you get around that but...

> Or if you don't want to pay for a ticket, there are plenty of talks available for free at GDC Vault.

This isn't helpful and does not add to the conversation.

Whose experience in the industry says that lock-in is good for development? Sources please. Or may be you have an example of GDC presentations titled "Lock-in - the ultimate driver of engines' progress" or "Drive development costs down by proliferating lock-in"?
The tax of supporting multiple APIs is not always huge. I recall reading that Unreal's Vulkan support was done by 1 or 2 employees.
> The tax of supporting multiple APIs is not always huge. I recall reading that Unreal's Vulkan support was done by 1 or 2 employees.

And because of that, we still don't see full Vulkan support there - it takes time to implement. See https://trello.com/b/gHooNW9I/ue4-roadmap (search for Vulkan).

If anything, it highlights the tax, not disproves its existence.

Because DX12 gives you support for 2 out of the 3 major AAA platforms. Sony seems to have no inclination of supporting Vulcan as a native API for the PS4/PS4pro.

Vulkan is also not Mantle, it's similar to the original Spec which was written by Johan Andersson from DICE. AMD did give Khronos the spec but there isn't some shared code implementation for Vulkan that is based on Mantle, there isn't a common shared library in general as the implementation for each IHV/System is proprietary.

Vulkan is still a camel, not as much as OpenGL but a camel nonetheless, it's currently quite behind DX as far as featureset goes and Vulkan Next which would add needed features such as mGPU support seems lag into late 2017.

Vulkan is a good alternative but it already shows some signs of getting it self into the same position that OpenGL found it self.

It's also worth noting that DX12 development has nothing to do with Mantle, it's a continuation of the Xbox 360 API and effectively the mature version of the API developed for the Xbox One.

> It's also worth noting that DX12 development has nothing to do with Mantle, it's a continuation of the Xbox 360 API and effectively the mature version of the API developed for the Xbox One.

... significant parts of DX12 are a carbon copy of Vulcan. Are you saying they ended up with the exact same solutions, including things like error codes that are entirely arbitrary choices, by accident?

DX12, and the Xbox One API was NOT developed from the Xbox 360 API. It's based on Mantle. As is Vulkan.

Vulkan was influenced by DX12 designs not the other way around, Vulkan is currently lagging behind. Mantle was written by Johan Andersson and as a result of DICE working on FB3 for the XboxOne.

The Vulkan spec diverges quite a bit from Mantle and is considerably closer to DX12, and again this isn't because DX12 somehow copies Vulkan, but because quite a few of the people involved like Niklas Smedberg and Aras Pranckevicius have been working with the XboxOne/PS4 for quite a while.

https://twitter.com/repi/status/446718535616585730

Direct3D 12 blog with some more details: http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-1... … You may recognize the design ;)

https://twitter.com/renderpipeline/status/581086347450007553

I had a déjà vu while reading in the #DirectX12 specs… #mantle

Look into the history of Mantle, why Johan Andersson wrote the spec as it was, gamedev is a good place to start.
While you'll keep repeating unfounded vague claims, and I'm talking for your original claim that DX12 influenced Vulcan/Mantle I'll keep posting links that prove the exact opposite.

> We’ve spoken to several sources with additional information on the topic who have told us that Microsoft’s interest in developing a new API is a recent phenomenon, and that the new DirectX (likely DirectX 12) will substantially duplicate the capabilities of AMD’s Mantle.

https://www.extremetech.com/gaming/177407-microsoft-hints-th...

Stop spreading misinformation, Vulkan was not influenced by DX12.

> Vulkan is derived from and built upon components of AMD's Mantle API, which was donated by AMD to Khronos with the intent of giving Khronos a foundation on which to begin developing a low-level API that they could standardize across the industry, much like OpenGL.

https://en.wikipedia.org/wiki/Vulkan_(API)

It's not misinformation, AMD delivered the mantle spec to Khronos, but you are ignoring the fact the mantle spec was nearly single handedly written by Johan Andersson and was derived from his work on building Frostbite for consoles. Vulkan then was influenced by quite a few other people from Unity, Epic and Valve.
DX12 is the base for XBox One API so it's going to be a thing, I suppose, until MS pulls out of console business (but I don't see why they would, the original XBox was a bigger disaster yet they stayed). After all, both Sony and Nintendo use their proprietary APIs too.

The reason you need a proprietary API on a console is that you cannot make a game running on a $200-300 piece of consumer electronics compete with a game running on a $1000+ PC if they both use the same API. There is a lot of work a DX/OpenGL driver does behind the scenes to make the same code run on GPUs of different architectures while sharing the same device with other processes. When you target only one GPU in exclusive mode you can do the same things so much faster.

Nintendo started to use Vulkan, so things are moving in the right direction, though pretty slowly.

> The reason you need a proprietary API on a console is that you cannot make a game running on a $200-300 piece of consumer electronics compete with a game running on a $1000+ PC if they both use the same API.

Their primary reason is to tax developers who want to release games cross platform. In practice, no one prevents console makers from making more expensive high end consoles. Those who want demanding games, would buy more expensive hardware. Console is just a type of human interface, nothing inherently in it requires it to be cheap. Same as in regular PCs. The only reason current incumbent consoles are like that is lack of proper competition in their space. Compare it to mobile hardware where competition is fierce.

I don't develop for Nintendo so I am curious, is it like PS3 support for OpenGL or is it an actual native API?

And to reply to your edit: It's true, nobody prevents anybody from making $1000+ consoles. They sell for shit though. Even PS3 suffered from being a $600 console a lot, a $1000 console would be as successful as the Steambox.

The Switch supports Vulkan but it also has its own native API. It's a bit early to tell but it looks from my perspective a lot like OpenGL on PS3, though perhaps with a bit more adoption since Vulkan is more suited to console-style dev and the Switch has less "weird" hardware like the SPUs to get in the way of a standard API.
It's not about supporting weird hardware but about removing the unnecessary abstraction. E.g. in Vulkan you cannot directly write non-uniform inputs for the shaders because different GPUs may need that data in different formats and layouts. There is absolutely no reason to do this on a console, which only has one GPU and the layout of its data is very well known so you can just save a whole bunch of unnecessary code and gain an ability to use GPU compute to set up your draws on top of that.
And how much of a benefit it gives vs requiring to make a completely different set of shaders which you can't even reuse? That's a strong claim that you can't have good performance, after SPIR-V is translated by the compiler.
They support OpenGL and Vulkan now natively on their Switch console. I.e. proper support, and not some fake pseudo API.

> They sell for shit though.

All it means, that most of those who use consoles don't want to play high end games. And console makers aren't incentivized to market that, because they don't have much competitors.

Compare it to mobile hardware as I said. You could argue, that people also don't want to overpay for it. Yet, mobile hardware makers rush to refresh it way more frequently than console makers do, and prices there are more realistic. Competition helps.

> a $1000 console would be as successful as the Steambox.

It would surely sell less than cheaper ones, but same goes for regular PCs. Only a minority of enthusiasts buy high end computers. The vast majority buy weak laptops and such. But gaming market can address both use cases. I don't see how interface of controller vs mouse + keyboard is supposed to change that.

> All it means, that most of those who use consoles don't want to play high end games.

It's actually opposite. Console audience (maybe with exception for Nintendo) wants to play high end games. This is why high end games sell much more on console SKUs. If by "high end" you mean AAA, of course.

Well, if they really want high end games, they shell out for PCs and high end GPUs, because as you said, current consoles simply are behind. No API can work around that.

By high end I mean demanding, those which heavily load the GPU, and benefit from better ones.

So IMHO those who stick to current day consoles, are OK with not getting the max settings in demanding games. But why those who do want more, can't play their games using controller / sofa style gaming? I.e. I don't see an inherent relation between console style gaming and avoiding more expensive hardware.

On which platform? I would LOVE some sources on this! (seriously! I would really appreciate it)
See https://www.khronos.org/conformance/adopters/conformant-prod...

(Search for Nintendo there).

They support Vulkan on the Switch, which shows that they now see benefits in using cross platform APIs.

<3 thank you! This makes me so much happier about my Switch preorder for gamedev purposes :)
For me personally, Nintendo is way too locked up and DRMed. I'm more interested in something like this: https://www.kickstarter.com/projects/smachteam/smach-z-the-h...

But it's good that they are pushing Vulkan forward.

Beware all who are reading below this comment: it's aggressively misinformed. It starts with this comment, which is almost completely inaccurate. And then it continues from there. Wth HN...
> Is DirectX 12 still a thing?

Unfortunately, while MS will require DX for Xbox, it will remain a thing. It's not needed otherwise.