For me it has to be native or no buy. I want something that is meant for linux and there is support out there natively so I am fine.

Even thought I would love more native support...... Proton is really important there is no denying that...... And honestly...... As long as it gets us to play more games on Linux with minimal fuss........ I dont have a problem with Proton......

Proton was a big factor for me making the switch to Linux....... So Proton has created at least one more Linux user...... And at the end of the day...... Isnt that what we all want????....... More Linux users?????.......

Native releases should be encouraged and rewarded. To a lesser extent, developers who officially support Linux via Proton should also be encouraged. However, buying games that don't support Linux at all is just rewarding laziness.

Native releases should be encouraged and rewarded. To a lesser extent, developers who officially support Linux via Proton should also be encouraged. However, buying games that don't support Linux at all is just rewarding laziness.

Why is it laziness though? We’re talking about businesses here. Is it laziness not to want to go into a tiny market that won’t make much money, and that they may not have any expertise for?

Bringing games to Linux isn't just about hitting a button remember. You have ongoing support costs, and we all know there's plenty of quirks on Linux that constantly trips up developers. Time and time again we've seen most developers say it hasn't been worth it. Over the years I've covered it, very very few say it was.

Last edited by Liam Dawe on 14 Jun 2023 at 11:37 am UTC

Native releases should be encouraged and rewarded. To a lesser extent, developers who officially support Linux via Proton should also be encouraged. However, buying games that don't support Linux at all is just rewarding laziness.

Why is it laziness though? We’re talking about businesses here. Is it laziness not to want to go into a tiny market that won’t make much money, and that they may not have any expertise for?

Bringing games to Linux isn't just about hitting a button remember. You have ongoing support costs, and we all know there's plenty of quirks on Linux that constantly trips up developers. Time and time again we've seen most developers say it hasn't been worth it. Over the years I've covered it, very very few say it was.

Correct me if I'm wrong, WorMzy, but I believe you're talking about supporting Linux, not developing for Linux. The difference is developers can choose to officially support Proton.

To be part of this class, in my opinion, the bare minimum is to have the latest Ubuntu release on a computer where you install the latest build of your game with the latest stable Proton release and check if it launches into singleplayer without crashing.

No need to have dozens of items on your checklist, just:

• Launches when you continue Singleplayer
• Works online (if applicable)
• No reproducible crashes

And step 2 would be fixing it if it crashes, I guess, but developers can't actually do that because they're not Proton developers. So, uh, alert the authorities, I guess.

...hmm. I wonder if this is really any better than just releasing the latest build you know has a problem and waiting for a user to report it. I guess the developer could start a Github issue on the Proton repository an hour faster than the user, but that's not much of an improvement. There'd have to be some sort of facility where they delay releasing the game until Proton fixes it, which means they need a way of distributing builds to those developers.

My assumption is this is something Valve can provide on the developer side. However, the problem is the fixes would only make it in in the next patch release for Proton, which tends to happen no sooner than once a month, and you can't realistically tell developers to delay the latest build for an entire month for the sake of a minority of players. Valve could fix this for singleplayer games by letting users rollback updates, but they won't do this.

The experimental branch might work for this? It's built straight from git and there are no releases. I don't really know how it works. But that branch includes a bunch of other experimental changes, so users can't rely on it. There should be another branch, proton-hotfixes, if Valve actually wants to see developers testing their games with Proton and reporting bugs to them.

Okay, so realistically...developers testing games with Proton is pretty pointless right now.

Yes, it's pretty damned hard to emulate/translate trial and error programming, or sneaky stuff written in assembly for a different binary format and/or windows low level filter drivers for DRM/anti-tampering etc. We translate programming interfaces (hence, the recursive acronym "Wine Is Not an Emulator" lol )

Here's the real secret to having your games or applications working on Linux. It's just plain good programming practice for use ON Windows too:

Stick to the bloody APIs. I do mean the chosen graphics APIs, but also the Windows APIs you are using too. Use STABLE (not subject to change) ones, methods that will work for everybody, for a long time. Cripes, it'll mean so much less maintenance if you do that anyway.

Trial and error programming means your game is going to be broken for somebody. If you think you are clever testing with both major graphics card vendors, you'll still run into problems with different chipsets (implementations) from those vendors. Especially with OpenGL.

