God of War is now on Steam and runs out of the box on Linux with Proton

Nice! I would buy it on Steam if I hadn't it for my Playstation 5 already. And sometimes I have to say, no tweaking at all and just enjoying is something nice, especially with this very nice game.

Oh boy, another developer that can't be arsed to support Linux, but will still benefit financially from open source software picking up their slack. Whoopee.

Where did they ask you to buy the game? You're throwing your money into their pockets like you've got no choice. Clearly you don't care about a Linux port so why should the developers?

I agree! The Open source community gets abused all the time. I've worked for so many companies that relied heavily on open source software, and when I'd ask them to donate even $100.00 a year to the developers they would look at me like I'm crazy...

It's no abuse when someone uses code as granted by a license. You may personally think that it's objectionable, but it's simply their right.

Good example of the bull:
https://opensource.org/blog/the-intriguing-implications-of-sfc-v-vizio#:~:text=The%20suit%20alleges%20that%20Vizio,its%20source%20code%20publicly%20available.

Yes, that's abusing the open source community, since it's a clear license violation. But this is a different case because the developer never intended to comply with the license.

Excellent! one more game in the list, for stuttering better to have patience some corrections will come out soon, when I bought Cyberpunk 2077 it was unplayable, now I play it with high settings on Nvidia 1060 6gb without stuttering and without correction... (Proton GE and Experimental)

Really ? I was holding back to play Cyberpunk 2077 (and Horizon Zero Dawn, which I haven't buy yet) on my 1070, because of reports indicating very poor performances...

I may be able to give it a try then

so getting between 80-135 fps ultra 1440p. proton experimental (5950x 6900xt).
there are frame drops at times but generally in changing cut scenes rather than in the action. definitely playable - looks great.

so getting between 80-135 fps ultra 1440p. proton experimental (5950x 6900xt).
there are frame drops at times but generally in changing cut scenes rather than in the action. definitely playable - looks great.

I got strutters during cut scenes on PS5, too. Probably the game loads some stuff in the background.

Manjaro KDE (Testing), i7-8700K, 5700XT, 1440p, it's running pretty damned well. I only got to play the game a little on the PS4 because the kids Bogart the system.

Article updated to note Proton-GE and DXVK_ASYNC, which does improve performance a lot.

Article updated to note Proton-GE and DXVK_ASYNC, which does improve performance a lot.

I think this is only temporary needed. Once Steams shader cache is somewhat fill and gets distributed, it should also be fine for other new players.

Oh boy, another developer that can't be arsed to support Linux, but will still benefit financially from open source software picking up their slack. Whoopee.

Where did they ask you to buy the game?

Oh, whoops, I thought making the game available for purchase on a digital game store meant they meant they wanted people to purchase it. My bad, I clearly misinterpreted their actions. They put the game up on Steam because they wanted people to.. uhhh.. re-evaluate their understanding of renaissance art, or something.

You're throwing your money into their pockets like you've got no choice. Clearly you don't care about a Linux port so why should the developers?

I'm not sure where you got the idea that I'm throwing money into this developer's pockets, but I can assure you that I'm not. No Tux, no bux; as the saying goes. I want developers to support Linux gamers, not just profit from them.

so getting between 80-135 fps ultra 1440p. proton experimental (5950x 6900xt).
there are frame drops at times but generally in changing cut scenes rather than in the action. definitely playable - looks great.

Getting only fps in the low forties @high 1440p, proton experimental (rtx2080).

so getting between 80-135 fps ultra 1440p. proton experimental (5950x 6900xt).
there are frame drops at times but generally in changing cut scenes rather than in the action. definitely playable - looks great.

Getting only fps in the low forties @high 1440p, proton experimental (rtx2080).

seems a bit low? is it an nvidia issue?

The sound issues in games are not really due to Pulse but down to WINE (hence why they also had to implement a PIPEWIRE_LATENCY env variable) or rather that it's still not clear exactly how the Windows sound system handles buffers, the wine wiki points to this bug https://bugs.winehq.org/show_bug.cgi?id=39814 as reference as "known bug in wine for sound issues" and reading it gives me the impression that games asks for a specific sized buffer but then tries to overwrite it before its consumed in full so there are bugs (in that they don't follow the written spec for the API) in lots of games that the Windows audio system somehow have workarounds for.

