> If you look at the list of games (https://www.vulkan.org/made-with-vulkan) that use Vulkan natively, as presented by the the Vulkan team itself, 270 of the of the 407 listed games run on Stadia! That is significantly more than half (though it is a little unclear how complete this list is).
Looks to me like you have it backwards. Many (most?) of those games predate Stadia. Seems Stadia/Google selected Vulkan for best compatibility with pre-existing games.
FWIW, there are hundreds (thousands?) of DirectX games that also run on Stadia hardware, but won't because of licensing concerns. Google doesn't want to license DirectX through a copy of Windows, and I'm guessing that using DXVK would be considered "flying too close to the sun".
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)
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.
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
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.
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.
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.
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.
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.
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
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.
The service will be around for a while, and Google plans to sell it to other companies interested in streaming games. One could imagine Nintendo pushing into streaming to compensate for the weak Switch hardware.
I think Nintendo already did something similar with games like AC Odyssey (and probably others) though they never did it in the western market to my recollection. However it might be another company that operates the servers.
It's another company that operates the services and "ports" games over. There is now several "Cloud" games available in western markets for the Switch like the Kingdom Hearts Collection, Guardians of the Galaxy and Hitman.
Proton isn’t perfect, and works much better on Windows Vulkan games vs Windows DirectX. So even windows developers are choosing vulkan just to ensure better compatibility.
(Edit: GeForce Now apparently runs fewer of my steam games than Linux. Certain games detect and block it. Same with android, but for different reasons.)
Your posts have always been so clear minded, and well-informed. If there were a way to follow a user on HN, you would be one of the few if not the only person on that list for me. Every post I see from you, it’s clear you’re informed on the market, you know how everything works, and you are very rarely wrong. I just wanted to say that in my opinion having used HN for many years, you’re in the top 1% of users for contributions. I think you would be successful as some sort of IT and business analyst. Or maybe a blog or YouTube channel commenting on industry events.
Nothing changed. I'm not much of a gamer, yet I have encountered a couple of Windows games that don't run on modern Windows very well but can be played flawlessly under Wine myself.
Proton uses DXVK to translate DirectX calls to Vulkan. I don't know if that counts as adoption, but its still the resultant API of Windows games running in Proton.
I would almost view Proton as a risk factor for Vulkan as it discourages the devs to use cross-platform approaches. Much easier to write only for Windows and let Proton folks to figure out the compatibility problems. This also results in Vulkan losing initiative and being forced to closely follow DX. I’m a bit worried that the way things are Vulkan is going to become “that API libraries use to emulate DX12 on Linux”…
Vulkan works on Windows too though, so you can still write for Windows only, get support for both platforms through proton, and use Vulkan.
And as a bonus you then work on Android if you do a bit of porting work later on, which can now support desktop shading models with Vulkan, while with a sufficiently old Direct X it may only let you more easily target Windows Phone...
I don't know if I agree with the conclusion. Are people choosing Vulkan because of Stadia, or because they want to deploy to the other platforms and Stadia is a nice bonus?
Yeah, he argues for causation using a correlation as evidence. I'm not an industry expert, but I sure never got the sense that developers relied on a Stadia release, or made it a main priority. He may be right, I just don't buy the argument in this article on its face.
You don't have to assume companies rely on stadia primarily to argue stadia is responsible for adoption. You just have to argue stadia brings more to table then it costs to target Vulkan. Which is orders of magnitude easier.
Some games use Vulkan only on Stadia, for example Cyberpunk 2077 — the Linux+Vulkan build was reportedly one of the most stable at release day, but was available only on Stadia and only because of Stadia, as main development target was Windows with DirectX then ported over to consoles.
Stadia's primary barrier to entry is that it's Vulkan-only. People are not choosing Vulkan because of Stadia, because Stadia has no actual incentive to develop for it due to having no playerbase and no market; but if you are already developing for Vulkan, supporting Stadia shrinks from an ask the size of supporting the Switch in addition to PC, to just the size of supporting Epic or GOG in addition to Steam.
I think the biggest driver of Vulkan adoption is the fact that since all the graphics APIs are so low level nowadays, everyone is writing abstraction layers. Plus, Vulkan is a hedge against all the proprietary APIs. Also, 2/3 major consoles are on AMD, Vulkan was originally AMD Mantle, gonna guess there's some common tools and functionality...
Anyhow, Vulkan will survive for the same reason as Linux; no one truly trusts MS, Apple, Sony, etc...
Just a minor nitpick: Vulkan might have Mantle DNA but it severely limited some of the original functionality (no pointers in resource binding). Funnily enough the closest API that matches what Mantle could do is Apples Metal.
Somehow there is this urban myth about Sony caring about Khronos APIs, when they only did such a thing with the Playstation 1, using GL ES 1.0 + Cg as alternative to their own API, as the adoption was very low, they eventually dropped it.
Even on the Switch, if you want all the low level features, you are better served using NVN.
Steam Deck also supports Vulkan, asks developers to add Vulkan support if it isn't already added, and if it isn't enabled, will try to automatically shim it:
> Vulkan API: We recommend targeting Vulkan as your primary graphics API for best performance and battery life. If you use an engine like Unity or Unreal, enabling Vulkan in your build for all users will result in the highest performance/longevity. (Note: Proton includes a DirectX-to-Vulkan translation layer. If your game or engine has high-quality DirectX support but no Vulkan support, it's likely that this automated translation layer will exceed the performance of doing a custom Vulkan implementation.)
Programming with Vulkan is like asking everyone to be a device driver developer and a GPU hardware engineer.
The recent webinar on profiles felt like a joke, manually jungling JSON files to generate bindings for specific profiles, meanwhile on proprietary 3D APIs that is a simple set of API calls.
Khronos still doesn't get what is a productive SDK development experience.
You don't need to program Vulkan, just whoever writes your engine. If you need to write your own engine it's fine if you don't use Vulkan, but Unreal Engine and Unity have supported Vulkan for a long time.
I can vouch. We recently switched from Vulkan to NVN on a Switch title, not for perf reasons but because NVN is supported in the tool chain a little better. If you have a Vulkan title already it might be OK for a quick port to the Switch.
Again, your understanding of how Mantle evolved into Vulkan is incorrect as is your understanding of which consoles support Vulkan and how much the graphics APIs for both those consoles differ from Vulkan.
Consoles are far from a driving factor for Vulkan other than the need for these engines to abstract anyway.
There's a lot more nuance to the situation than that... different GPUs will have different performance footprints on Vulkan, and the actual ways these engines use Vulkan can differ greatly.
Generally, Vulkan yields better performance than directly-equivalent DirectX code. Even since the early days of commercial Vulkan use (2016), the performance uplift has been a notable upside. However, Vulkan code is generally more difficult to write than DirectX (or even OpenGL and Metal, AFAIK), which is part of the price you pay for portability. High-level libraries were expected to paste over these issues, but this infrastructure is still in it's infancy. Ironically, one of the best uses for Vulkan right now is acting as a sort of intermediate representation for DirectX/Metal API calls.
Vulkan vs what? DX9 or DX11 or DX12. Also it really matters how well you wrote your Vulkan layer. If you write a good DX12 layer and a good Vulkan layer I think they will be comparable in perf - The bottleneck will be the GPU and/or driver. So it also depends on how well the driver writers did.
Am I missing something here, or is there a huge gap in the author's logic?
As I understand it, the argument is like this:
* 407 games run Vulkan
* 270 of those games also support Stadia
* Therefore, direct quote here, "the entire gaming industry is better off because of Stadia and their partners paving the way here"
It's hard for me to believe that a writer who, to quote his own bio, "is an HPC professional with a PhD in Physics from the University of California, Berkeley" would make an argument that correlation implies causation. On the other hand, I've looked over this article a couple of times and that seems to be all the argument there is.
Considering how many tenuously related keywords the author stuffed into the article, I think a likely explanation is that this blog commissioned the article as SEO bait; a writer who doesn't know correlation from causation from their elbow and isn't being paid enough to find out wrote the article, concentrating mainly on keyword stuffing; the editor, who would have known better than to make this argument, posted the article after only the most cursory of readings, enough to satisfy himself that there were no blatant misspellings or racial slurs.
It's not an interpretation that's flattering to the putative author, but on the other hand, it also wouldn't be flattering to think of him as a scientist with such a poor grasp of logic.
Moot point anyway, I suppose, since though we might argue about how much Vulkan adoption Stadia was driving, I think we can all agree on how much more it will drive.
It seems to be a Stadia fan site so the reason for this article existing is that they need to keep a steady stream of Stadia news and puff pieces. They're just trying to come up with positive things to say about Stadia, not trying to actually come up with true insights about the broader industry.
I see it the same way. My point is just that this one particular puff piece contained an error, and that the nature of this error and the background of the (putative) author make it seem unlikely that he could have made that error. So it seems to me that the most likely explanation is that the "author" had this ghostwritten, and didn't read it over as carefully as he might have before posting it.
Eh, last I checked (and I admit it's been a while) a UCB degree still means something in the hard sciences. It's a school you might be able to fake your way through for a little while, but not for the six years or so that undergrad followed by a PhD program would take.
Not a dig, I'd not turn down a PhD grad from UCB but that's my point: if I see someone with a solid background in CS I'm more likely to be critical as they should know better.
As you say, likely just ghostwritten/not their work.
I'm surprised more PC/Console AAA games aren't being written/ported for iPads and M1 Mac's since they have really good CPUs, GPUs and fast storage. Why is that? Is it because of Apple's insistence on Metal?
The mobile games market has exploded hugely, there's definitely a big market there.
Combo of Apple’s insistence on Metal and biz model mismatch. You can either make gambling for children or have apple throw pity money at you. No one is buying $70 apps.
i think it's probably because the people who tend to play AAA PC or Console games already have a PC or console. Could developers really make more money, or would it just be people who already bought the game for PC on steam downloading an additional version for free?
the mobile game market has exploded, but AAA games are a different dynamic and a different audience to the casual games popular in the mobile market.
and for iPad specifically, apple's 30% cut probably factors into the decision in a big way.
> i think it's probably because the people who tend to play AAA PC or Console games already have a PC or console. Could developers really make more money, or would it just be people who already bought the game for PC on steam downloading an additional version for free?
Which services give you the game on any platform? In my experience, you have to buy the game on each platform (and for some games, I have purchased them on multiple platforms because they were that good).
> Which services give you the game on any platform?
The Microsoft Store generally will, ironically. Buying a game on Xbox will often net you the PC version as well (so long as you get it from the Microsoft Store). I think Sony tried a similar thing with the Vita a while ago, but I'm presuming that was a failure.
Steam? I guess you could say Steam is the platform but in the past Mac was a seperate platform and except for a handful of exceptions like Blizzard games usually required a seperate purchase. These days buying on Steam gets you the Windows/Mac/Linux versions if available. GOG is similar too. But buying off the Mac app store just gets you the Mac version (why does anyone buy off there ever?).
Sony has also done some crossbuy stuff in the past. Their PS1 classics used to be generally PS3/PSP/Vita compatible and some titles were cross PS3/Vita/PS4 like Spelunky or PlayStation All Stars Battle Royale. Microsoft has done some cross Xbox/PC stuff too although you have to buy from their store.
The game studio making Resident Evil series has announced just a week or two ago during their big presentation a native M1 port of Resident Evil VIII (the most recent one), among many other things. And not only that, they actually talked about it quite a bit in detail, and even showed some actual footage.
Overall I agree with you though, this is literally just a single datapoint, and I cannot think of another one. But that seems like a solid start, especially since it is a legitimate AAA game, and they are doing it a year after the (very successful sales-wise) release. So they clearly are doing it for reasons other than just boosting up the initial sales by promising the moon. Looks like they genuinely believe they might make enough money with that M1 port.
We saw the same thing happen with Eidos and Tomb Raider, but that didn't exactly usher in a new era of MacOS gaming. Time will tell how successful Macs are for gaming, but I don't think the critical issue (the limitations of the software layer) has been fixed.
> We saw the same thing happen with Eidos and Tomb Raider, but that didn't exactly usher in a new era of MacOS gaming.
To be fair, Eidos and Tomb Raider didn't happen during M1 era, it was just a port for devices that were still using x86. Iirc Resident Evil devs explicitly called out working with M1 an what it brings to the table.
I agree though, we will see how it goes, somewhat impossible to tell how it is going to pan out. Could easily end up being just a one-off.
Realistically, I don't think it is going to usher in a new era of gaming on macOS, but I hope it will slowly move it in that direction. Similar to how it happened with Proton and Linux. It's been out for a while, but only somewhat recently (at some point in the past year or two) has it reached a critical mass on the market.
Proton and Linux work because everyone can contribute to them. Hell, Proton even ran on MacOS up through Mojave, but architectural changes prevented it from going any further.
But, like you've said, there's dozens of allegories for why gaming doesn't work on MacOS. I guess we'll just have to see how (if?) Apple addresses that.
Gaming on iOS is practically dead. No one wants to pay anything, so about all that gets made is freemium junk full of ads and IAPs. The glory days of amazing iPhone games is gone.
Apple Arcade is helping, but it’s never going to turn the tide. It’s a last bastion with a few games.
Port a recent game, sell it for $10, watch nothing happen. There are a few great ports out there (I just replayed SotN) but I doubt they make their cost back.
Don’t be so sure. Candy Crush, Clash of Clans, and many others have thought in tons of money.
More than AAA? I’m not sure.
But Candy Crush didn’t cost what Horizon Zero Dawn or God of War did either. Not even close. And the game prints money year after year in a way most AAA games don’t.
It's generally through IAPs in freemium games, people have just become far more resistant to pay-up-front apps. I think a large part is not allowing you to try before you buy, people are afraid of getting burned. Even though freemium games are often horrible after a while of playing (unless you're willing to dump hundreds of dollars into them), the initial experience usually feels pretty fun and you feel good that you got it without having to spend any money to get to that point.
They earn a metric ton from IAPs, which is almost all consumable Smurfberries and such.
I’m not saying there are no games. Games could easily be the biggest section of the App Store. I’m saying there are no *good* games, only those designed to force you to make IAPs.
Stand alone titles that cost a few bucks (immediately or as a one time unlock) are basically dead compared to the era before IAPs existed.
The hardware is great for developing games, but the software experience is so cumbersome that it makes sense why game devs don't port to Apple Silicon:
- You need to port to ARM (not that bad, but now you're debugging two versions and increasing your dependency graph)
- You need to distribute on MacOS/iPad (not insurmountable, but kowtowing to Apple's ever-changing demands is a different game than jumping through Sony/Nintendo's hoops)
- You need to port to Metal (pretty hard, requires Mac-specific developers and a separate dev branch)
Of course, there are still devs who spend the extra time to make Mac-native games (Factorio and Rimworld), but compared to targeting Linux/Windows the effort doesn't make sense. For Apple to make their platform an attractive gaming platform, they can either a. Allow sideloading < or > b. Welcome third-party graphics APIs to Apple Silicon. Unless they sweeten the deal though, I doubt we'll see many AAA ports in the future.
Rimworld is actually built in Unity, but without using most of Unity's conveniences; I think it just uses it as a sort of platform-independent shim: launch an empty scene and then do everything with userspace render calls rather than Unity's GameObjects. It's certainly not a /typical/ Unity game, but nor is it in any way Mac-native.
And I think Factorio uses OpenGL (which is cross-platform but deprecated on MacOS) and doesn't distribute via the app store, and is only distributed as x86-64[0], bypassing most of all three of GP's points.
[0] It was recently announced for Switch, but from what I've heard there aren't plans to release it for ARM on other platforms in the immediate future.
How many games on AppStore can you see costing 69.99$ and how many people would pay that?
The only mobile platform with any adoption is Switch where the audience is used to paying much more for games than on PC/Consoles (equivalent games tend to be even up to twice the price there after awhile).
The other, potential mobile competitor, is Steam Deck which shares prices and game library with its desktop counterpart.
It’s insane to me that after all these years apple is still somewhat ignoring the gaming market. I basically haven’t played any pc games in like 6y due to that. Thanks god there’s the steamdeck now
It's a strategy that served them well early in the life of the company. In the 80's both Atari and Amiga made better price / performance computers than the Apple II. Yeah the Mac was great but it wasn't paying the bills at that point. They positioned themselves as the "serious" company for business and especially in that segment education.
I am saying this as someone who has made games for the Macintosh in the 90's and iPhone in 10's. Apple avoids pandering to gamers to make sure they seem adult and serious.
The GPUs on macOS and iOS are incredible for mobile processors, especially in terms of power efficiency, but they don't compete with the GPUs in gaming PCs or current generation consoles.
In Rust land, the Rend3/WGPU stack is able to target Vulkan and Metal, pretty much invisibly to the application. Also Android and WebGL, although not as seamlessly, because the threading model is different in those worlds.
It's supposed to also support DirectX on Windows, but since Windows supports Vulkan, why bother? I have the same code running on Windows and Linux with no conditional compilation in my code.
The Bevy game engine reportedly runs happily on all those platforms.
In C++ land, Godot has similar portability. So do UE5 and Unity.
If it wasn't for Apple shooting themselves in the foot with Metal, we'd all be on Vulkan now, without these portability layers.
Android does support Vulkan. Although I don't think you can do graphics from outside the main thread, which is a major feature of Vulkan. A key idea in Vulkan is that the main thread is just doing refreshes, while other threads are changing what's in the GPU. This allows keeping the frame rate up even when the scene is changing.
(We've had a split on concurrency. Web devs think in terms of callbacks and async, but not real multiple threads running on multiple CPUs with explicit locking. Game devs doing high performance games think in terms of multiple CPUs and the GPU all working in parallel, pumping huge amounts of graphics content. WASM and Android follow the web model. There's kind of a hack involving multiple processes with some shared memory, but it's not general purpose threading.)
It would be interesting to see some data on how good the Vulkan support coverage is. And early Vulkan devices may have buggy or poorly performing drivers.
Apps usually go for the API that works on all devices.
Right now, someone is trying to get my ui-mock cross platform test running on a Raspberry Pi. Current problem involves glib 2.0 not available on some version of LUbuntu.
I agree, whenever something claims to be "pretty much invisibly to the application", it means the abstraction is going to be too costly to build an AAA game that runs at 200 fps on modern hardware. There is a reason why DX12 is the framework of choice for 99.9% of the industry.
I know everyone likes to hate on Apple for doing their own thing (and often rightfully so) but Metal predates Vulkan by 18 months. They needed to do it themselves because something like Vulkan/DX12 didn't exist to adapt and the alternative was OpenGL ES.
AMD created Mantle, it was a good idea that they agreed to create it as an open standard and invited everyone in to participate in a unified standard. Halfway through Apple decided to do its own thing and created Metal.
Apple were clearly sabotaging a unified GPU platform by creating Metal.
Don’t keep saying Apple got there first because AMD did.
131 comments
[ 2.0 ms ] story [ 204 ms ] threadNow that Stadia is shutting down [1], does that mean anything bad for Vulkan, I’m curious?
[1] https://news.ycombinator.com/item?id=33022768
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.
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.
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.
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.
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.
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).
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/
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.
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.
People buy it to use like console
- 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.
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
And that platform is used in professional aerospace.
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.
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.
LG and Asus are arriving this year.
Then there is the whole Geoforce Now and XBox Cloud, where those DirectX games can be streamed everywhere.
(Edit: GeForce Now apparently runs fewer of my steam games than Linux. Certain games detect and block it. Same with android, but for different reasons.)
(At least on my collection of games ranging from the mid-1990's to 2022.)
And as a bonus you then work on Android if you do a bit of porting work later on, which can now support desktop shading models with Vulkan, while with a sufficiently old Direct X it may only let you more easily target Windows Phone...
https://developer.android.com/about/dashboards
- out of 407 games running Vulkan natively, 270 run on Stadia (from the article)
- out of 407 games not running Vulkan natively, also 270 run on Stadia (numbers the article doesn’t mention that I made up to make a point)
Then, the two “runs Vulkan natively” and “runs on Stadia” are 100% independent.
Anyhow, Vulkan will survive for the same reason as Linux; no one truly trusts MS, Apple, Sony, etc...
Somehow there is this urban myth about Sony caring about Khronos APIs, when they only did such a thing with the Playstation 1, using GL ES 1.0 + Cg as alternative to their own API, as the adoption was very low, they eventually dropped it.
Even on the Switch, if you want all the low level features, you are better served using NVN.
By the way here is one of the public sources on the matter,
http://sandstormgames.ca/blog/tag/libgcm/
> Vulkan API: We recommend targeting Vulkan as your primary graphics API for best performance and battery life. If you use an engine like Unity or Unreal, enabling Vulkan in your build for all users will result in the highest performance/longevity. (Note: Proton includes a DirectX-to-Vulkan translation layer. If your game or engine has high-quality DirectX support but no Vulkan support, it's likely that this automated translation layer will exceed the performance of doing a custom Vulkan implementation.)
https://partner.steamgames.com/doc/steamdeck/recommendations
Programming with Vulkan is like asking everyone to be a device driver developer and a GPU hardware engineer.
The recent webinar on profiles felt like a joke, manually jungling JSON files to generate bindings for specific profiles, meanwhile on proprietary 3D APIs that is a simple set of API calls.
Khronos still doesn't get what is a productive SDK development experience.
Yes, that's the point. To use a programming language analogy, OpenGL is C++ and Vulkan is LLVM.
Portable game code has survived with middleware for ages.
Vulkan is basically a bullet point on the API plugin selection dialog.
That doesn't add up. The PlayStation came out in 1994, and was followed up by the Playstation 2 in 2000. OpenGL ES 1.0 wasn't released until 2003.
Consoles are far from a driving factor for Vulkan other than the need for these engines to abstract anyway.
Engine is a totally different topic as they do have experts to just support both in parallel.
And when you look how DirectX is the default for tons of games on windows you wouldn't say what you said.
The DirectX sdk and documentation is also really good.
Generally, Vulkan yields better performance than directly-equivalent DirectX code. Even since the early days of commercial Vulkan use (2016), the performance uplift has been a notable upside. However, Vulkan code is generally more difficult to write than DirectX (or even OpenGL and Metal, AFAIK), which is part of the price you pay for portability. High-level libraries were expected to paste over these issues, but this infrastructure is still in it's infancy. Ironically, one of the best uses for Vulkan right now is acting as a sort of intermediate representation for DirectX/Metal API calls.
As I understand it, the argument is like this:
* 407 games run Vulkan
* 270 of those games also support Stadia
* Therefore, direct quote here, "the entire gaming industry is better off because of Stadia and their partners paving the way here"
It's hard for me to believe that a writer who, to quote his own bio, "is an HPC professional with a PhD in Physics from the University of California, Berkeley" would make an argument that correlation implies causation. On the other hand, I've looked over this article a couple of times and that seems to be all the argument there is.
Considering how many tenuously related keywords the author stuffed into the article, I think a likely explanation is that this blog commissioned the article as SEO bait; a writer who doesn't know correlation from causation from their elbow and isn't being paid enough to find out wrote the article, concentrating mainly on keyword stuffing; the editor, who would have known better than to make this argument, posted the article after only the most cursory of readings, enough to satisfy himself that there were no blatant misspellings or racial slurs.
It's not an interpretation that's flattering to the putative author, but on the other hand, it also wouldn't be flattering to think of him as a scientist with such a poor grasp of logic.
Moot point anyway, I suppose, since though we might argue about how much Vulkan adoption Stadia was driving, I think we can all agree on how much more it will drive.
As you say, likely just ghostwritten/not their work.
The mobile games market has exploded hugely, there's definitely a big market there.
the mobile game market has exploded, but AAA games are a different dynamic and a different audience to the casual games popular in the mobile market.
and for iPad specifically, apple's 30% cut probably factors into the decision in a big way.
Which services give you the game on any platform? In my experience, you have to buy the game on each platform (and for some games, I have purchased them on multiple platforms because they were that good).
The Microsoft Store generally will, ironically. Buying a game on Xbox will often net you the PC version as well (so long as you get it from the Microsoft Store). I think Sony tried a similar thing with the Vita a while ago, but I'm presuming that was a failure.
Sony has also done some crossbuy stuff in the past. Their PS1 classics used to be generally PS3/PSP/Vita compatible and some titles were cross PS3/Vita/PS4 like Spelunky or PlayStation All Stars Battle Royale. Microsoft has done some cross Xbox/PC stuff too although you have to buy from their store.
Overall I agree with you though, this is literally just a single datapoint, and I cannot think of another one. But that seems like a solid start, especially since it is a legitimate AAA game, and they are doing it a year after the (very successful sales-wise) release. So they clearly are doing it for reasons other than just boosting up the initial sales by promising the moon. Looks like they genuinely believe they might make enough money with that M1 port.
To be fair, Eidos and Tomb Raider didn't happen during M1 era, it was just a port for devices that were still using x86. Iirc Resident Evil devs explicitly called out working with M1 an what it brings to the table.
I agree though, we will see how it goes, somewhat impossible to tell how it is going to pan out. Could easily end up being just a one-off.
Realistically, I don't think it is going to usher in a new era of gaming on macOS, but I hope it will slowly move it in that direction. Similar to how it happened with Proton and Linux. It's been out for a while, but only somewhat recently (at some point in the past year or two) has it reached a critical mass on the market.
But, like you've said, there's dozens of allegories for why gaming doesn't work on MacOS. I guess we'll just have to see how (if?) Apple addresses that.
Apple Arcade is helping, but it’s never going to turn the tide. It’s a last bastion with a few games.
Port a recent game, sell it for $10, watch nothing happen. There are a few great ports out there (I just replayed SotN) but I doubt they make their cost back.
Consumable IAPs ruined everything.
And then you still can only charge a single digit (or at most a low 2 digits) amount of dollars.
There's no way you can charge as much as AAA titles with iOS games.
More than AAA? I’m not sure.
But Candy Crush didn’t cost what Horizon Zero Dawn or God of War did either. Not even close. And the game prints money year after year in a way most AAA games don’t.
Unless they IAPs too like GTA Online.
Uh no it isn’t. People who make that claim only think about AAA titles and high profile indies.
If you consider the entire gaming landscape, Apple earns more from gaming than most companies that actually operate in the gaming space.
https://appleinsider.com/articles/22/05/31/apple-earner-the-...
I’m not saying there are no games. Games could easily be the biggest section of the App Store. I’m saying there are no *good* games, only those designed to force you to make IAPs.
Stand alone titles that cost a few bucks (immediately or as a one time unlock) are basically dead compared to the era before IAPs existed.
There are some very highly regarded mobile games that do quite well.
- You need to port to ARM (not that bad, but now you're debugging two versions and increasing your dependency graph)
- You need to distribute on MacOS/iPad (not insurmountable, but kowtowing to Apple's ever-changing demands is a different game than jumping through Sony/Nintendo's hoops)
- You need to port to Metal (pretty hard, requires Mac-specific developers and a separate dev branch)
Of course, there are still devs who spend the extra time to make Mac-native games (Factorio and Rimworld), but compared to targeting Linux/Windows the effort doesn't make sense. For Apple to make their platform an attractive gaming platform, they can either a. Allow sideloading < or > b. Welcome third-party graphics APIs to Apple Silicon. Unless they sweeten the deal though, I doubt we'll see many AAA ports in the future.
Rimworld is actually built in Unity, but without using most of Unity's conveniences; I think it just uses it as a sort of platform-independent shim: launch an empty scene and then do everything with userspace render calls rather than Unity's GameObjects. It's certainly not a /typical/ Unity game, but nor is it in any way Mac-native.
Not that that detracts from your point, really.
[0] It was recently announced for Switch, but from what I've heard there aren't plans to release it for ARM on other platforms in the immediate future.
The only mobile platform with any adoption is Switch where the audience is used to paying much more for games than on PC/Consoles (equivalent games tend to be even up to twice the price there after awhile).
The other, potential mobile competitor, is Steam Deck which shares prices and game library with its desktop counterpart.
I am saying this as someone who has made games for the Macintosh in the 90's and iPhone in 10's. Apple avoids pandering to gamers to make sure they seem adult and serious.
The GPUs on macOS and iOS are incredible for mobile processors, especially in terms of power efficiency, but they don't compete with the GPUs in gaming PCs or current generation consoles.
iPad native ports are kept back by the small share of users who have a compatible gamepad and AAA games don't work with the touchscreen interface.
The Bevy game engine reportedly runs happily on all those platforms.
In C++ land, Godot has similar portability. So do UE5 and Unity.
If it wasn't for Apple shooting themselves in the foot with Metal, we'd all be on Vulkan now, without these portability layers.
(We've had a split on concurrency. Web devs think in terms of callbacks and async, but not real multiple threads running on multiple CPUs with explicit locking. Game devs doing high performance games think in terms of multiple CPUs and the GPU all working in parallel, pumping huge amounts of graphics content. WASM and Android follow the web model. There's kind of a hack involving multiple processes with some shared memory, but it's not general purpose threading.)
Apps usually go for the API that works on all devices.
Plus you’d still have different graphics backends needed for the consoles.
AMD created Mantle, it was a good idea that they agreed to create it as an open standard and invited everyone in to participate in a unified standard. Halfway through Apple decided to do its own thing and created Metal.
Apple were clearly sabotaging a unified GPU platform by creating Metal.
Don’t keep saying Apple got there first because AMD did.
AMD pushing Vulkan while their GPU are powering both the Xbox and the PlayStation.
ID Software adding Vulkan support to DooM (2016), resulting in a >30% FPS boost.
Is this the same disinformation as people claiming that PS3 used OpenGL?