Whether DirectX, Vulkan or OpenGL (for Windows-only games, why, just why), write for the APIs, not the hardware and don't take sneaky shortcuts. That's how this is supposed to work. It's then up to the hardware manufacturers to support the specs. If they do, the game will work.

I don't know what to say about the DRM other than "stop it". It tends to foil the legitimate user more... and what we're doing is bloody well legitimate, whether they like it or not.

P.S. Cobbled together middleware that may be used in, or with games is an issue too. Choose wisely!

Last edited by Grogan on 15 Jun 2023 at 4:00 am UTC

Yes, it's pretty damned hard to emulate/translate trial and error programming, or sneaky stuff written in assembly for a different binary format and/or windows low level filter drivers for DRM/anti-tampering etc. We translate programming interfaces (hence, the recursive acronym "Wine Is Not an Emulator" lol )

Here's the real secret to having your games or applications working on Linux. It's just plain good programming practice for use ON Windows too:

Stick to the bloody APIs. I do mean the chosen graphics APIs, but also the Windows APIs you are using too. Use STABLE (not subject to change) ones, methods that will work for everybody, for a long time. Cripes, it'll mean so much less maintenance if you do that anyway.

Trial and error programming means your game is going to be broken for somebody. If you think you are clever testing with both major graphics card vendors, you'll still run into problems with different chipsets (implementations) from those vendors. Especially with OpenGL.

Whether DirectX, Vulkan or OpenGL (for Windows-only games, why, just why), write for the APIs, not the hardware and don't take sneaky shortcuts. That's how this is supposed to work. It's then up to the hardware manufacturers to support the specs. If they do, the game will work.

I'm a programmer only by technicality, but my understanding is WINE Is a complete re-implementation of the WIN32 APIs (and whatever else is part of that family), reverse-engineered. WINE developers are bound to introduce errors and bugs because they don't handle calls exactly the same way as the actual APIs do. That's a mistake on the WINE developer's side, not the game developer's side, and they can't fix it. Not without being WINE developers themselves.

I mean, feel free to prove me wrong if game developers have made the wrong choice for every single bugfix Proton developers have had to make over the past 3 years, but it seems unlikely to me. It seems far more likely to me that WINE's implementation is (naturally) far from perfect or complete. I'm not saying game developers are perfect either, but if it works on Windows...it should probably work with WINE.

I don't know what to say about the DRM other than "stop it". It tends to foil the legitimate user more... and what we're doing is bloody well legitimate, whether they like it or not.

Try telling Japanese game publishers that...they're very protective about their copyright. It's just the world we live in, unfortunately. I could just not play those games, but then I might as well not play games at all, because those are the games I play the most, by far. And it's very obvious that 99% of these publishers will never care about Linux. I don't think that gives me a license to obtain cracked versions of these games that actually work with WINE like so many other players in my position seem to, but it certainly makes it tempting.

What he said

Well, you have chosen to maintain a Windows environment for your games, if you want to do that, it's really the best solution for troublesome games. To be honest, I'd probably still have a Windows installation too if they hadn't have ruined it. I didn't hate Windows 7, it was in my opinion, the best thing Microsoft ever beshat. It had its limitations, but it didn't annoy me to keep it around for some games. It was pretty clean and quiet, if you turned off the right stuff. (and the crux of the matter for me is, even older, more horrible versions of Windows, kludgy and unreliable they may be, didn't try to take over my computer like later iterations.

Back to this, sticking to the APIs is a start. It's all they can do. Take a look into what graphics driver software does on Windows, with workarounds for different games. Ours do that too, for example Mesa has game specific workarounds.

I'm not a programmer (and no specialist in any discipline, more of a technician with boots on the ground), and I can't tell you exactly what's wrong with all those games, or all the games that can't work at all, and this is going to seem like reversing the logic here, but how about all those games that just work out of the box on day zero? I don't mean stuff where the Proton devs got pre-release copies to test and had to do things to make them work out of the box. They didn't write them with Wine translation in mind at all. We can translate proper use of most APIs used by games, and specific workarounds, for whatever reason, ("cleverness" or differences between theory and reality) could almost be considered part of the process.

Forgetting about translation for a sec, those that write good, bog standard code that sticks to the APIs have their games and applications working years, even decades later. Use the correct APIs, correctly on Windows, and Microsoft may successfully keep your software running. They'll give you assloads of backwards compatibility dependencies in WinSxS, for example.

