Join us on our own very special Reddit: /r/Linuxers

The first Steam Play update for this year is out with Proton 3.16-7 beta

By - | Views: 27,958

Valve have pushed out a Steam Play beta update with Proton 3.16-7 now available for testing. Lots of fixes!

Not quite the huge upgrade many were expecting, most people thought Valve would be pushing ahead with a major update of Wine but this release still seems like a very nice update overall

Firstly, they've updated DXVK to 0.96 and FAudio to 19.02. This should hopefully mean quite a number of games will see improvements and begin working. Additionally, there has been some controller improvements, with Unity specifically mentioned for games like Subnautica and INSIDE.

As for bug fixes and other changes, here's what they improved:

  • Fix for fullscreen behavior in Into The Breach.
  • Fix for crashes in some d3d9 games on Mesa.
  • Fix for crash when launching certain games, including Path of Exile, the Bloons series, and the Naruto Shippuden series.
  • Fix for games with special characters in paths, including LEGO Harry Potter.
  • Restore previous functionality of the Uplay client.
  • New runtime option for old games that can't handle modern GL extension strings. Set PROTON_OLD_GL_STRING to limit the extension string length.
  • New runtime option to disable d3d10 support, PROTON_NO_D3D10.
  • Better support for games that use very old steamworks SDKs, including Lost Planet.
  • Fixed various problems with the build system, and added a new top-level Makefile to make simple builds much easier.

You can see the changelog here. Looks like it's going to be a fun weekend of testing ahead!

If you're having issues updating, you can select Proton from Steam's tools menu found when you hover over "LIBRARY" -> "TOOLS" and search for "Proton" then install "Proton 3.16 Beta". Seems many people have had issues with it not updating properly.

After some fresh testing, with a forced Proton update I can confirm Into the Breach fullscreen now works as expected—hooray!

Article taken from GamingOnLinux.com.
36 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
54 comments
Page: «5/6»
  Go to:

etonbears 17 Feb, 2019
Quoting: Comandante ÑoñardoSniper Ghost Warrior 3 via PROTON 3.16-7..


Is that the amount of system RAM used or the amount GPU memory used?

I don't know for certain, but I would expect it to be the GPU allocation, since that is what DXVK is most interested in. CPU allocation is less important since the OS can provide virtual memory.
Purple Library Guy 17 Feb, 2019
Quoting: 14I don't enjoy having a 50 GB game backup eating up disk space.
50 . . . gigs. For one game. I've had hard drives way smaller than that. I've had adventure games I plugged away at for hours and never finished that were 16K. OK, I didn't finish them mostly because they were badly designed, but still. What is the excuse for a game taking up 50 gigs?
Sorry, my old curmudgeon is showing, but really . . . 50. gigs.
kuhpunkt 17 Feb, 2019
Quoting: Purple Library Guy
Quoting: 14I don't enjoy having a 50 GB game backup eating up disk space.
50 . . . gigs. For one game. I've had hard drives way smaller than that. I've had adventure games I plugged away at for hours and never finished that were 16K. OK, I didn't finish them mostly because they were badly designed, but still. What is the excuse for a game taking up 50 gigs?
Sorry, my old curmudgeon is showing, but really . . . 50. gigs.

The new DOOM is 71 GB, Project Cars 2 is 52 GB, Deus Ex Mankind Divided is 60 GB. Those are the biggest games I have installed at the moment :D
tuxintuxedo 17 Feb, 2019
I have been using the 3.16.6 version with Banished. I always had to kill it manually after exit, because it wouldn't stop and slowed down the system significantly. Now with the 3.16.7 version it exits without problems and slowdowns, but the gameplay itself became sluggish. They don't want me to get bored.
wvstolzing 17 Feb, 2019
Quoting: kuhpunkt
Quoting: Purple Library Guy
Quoting: 14I don't enjoy having a 50 GB game backup eating up disk space.
50 . . . gigs. For one game. I've had hard drives way smaller than that. I've had adventure games I plugged away at for hours and never finished that were 16K. OK, I didn't finish them mostly because they were badly designed, but still. What is the excuse for a game taking up 50 gigs?
Sorry, my old curmudgeon is showing, but really . . . 50. gigs.

