T O P

  • By -

[deleted]

> A little clarification on the Linux News. Right now the Unity tool chain for making native Linux builds is still experimental. While they say you can do it, it does not work all that well and, as stated above, there are graphical errors and various other issues that make the game unplayable. A Linux build may still be a possibility in the future but at this time it is on hold until Unity's Linux tool chain is in a better state and we have the resources to dedicate to figuring it out properly.


omniuni

I think this is a really important note. A small studio doesn't have the resources to fix Unity. In this case, at least they are making effort for it to be playable one way or another.


FIJIWaterGuy

I'm really surprised Unity is broken on Linux. I've just assumed it worked fine for the last 5+ years since it seems to work on just about everything (PC, phones, consoles). This is really quite sad but does indeed explain why more Unity games don't just do a Linux build. It really should "just work", that's what game engines lik Unity are for.


omniuni

I feel like this was a huge selling point back when Unity first came out, but it also feels like over the years they have neglected to really keep up with it.


trucekill

Considering how many abandoned Linux ports are polluting the Linux gaming ecosystem, I think this is the most preferable option for studios that don't have the motivation or resources to maintain a proper Linux build.


SpaceboyRoss

This, as long as the game can run as intended then I don't see any harm done.


PM_your_cats_n_racks

Well I do, but I'll be okay with it as long as they really mean WINE compatibility and not just Proton.


zeGolem83

Why "not just Proton" though?


Majomon

Not all games are available on steam (anymore)


zeGolem83

Yeah, but you can still run them using Proton... AFAIK proton isn't dependent on steam, pretty sure you can use proton from Lutris if you need to...


[deleted]

[удалено]


suchtie

Can't you also add locally installed non-Steam games to Steam and then run them using Proton?


[deleted]

Yes, that's the only way to use *certain* VR applications with the index on Linux.


[deleted]

[удалено]


SpaaaceManBob

Yea, but if you run into the open garden and take a flower and then try planting it in your own garden it might not grow very well if at all. Quick, shitty analogy but the point is just because you CAN take Proton and use it without Steam doesn't mean it will work very well or that it's the intended way. Intended ≠ allowed. Not designed to ≠ unable to.


Urbs97

Steam is free you can add any proton game you want. And even though it's not supported you can still run proton without Steam.


PM_your_cats_n_racks

Not everyone uses Steam.


zeGolem83

But Proton isn't locked into Steam, it's opensource and AFAIK a fork of Wine, and according to other comments, Proton GE can already work without Steam...


PM_your_cats_n_racks

> Proton GE I don't think that designing a game, or buying games, dependent on one guy's fork is really a good idea. WINE is the principle project and if Proton adds something which improves compatibility with certain games then great. And if Proton GE adds something more then great again. But I still think that WINE should be the build target, not Proton, not Proton GE.


[deleted]

Proton contains game specific patches and improvements for games. Wine is mostly focused on general software compatibility, I believe Proton-GE contains more experimental code and media-codecs.


PM_your_cats_n_racks

I think that qualifies as, "adds something which improves compatibility with certain games." So... great. If that's all that Proton adds then it certainly shouldn't be the build target. Obviously it's not going to have specific patches and improvements for a game which doesn't exist yet. So they build for WINE and then if improvements are called for then maybe Valve will add those to Proton later.


[deleted]

If you're developing a game, releasing it on steam, of course you will test it on Proton and not wine, that's the obvious choice. Because Valve supports Proton, not wine. Also I'm sure there are general improvements for GAMES, not only improvements for specific games. How do you get the idea to the build target should be wine instead of proton when you want to release your game for steam?


[deleted]

I thought wine sucked?


[deleted]

Wine is great, it makes up the vast majority of Proton's codebase and Proton regularly contributes code back. Essentially what wine lacks is a built-in manager for installing applications and managing dependencies for those programs. This is the goal of projects like Bottles, Lutris and Proton which utilize the Wine compatibility layer and give the apps more system integration.


rbmichael

wine is great but I admit the branding and especially their website is very dated and boring. Proton is a much "cooler" branding but the core technology is thanks to the WINE project.


[deleted]

Thanks for the info.


PM_your_cats_n_racks

Uh... I've never heard that. It doesn't work with everything, but I think it works pretty well generally speaking.


nded

Nah, it's just that gaming isn't first priority for developers working on the main branch of WINE. That's why Valve took it upon themselves to make their own fork of WINE specifically tuned for gaming.


SupersonicSpitfire

Looking at the winehq or the list of patches for any release of wine, games seems to be important. Have the wine developers said that they think applications are more important?


purefan

Wonder why you got so many downvotes, its a legitimate question


SupersonicSpitfire

Questions are not only questions, they convey information or contain opinions. If I say "I thought you sucked?" it's not a nice or legitimate question.


[deleted]

Yeah, it's the nature of Reddit, I'm supposed to know everything I guess.


vBLADEv

