Hacker News Reader

Comment by danielvaughn | Hacker News Reader

I'm not super familiar with the space, but from what I know, I'd say it would have almost no impact. The industry seems to have been moving towards Vulkan for a while now. Stadia may indeed have accelerated it, but the shutdown isn't going to halt its progress. (IMO)

View on HN

Vulkan is only really relevant if you also want to publish your game on Linux or Android (targeting Linux is not as laughable as it was a couple of years ago because of Steam Deck - of course there's also Proton, so a native Linux port isn't even needed in most cases).

Game consoles don't use Vulkan, Windows is better served with DX12 if you also publish on Xbox, macOS has Metal but macOS is also a fairly tiny market. All in all, Vulkan doesn't actually matter all that much outside of Linux and Android.

Steam Deck does.

...which is a regular Linux PC in a handheld format, not a 'traditional' game console (which have highly customized operating systems).

Distinction without difference.

People buy it to use like console

This thread is about Vulkan adoption though, which doesn't matter for regular users buying any piece of hardware. For developers the fact that the Steam Deck is "just a Linux PC" matters though.

Afaik,

- Xbox is basically using Windows Core + the xbox shell and runs the games in virtual machines.

- The PS4/5 use FreeBSD with their shell and libraries on top.

- The Steam Desk ships Linux and a shell on top of it (Steam Big Picture + Proton).

modern consoles are just PCs using PC OSs with custom UIs that fit the control scheme.

The only one that I could think of that's heavily modified is the Switch.

I only know the dev environment on the Xbox up to 360 and the Playstation up to PS3, but both have OS APIs that differ quite a bit from their 'desktop counterparts'. E.g. even though the PS has a FreeBSD kernel, this has little relevance for development on the console, it's just a shortcut for Sony, but not for game devs (for instance the 3D rendering, sound, input etc... APIs are completely custom). On the Xbox it was the other way around the kernel was written from scratch (AFAIK) but had some stripped down Win32 and DirectX APIs layered on top to simplify porting, but in any case the system APIs were different enough that one couldn't simply move much existing code based over without at least some adjustments. Some game dev APIs originating on the Xbox were even moved to Windows, to simplify porting Xbox games back to Windows.

That is very true for the the consoles before the Xbox One and PS4.

However, since the release of those 2, seems like Microsoft and Sony use an off the shelf OS + their Shell and APIs (graphics, networking, matchmaking ...etc), which makes sense, especially for Microsoft, as they already develop a very capable x86 kernel, so why not use it.

Afaik, with the introduction of the Xbox one, they used the Windows 8 Core as part of their "One OS" strategy to unify all of their devices on the same platform/OS (eg. consoles, mobile, AR/RV, PCs ...etc).

The current version of the Xbox OS is based on Windows 11 [0].

Ofc, it's not exactly the same as Windows, but, it's largely based on it, at least as far as we know.

[0]: https://en.wikipedia.org/wiki/Xbox_system_software

EDIT: Added the wikipedia link. It's the only source I could access from my work's network, but it show's the OS progression since the the first generation Xbox

X-Plane notaby put in a major effort to move the entire pipeline to Vulkan.

And that platform is used in professional aerospace.

> Game consoles don't use Vulkan

The Switch does.

Windows may be better served with D3D12, but Vulkan is fine for almost all cases. If you choose Vulkan rather than D3D12 you also get Android, Switch, Steam Deck/Linux and if you aren't too bothered about performance, iOS/macOS via the MoltenVK translation layer.

PC+Mobile is a pretty massive chunk of the gaming market to get with just one graphics backend.

I haven't worked on the Switch yet, but AFAIK Vulkan is just an option there, the actually 'native' API is something provided by NVIDIA called NVN (would be interesting to know how many games use NVN vs Vulkan). In that sense it's similar to older Nintendo consoles, OpenGL was offered as an option, but everybody used the lower level native API anyway.

PC GPUs are developed with collaboration with Microsoft, based on DirectX features, and if users of Khronos APIs are lucky they might eventually get them as extensions.

Steam Deck/Linux emulates DirectX and Windows, no need to bother with anything Linux native.

On Switch there is support for OpenGL 4.6, Vulkan and NVN, and just like on PC, if you want the full deal, NVN is the way to go.