The new DOOM is 71 GB, Project Cars 2 is 52 GB, Deus Ex Mankind Divided is 60 GB. Those are the biggest games I have installed at the moment :D

Doom's ridiculous size is probably due to the multiplayer & level editor, which they haven't been arsed to move to a separate install.

I think GTA5 is also in the ~70G range.
etonbears 18 Feb, 2019
Quoting: Purple Library Guy
Quoting: 14I don't enjoy having a 50 GB game backup eating up disk space.
50 . . . gigs. For one game. I've had hard drives way smaller than that. I've had adventure games I plugged away at for hours and never finished that were 16K. OK, I didn't finish them mostly because they were badly designed, but still. What is the excuse for a game taking up 50 gigs?
Sorry, my old curmudgeon is showing, but really . . . 50. gigs.

Some games are impressively large, aren't they? I can't speak for the detail of why any particular game is the size it is, but I can give you some indications as to why.

The first thing to understand is that games are always trying to do more than the hardware computational ability will allow. A lot of developer time is spent in finding ways to get a higher quality or accuracy, but with the same or lower computational cost at runtime. Almost all of these techniques boil down to pre-computing "stuff" and storing it in data files ( usually image-like texture files ). Then, at runtime, the game just fetches the pre-computed values using a simple algorithm rather than using expensive calculations every frame.

If you compare games of, say, 15 years ago with today, the largest textures have increased in size from 512x512 to 4096x4096, which is 64 times the number of data locations per texture.

A typical character model 15 years ago may have used textures with fewer than 10 data values per location, most of which would be 1 byte each. A modern game renderer could easily need 10 times as much data.

Pre-calculation to data files is also used for non-character models ( buildings and other "placeable" props ) as well as light-maps and shadow maps if circumstances allow ( typically indoor environments with mostly static lighting ); in fact, whatever the ingenuity of games developers can come up with.

This explosion of texture data has partly been offset by better compression algorithms. GPUs implement the read of compressed data in hardware, so it does not cost much processing power.

Alongside this, the geometry data describing the shape of models has increased in like fashion, animation based on curve calculations has been replaced by data-intensive motion-capture, and there are now often multiple copies of everything at different quality levels to cater for the broader range of modern player hardware.

This is a generalization and simplification, but I'm sure you get the gist of it. Modern games without lots of immersive 3D models are much smaller, on the whole.
Comandante Ñoñardo 18 Feb, 2019
Quoting: etonbears
Quoting: Comandante ÑoñardoSniper Ghost Warrior 3 via PROTON 3.16-7..


Is that the amount of system RAM used or the amount GPU memory used?

I don't know for certain, but I would expect it to be the GPU allocation, since that is what DXVK is most interested in. CPU allocation is less important since the OS can provide virtual memory.

If it is the GPU memory used, that can explain the FPS drops, because my GTX 970 has 3.5GB....
14 18 Feb, 2019
View PC info
  • Supporter Plus
Quoting: etonbears
Quoting: Purple Library Guy
Quoting: 14I don't enjoy having a 50 GB game backup eating up disk space.
50 . . . gigs. For one game. I've had hard drives way smaller than that. I've had adventure games I plugged away at for hours and never finished that were 16K. OK, I didn't finish them mostly because they were badly designed, but still. What is the excuse for a game taking up 50 gigs?
Sorry, my old curmudgeon is showing, but really . . . 50. gigs.

Some games are impressively large, aren't they? I can't speak for the detail of why any particular game is the size it is, but I can give you some indications as to why.

The first thing to understand is that games are always trying to do more than the hardware computational ability will allow. A lot of developer time is spent in finding ways to get a higher quality or accuracy, but with the same or lower computational cost at runtime. Almost all of these techniques boil down to pre-computing "stuff" and storing it in data files ( usually image-like texture files ). Then, at runtime, the game just fetches the pre-computed values using a simple algorithm rather than using expensive calculations every frame.