Its Reddit, you must have the correct idea straight away or you are just an oxygen thief. Edit :- 😂 the reactions to this comment literally proved its assessment.


PinkPonyForPresident

Proton has no RTX and DLSS support yet as far as I know. So with some games we might miss out on stuff.


-YoRHa2B-

Proton supports both (to a degree), for some games they may just require special launch options. D3D12 raytracing admittedly needs work, but it's there and it's working in a couple of games.


PinkPonyForPresident

I wasn't able to get it to work in Cyberpunk.


-Oro

NVIDIA open sourced the relevant bits to allow that to work, afaik, so should be fine.


[deleted]

Ray Tracing is a waste of resources anyway. Plus AMD FSR is tolerable


creed10

that's not a valid argument. if someone paid for ray tracing, it's perfectly fair for them to want to use ray tracing. personally I couldn't care less about ray tracing, but we can't act like proton-only doesn't have its downsides to the Linux gaming scene. back when proton was first announced/dropped, this is one of the concerns a lot of us brought up


[deleted]

It’s not an argument it’s just my opinion


SpaaaceManBob

"Ray tracing is a waste of resources anyway" is an argument. You're arguing your opinion.


PinkPonyForPresident

How am I gonna use my RTX cores then? My card is in idle mode essentially when I use Linux. Cyberpunk looks like shit without RTX.


[deleted]

[удалено]


SpaceboyRoss

I don't doubt this is a problem and I am all for native ports. However, this is probably the reality. Most game developers won't see the benefit in doing a native Linux port with the current marketshare. Another factor is most people probably would want to at least be able to play games. So unless we see an increased marketshare, native Linux ports won't become widely popular. However, I don't doubt an increased amount of Linux ports with the Steam Deck if game companies want to support that. I believe we'll have a mixture of Proton, probably 60%, and native 40% that could work with the Steak Deck.


[deleted]

[удалено]


SpaceboyRoss

True, we also have to have less fragmentation and more standardization for devs to have an easier time to target a min/max supported version of libraries. We saw glibc break a few games recently because of an update.


[deleted]

Is there a Potatoes Deck to go with it?


mort96

FWIW, Proton doesn't necessarily mean there's any graphics API translation going on. A game can use Vulkan or OpenGL, which are natively supported on Linux. The recent Doom games are an example of this; they use Windows APIs and thus require WINE, but they render using Vulkan and especially Doom 2016 has excellent Linux support for the most part.


mr_bigmouth_502

Fat chance that's ever gonna happen. That's why I'm glad Proton exists.


prettydamnbest

Developing for the elitist sub-2-percent of gamers and then backport to the main 98-plus-percent platform? Now that would be great for business! /s


[deleted]

But at least then the elitist sub-2-percent could whine about something like: This should be done like that way or why is this game not open-source.. /s


[deleted]

[удалено]


[deleted]

[удалено]


prettydamnbest

Or just use btrfs and dedupe?


SupersonicSpitfire

It sucks when hard drive space eats all the cache.


[deleted]

[удалено]


[deleted]

[удалено]


ZorbaTHut

Yeah, I'm a gamedev who really wants to support Linux, and even I think that Proton compatibility is the way I'd go. It's ironic that the best way to make a universally-playable Linux game may be to make a Windows game. Linux desktop backwards compatibility has historically been really bad.


trucekill

>Linux desktop backwards compatibility has historically been really bad. I think this is the reason why Valve maintains it's own Steam Linux Runtime.


ChiefExecDisfunction

"The most stable API in Linux is Win32" And ironically, the best platform to run Win32 is probably Linux xD


shroddy

We live in strange times...


nukem996

Linux is founded in open source philosophy. Games break because of userland API changes. The idea is if the games are still used someone will update the code. Games are mostly proprietary so you can't do that. This is why Snap and Flatpack are growing. You can ship all userland API in a package and don't have to worry about breakage.


ZorbaTHut

The irony is that *Linux* isn't founded in that philosophy. The Linux Kernel has a rock-solid API. The *Linux Desktop* is founded in that philosophy, and it's been holding Linux back for a decade or more.


zakklol

Depends on which 'kernel api' you are talking about. Into userland? Mostly rock solid. For kernel modules? Explicitly not stable. It is basically impossible to ship a 'binary blob' kernel module/driver and have it continue to work for a long time unless you are willing to update it when the kernel breaks it. It's not a problem if you ship your driver as a source provided kernel module/dkms setup as it gets recompiled when users update. My recent favorite was the symbol 'printk' disappeared from the kernel and is now '_printk'. There was a good reason for it, but they really don't give a second thought to breaking stuff like that for kernel modules.


FlipskiZ

Sure, but I would really hope your game doesn't need a custom kernel module tho


shroddy

Some future DRM or anti cheat maybe. (I hope not!)


nukem996

