More Wine Wayland Code Has Been Merged

[oiaohm]

I believe Linux has closed the gaming gap with Windows through Wine. There are only games now, not Windows or Linux games. Game developers just test their game in Wine (or Proton) and no additional development necessary.

There are game developers where that idea does not work. Some game developers go native Linux to have a lower memory foot print. And by having a lower memory foot print more copies of the game sell to Linux users. Some is the marketing,

Wine/Proton are not without their quirks.

https://test.winehq.org/data/

There is still on going problem.

Note you said game developer tests with "wine or proton they are done." Problem here is the reverse as well. Wine when programs report features that need adding then they are put in the issue list to be added to wine. Wine does not attempt to implement all of Windows API/ABI.

There was a recent game were everyone was getting upset because developer blocked the beta from working on wine. Developer did not get by doing that they blocked wine using people running the program and reporting to wine that the program was using different sections of the windows API some what wine/proton has not implemented yet.

Competition gaming wine at times can be a nightmare. Because developer tested on X version of wine and it performed fairly but on newer Y version of wine with a few more functions implemented game goes down unexpected code path resulting in wine user getting unfair advantage.

Steam runtime/flathub runtime solutions do have their places for particular games over wine/proton due to being a more set in time runtime.

Wine/proton has helped to close the gap you are right. But wine/proton is a double sided sword for game developers.
Wine/proton advantages
1) Can make porting simpler because you don't have to port. Of course some games the game engine selected from the start of development already works natively on Linux so there is not a porting cost.
Wine/Proton disadvantages.
1) can also be cause of wine players getting unfair advantages over other players of the game.
2) can require higher memory and cpu due to wine/proton overhead.
3) can cause wine player to have unfair disadvantage.
4) updates of wine/proton can randomly change all these disadvantages.
5) can at time cause program to report confusing bug reports as in a bug report generated from program running under wine crashing appear to be a windows issue so causing developers to waste a lot of time.
6) wine/proton as solution to supporting mac/linux does not give you extra release announcements for marketing. New release sections of steam/gog... yes the Windows release gets a new release entry the mac release gets a new release entry the Linux release gets a new release entry. So windows only equals 1 appearance in the new release section staged windows, mac and Linux releases gets you 3 appearances in the new release section.

Yes 1 to 5 of Wine/Proton disadvantages can happen to a game developer who does not bother releasing on Linux anyhow. Number 5 of the disadvantages of wine/proton is a good one kind of kicked game developers were it hurts by deciding not to support wine/proton.

Number 6 is reduced marketing. Reduced views on those looking at new games.

mrg666 game consumer and game developer there is different math here. If it simple to port to steam runtime/linux native that gives you extra shot for a user looking though new games to buy the game. port to mac OS gives extra shot for user looking though new games to buy the game. This also explains why you see windows release then a few months latter mac release few months latter linux release. Yes later mac/linux releases cause the game to show up again in the new release list on gog and steam to the windows users so getting more window users sales. Not doing Linux/Mac releases results in less windows copies of a game sold all due to how new releases on steam and gog work This is why lot of cases it is worth at least 1 release of mac and linux each of game not for Linux users sales but for windows users sales.

[mrg666]

There are game developers where that idea does not work. Some game developers go native Linux to have a lower memory foot print. And by having a lower memory foot print more copies of the game sell to Linux users. Some is the marketing,

Wine/Proton are not without their quirks.

https://test.winehq.org/data/

There is still on going problem.

Note you said game developer tests with "wine or proton they are done." Problem here is the reverse as well. Wine when programs report features that need adding then they are put in the issue list to be added to wine. Wine does not attempt to implement all of Windows API/ABI.

There was a recent game were everyone was getting upset because developer blocked the beta from working on wine. Developer did not get by doing that they blocked wine using people running the program and reporting to wine that the program was using different sections of the windows API some what wine/proton has not implemented yet.

Competition gaming wine at times can be a nightmare. Because developer tested on X version of wine and it performed fairly but on newer Y version of wine with a few more functions implemented game goes down unexpected code path resulting in wine user getting unfair advantage.

Steam runtime/flathub runtime solutions do have their places for particular games over wine/proton due to being a more set in time runtime.

