Except that the availability of emulation may cause developers to stop native linux support. I dont want to hear "talk to valve about your linux issue" every time i report a bug.
Native means nothing. Nobody rewrites DX engines to OpenGL from scratch. If you believe so then you have been lied to. Feral interactive uses InDirectX to translate DX calls, VP has eON which is very similar... Everyone is doing it already.
I don't know if this is what you meant, but plenty of game engines definitely have separate backends for Direct3D and OpenGL that are more than just translation shims.
There's the big ones like Unreal, Unity, etc. The same is true of smaller in-house engines I've seen and worked on. Even open source hobbyist-driven engines like Godot have multiple renderer backends.
It is true that there is a fair amount of translation going on (browsers and ANGLE is a big example, along with the recent MoltenVK) but it's by no means the only way people do things.
Middleware engines yes. But not all AAA games rely on those. And you know what? Most games using Unity for example dont get Linux ports even though it should be relatively straightforward in many cases. So in practice, DirectX is the main renderer used everywhere on PC.
Wow. HN is so literal. Without expanding upon ever tiny definition, take "native" to mean a linux release developed, beta-tested, and supported by the original developer. Not something developed for windows and then expected to just run on linux boxes thanks to a compatability layer.
KSP, factorio, prison architect, they all put considerable efforts into native linux support. I'd hate to see that be outsourced to valve's compatability layer(s).
> KSP, factorio, prison architect, they all put considerable efforts into native linux support. I'd hate to see that be outsourced to valve's compatability layer(s).
Nothing prevents developers from making specific Linux clients. Valve just provides the option for when clients are not available. Nothing to lose, really.
He claimed that developers could become lazy and simply stop making specific Linux clients, he never claimed that this additional option could prevent developers from making specific clients.
Most developers already dont produce Linux ports. Even indies. So thats the current sad state of affairs. We tried. It does not work well so it was kind of obvious a WINE based solution would have to come sooner or later.
Well, other than companies just not bothering with making specific Linux clients, and relying on Valve. And then when something doesn't work, the developers brush it off and say, "not my problem".
We already know what the current state of Linux gaming is like. Almost nobody apart from 20 percent of indie gamers make Linux ports, there are no AAA games apart from rarely a few ports from Feral every year, its not going anywhere. In the meantime with DXVK i was able to play several DX11 titles as if they were native. This is the only way to go.
The thing is just because a few take the time to do that doesn't mean most developers do and it seems like most don't want to take the time to do so. But, more developers may be interested in using an emulation layer if it's supported and easy for them to use. If developers see their titles being purchased and played more on Linux systems because of this, this gives them more incentive to put more effort into developing native Linux clients and providing proper support.
The way I see it, devs aren't obligated to support any system they don't want to. I really appreciate the ones that take the time to support Linux natively, or even by using an emulation layer because I realize they don't have to. If this makes more developers realize Linux is a viable ecosystem for them to make games for. Even if it's just through an emulation layer to begin with at least they're making some efforts which is more than can be said less than a decade ago.
1) The ease of quality emulation leads to developers ceasing native linux support, resulting in lower quality linux gaming overall.
2) The ease of quality emulation leads more gamers to be willing to migrate to linux as their primary OS, thus helping linux come closer to being a first class deployment target, resulting in higher quality linux gaming overall.
Of course this isn't a dichotomy, but rather I think it's often unwise to look a gift horse in the mouth, especially when you're looking at hypotheticals.
I think point 2 should be swapped for "ease of quality emulation means developers are willing to support linux through the emulation layer and can do so at reduced cost compared to porting"
He's right though. Linux gaming is a chicken and egg problem. Without enough users, the financial argument for making a Linux port is very weak. Without enough games, gamers will stay on Windows. At least if there's a reliable shim, the Linux gaming community might grow and become more relevant, fostering competition amongst game developers and hopefully incentivizing them to eventually doing native ports.
I'd rather see Microsoft and/or Valve shoot themselves in the foot, which they have come close to a couple times. As they took more control over what software is allowed to run on windows machines (or within steam's launcher) there was talk of content moderation, of limiting the most violent/adult games. Had that happened, linux could have been the place for 'adult' games. It might still happen. MS could take action against ROM emulators, bittorrent, client-side encryption, or any other form of software that would send the masses running to linux.
Prison Architect ran into this. It shows gang violence, drug use and executions, all of which are red flags for those who rate media. Funny story: Prison Architect actually received a notice that it was in violation of the Geneva convention. Papers Please, an indi great, might also have been shunned had Valve/MS adopted MPAA-like content moderation.
I think what we see more and more of is a focus on development frameworks that can target multiple platforms.
This already happening with frameworks like Unity.
As the plethora of capable devices increases, especially in the non-traditional gaming platforms like mobile and VR, the ability to support any device is going to be demanded by developers and will continue to improve.
The line between compiling for native and compiling for an emulation layer will shrink until there isn't really a difference. That's the only way for game developers to be able to keep up with new devices being released every other week.
The other benefit is keeping old catalogues around and playable into the far future, as long as we can keep beating DRM or always online mechanisms!
If dev teams want "native" (as per the definition you posted downstream [1]) linux ports, they will put in the effort just like before, except they now have another tool.
Maybe with this new tool, teams that wouldn't have considered putting any effort into porting their game will now change their mind.
Regardless, no one who cares about porting their game will ignore issues because it's not their problem.
[1] "Without expanding upon ever tiny definition, take "native" to mean a linux release developed, beta-tested, and supported by the original developer. Not something developed for windows and then expected to just run on linux boxes thanks to a compatability layer."
This isn't an entirely new idea. Eve Online had an officially supported Linux 'port' for a while until they dropped it because of low adoption rates. They 'ported to Linux' simply by licensing and bundling Cedega, and officially supporting the resulting package [0]. Not an unreasonable thing to do.
I wonder how much Vulkan will help here. I presume many devs will target Direct3D 12 instead, simply because of the Xbox One.
Somewhat related: slides from Valve about porting their Source engine from Windows to Linux [1].