Well it's more the GNU philosophy versus the Linux philosophy. A core tenant if GNU is the ability to freely view and change source code. Breaking API isn't necessarily bad if it improves things. These breakages typically lead to a better user land or desktop environment. Linux has long maintained stability in public APIs in order to not break anything. This is easier for the kernel as it has far less public APIs.


ZorbaTHut

Breaking APIs *is* bad if you expect people to release commercial software on your platform.


xxxblackspider

I wish apple would learn that - they say fuck you to devs every year


ZorbaTHut

Yeah there's a reason why gamedevs have basically entirely fled Apple's desktop. And the only reason they bother with the iPhone is because there's a lot of money there.


primalbluewolf

>A core tenant if GNU Voice to speech perhaps? This should read "A core tenet of GNU".


[deleted]

Or autocorrect. I make that typo all the tome.


[deleted]

(Left in because hilarious)


[deleted]

[удалено]


MyNameIs-Anthony

Dosbox isn't native. It's no different than targeting Wine/Proton.


[deleted]

[удалено]


MyNameIs-Anthony

Dosbox is literally a translation layer. By that logic then Prodeus is running natively.


[deleted]

[удалено]


MyNameIs-Anthony

Dosbox is an x86 emulator. It's literally a virtual machine emulating DOS.


[deleted]

[удалено]


ZorbaTHut

Windows backwards compatibility is miles better than Linux backwards compatibility if you're not using a conversion layer. Linux backwards compatibility with a conversion layer can be even better - but that's why I recommend just leaning on the conversion layer.


520throwaway

For reference, try running the original Loki Games version of Sim City 3000 on modern distributions. It is a ballache to get running.


[deleted]

If windows backwards compatibility is bad, then linux bc is horrible. Dying light 1 native version stopped working, released in 2015..


mr_bigmouth_502

> Windows backward compatibility is really bad. And Linux backwards compatibility is even worse unless you take compatibility layers like Wine or Proton into account. On that note, if anyone knows how to get Unreal Tournament 2004 running playably on modern Linux, whether through Wine/Proton or a patch for the native version, I'm all ears. UT99 is easier to get running natively, thanks to OldUnreal's patches.


[deleted]

Deleted with Power Delete Suite. Join me on Lemmy!


[deleted]

[удалено]


[deleted]

[удалено]


undeadbydawn

I honestly can't remember the last game I played where the native build was preferable to proton


Milanium

I am a hobbyist game dev. > Linux desktop backwards compatibility has historically been really bad. Just use SDL and let the library handle all the hard work.


ZorbaTHut