That may be true for wine in some cases. However, you should also note that pulseaudio had stuttering and delay issues even for applications that are not wine (for example, Kodi and VLC). I remember when pulseaudio first replaced alsa - there was problems in just about everything after.

In any case while pulseaudio worked for the most part and did improve in many areas - pipewire is far superior in many aspects.

For example, pulse would often struggle with some bluetooth codecs and may have sound issues with bluetooth, where as pipewire works perfectly with aptX codecs (no tweaking, out the box) and all other BT codecs so now my sennheiser momentum 3s can happily play along using the aptx codec without doing workarounds.

It also solves the jack latency issues and random issues where pulseaudio would get confused with too many sinks and you'd have to kill pulseaudio and restart it to make it work again etc.

In any case, you're better off with pipewire at this point.

I hated PA when it first came out, and I still hold a grudge to it now for all the trouble it caused me over the years

With that said I've experienced issues with pipewire too for example sometimes when playing audio at 96kHz/24bit or above it could "pop" occasionally - but then resume playing normally (no need to reboot it or reset it like pulse ) although that issue seems to have been solved as I haven't noticed it lately.

Long story short, neither system is perfect. But pipewire is better.

Just my 2p

Do note that there are plenty of bug reports of VLC stuttering with ALSA as well so there is no guarantee that those specific problems are down to Pulse. Pipewire is better yes, but that does still not mean that it will magically solve problems that wasn't due to Pulse, it's just that the bad state of ALSA (yes ALSA) when Pulse became widespread gave Pulse a bad reputation and now everyone blames every single problem on Pulse which leads to the real source of those issues not being fixed.

Started preloading it before launch. Wasn't even worried. Can always play it on my duppy windows POS if I needed to. Getting amazing frame rates. So happy about this!!

Do note that there are plenty of bug reports of VLC stuttering with ALSA as well so there is no guarantee that those specific problems are down to Pulse. Pipewire is better yes, but that does still not mean that it will magically solve problems that wasn't due to Pulse, it's just that the bad state of ALSA (yes ALSA) when Pulse became widespread gave Pulse a bad reputation and now everyone blames every single problem on Pulse which leads to the real source of those issues not being fixed.

One advantage of pipewire as well is that it replaces ALSA/JACK as well - providing an interface that applications can understand while at the same time using a much needed overhaul of the codebase.

Previously with pulse it simply had ALSA/Jack running through it - instead of replacing the interface. This is often what caused the latency in the first place as it added an additional step of using multiple audio systems which got in the way.