Last edited by Grogan on 15 Jun 2023 at 5:27 am UTC

Well, you have chosen to maintain a Windows environment for your games, if you want to do that, it's really the best solution for troublesome games. To be honest, I'd probably still have a Windows installation too if they hadn't have ruined it. I didn't hate Windows 7, it was in my opinion, the best thing Microsoft ever beshat. It had its limitations, but it didn't annoy me to keep it around for some games. It was pretty clean and quiet, if you turned off the right stuff. (and the crux of the matter for me is, even older, more horrible versions of Windows, kludgy and unreliable they may be, didn't try to take over my computer like later iterations.

I dual-boot Windows for multiplayer games, but for VNs, I tend to buy physical versions because they are usually not encumbered by DRM, or they are usually encumbered with AlphaROM, which has a legal bypass. I don't buy VNs digitally anymore except on DLSite because they use the only DRM that works through WINE (at least for now). It's more expensive, but I don't need to use Windows most of the time.

Aside from Windows being a proprietary operating system (which is a pretty big issue), I don't have any issues with it. Mostly. It's more just usability things that are harder on Windows, like virtual desktops and whatever. I mean, I don't use it aside from playing games, so there's not much opportunity for me to complain about it.

Back to this, sticking to the APIs is a start. It's all they can do. Take a look into what graphics driver software does on Windows, with workarounds for different games. Ours do that too, for example Mesa has game specific workarounds.

I'm not a programmer (and no specialist in any discipline, more of a technician with boots on the ground), and I can't tell you exactly what's wrong with all those games, or all the games that can't work at all, and this is going to seem like reversing the logic here, but how about all those games that just work out of the box on day zero? They didn't write them with Wine translation in mind at all. We can translate proper use of most APIs used by games, and specific workarounds, for whatever reason, ("cleverness" or differences between theory and reality) really could be considered part of the mechanism.

Forgetting about translation for a sec, those that write good, bog standard code that sticks to the APIs have their games and applications working years, even decades later. Use the correct APIs on Windows, and Microsoft will try to make sure that your software keeps running. They'll give you have assloads of backwards compatibility dependencies in WinSxS.

I wrote a few Python programs once upon a time, which makes up most of my programming experience. Yes, adhering to the APIs is the only thing they can really do right now. I suppose if there's a crash, they should check to make sure the introduced code for the latest build is complying with their chosen APIs in the best way possible and rebuild it. It benefits Windows and other platforms supported through WINE simultaneously, after all.

From what I've seen, which is admittedly not much, games that work through WINE on day zero with no testing tend to be smaller indie games, and/or use Vulkan, so there's less complexity in translation. For example, it is extremely unsurprising that >90% of visual novels work out of the box through WINE and have for years (save for some cutscenes because of the video codec) if they aren't encumbered by DRM (and have SHIFT-JIS for the games that need it). They're very simple games.

But if your use of the Windows APIs (and whatever other APIs) is standard, it's very likely been tested extensively with WINE, so support for it is good. I agree with you that developers should stick to standards when possible, and that it should mean it works flawlessly through WINE (if not, it's a problem with the re-implementation and not a game-specific workaround, which is a productive bugfix).

I think that I have to correct that native Linux games always work on popular Linux distributions like Ubuntu, Suse, and so on. Games couldn't work on the more exotic distributions.

When a company stops creating patches for the Linux version, users start having problems with some games. We upgrade our Linux distributions more frequently than Windows users. It's an impossible task for some companies to create patches for more than a few years.

It's a good idea to keep the old version of the Linux distribution. In my case, it looks like this with some examples:

Mandrake 7.2 - Exile 3, Würstelstand
Suse 9.3 - Mohaa, Raptor, Reel Deal Slots
Suse 10.1 - Universal boxing manager, Odyssey By Car, Nuts & Scrap
PCLinuxOS 2010 - Runesoft, LGP, Loki
Ubuntu 22.04 - current games

I noticed that Grid Autosport doesn't run on Ubuntu 22.04. I will install something from 2016 because there is a difference between Linux in 2016 and 2023.

What a terrible operating system!

I can force to run some old games like Shogo on Ubuntu 22.04. It's better than Mac when Apple doesn't allow you to run the old games.

The current state of native games is very different from 2004 when I started to use Linux.

