More Wine Wayland Code Has Been Merged

[Berniyh]

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.

You're completely missing the point. Yes, you can install steam, origin or other programs via flatpak, but the games themselves are distributed via those tools and not via flatpak and that will not change.

I'm not saying that flatpak is useless (I actually use it myself for a couple of things), but it's not going to be a solution for game distribution, it just won't happen.

[oiaohm]

You're completely missing the point. Yes, you can install steam, origin or other programs via flatpak, but the games themselves are distributed via those tools and not via flatpak and that will not change..

Except this is not true that games are not being distributed via flatpak or snap.

https://zetsubou.games/an-adventurers-gallantry/

You are seeing different smaller Proprietary/closed source game makers do direct flatpak/snap releases these are normally free to play games.

Do notice with that zetsubou game steam you don't get the arm version for Linux. Steam takes 30% sales cut. google play 15 to 30%, itch.io takes a 10% sales cut by default but this can be lowered. . At this point we don't know what flathub will be charging. Yes the difference between steam and itch.io means that 5 sales on itch.io equals the same profit as 6 on steam.

Berniyh human greed is going to be a factor here.

https://github.com/flatpak/flatpak/wiki/TestingPurchases

We are still in a very early time frame. Flatpak/flathub could provide smaller game developers with pre-built tools to setup their own stores to keep more of the profit for themselves.

I am not sure that we can say that it will not change because we are already seeing some closed source makers take flatpak and snap as one of their distribution solutions. The big thing will be when paid applications come to flathub how well it works.

[Berniyh]

Even if they take 0%, things won't change.
But yeah, you'll always find some exception. But it'll remain the exception.

[oiaohm]

Even if they take 0%, things won't change.
But yeah, you'll always find some exception. But it'll remain the exception.

Flatpak for sure is not that straight forwards.

https://github.com/flatpak/flatpak/wiki/TestingPurchases

The way flatpak is game could remain being solid by steam/itch.io... and the store decides to pick up flatpak for distribution. Of course flatpak paid shipping system would need real world testing before any of the big game providers will move.

This is why the flatpak taking a small percentage we cannot be 100 percent sure where it will end.

Do I see flubhub ending up with an ultra big games store the answer is most likely no. With the flatpak paid application support lower barrier to entry to any party wanting to setup their own paid game/application store on Linux o yes it will. Will this also open way for different parties providing games on Linux to possible share distribution work by flatpak yes again.

What going on with flatpak is something new. No Linux distribution package management system has ever included proper support for paid applications.

My point of view it too soon to tell how paid applications with flatpak will play out big next bit is flathub getting the support for paid for applications and testing out if the system is classed as suitable enough for valve and others. Valve with Steam has looked at flatpak for different things in the past.

Time will tell with flatpak path is right or wrong.

I don't see snap as anything major at this stage. Having valve and others having to pay canonical to have a snap store is absolutely never going to fly. That the advantage of the flatpak solution self hosting is allowed.

[wagaf]

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.

Your point makes sense for non-game apps, which need to be fully re-written for GNU/Linux.

Games are different because they usually don't make much use of native GUI toolkits.
A C++ Android game using OpenGL or Vulkan can be trivially ported to GNU/Linux.

And anyway, I was just pointing out that Android is an example of a successful native Linux game market.
It was successful because Google made Android a stable long-term platform with heavy containerization, which as others pointed out in this discussion provides a lot of value for developers.

Long-term compatibility was obviously also a Windows strength compared to always changing GNU/Linux environments.

[ssokolow]

Your point makes sense for non-game apps, which need to be fully re-written for GNU/Linux.

Games are different because they usually don't make much use of native GUI toolkits.
A C++ Android game using OpenGL or Vulkan can be trivially ported to GNU/Linux.

And anyway, I was just pointing out that Android is an example of a successful native Linux game market.
It was successful because Google made Android a stable long-term platform with heavy containerization, which as others pointed out in this discussion provides a lot of value for developers.

Long-term compatibility was obviously also a Windows strength compared to always changing GNU/Linux environments.

That's fair, but, if something is open-source and people are talking about source portability, then "native Linux" doesn't really enter into the discourse much because it's "native" to any ecosystem with enough interested programmers.

When people qualify "Linux" with the word "native", they're generally talking about what they can do right now, not what is possible for a porting team. For proprietary stuff, that generally means x86+glibc+X11/Wayland builds. Not ARM+Bionic+SurfaceFlinger. Yes, I'll acknowledge that games are an exception to the side of things where "not Electron either" is also often implied by "native", but the "how natively does it run on my machine right now part doesn't change".