If you compare games of, say, 15 years ago with today, the largest textures have increased in size from 512x512 to 4096x4096, which is 64 times the number of data locations per texture.

A typical character model 15 years ago may have used textures with fewer than 10 data values per location, most of which would be 1 byte each. A modern game renderer could easily need 10 times as much data.

Pre-calculation to data files is also used for non-character models ( buildings and other "placeable" props ) as well as light-maps and shadow maps if circumstances allow ( typically indoor environments with mostly static lighting ); in fact, whatever the ingenuity of games developers can come up with.

This explosion of texture data has partly been offset by better compression algorithms. GPUs implement the read of compressed data in hardware, so it does not cost much processing power.

Alongside this, the geometry data describing the shape of models has increased in like fashion, animation based on curve calculations has been replaced by data-intensive motion-capture, and there are now often multiple copies of everything at different quality levels to cater for the broader range of modern player hardware.

This is a generalization and simplification, but I'm sure you get the gist of it. Modern games without lots of immersive 3D models are much smaller, on the whole.
In the case of Divinity: Original Sin 2, another factor might be uncompressed or very little audio compression. There is a lot of voiced dialogue. I'm just guessing here, but that's what came to my mind first.
etonbears 18 Feb, 2019
Quoting: 14
Quoting: etonbears
Quoting: Purple Library Guy
Quoting: 14I don't enjoy having a 50 GB game backup eating up disk space.
50 . . . gigs. For one game. I've had hard drives way smaller than that. I've had adventure games I plugged away at for hours and never finished that were 16K. OK, I didn't finish them mostly because they were badly designed, but still. What is the excuse for a game taking up 50 gigs?
Sorry, my old curmudgeon is showing, but really . . . 50. gigs.

Some games are impressively large, aren't they? I can't speak for the detail of why any particular game is the size it is, but I can give you some indications as to why.

The first thing to understand is that games are always trying to do more than the hardware computational ability will allow. A lot of developer time is spent in finding ways to get a higher quality or accuracy, but with the same or lower computational cost at runtime. Almost all of these techniques boil down to pre-computing "stuff" and storing it in data files ( usually image-like texture files ). Then, at runtime, the game just fetches the pre-computed values using a simple algorithm rather than using expensive calculations every frame.

If you compare games of, say, 15 years ago with today, the largest textures have increased in size from 512x512 to 4096x4096, which is 64 times the number of data locations per texture.

A typical character model 15 years ago may have used textures with fewer than 10 data values per location, most of which would be 1 byte each. A modern game renderer could easily need 10 times as much data.

Pre-calculation to data files is also used for non-character models ( buildings and other "placeable" props ) as well as light-maps and shadow maps if circumstances allow ( typically indoor environments with mostly static lighting ); in fact, whatever the ingenuity of games developers can come up with.

This explosion of texture data has partly been offset by better compression algorithms. GPUs implement the read of compressed data in hardware, so it does not cost much processing power.

Alongside this, the geometry data describing the shape of models has increased in like fashion, animation based on curve calculations has been replaced by data-intensive motion-capture, and there are now often multiple copies of everything at different quality levels to cater for the broader range of modern player hardware.

This is a generalization and simplification, but I'm sure you get the gist of it. Modern games without lots of immersive 3D models are much smaller, on the whole.
In the case of Divinity: Original Sin 2, another factor might be uncompressed or very little audio compression. There is a lot of voiced dialogue. I'm just guessing here, but that's what came to my mind first.

Could be; what takes the space is very game dependent, but textures are usually the culprit for really big new games. With Bethesda games, for example, original Skyrim was 6GB with an optional 4.5GB high-resolution texture pack, whereas Fallout 4 is 28GB with an optionl high-resolution texture pack of 58GB for a whopping total of 86GB. There is quite a lot of audio in Fallout 4, but it clearly doesn't contribute much to the overall size.
neowiz73 19 Feb, 2019
looks like Kenshi 1.0.13 experimental version works fine now. if anyone is interested in that. :)
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.
Livestreams & Videos
Community Livestreams
Latest Forum Posts