I have low expectations about Linux. I appreciate every hour that companies spend porting games to Linux. Linux can compete with Mac, but it will never be a replacement for Windows.

Apple made horrible decisions with 32-bit applications, Nvidia drivers, and unrepairable computers. Linux users don't have to deal with these issues.

The biggest issue with Proton is that Windows is cheap. It will always work better than Proton. I don't see any reason to waste time with Proton if a perfect solution exists. I can tell you that as a former Cedega subscriber, I tried to use it for a few months.

From a historical perspective, you can't use the technology created by Microsoft to compete with Windows.
IBM failed with OS/2, and it's hard to point out the emulator that will be better than the original solution.

For example, BSD has Linuxulator, and it's just a nice tidbit. It doesn't change anything.

Linux distributions would be a disaster if Linus decided to create them to emulate Unix applications.

In 2023, we don't have the Linux distribution that will allow us to install only applications for Windows. In this case, I think about open source (Chrome, LibreOffice) and commercial applications (Microsoft Office, Photoshop). This Linux distribution doesn't allow to install Linux packages like rpms, debs, flaptaks etc.

Nobody talks about it, and I think this distribution could sort out this constant argument: Native vs. Wine.

I worry that the current state of native games for Linux is temporary. We can spend money to support the right companies or waste them on games only for Windows.

Look at ArcaOS, Haiku, AmigaOS/ MorphOS, and the current availability of commercial games for these operating systems. The previous generation of users had their chance and threw it away. They can only dream about games from Steam, GOG, HIB, etc.

Last edited by gbudny on 16 Jun 2023 at 1:38 pm UTC

I don’t think Chrome is open source.

I don’t think Chrome is open source.

You are right.

Thanks for correcting it.

It's a Freeware application based on open source components.

I don’t think Chrome is open source.

"Google Chrome" itself isn't, but the underlying browser engine is of course. We also refer to the back end as Chrome also though. (I do, and actually have done so today already)

For whatever good that will do you. It's not like it's a user friendly community, it's pretty Google dictatorial and the ever changing build environment can be onerous, or it used to be when I was doing it. It's also a monstrous code base, and someone inclined to customize it would have to get to know it. I used to build Chromium for my browser, but I've discovered in my years that the only good thing about masochism is that it feels good when you stop doing it. I prefer to work with Firefox again anyway now.

So yeah, it's open source.

I think the "no tux, no bucks" movement was the right things to do at the times. "Native" was not the concept it is today and wrapped in an emulator windows exe counted as native. If I remember correctly, most of the Linux version of the humble indie bundle that really launched Linux as a gaming platform were done this way (I may be wrong).

I still things the reaction to The Witcher 2 eon port was the right call. Oh, I strictly condemn the excess that turn CD Projekt which was one of its few proponent with GoG wrapping old game in wine into a durable enemy of Linux but the community couldn't stay silent when a game was released at 2FPS on high end PC. Windows gamers were doing the same with the console port that wasn't playable.

Proton did a lots of goods to Linux gaming. Still Vulkan, no middleware and engine that cross compile would be the best solution. As engine gets more and more complete, there is fewer and fewer middleware so we gets to it. DirectX still exist through and remain a danger for Linux gaming. I'm pretty sure that there is a guy at Microsoft whose job is to see what change could be done to DirectX that Proton would not be able to emulate.

P.S: I did not watch the video cause I'm a zealot that block youtube :p

I still things the reaction to The Witcher 2 eon port was the right call. Oh, I strictly condemn the excess that turn CD Projekt which was one of its few proponent with GoG wrapping old game in wine into a durable enemy of Linux but the community couldn't stay silent when a game was released at 2FPS on high end PC. Windows gamers were doing the same with the console port that wasn't playable.

I bought Witcher 2 in 2012 and played it on Windows 7 back then. I'd pretty much mostly given up on Linux gaming, as most of the porting had stopped since the good old Icculus days.

In 2014 I tried it on Linux and it was worse than on Windows, I think I recall having to cut a few things down to Medium. I got through it though... I think I had Radeon HD 5870 still back then, using Mesa.

Later, with greater graphics hardware I played it again and it was OK, still felt kind of crappy as those are problems you can't even solve by throwing hardware at it (eON was pretty poor). I mean, specifically, a more powerful CPU is going to wait for i/o just like a lesser one when the problem is wasted clock cycles.

