>> Microsoft can change DirectX whenever they want
They really can't. Software that uses DirectX will require a specific version of DirectX in order to have the correct ABI so that it can dynamically link against the DirectX libraries. Those versions and therefor ABIs are set-in-stone. Not to mention that a huge cross-section of the DirectX software library also distributed the required version of DirectX with the software.
Microsoft can change any FUTURE version of DirectX, but the deployed versions in the wild are out there and can't be changed.
I wonder if Microsoft has a cross platform .Net Core-like DirectX in the works. Given their push to unify their Windows and XBox gaming experiences, I can't imagine it'd hurt to spread that out even further and expand to capture as many games as possible. Though I guess outside the other consoles there's not a lot of other game systems.
I would not be surprised in the slightest if they did that. In fact, they've actually tried that before: https://en.wikipedia.org/wiki/Microsoft_XNA. It's discontinued, but still used.
MonoGame implements the XNA API and lets you write games that run on Win32, UWP, macOS, Linux, iOS, Android, Xbox One, PS4, PSVita, and Switch. That's probably the best cross-platform support of any game framework.
> Create a standard, ask Unity and Unreal Engine to support it
It's called Vulkan, I believe. Or, you know, OpenGL even. Doesn't change the fact that it's the developer who will have to support it. Also doesn't change the fact that the developers _won't_ support it because of the same reasons that they don't now: it's not commercially viable. DirectX is not the problem.
Graphics is not the primary problem. The DirectX family of APIs also supports audio, input, networking, and other useful things that are in many ways far more difficult to make work across all platforms, at least historically.
So in some sense, DirectX's existence changes the economic equation, which does make it part of the problem.
Yes and no, there are new APIs to support the same use cases, and none are standard/cross platform. Whether they are part of DirectX formally or not is not important.
While XAudio2 is a key library, it is not DirectX one, as we were talking about DirectX umbrella project. It is not as low-level library as other DirectX projects were anymore, it doesn't talk to the hardware directly. It is really just a user space library with convenient functions, made by Microsoft. It also has competition, there's OpenAL, which is similar - even if it doesn't have as nice API, it is cross-platform.
Yeah, I understand, that is why I said it is not DirectX, but being in DirectX or not is just marketing.
The reason is that XAudio2 (and lower level ones and other non-audio ones) is developed, distributed and recommended by Microsoft, and it is used by many major games and audio engines.
So I don't understand who cares about whether it is formally part of DirectX or not.
I didn't claim there aren't alternatives like OpenAL or Wine's XAudio2 implementation. I simply said the original XAudio2 is not portable on its own, which means you cannot simply use it in Linux, for instance.
I share your criticism, but just "Create a standard" is maybe a bit hard to do. Game devs need a market. The linux market is not really the biggest one, neither in numbers, nor in money. It only became a bit relevant, because Valve used linux, to threaten Microsoft, as they tried to get a big cut of game sales, with their own market. So good for linux, yes, but the normal linux game market is still quite uninteresting (mildly put) for publishers.
> I share your criticism, but just "Create a standard" is maybe a bit hard to do. The linux market is not really the biggest one, neither in numbers, nor in money.
I know of at least one game that's regularly in the Steam top 10 (Path of Exile) that is doing a port from DirectX to such a standard, Vulkan.
Not to support Linux, but because Vulkan is cross-platform, allowing them to reuse their code base for a mobile game, and also to be able to potentially support things such as Stadia. They also said this will lead to a mac port and may lead to a Linux port.
So there might actually be incentives already for game devs to use cross-platform tech, which could lower the barrier for Linux ports significantly and make it worthwile.
Sure thing, and they are not the only one. And it is good thing. Star Citizen for example is a very big one, who will use vulkan (so probably around 2030+, when the game is finally somewhat finish ...)
But my criticism to the comment above was about "just create a standard" for the linux world, as it is something trivial to do. But yes, with vulkan there now exists a standard for graphics, that can compete with DirectX again. (even though linux-foundations are not really involved directly in the Vulkan standard)
But games are more about the graphic layer, because with OpenGL there was a graphic standard before, yet still allmost no one bothered to port to linux.
That changed, for various reasons. (mainly Valve and Android, I think). Also it helps, that unity for example can target linux, and their editor also now runs on it (but I don't know, how well).
The thing is it's not that hard to write cross-platform games. Compatibility layers like SDL2 make it easy to target a platform agnostic system interface. Vulkan enables high performance graphics on most platforms.
Just out of curiosity, do you speak out of first hand experience, that it is not hard?
When you sell a game, people expect it to just run. Windows only games have already countless bugs, making it impossible to start for quite some people. Now add to that Android (with all its different versions and vendor specific implementations) Apple with a slightly different ecosystem .. and then Linux Desktops.
Lets just say, that I am making a game. Even open source. And I want cross-platform, but don't want to get mad along the way and I want to focus on the gameplay and not platform specific code. (and did not want to use unity for various reasons)
> And I want cross-platform, but don't want to get mad along the way and I want to focus on the gameplay and not platform specific code. (and did not want to use unity for various reasons)
Which platform specific code? With a compatibility layer and a cross-platform graphics API we're talking about a vanishingly small amount of code.
"Which platform specific code? With a compatibility layer and a cross-platform graphics API we're talking about a vanishingly small amount of code."
Again, do you have really first hand experience, how "vanishingly small" that amount of code is?
I have not much experience in that area, as I specialiced on the web years ago, BECAUSE I heard too much horror stories about the difference in "theoretically cross plattform" and reality.
I have not released a commercial product, but I have worked quite prolifically with these tools and the experience is very good.
Web is an interesting value proposition because somebody else is worrying about portability, but it's quite limiting isn't it? I mean you're limited to webGL and a single-threaded host environment. It's certainly possible to make some nice experiences within those limitations, but you're not getting anywhere close to the full capacity of a user's hardware.
Good luck, if you do. I am serious. I also think the waste of the millions of layers of the web to the hardware disturbing, but it is the best compromise I see.
"but you're not getting anywhere close to the full capacity of a user's hardware. "
Certainly not. So no, doing a graphical bombastic AAA game is not possible, but the vast majority of games is today quite doable on the web.
"a single-threaded host environment"
And fortunately today this is not true anymore. With web workers and various other approaches, you can have costly calculations in the background, but sure, this is still not the same as real multi-threading.
ProtonDB had that issue in the beginning when users selected their own rating, but they changed the rating system. The only complain that could remain is the one for the multiplayer - if the single player runs perfectly but the multiplayer not, which rating is that? But pure multiplayer games are rated correctly, see https://www.protondb.com/app/578080 for example.
Doom Eternal while it works pretty well does have significant artifacts in some levels. There is also some weird bugs that don't exist on Windows and significant performance drops (game goes into single digit framerate) which again doesn't happen on Windows 10. Doom Eternal needs a high framerate to be played properly. I have a 1080Ti, I shouldn't have frame drops.
I been playing a lot of Doom Eternal (clocking over 40 hours in game) while in Quarantine and I've played it both on Arch Linux and Windows 10. My rig is pretty good (Ryzen 7 3700X and a 1080Ti).
Also if you have kernel.modeset=1 as a kernal parameter on to get Wayland with Nvidia, proton just doesn't work as it can't load up the vulkan libs (this is me going through the steam logs). I believe Pop_OS! does this, however I switched to Arch Linux now.
So I have to choose playing games with screen tearing while scrolling in Firefox or smooth Firefox with no-games.
Nontrival answer to a nontrival question. your first order goal, gaming on linux, has a dangerous second order effect - removing microsoft market. even if you could magically solve all the problems to make a technically sound widely adopted gaming mechanism on linux, id bet MS and/or Apple take an interest in shutting you down one way or another.
Linux server is perfect because there is huge commercial demand for it. Linux desktop has problems because there is almost no commercial demand for it. Good things require money because effort isn't free.
ChromeOS is a great demonstration of this. A polished, solid, very good desktop experience based on Linux because a large company has a vested interest in its success.
The Linux desktop is perfect for some goals and situations, this however, has nothing to do with that. Having issues while running a game on a platform it was not written for says nothing about the quality of Linux as a Desktop OS.
Being a sysadmin for 15 years and a Linux desktop user for 18+ years, I can say that the requirements are vastly different after a certain point in the OS.
The crux is making users do everything they need without accessing the parts they shouldn't.
In the 90's that situation was flipped: it was the desktop side that was stronger and the server side weaker. This was mainly because it was a bunch of hackers making the system they wanted for themselves. But then businesses started being built on Linux pouring money into server-side development (adding features, fixing bugs, improving performance etc.) and many of the hobbyists decided it was time to get paid for their efforts. So you end up where we are today.
Personally I've had less issues with the Linux desktop (KDE) than with the Windows desktop (outside of course of dumb things I did myself, like messing with GPU setups, or removing a vital library for rendering).
"Doom Eternal runs perfectly - it just have some pink flickering every minute!"
"runs perfectly - it just closes when you try to start it."
"runs perfectly - multiplayer doesn't work though."
Microsoft can change DirectX whenever they want, that goalpost is always going to change to suit them, so why even play them at their game?
Create a standard, ask Unity and Unreal Engine to support it, take a smaller cut when buying the Linux version on Steam.