Other than Linux, specially Android, very few game developers would bother with Vulkan per se.

PlayStation and XBox were never found of Khronos APIs (other than GL ES 1.0 + Cg on the PS 1).

Nintendo had a GL subset on the Wii, and while Switch supports GL 4.6 and Vulkan, those that want full control need to use NVN.

Apple is going with Metal.

And if one intents to use Vulkan abstraction layers as a kind of pseudo middleware, they are better of using classical middleware anyway.

Is there an industry advantage to divesting from OpenGL and splitting into a device specific APIs with hugely overlapping features, yet I’m sure, an impedance mismatch? Since most devs are targeting Unity or some other batteries included game engine, does it just not matter anymore?

The total impedance matches of all device specific platforms you might target is often less than the impedance mismatch of just OpenGL vs. the real world.

It never mattered outside FOSS circles, in the 8 and 16 bit days every platform was a special snowflake, so the industry grew porting contractors, platform specialized studios and middleware.

If you dive into something like Ogre3D, you will see that actual 3D rendering API is a tiny slice of the whole cake, let alone in something like Unreal.

No game developer is using raw Vulkan, Metal or DX12. these APIs aren't the same level of abstraction as OpenGL...

Vulkan is AMD's Mantle open-sourced, it's far too low level for devs to waste time with, it's a target for game engines and renderers.

I think both your sentences are incorrect.

Tons of AAA game developers make their own engine and therefore work directly with the APIs while making an abstraction layer for their higher level game developers.

Vulkan is also not just Mantle open sourced. It’s a significant deviation from the original Mantle API. Mantle was a starting point but what emerged as Vulkan was quite different.

> Tons of AAA game developers make their own engine

Recently a bunch switched to Unreal. Are there THAT many that still maintain their own? Seems like it's just big studios and less than a dozen. Even a massive company like Square Enix is now using Unreal for many projects.

Ubisoft have about 5 engines themselves. When Microsoft acquires Acti-Blizz, they'll have close to a dozen engines under their umbrella as is, I think.

UE being picked up by a AAA studio is news, because gamers associate UE with extreme fidelity graphics. A studio using a proprietary engine is boring because it won't matter one bit for 99% of people, and is modus operandi, basically.

Edit: remembered SteamDB has a rough breakdown based on manual rules, so a lot of engines aren't picked up, but it's still interesting - https://steamdb.info/tech/

Proprietary engines tend to be more common on consoles I think - Steam has a lower barrier to entry overall, so it doesn't filter out the smaller projects as much (which are more likely to use an off-the-shelf engine).

Almost all Sony first party studios use custom engines, even when they support PC. Most Nintendo first party games are custom engines. The majority of Microsoft first party games are custom engines.

Ubisoft use custom engines, EA use custom engines.

Call of Duty is a custom engine (derived from idTech)

If you go to the GDC YouTube channel ( https://youtube.com/c/Gdconf ) you can see the range of game specific things that these studios are working on that using an off the shelf engine is limiting

I also recommend looking at the presentations on http://advances.realtimerendering.com/

Not just AAA. It's certainly a minority, but custom engines aren't that uncommon even among indies. The last game I finished was Return to Monkey Island released two weeks ago, built on a custom engine with custom Vulkan and DirectX 12 renderers (and I guess the macOS version probably uses Metal).

I’m curious why they went full-on Vulkan/DX12 instead of just DX11. It’s an adventure 2D game, the performance requirements aren’t that high, and DX11 still has the most stable and performant drivers out of all the APIs.

Possibly their next game is less refined so they learned the dev stack on something that was less up for debate. Now the know the dev stack to focus on content.

The industry has most definitely not moved towards Vulkan. It’s still quite a small player in terms of market share of games.

Most windows games still target DirectX or OpenGL instead of Vulkan.

With how well Proton runs, there’s even less incentive for game devs to directly target Vulkan now.

In terms of market share sure, though the Vulkan/Metal/whatever approach is clearly the future, no? AFAIK that isn't in question, it's just a matter of how long it will take for mass adoption.

Yea going towards low overhead APIs like Metal, Vulkan and DX12 are definitely the way. DX12 has a very significant market share lead and is what most game devs on PC would target. Vulkan being a distant second and Metal being an even more distant third.

Reply on news.ycombinator.com