Meanwhile with pipewire it simply replaces pulse, alsa and jack all at once with it's own interfaces, while they are still technically alsa and jack they are much more refined (think of it like only getting the bits you need, instead of everything). This is why the latency issues are mostly resolved because you are no longer having to run multiple audio systems to get sound, it's just the one (a system with pipewire properly installed doesn't need to have alsa/jack installed, pipewire handles this directly).

This also makes the codebase far easier to maintain - application has broken sound? Well we've only got to check pipewire's code for the problem, instead of trying to determine if it's in alsa, pulse or jack and then trying to contact those developers etc.

I'm not claiming it will magically solve everything, I'm simply saying it may be worth trying it on pipewire as it may (or may not) fix the issue - as whether you like pulseaudio or not you cannot deny all the issues it caused over the years and pipewire has solved many of them.

Give it a try, you might be surprised at just how well it works. No need to argue over this though, you're welcome to stay with pulseaudio and never install pipewire if you prefer and I will use pipewire as it meets my requirements better than pulse - that's the beauty of FOSS, we can set our systems as we need them.


Last edited by BlackBloodRum on 16 January 2022 at 5:30 am UTC

Runs pretty bad with nvidia 1070, so refunded it for now.

Oh, sad, I am on a 1070TI@1440p - that may be not enough for good gameplay :-(

Give it a go.. I am running perfect on my GTX 1060. No issues at all. Got many settings to ultra proton experimental.

Runs pretty bad with nvidia 1070, so refunded it for now.

Oh, sad, I am on a 1070TI@1440p - that may be not enough for good gameplay :-(

Give it a go.. I am running perfect on my GTX 1060. No issues at all. Got many settings to ultra proton experimental.

How did you install the game though ? I am trying to install it using GameHub (because I had pre-ordered the GOG version), but the installation fails somehow. Are there any specific steps / options to do beforehand ?

Do note that there are plenty of bug reports of VLC stuttering with ALSA as well so there is no guarantee that those specific problems are down to Pulse. Pipewire is better yes, but that does still not mean that it will magically solve problems that wasn't due to Pulse, it's just that the bad state of ALSA (yes ALSA) when Pulse became widespread gave Pulse a bad reputation and now everyone blames every single problem on Pulse which leads to the real source of those issues not being fixed.

One advantage of pipewire as well is that it replaces ALSA/JACK as well - providing an interface that applications can understand while at the same time using a much needed overhaul of the codebase.

Previously with pulse it simply had ALSA/Jack running through it - instead of replacing the interface. This is often what caused the latency in the first place as it added an additional step of using multiple audio systems which got in the way.

Meanwhile with pipewire it simply replaces pulse, alsa and jack all at once with it's own interfaces, while they are still technically alsa and jack they are much more refined (think of it like only getting the bits you need, instead of everything). This is why the latency issues are mostly resolved because you are no longer having to run multiple audio systems to get sound, it's just the one (a system with pipewire properly installed doesn't need to have alsa/jack installed, pipewire handles this directly).

This also makes the codebase far easier to maintain - application has broken sound? Well we've only got to check pipewire's code for the problem, instead of trying to determine if it's in alsa, pulse or jack and then trying to contact those developers etc.

I'm not claiming it will magically solve everything, I'm simply saying it may be worth trying it on pipewire as it may (or may not) fix the issue - as whether you like pulseaudio or not you cannot deny all the issues it caused over the years and pipewire has solved many of them.

Give it a try, you might be surprised at just how well it works. No need to argue over this though, you're welcome to stay with pulseaudio and never install pipewire if you prefer and I will use pipewire as it meets my requirements better than pulse - that's the beauty of FOSS, we can set our systems as we need them.

I can second that: switching to Pipewire removed all hassles I previously had with my external audio card. No more messed up outputs, no more fiddling with Catia, outputs are recognised perfectly, and I no longer have problem with Jack server not starting properly once in a while (messing up all settings in applications such as Discord and Skype every time).

Do note that there are plenty of bug reports of VLC stuttering with ALSA as well so there is no guarantee that those specific problems are down to Pulse. Pipewire is better yes, but that does still not mean that it will magically solve problems that wasn't due to Pulse, it's just that the bad state of ALSA (yes ALSA) when Pulse became widespread gave Pulse a bad reputation and now everyone blames every single problem on Pulse which leads to the real source of those issues not being fixed.

One advantage of pipewire as well is that it replaces ALSA/JACK as well - providing an interface that applications can understand while at the same time using a much needed overhaul of the codebase.

Previously with pulse it simply had ALSA/Jack running through it - instead of replacing the interface. This is often what caused the latency in the first place as it added an additional step of using multiple audio systems which got in the way.

Meanwhile with pipewire it simply replaces pulse, alsa and jack all at once with it's own interfaces, while they are still technically alsa and jack they are much more refined (think of it like only getting the bits you need, instead of everything). This is why the latency issues are mostly resolved because you are no longer having to run multiple audio systems to get sound, it's just the one (a system with pipewire properly installed doesn't need to have alsa/jack installed, pipewire handles this directly).

This also makes the codebase far easier to maintain - application has broken sound? Well we've only got to check pipewire's code for the problem, instead of trying to determine if it's in alsa, pulse or jack and then trying to contact those developers etc.

I'm not claiming it will magically solve everything, I'm simply saying it may be worth trying it on pipewire as it may (or may not) fix the issue - as whether you like pulseaudio or not you cannot deny all the issues it caused over the years and pipewire has solved many of them.

Give it a try, you might be surprised at just how well it works. No need to argue over this though, you're welcome to stay with pulseaudio and never install pipewire if you prefer and I will use pipewire as it meets my requirements better than pulse - that's the beauty of FOSS, we can set our systems as we need them.

Well a problem here is that this is only half true, yes Pipe replaces pulse and jack but no it does not change anything in regards to ALSA. Note that the solution in WINE to reduce the stutters is to use PULSE_LATENCY_MSEC=60, the default is 5.5ms so what WINE has to do is to increase the buffer size and hence increase the latency in order to keep up.

Pulse never had "ALSO/Jack running through it", Pulse uses ALSA for the output just like Pipe does, there is zero changes here. The main difference between the two is that Pipe doesn't use the rewind feature in ALSA while Pulse is built around it and rewind is apparently rewind is still semibroken in most ALSA drivers.

So you still have to check both the client, Pipewire and ALSA when problems occur just like you would with Pulse, zero differences in that regard. Pipe just replaces Pulse on a 1:1 regard for 99% of all setups (aka the ones that don't also run jack).

The introduced latency is due to pulse giving clients a buffered interface so that they don't have to worry about realtime scheduling in order to keep up with feeding the audio system data, pipe changes nothing in this regard either.

There is no denying that Pipe is better than Pulse in many regards, but it's not a panacea. The problems with sound dropouts and latency in games lies often elsewhere, switching between Pipe and Pulse will simply stir in the pot of random that will solve it for game X but create new problems with game Y. Or if we are lucky then the WINE driver for Pipe will simply be better written than the driver for Pulse and Pipe will take the credit, such is life sometimes.

Really great news.

As far as the game itself goes, I stopped playing it a month or more ago (came with PS Plus). I'd say it was pretty much a good game, and I am sure a lot of people will love it, but I wasn't into it. The game is half walking around, looking at scenery, and listening to annoying dialogue. The back-and-forth of the main dude and his son is filled will long silences and single-word answers. It is just annoying to be a witness. And that's what I felt like more than anything: someone tagging along and watching (as opposed to playing). While the scenery is incredible at times, there wasn't enough actual action and gameplay for me. I also couldn't get past the idea of who he used to be based on older games in the series, and now dealing with this character who does not make you feel cool to be at all. I put it down deciding that if I wanted a story, I wanted a different one -- an actual RPG or, really, a good book. God of War didn't have enough game for me.

Oh, whoops, I thought making the game available for purchase on a digital game store meant they meant they wanted people to purchase it. My bad, I clearly misinterpreted their actions. They put the game up on Steam because they wanted people to.. uhhh.. re-evaluate their understanding of renaissance art, or something.

Well, yes. They are selling their game on Steam™ (a store) for Windows® (an operating system). And they are quite open about it. It is literary (well, more like graphically) depicted on the store page. And they never made any attempts to enforce their Windows-game onto Linux users.

You're throwing your money into their pockets like you've got no choice. Clearly you don't care about a Linux port so why should the developers?

I'm not sure where you got the idea that I'm throwing money into this developer's pockets, but I can assure you that I'm not. No Tux, no bux; as the saying goes. I want developers to support Linux gamers, not just profit from them.

You both are right in a way. I don't know why are you arguing.
The developers never intended to sell their game to Linus users. And yes, they will benefit financially from both "Linux gamers" and Open Source technologies. Thanks to Valve propagating Proton™ technology (taking advantage from WINE project), "Linux gamers'" willfulness to pay for a Windows game and one Linux gaming news site author/admin giving the game a spotlight; please note however, he wrote one can buy the game on Steam and Humble Store, not one ought to do so.

P.S. In order to sweeten the medicine I want to remind everyone that a game is not all about code or OS'es. A game is a multimedia product composed of: sound, script, voice acting, level design, visual assets and so on. And most of those have nothing to do with code or Win32 API, so most of the price paid for a Windows game actually goes for artists' work, not OS compatibility.

P.P.S. I personally will never purchase this game. Not even if it goes Linux-native-freeware. Not my cup of vodka.

P.P.P.S. I also do not drink vodka. :)