[dimko]

But the amount of Linux, good Linux apps is also growing. It's just for gaming where native apps switch away and studios support proton. And that's fine

I disagree, but we both are entitled to opinions.

[dimko]

If the game runs on Linux distributions as well as on Windows, I don't see any benefits to making a Linux port, only unnecessarily increasing costs. Often older games run better with dxvk than native with OpenGL. I don't really understand your point. Old Linux games won't support new technologies like Wayland, while with Proton they could.

1. You depend on dxvk/proton, which breaks compatibility all time.
2. It makes game code better FOR WINDOWS and other platforms like MAC and consoles, etc. In several ways, not limited to, you catch more bugs, and you implement better cross platform input tools, like SDL.
3. You learn about other OS. So you can now make better server for multiplayer running on BSD or Linux, which slashes costs of maintenance.
4. You increase sales AND sales profits. Many linux users like me wont ever buy windows game full price. I will cheap out on eneba or similar service.
5. Older game's performance is not so relevant, as modern hardware will usually outperform required FPS anyway, AND linux requires less hardware/RAM/CPU to run in first place, so it may be will even out. Unless port is EXTRA shitty.

There are more, but i am too f'd up in a head to mention it.

[lumks]

dimko Proton is a very good target. The linux userspace (not the actual userspace, but tooling, libs, frameworks,…) breaks all the time. Mostly because of glibc upgrades, but other parts also. We do not have a stable base. Proton however is kind of stable. The problem is that game devs would need to target proton directly, not general Win32.
Linux itself is not worth developing for if you want to make money. The value of Linux is the community. We are mostly nerds. We will help you with quality feedback if your games does run into problems. On top of that, yes, if a game runs on linux, it will run just fine on Windows and MacOS, because all our tools are available for every other OS.
Server code is another topic. These are more often own codebases nowadays and might have no impact on the client or how something runs.
System resources are about the same on "enduser-linux" and Windows. On Windows you have the defender that slown certain actions down, but thats mostly not a problem for gaming.

[oiaohm]

dimko Proton is a very good target. The linux userspace (not the actual userspace, but tooling, libs, frameworks,…) breaks all the time. Mostly because of glibc upgrades, but other parts also. We do not have a stable base. Proton however is kind of stable..

Linux userspace is not the same thing. Proton vs steam runtime(the Linux runtime provided by valve) steam runtime is more stable than proton. You application states under steam what version of the steam runtime it wants. Then you have freedesktop runtime in flatpak where you application states the version of runtime it wants. Snap again your application states what version of the Linux runtime it wants.

That glibc issue does not exist with the flatpak, steam runtime or snap setup. There is a reason why parties will release Linux games on steam but not on gog and itch.io because both gog and itch.io says you have to use the hosts glibc so making your application at risk from glibc upgrades and other parts.

On steam the value of releasing a Linux version is not the Linux community its that you application gets to appear again in the new releases list so getting displayed to Windows/Mac OS users who look at the new releases list again.

Proton under steam works as well as it does again because you have per application. Go into steam compadiblity some time you will find "Force the use of a specific Steam Play compatibility tool.'" so allow user to force particular version of proton to be used also this happens in background without users noticing.

The problem is that game devs would need to target proton directly, not general Win32.

This is not exactly true. If game developer is auto testing proton and detect that X version of proton does not work with their application they can have the game metadata in steam prevent their game running with that version. Generally is a bad idea to target development for proton or wine because wine and proton are a moving target that over time will get its API/ABI corrected to be more like windows. Building for a wine/proton quirk normally just causes more trouble down the line. Having a test server running tests running the development branch of proton to inform valve of issues before users hits them is as far as game developer should go.

lumks you missed why proton works so well. Proton only works as well as it does because you have multi runtimes and runtime choice per application. Flatpak, snap and steam runtime for Linux native all provide the same thing.

Steam runtimes, freedesktop runtimes(what flatpak users) and fixed ubuntu version snapshots(snap uses) all provide stable distribution neutral run-times for Linux native applications. Proton under steam would not be as stable as it is without the native steam runtime as well.

Yes a Linux native game under steam/flatpak you can force the game to run with different versions of the steam/freedesktop runtime as well but if it breaks it your fault.