zlacker

>>emidoo+(OP)
Microsoft has no incentive to make good software. Most people will use it no matter what.

>>mouse_+L9
That is not true. People use it as long as the pain of using it, is lower than the pain of switching. Assuming they have even something to switch for.

>>lukan+eg
Thankfully Valve is doing the good work to keep game developers targeting Windows and DirectX without caring about alternatives on the PC space.

>>pjmlp+kh
Apologies if I'm misreading your intention, but are you suggesting that Valve's work on Wine is somehow worse than asking game developers to target Linux/other OSes natively? As a Linux desktop enthusiast, I much prefer the Valve's approach: the library of existing Windows-only games that are unlikely to be ever ported is too vast, and the benefits of targeting a disjointed[1] platform with <2% market share[2] for new games are not at all clear. It's only thanks to Valve that I (and hopefully many other Linux users) do not need to maintain a second Windows system for fun, as the majority of games run perfectly fine on Linux and require nothing more than clicking Install then Play in the Steam client.

[1] Case in point: glibc's compatibility guarantees are weaker than what you get on Windows. (For instance, your system's glibc cannot be older than what a game is built against, which may present problems for devs using Fedora/Arch and players on Debian/LTS Ubuntu, something I've experienced first-hand for my apps.) The X11 to Wayland migration is also still underway. (Though things are getting better, the attitudes of some Wayland maintainers are a bit concerning: "I don't [care] what you think is normal behavior for games. You get certain guarantees with wayland. Deal with it. If clients decide to do exactly what they do on windows or X11 they won't work correctly." [3] I'm not sure game developers would enjoy such reception.)

[2] https://store.steampowered.com/hwsurvey

[3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18...

>>timlat+pk
Yes I am, everyone worshiping Valve for that, has skipped classes on OS/2 history lesson.

Porting games from Android/NDK into GNU/Linux is relatively a child's play.

Playstation OS is also POSIX friendly.

Finally every serious middleware engine supports GNU/Linux.

Still the amount of studios that care about GNU/Linux is almost zero.

With Valve, there are no reasons to bother at all as a studio, target Windows/DirectX, let Valve do the work, collect the money with zero additional effort.

Now with Windows based handhelds, Valve will learn what happened to netbooks.

>>pjmlp+fp
GNU/Linux means Linux plus bash, coreutils, glibc, etc.

What do I need to make a video game? Input, sound, graphics. What use is a shell, a userland, or even a C library (if I'm not writing in C) for making a video game?

Android is _not_ GNU/Linux. It doesn't need to provide a shell or userland as part of the platform, and its C library is bionic not glibc. It also provides a lot of things GNU doesn't*, like input, sound, and graphics. It's also not designed to run on a desktop, and the differences between mobile and desktop are non-trivial and slowly growing.

Windows and macOS are full graphical operating systems. Linux is just a kernel. GNU/Linux is just a command-line operating system. Great for servers, terrible for video games.

Moreover, commercial video games are distributed in binary format, not source. Even if input, sound, and graphics were solved on Linux in a consistent way, the developers** can't help but break ABI compatibility every couple of years. Many apps from Windows 3.1 days can still run on Windows 11. What binary from Linux's early days can still run today, never mind with graphics or sound?

* = You could include GLib/GTK+/GNOME but then you're targeting a specific desktop environment and not simply "Linux" or even "GNU/Linux" anymore

** = Except for the kernel developers, upon whom Linus forces "never break userspace" as a hard rule