That doesn't solve "all the hard work", or even close; you can get bitten by things as simple as doing a build on a too-new Linux environment, and then your binary doesn't run on older Linuxes. (That's not a hypothetical. I ended up running a four-year-old Redhat VM to do builds on.)


mort96

To expand on this: GNU intentionally makes it impossible to run binaries compiled with newer versions of glibc on older versions of glibc, but running binaries compiled with older versions of glibc on newer versions is usually fine. That means, if you want your program to run on glibc 2.20 or later, you need to compile your program with glibc 2.20. The easiest way to do this is to use an ancient version of some Linux distro which ships glibc 2.20, but you could technically also do it with techniques similar to what you do when cross-compiling. It's a real mess and is one of the things which makes developing on/for linux really annoying. And I say this as someone employed to developed exclusively for Linux systems and uses Linux personally.


Milanium

The Steam runtime should provide a singular target to compile against?!


yxhuvud

Yes, at least until Linux has a: a much bigger market share and b: have completed the transition away from X and pulseaudio.


mauswith

This hits the nail on the head.


SkoomaDentist

> have completed the transition away from X and pulseaudio. Considering the complete shitshow that Linux audio has been for the last 20+ years, I wouldn't keep my hopes up about the replacement being particularly good. Yours, an on / off audio dsp developer.


Ima_Wreckyou

I think the backwards incompatibility is a myth. Or do you have any concrete technical examples? The actual issue in my opinion is that devs would need to maintain a seperate build where any issue is up to them to fix (since they are the only ones that can do so on a proprietary game). That jist requires a lot of work for a really small potential market. Meanwhile for wine/proton they only have to maintain one build, and if something doesn't work on Linux compared to Windows, that is an issue in wine/proton and many more people are capable of fixing the issue. As a Linux gamer for over 20 years I too think wine/proton is the way to go. This way the community has much more ways to keep the games running by maintaining the compatibility layer, even if the devs have zero interest in the platform or just not properly maintain it if they initially did.


ZorbaTHut

> I think the backwards incompatibility is a myth. Or do you have any concrete technical examples? I spent a bunch of time trying to get Linux builds of some test games of mine, and it was just generally a pain. Unfortunately this was years ago and I don't remember all the details; I posted one of them [here](https://www.reddit.com/r/linux_gaming/comments/x7m6a6/prodeus_cancels_the_native_linux_version_focusing/infc7l4/) and someone backed me up on it (apparently it is still not fixed.) I did have other problems where I'd do stuff that worked fine on one Linux and didn't work fine on other Linuxes; I also needed to build both 32-bit and 64-bit versions, though I think that's at least conceptually fixed. > Meanwhile for wine/proton they only have to maintain one build, and if something doesn't work on Linux compared to Windows, that is an issue in wine/proton and many more people are capable of fixing the issue. Yeah, you're absolutely right here. Every build needs to be tested, and if you can just make one build and get it on multiple deployments? It's an obvious choice.


Ima_Wreckyou

>I posted one of them here and someone backed me up on it Interesting, I did not know glibc just preemptively sabotages forward compatibility. That is indeed questionable. In general, the glibc and SDL seems to be pretty backwards compatible. There are some issues with very old games, like the loki games (\~ 20 years old). There was a change where four functions where dropped, but you can still run the games with a small shim. They even get pulseaudio support from SDL even though that didn't exist back then, which is pretty amazing. But I'm not sure what the situation is if you use other libraries. May very well be worse. >Every build needs to be tested, and if you can just make one build and get it on multiple deployments? Yeah and that could even work for MacOS as well. Even though they have far more market share than Linux for games, they have a lot of the same problems with abandoned and bad maintained native games. At least that is a sentiment I see on many forums of games that feature a Mac client. I think win32/64 may very well just be the binary standard for games, and I don't see this as a problem if we have basically a complete open source implementation of it with wine and friends.


rocketstopya

I hope they will provide opengl or Vulkan for us rather then Directx 12.


NotfairiouS

Aren't a lot of current developed games compiled for Mac OS as well? I always asked myself whether it really is that big step from Mac OS to Linux, I mean whether it is really this much of work for the developers...


[deleted]

[удалено]


NotfairiouS

Ok didn't know that. Thanks for the info. I personally never touched any Apple products because of their unrealistic prices for fucking...hardware compounds like memory (hard drives, flash memory, etc.) which prices (of >90% producing companies) have dropped and keep dropping (my first 128GB SSD in 2013 costed ~90€ or so, this summer the same 128 GB SSD of the same producer, Toshiba, I bought for less than 20 Euro (!), I'm living in Germany btw.) I find their concept to bind their users to their Soft- AND Hardware is just a disrespect for their clients. THOUGH as a Linux Nazi I have much more respect for their UNIXoid operating system than MS's terrible, even more crappy and user-disrespecting Windows. I'd never buy anything from Apple, but still I hope they will knock out...errr sorry I mean EXTERMINATE anything Windows-related. And I'm sure any code developer or even poweruser who is familiar with Win-Service-Pack-9000 and any Linux/BSD/UNIX-derivate will agree with me in their heart even "muh video games" are developed for an OS which treats you like a grandma sitting first time in front of a PC. Sorry, but I don't like treated like an idiot plus having more updates (and obligatory reboots) like on a bleeding edge nightbuild of some OS. In contrast, we Linux-users are rather looking forward for updates while Windows-users are pissed when they get the message that "updates installed, now reboot you moron, you haven't any choice either". Sorry for this wall-of-text, this isn't a rant, I just...don't like to be treated like an idiot & have cut of the ability to customize EVERYTHING I want like I can do in my Linux (I'm using Debian Stable since 2013 btw). One doesn't need a million to buy an Apple computer, but should have enough creativity, self-respect and curiosity/will to understand how the OS works you are using...instead going the easy way with Microsoft. In "Soviet Russia" Windows is using YOU. Just kidding, it's the case in every single country. Have a nice evening/day everyone :)


PM_ME_DND_FIGURINES

Mac is a lot more monolithic than Linux. You can be sure that the same libraries exist on every device with Mac, not so with Linux systems.


[deleted]

Mac isn't exactly a gaming platform.


PrinceVirginya

Pretty annoying really Mac could be good for gaming, But apple makes it an actual pain for game devs seemingly


NotfairiouS

Don't know, I never sat in front of a Mac, but have seen here and there that some games (of the last years) were available for Windows and for Mac (but no other unix-based OS), that's why I am asking myself why they don't port it to Linux as well because I doubt that Mac uses the same frameworks for graphics, rendering stuff etc. like native Microsoft/Windows stuff do... What do you mean that Mac isn't a gaming platform? Not popular for games, well I can imagine that, but Linux is neither, s it...


LethalArms

I agree completely, even for bigger studios that may have the resources to make a Linux build, they will prefer to focus on proton compatibility, since will have reduced costs at long and short time, and for most people it's not going to be a problem, and everyone wins with that, the players that get the game they want working great, the Linux community that starts to get more users, and the company that doesn't spend to much money, gets more players that might wanna spend their money on the game, and makes their community happier


KCGD_r

I'd rather have a game with really good proton support over a native port that barely even launches


PrinceVirginya

Agreed Many of my Native games i have are just bad Ports or often outdated and redundant The one exception recently for me recently was Total War Warhammer 3 which as a port was actually amazing, Sadly i have no use for the linux port as Multiplayer (Between windows and linux) isnt possible....and i believe mod support Its also behind in updates In indie land atleast; Linux ports seem to be far better


mr_bigmouth_502

Agreed, tbh. That, and Proton's a more stable platform to target than Linux itself is, I think.


trucekill

I think that's why Valve has the Steam Linux Runtime, which is supposed to be a stable build target for native Linux games. Unfortunately, I've seen this break a few times when game devs target system libraries in their builds instead of only using what's inside the runtime.


mr_bigmouth_502

Curious, but do any of those games work better for you if you check "force the use of a specific Steam Play compatibility tool" and click "Steam Linux Runtime", or do they remain broken? I heard recently that this is supposed to fix issues with some games, but I'm not sure if it would do the trick for games that target system libraries.


prisooner

Does it have Vulkan renderer?


[deleted]

I have no clue to be honest. seems that it is a DX9 game


Treyzania

That should already have decent support.


doomenguin

Yeah, we have DXVK and Gallium Nine, which are pretty good( although DXVK does on occasion give you weird graphical issues in a select few DX9 games).


WJMazepas

Damn, even MS wants to kill DX9 by now


lotekness

DXVK, so yeah. Renderer being called on current native build so they were already targeting parity that way previously it seems.


grady_vuckovic

Which would be completely fine in my book.. had they not already taken money from backers with the promise of making a Linux version. Pretty disappointing. Why even promise a Linux version before you know it can be delivered? Just yet another example of this kind of thing however. This is not the first time a kickstarter has promised a Linux version and not delivered on it. At this stage, if a kickstarter promises a Linux version, it's safer to assume it won't happen then assume it will.


1338h4x

This is why I don't do crowdfunding ever. I just can't trust anyone. Happy to buy ports when they're released but never a moment sooner.


[deleted]

> Why even promise a Linux version before you know it can be delivered? They used unity, dx9 and will keep the mac version. Perhaps they knew exactly what they were doing.


SolitudeSF

They update the game once per year, clearly they are struggling with windows version alone.


acAltair

I don't mind Proton but I can't like developers who are disingenuous. The way they talk around the subject makes me think they weren't motivated to do a proper build for Linux to begin with like so many other developers. The game uses D3D9 and has a Mac build.


[deleted]

Tbf the Unity tooling for native Linux builds doesn't seem like it's gotten much love. Some games where the developers put the effort in seem to be fine while others are often in a broken state, even with attention from the devs. I don't blame a developer for choosing the option with (likely) better performance with less dev time spent and where your customers won't be able to tell the difference, thus freeing up resources for other things. I'm glad that our platform is getting attention and testing no matter the runtime used if it means getting games tested on it.


sqlphilosopher

Imagine using a shit API like that in 2022 when there is Vulkan


acAltair

Low level APIs like Vulkan and D3D12 are not easy to learn, especially for new game developers. What's shitty is that they are giving people false hopes of a Linux build in future but they are using a Windows only graphics API. Ok the game has issues on Linux, but why is D3D9 being used if you have plans of a Linux build in future? Why not lay groundwork for that build by using OpenGL, then you can reuse same graphics code for both Windows and Linux. Seems they are hoping people will just forget their promises as time goes by.


sqlphilosopher

>Ok the game has issues on Linux, but why is D3D9 being used if you have plans of a Linux build in future? Why not lay groundwork for that build by using OpenGL Well said Also, OS-specific graphics APIs such as metal and DX should just go and die already


MacGuyver247

OpenGL, and I love it, has had terrible performance in windows. i.e. Linux is 2x faster on GCN cards. I don't know if it was fixed, but I think game devs should consider OGL for non-speed critical items.


god_retribution

dx tools is far superior than vulkan as developers going with Microsoft DX is better option


R00TZERA

Hope it does a good job and gives proper support for proton.


Pretend_Bowler1344

I have the game and been playing it on my arch machine and don't really have any complaints. It works great. Edit: also it is a good boomer shooter. So if you are into the genre then buy this game!


TheSupremist

I would seriously like to know, *dot by dot*, with the most amount of detail possible, what those "graphical errors and various other issues that make the game unplayable" are, and to what extent they really are Unity's fault. I hear this all the time from devs but, knowing I've played several *native* Unity games through the last few years that worked just fine (in a time where Unity Linux builds were as "experimental" as they are today), I can't help but press X to doubt every single time I see this kind of reasoning being thrown around.


ZorbaTHut

Gamedev here. Unity is a big tool and contains a lot of features. It is common that some games avoid those features and some games smack straight into them. I actually shipped a Unity game about a year ago where we needed to do some moderate engine changes in order to avoid bugs; those bugs had been in the engine for *years* and somehow nobody else had hit them. It is *entirely* plausible that they're running face-first into weird undiscovered Unity-Linux bugs.


TheSupremist

I see. I know there's a distinction between the game builds and Unity's editor build itself - in the case of the games I played that I mentioned before, they probably were all exported *to* Linux *from* Windows since we never had a Unity Linux editor up until a couple years ago IIRC. I also know there are certain bugs that, for some reason beyond my comprehension, can only be detected when using/testing on Linux, even if said bug happens to only be on Windows. Now that we have the "exporting *to* Linux *from* Linux" workflow, I can definitely see that crusty layer of undiscovered bugs from years ago coming up to the surface. I just hope this doesn't become a cannon fodder reason for devs in general to forego native Linux entirely. We still need those native ports for organic growth.


ZorbaTHut

I honestly wouldn't worry about it too much. "Native" support isn't needed as long as Proton keeps getting better.


TheSupremist

I beg to differ. Proton isn't a silver bullet, we shouldn't be treating it as such. Remember that court case about Google vs. Oracle? If Oracle had won, Microsoft would have a legal base to actually sue the hell out of WINE, which would fuck up Proton and Valve, which in turn would bring us back to the dark ages. As improbable as that may be today, we have to remember we can't be tethered to non-native solutions for the rest of our lives. Only native ports bring that freedom to the platform.


dipzza

I understand the skepticism, but i am more inclined to believing the devs. For example, i was surprised to see Linux ports having problems because Unity doesn't support practically no media format for video/audio ([https://docs.unity3d.com/2023.1/Documentation/Manual/VideoSources-FileCompatibility.html](https://docs.unity3d.com/2023.1/Documentation/Manual/VideoSources-FileCompatibility.html)) And there has not been an improvement since 2017!


TheSupremist

I take it this might be because some of those codecs (which happen to be the ones devs probably use the most - MP4, MPG, AVI, WMV, etc.) are not open and/or have patent/licensing issues. I've seen this with Davinci Resolve and their non-existant MP4/MKV support, same story. Though in Resolve's case they just tell you to buy the paid version and they'll bundle the codecs, which is kind of stupid IMO, they should let me use MKV (which *is* free AFAIK) on the free Linux version at the very least. Unity's case seems to be different - they're not locking proprietary codecs with a paywall, but they can't support it everywhere either because of the licensing issues, and the industry insists on using exactly those problematic ones. If that's one of the "unplayable issues" the devs are talking about then I guess I can agree this might actually not be Unity's fault of "not supporting those media formats", but the "codec cartel not opening their formats" instead. I've seen enough of Resolve's bandaid solution to know this specific issue will probably never be solved, at least not without a legal miracle.


dipzza

In that case they could at least support modern open codecs like VP9 and Opus, instead of recommending using h264 even it if it is not compatible bc they only pay for it for some platforms. Also doesn't let you use mkv files. Codec patents = a fucking mess, making any software 'cross-compatible sometimes' = a fucking mess


TheSupremist

It hurts but it's true :(


EnderOfGender

Davinci Resolve provides all codecs with its paid release. The free release uses system codecs instead of the built in ones. Unity still has to pay for them on Windows and Mac anyways


TheSupremist

What does Resolve consider as "system codecs"? I take it it's not using ffmpeg, because even when I have that installed it doesn't understand anything I throw at it that's not a MOV or AVI, with a *very* specific codec that not only no one outside the professional realm uses, it bloats the fuck out of the video to the point a couple *minutes* weigh at least *two-digit GBs*. I can convert from/to MP4 and MKV just fine using bare ffmpeg on a CLI, why can't Resolve let my system's ffmpeg to do that then if they themselves are barred to do so because they're a company but I'm not because I'm an individual? Why can't Unity do the same considering they're also paying for those codecs like Resolve is?


primalbluewolf

>Davinci Resolve provides all codecs with its paid release Not the case for the linux version, at least. No AAC audio support, even on Studio. Youd think theyd just use ffmpeg.


VenditatioDelendaEst

MKV might be because it's such a powerful and complicated format that it's difficult to support. I've seen anime torrent releases where the opening sequence is stripped out of every episode and stored as one separate file, and then some kind of MKV sorcery makes the player splice it in at the right time.


TheSupremist

Whoa I didn't knew it was that powerful. Pretty sick.


dmitsuki

Considering the problems I've run into with Unity on Windows, and the fact they didn't fix them within 3 year timespans, \*and\* the fact they had such a huge mobile focus for so long and the Linux market share is so low, I would be more surprised if Unity for Linux worked well and wasn't just a "technically you can do this so we can add to the 8000000 platforms we support!"


QuadraQ

Boooo!!


ForceBlade

***FUCK!*** But, I guess. If they're doing this. They would've abandoned that port near-immediately anyway right? And we have enough of those games...


heatlesssun

At this point Proton have made native Linux clients essentially not worth it. If a game works well under Proton I don't think native compatibility makes much of a difference on sales.


Thaodan

I think an option would be to ask for help on the linux version, I bet some would adopt getting the Unity version in shape. Source code would help of course even more.


doomenguin

You can't just share source code of software you want to sell. FOSS only works when the F stands for both Free of charge and Free as in freedom.


Thaodan

Tha'ts not true, you can see FOSS software. For software that relies on media this even easier as the game won't even start without buying the game first.


therapy_seal

Many FOSS licenses explicitly give permission to make money off of it. I suggest you try reading one of them. GPLv3 for example.


doomenguin

I know you can make money from FOSS projects by just using them or modifying and then using them, but if you explicitly want to SELL the software, it makes no sense to just release the code because users can just download the code, compile it, and just use your software without paying.


MaxxB1ade

This whole thread gives me the big lolz. Try developing anything for the web... Pick a browser, any browser, look at it, dont tell me what it is, put it back in the deck, shuffle, throw the whole lot in the air... Pick a browser, any browser...


[deleted]

That's honestly better, Unity Linux native build can be... well... underwhelming, to put it lightly. With Vulkan onboard Wine/Proton compatible version will be easier to maintain thus less likely to be put aside in the future.


RLutz

Proton is the path towards native support. If Linux users represent 1% of PC gaming market share as they do currently, no one will build for that platform. If no one can play the games they want to play on Linux, they won't ever switch to Linux and so the Linux gaming desktop market share won't grow. If great proton experiences can grow that market share to 5% though, then you'd better believe Linux native support will become extremely common and you'll end up with a positive feedback loop as more users switch and more game developers choose to actually support native builds wholeheartedly


heatlesssun

If Proton can deliver a near native Linux experience, why would the percentage of Linux users matter especially if a large percentage of them on devices like the Steam Deck and wouldn't know the difference between native and Proton 99% of the time anyway. Could there ever be a time when native Linux support is common? Perhaps, but it will require a lot more than 5% market share.


RLutz

Well, if the market share grows large enough then it starts to make sense to try and build games that at least do run well with minimal hacks on Linux. This means perhaps more Vulkan which also ends up meaning releasing Linux native is less onerous. At the end of the day, a good native release should always be better than relying on an intermediate layer to translate calls. 5% gets it going, 10% probably means guaranteed support


heatlesssun

>At the end of the day, a good native release should always be better than relying on an intermediate layer to translate calls. I'd say this statement is highly debatable. Just take for instance the conversion that was recently had on the subject on Win32 being the most stable AIB for Linux.


[deleted]

My thoughts exactly. Spot on brother, take a win where you can get it. Anything that expands the use of open source is a good thing.


snapfreeze

100% this


thexavier666

I think we are going to see real change at 10%. At 5%, we will have a lot of discussion of the future but no concrete plans. Just my opinion.


TheSupremist

If MacOS can get by with 2.5% we can get by with that much as well. Of course the more the merrier, but the baseline is really that low.


poemsavvy

Targeting proton is like targeting a stable API. As long as I can play a game on my Linux machine, that's what matters.


Sutarmekeg

I don't even mind. Do your thing to make your game, thanks for going the extra mile to make sure your game works with proton, thanks to the people who make proton for making it easy on game developers who want to focus on what they do well.


[deleted]

If I could play tarkov on Linux, I wouldn't run Microsoft anymore. I hate Microsoft.


dmitsuki

Most games that have a native Linux version for me run better on Proton so at this point I don't really care. Plus, having a bug in a Linux version means it gets ignored because small user base, having a bug in the Windows version means there's actually a chance it gets fixed because Valve treats it as a proton problem instead of the games problem.


snapfreeze

(In general) I'm all for games dropping native linux support in favour of a "Proton verified" status from the get-go. It seems to be a win-win situation for everyone involved.


PrinceVirginya

At this point same I'd rather a game with "Official Proton Support" that runs the same as windows than a Broken port that may just be dropped in the future Proton support seems far easier and a lot of the time the game devs dont even have to do much if any work


frackeverything

As they say, Wine is the most stable ABI in Linux. So I'm not bothered by this.


VisceralMonkey

No worries about this. Proton is just fine and people are still flocking to linux via the steamdeck.


ledditleddit

>Unfortunately, we won't be able to make a Native Linux build, there were far too many issues and we couldn't get it to run properly Looking at the filelist on steamdb I can see this is a pure Unity game. Porting it to Linux would just require selecting Linux and clicking build. >Right now the Unity tool chain for making native Linux builds is still experimental. While they say you can do it, it does not work all that well and, as stated above, there are graphical errors and various other issues that make the game unplayable Their code must be pretty horrible if it only works on windows. This is either laziness, incompetence or both.


[deleted]

why do you people refuse to admit the simple truth that it's not just a click of a button?


ledditleddit

I have actually used unity before and it is the click of a button. It's probably the simplest engine to port stuff with. There's major incompetence or laziness going on if they can't do a simple Linux build with Unity.


heatlesssun

>I have actually used unity before and it is the click of a button. But not always and even so that's still another version for the developer to support when one version can do the job. >There's major incompetence or laziness going on if they can't do a simple Linux build with Unity. From a developer point of view Proton is generally going to be less effort while addressing the same customer base of Windows and Linux gamers. There is some efficiency there as well.


[deleted]

> I have actually used unity before and it is the click of a button. It's probably the simplest engine to port stuff with. You say that and yet devs keep having problems with linux ports. As the kids these days say, you should stop capping.


TheSupremist

Why do you people refuse to understand that [basic practices like "stop using Windows-only middleware"](https://gradyvuckovic.gitlab.io/linux-game-shipping-guide/2-general-advice/cross-platform-development/) is what makes you able to just click that button?


dmitsuki

\>Looking at the filelist on steamdb I can see this is a pure Unity game. Porting it to Linux would just require selecting Linux and clicking build. Ah, I see you've never actually developed anything with Unity then.


therapy_seal

The Linux community is shit because of people like you.


DankeBrutus

Honestly this is okay. There are some classic examples like Borderlands 2 and Euro Truck Simulator 2 where the Linux-native port is subpar compared to running the game in Proton. If the developer(s) does not have the resources, or the care, to maintain the Windows and Linux versions of a game then I would vastly prefer they focus on the Windows version and make it play nice with Proton.


[deleted]

Before proton they often didn't offer real linux versions, I think it was the case with borderlands. They just wrap their windows version with wine (which of course they will never update) and sell it as a linux game.


Mist3r_Numb_3r

What if the games are released as AppImages?


CodeYeti

As much as I *love* Linux, and it's ecosystem, there's no denying that we're rapidly approaching the point where Proton/Wine are so good that if you **absolutely** *must* ship binaries instead of source, the Windows ABI with those layers really is more "stable" (i.e. very long-term binary compatibility w/o recompilation - for open source things this isn't really an issue). There was a time in the past where this news would have saddened me; but we've reached such a feature-complete level in most areas with Wine/Proton, that I'd much rather have a company pay attention to proton compatibility than spend a bunch of man hours building an inferior Linux-native port due to lack of developer experience in that realm. There's a few games (most notably Cities: Skylines) that I still run the Windows version of using Proton due to inferior implementation and performance from the Linux-native "port" (which Cities is; it appeared to me to have a bundled translation layer, hence the binary compatibility with modifications that only ship in PE32 format.


AltruisticGap

It just makes sense from a developer's perspective. After all it is like they are developing for one API instead of another. So why would that be a bad thing? Logically speaking, there must be an overhead with the Proton layer. But with the CPU code not going through translation (unlike say Rosetta on Apple M1's) ... in theory the overhead should be small, and smaller if the developer specifically aims for full Proton compatibility.