Wine/proton has helped to close the gap you are right. But wine/proton is a double sided sword for game developers.
Wine/proton advantages
1) Can make porting simpler because you don't have to port. Of course some games the game engine selected from the start of development already works natively on Linux so there is not a porting cost.
Wine/Proton disadvantages.
1) can also be cause of wine players getting unfair advantages over other players of the game.
2) can require higher memory and cpu due to wine/proton overhead.
3) can cause wine player to have unfair disadvantage.
4) updates of wine/proton can randomly change all these disadvantages.
5) can at time cause program to report confusing bug reports as in a bug report generated from program running under wine crashing appear to be a windows issue so causing developers to waste a lot of time.
6) wine/proton as solution to supporting mac/linux does not give you extra release announcements for marketing. New release sections of steam/gog... yes the Windows release gets a new release entry the mac release gets a new release entry the Linux release gets a new release entry. So windows only equals 1 appearance in the new release section staged windows, mac and Linux releases gets you 3 appearances in the new release section.

Yes 1 to 5 of Wine/Proton disadvantages can happen to a game developer who does not bother releasing on Linux anyhow. Number 5 of the disadvantages of wine/proton is a good one kind of kicked game developers were it hurts by deciding not to support wine/proton.

Number 6 is reduced marketing. Reduced views on those looking at new games.

mrg666 game consumer and game developer there is different math here. If it simple to port to steam runtime/linux native that gives you extra shot for a user looking though new games to buy the game. port to mac OS gives extra shot for user looking though new games to buy the game. This also explains why you see windows release then a few months latter mac release few months latter linux release. Yes later mac/linux releases cause the game to show up again in the new release list on gog and steam to the windows users so getting more window users sales. Not doing Linux/Mac releases results in less windows copies of a game sold all due to how new releases on steam and gog work This is why lot of cases it is worth at least 1 release of mac and linux each of game not for Linux users sales but for windows users sales.

1, 2, 3: I can argue only about my experience. I regularly play in Linux through Proton, the games I play are heavy games in graphics like Cyberpunk. There is no performance difference I can tell without benchmarking and the benchmark shows less than 2% difference in FPS (RX 6800XT). A light game, such as Counter Strike, will absolutely have no disadvantage on Linux. Resource usage is actually lower, since Linux system (Ubuntu 23.04 + KDE Plasma currently) requires 50% memory of what Windows 11 takes.

4: Things randomly change in Windows as well. Driver updates, for example, break games frequently

5: That is true, by time and experience the bug reporting/diagnosis will improve

6: I don't understand marketing and not interested. So, you might have a point there. Reduced marketing looks good to me though

[Melcar]

I usually buy games on GOG (old games that are almost guaranteed to work on WINE/Proton and Linux compatible), but due to many companies refusing to release Linux versions of their games there I sometimes have to bite the bullet and buy it on Steam.

[oiaohm]

1, 2, 3: I can argue only about my experience. I regularly play in Linux through Proton, the games I play are heavy games in graphics like Cyberpunk. There is no performance difference I can tell without benchmarking and the benchmark shows less than 2% difference in FPS (RX 6800XT). A light game, such as Counter Strike, will absolutely have no disadvantage on Linux. Resource usage is actually lower, since Linux system (Ubuntu 23.04 + KDE Plasma currently) requires 50% memory of what Windows 11 takes.

https://www.youtube.com/watch?v=ycpAc_adJgI

You are thinking PC hardware and recent hardware. There is a lot of Linux market running very old hardware as in hardware too old to run Windows 11 and odd ball SBC. Yes when the hangover items mainline into wine will be a big thing.

My point 2 also depends on the game if the proton/wine overhead is problem. Some VR titles and the like 2% difference is the difference between the user being able to play the game and the player losing their lunch(I am not kidding) and refunding the game.

4: Things randomly change in Windows as well. Driver updates, for example, break games frequently

Its number of paying users on the platform vs the problems is a factor here as well. Wine development branch has the 2 week cycle thing this is a lot faster than Windows driver changes. Less user and faster breakage rate is not what you call ideal for game developers to be on the end of. One of the advantages of the steam runtime to some game developers is a slower update cycle than proton or wine.

Should have been more clear it the speed of breakage with 4 and number of users. As number of Linux users grow this will come more tolerable to game developers.

6: I don't understand marketing and not interested. So, you might have a point there. Reduced marketing looks good to me though

That the thing there is a difference between person selling game and end users.

End users always want less marketing but they fail to see just because you have seen a bit of marketing 3 to 4 to 50+ times does not mean every person has and the person seeing it for the first time could be the time that person buys. As person selling game less low cost marketing is normally bad thing for profits and it normally bad thing for players of the game. GoG/ Steam new release page entries as a game developer you don't pay to there other than releasing doing the new release of the game.

[wagaf]