The only problem I ever recall having was it crashing at an impassable point once. I tried it several times. It didn't crash after a reboot (driver in bad state, IPC resource stuck, hardware register bits wrong... who knows) and I don't recall having any problems with it aside from lackluster performance again.

I'm getting the gumption to see that game again, I couldn't say if the Linux port even still works. I think I'll go straight to trying it with Proton first when I get around to it though.

Last edited by Grogan on 17 Jun 2023 at 3:43 am UTC

I think the Linux gaming landscape just changed massively over the years due to Valve's involvement in various pieces of software. Also Vulkan happened. Imagine a world where we'd still be stuck with OpenGL on Linux...

Today, I feel, translation layers are just another tool enabling a game on Linux, for those "stuck" with engines that have second-class Linux support (which sadly seems the case for most engines). This of course still demands some commitment from a game's developer. Skipping games that lack such commitment is a totally valid "no tux, no bux" move in my book.

In the end, a native version means nothing, when support is lacking. And this isn't even a Linux problem, go and take a look at some older Windows native games running (or rather not) on a modern Windows machine.

I've yet to have a smooth experience with Wine and Proton. So when I say I'm not interested, I just want to click and play...every time I hit up a LAN or LUG meeting and ppl try to sell me on using Wine and Proton they educate me all on this extra work they had to do to get the game to work and/or sell me on accepting a compromise that I'm just not going to do.

I'm glad proton and Steam exist for others to take advantage and game as they see fit but it's not for me.

I want offline, launcher free & drm-free games so that I click & play without issue. If those games go bye bye then I just stay with what I got and that's it. Even with emulation, if it's not get emulator + get rom = play....I don't mess with it. It is lazy? Maybe but I'm not going to give someone money then fuss with something that may or may not work.

Perhaps my gaming diet is just different, I still play games from the 90's because when my friends gather we can get in and keep it moving without issue. So outside of fighting games (and I get to play those for free at locals on the console or arcade units in house), I don't look forward towards any game per se like that so I'm probably not the demographic for the industry at all.

There are only 4 gaming platforms: Win, PS, XB, Switch

I would add that android and iOS deserve a mention in this list. I'm finding myself playing more and more Playstore and apk games from the community as time passes. I have adult children that know my taste very well and they often either buy me the game or family pass me a copy on Google and so far the games they sent me have been hits for SP gaming while traveling and MP with them from time to time.

As a developer, I will say it can be worthwhile to keep a linux port running even if you choose not to release it. Memory bugs that don't cause a problem most of the time under windows can crash more often under linux. By porting to multiple systems it can make the program more stable. Also since you have all the system specific code isolated (or at least you should), it can be easier to port to other systems.

I'm building my game on Linux because it's the environment I'm most familiar with nowadays. (10 years ago it was Mac, but that's a different story.) I do test the Windows build using Wine, but there are some minor bugs that would drive me insane if I had to deal with them every moment of every day. I don't think players would notice though... Also, I won't make bets on if the native or Wine version will have fewer issues 10 or 15 years from now.

As a player, Proton is amazing! I started transitioning my workflow from Mac about a year before Proton was really a thing. I had tinkered with Wine a bit, but I'm honestly not much of a tinkerer. Like as a dev I enjoy making my own "engines" and even the occasional assembly code, but as a user, I just want something that works. It's why I used to dev on Mac, and why I found Ubuntu so inviting when I started switching. Everything basically worked out of the box, and I already treated the Mac like a "Unix machine with a nice GUI". In contrast, I was contracting on a couple XBone/PS4 games at the time and ended up making a Win10 machine for it. It was awful. I had more problems with Windows 10, and Windows Update constantly breaking things than the rest of my 30 years of computing combined. I hadn't run desktop Linux since the Gnome 2.x days and figured I'd give it a try again, and found it to be perfectly comfortable. Proton sealed my Macs' fate. Even when it was experimental it was so much better than gaming in Apple land. I built a new tower to replace my retina iMac, and bought a System76 laptop to replace my MacBook Air. That's my story.

What do you think?

Native Linux games are ideal. But I am very happy to use Proton as long as it works. Game developers should only have to build their product one time. I'm just happy to be able to play games on Linux. It's crazy how far Linux has come. Viva La Linux!