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.

Quoting: WorMzyNative 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 June 2023 at 11:37 am UTC

Quoting: Liam Dawe

Quoting: WorMzyNative 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 June 2023 at 4:00 am UTC

Quoting: GroganYes, 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.

Quoting: GroganI 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.

Quoting: pleasereadthemanualWhat 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 June 2023 at 5:27 am UTC

Quoting: GroganWell, 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.

QuoteBack 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 June 2023 at 1:38 pm UTC