The other side of that debate is that Proton would bring more people to Linux, and therefore the incentives for a good native version of the game on Linux would be a lot higher.

anecdote with sample size of one:

I finally switched to Linux (Pop_OS 19.10) after realizing Proton was good enough for all the games I enjoyed.

If you count "switched to Linux" as including "finally stopped propping up the grungy old Windows partition", then mark that down for a sample size of two.

While you're right, I'm kinda OK with Windows becoming/staying the main PC gaming "API" that more than one operating systems implement. It's just gaming; the important things are fun, challenge, immersion, escapism and great stories. Not how pretty it is under the hood.

Having tried to write interesting applications for linux, I should ask -- what does "native linux" mean?

This is a serious question, and I don't know if it has an answer.

For example, it was easier for me to use pygame, which is based on SDL (simple directmedia layer), which is based on porting windows code.

> which is based on SDL (simple directmedia layer), which is based on porting windows code.

Huh?

Building on top of SDL is probably the easiest way to make a game native on all platforms. There's nothing Windows specific about it.

My "based on porting windows" comment was based on my understanding that SDL started with windows.

Wikipedia says: "Sam Lantinga created the library, first releasing it in early 1998, while working for Loki Software. He got the idea while porting a Windows application to Macintosh."

Even the naming of directmedia suggests microsoft roots to me: direct3d directplay directx, etc.

But my larger point was that I don't know how you would create a "native linux" game - I think high-functioning games on linux use cross-platform toolkits of one type or another.

I don't know maybe you could cobble something together part wayland, part mesa, part pulseaudio, part v4l, part /dev/input...

At the end of the day anything that runs on Linux without needing additional compatibility tools is native.

You could make a distinction for Windows/whatever games bundled together without Wine/eON/whatever and depending what want to determine that might make sense but at that point you probably also want to exclude things like Unity that don't really do a great job at integreating into the Linux environment.

SDL can be used for porting games (ie, making them native) and that's what it was originally created for but it's not really comparable to bundling a Windows .exe with Wine, which would add a lot more complexity.

Ideally games would have native Linux versions. Practically, no one did this before Wine/Proton because the Linux market is so small and bug-prone, so the choices are Proton or no games at all.

I think the major change was Steam and the Steam runtime rather than Proton, which solved the library fragmentation problem. Since then we have seen a considerable amount of same-day releases and native ports on Linux.

It didn't solve library fragmentation as much as it showed the solution that was always available and already used by most ports before the Steam runtime existed: to bundle all the libraries you need besides system interface like libc, libGL, etc. This is really no different on Windows.

> Practically, no one did this before Wine/Proton.

Oh come on, that's a huge exaggeration. There are thousands of native games available for Linux and Wine/Proton had nothing to do with that. Finding something to play hasn't been a problem for a long time if you are interested in a wide enough range of games.

Steam did make a big contribution to that but that was before Proton - if anything, Proton might have slowed down the number of new native releases. What Proton solves for people is being able to play specific games they want to play, like for example the latest popular AAA game that everyone is talking about - for that it's not enough if there are x% of games available no matter how big x is.