The largest native Linux game store right now is probably the Play Store because unlike distros, Android provides a stable platform with long-term compatibility on top on Linux.
GNU/Linux gaming will start to potentially be a serious thing when/if the whole platform including the graphic pipeline is stable enough.
Snaps and flatpacks now start providing a good stable platform to ship stuff like games. Vulkan is also a great step forward.

[ssokolow]

The largest native Linux game store right now is probably the Play Store because unlike distros, Android provides a stable platform with long-term compatibility on top on Linux.

Android games aren't "native Linux games". If they were, then Win32 apps running in Wine and WebAssembly-based web apps running in ChromeOS would be "native Linux apps".

Android as a platform goes to great lengths to treat the use of the Linux kernel as an implementation detail separate from the APIs and ABIs developers are intended to rely on and to provide a complete alternative to POSIX.

[wagaf]

Android games aren't "native Linux games". If they were, then Win32 apps running in Wine and WebAssembly-based web apps running in ChromeOS would be "native Linux apps".

That's not the case.

Native Android apps are actual native Linux programs, using direct Linux syscalls etc. Not comparable with emulation.

[ssokolow]

That's not the case.

Native Android apps are actual native Linux programs, using direct Linux syscalls etc. Not comparable with emulation.

Good point. I forgot about those. I correct my statement to "Native Android apps are provisionally Linux apps, with the provision being that you accept that people won't be satisfied with the equivalent to 'winelib apps are native Linux apps', since they blend together a reliance on Linux -flavoured POSIX APIs with a reliance on ported Win32 APIs in the same binary and almost certainly present a Win32 GUI, rather than using a more native-feeling UI toolkit".

TL;DR: My attempt at avoiding the need to explicitly say "They're technically Linux apps, but when people make that argument, it's because they're using 'Linux' as shorthand for X11/Wayland+Linux apps, not Android+Linux apps." utterly failed.

(Or, to put it in other terms, it's as satisfying an answer as saying that something which only works inside WSL2 counts as a "Linux-native app", because it runs on the Linux kernel the WSL2 VM provides, but demands some kind of WSL-specific API in addition.)

...or, if you're going at it from a user experience angle, you could argue that something still counts as a "KDE-native app" if you use Qt to build your app but obsessively re-implement the libadwaita look-and-feel and the GNOME 3.x HIG on top of it. Android apps are as "Linux"-native as that is "KDE-native". (Disclaimer: I'm a KDE user who's been working to find replacements for even non-GNOME GTK+ apps like Inkscape as it gets more and more difficult to reliably disable creeping GNOME-isms like the context menu drop shadows which interact poorly with KWin's runtime-switchable compositing.)

If you're talking closed-source stuff like GOG.com games, then "Linux" becomes shorthand for "Linux+glibc+X11/Wayland-on-x86 apps". It's always shorthand for "whatever is compatible with my 'Linux' machine".

In the end, the pushback against "Android is Linux" comes down to people using Linux to describe an amorphous mass of source-compatible combinations of parts, with an X11/Wayland requirement for GUI applications but not for CLI ones, that Android fails outside of, and feeling that you're trying to to play sophist games to de-legitimize their stance by stripping them of usable words if you argue that Android is Linux.

[Berniyh]

Snaps and flatpacks now start providing a good stable platform to ship stuff like games.

Nobody will do that. Games are shipped via Steam, Origin or etc.
gog being an exception here, but it's relatively small compared to the others.

Applications, maybe. But even those tend to be sold via content stores more frequently since Microsoft is pushing theirs.

[oiaohm]

Snaps and flatpacks now start providing a good stable platform to ship stuff like games.

Nobody will do that. Games are shipped via Steam, Origin or etc.
gog being an exception here, but it's relatively small compared to the others.

This is a little more complex. What wagaf said is not 100 percent wrong. Steam shows something interesting.

April 2023 numbers. Linux platform detected.
1 steam deck.
2 Ubuntu
3 Arch
4 Freedesktop/flatpak.
This is also turn up in other Linux game store option numbers. Flatpak installs of game store installer are increasing in number. So stable platform for steam, Origin or etc on Linux is being flatpak.

Snap we cannot really tell because that would show up as a generic Ubuntu.

Shipped and the platform are two slightly different things.

Shipping games you normally want a sales system. Flathub does not have a sales system yet. Interesting point flatpak does not have a sales system yet it showing up game in the top 5 of Linux platforms in the different game store published stats.

Current nobody does it with flatpak directly makes sense due to no sales system. The usage indirectly does say getting listed on flathub would have a percentage of market share access. Question now comes what will be flathub percentage charged on transactions for sales.

Nobody current does that is true. Nobody will do that is a never statement and those are always risking to being wrong long term.