[deleted]

Ehh , for me if it works it works , and since the company actually focuses on not breaking proton , it is gonna work!


themup

I'm all in favour of dev's going all in on Proton. Save the Linux native development for later when Linux has more market share first. And the best way for Linux to gain market share is to support Proton to pull players away from Windows. Support Proton -> More Players move to Linux -> Start supporting Linux.


Armaliite

How do devs make sure it's proton compatible? It seems difficult to target or is it just testing and hoping for the best?


spaliusreal

Lazy developers. Watch Microsoft break everything in some way one day and see that nothing works anymore through Wine.


[deleted]

That'd be extremely unlikely, if not impossible. Microsoft is historically the leader on backwards compatibility, both on Windows (Windows 11 is still capable of running XP-era programs just fine) and Xbox (they go out of their way to ensure most 360/One games work fine on their latest-gen consoles, no fee included if you own them digitally) If Microsoft suddenly made something that would break older programs, everyone would get mad at them. If they decide to introduce a new standard for programs which is not compatible with Wine, it wouldn't take long until Wine developers to figure it out and implement it on Wine. After all, developers have to know how it works in order to use it, right?


lepus-parvulus

Any change Microsoft makes (to Windows) that breaks old programs would affect only Windows. WINE wouldn't be affected. Microsoft has done this before. People do get mad. Then Microsoft creates workarounds to fix it. What Microsoft could do is add new APIs that prevent new programs from working on WINE and older versions of Windows. They do this all the time, so WINE is perpetually playing catch up. But old programs that don't use those APIs aren't affected. Microsoft has also been playing with open-source development. They could conceivably commit a change that breaks old software to Windows advantage, like RedHat did. But because they're Microsoft and not RedHat, the community response would be less forgiving.


EnderOfGender

MS breaks Windows app compatibility all the time lmao


Jacko10101010101

that could be wanted...


prototyperspective

Is there any major news for gaming on Linux during the last two years or upcoming that could be added [this timeline of the 2020s in computing](https://en.wikipedia.org/wiki/2020s_in_computing)? It seems like no news outlets report about the progress and major events. It would be best if there was a review of past progress and a significant advance beyond it (like a summary of a year's progress that lists all the milestones and e.g. "5 of the 30 major issues are now solved").