Quoting: dreamer_It is impossible to write browser extensions for it due to technologies used.

Are you trying to do something complex? Because this simple extension [External Link] (shows Proton rating in Steam store) works just fine...

Quoting: dreamer_ProtonDB decided to do a pretty stupid thing and store Steam System Information in a cookie file (ok) and basically never invalidate it (not ok). In the result, we get a disproportionate view on driver versions and likely other information in there as well.

Well, this is a strange thing, yes. And a lot of tracking is also disturbing...

View this comment - View article - View full comments

Quoting: ShmerlAnd regarding DRM - it's not actually hard for Valve to start offering DRM-free options, like other stores do. They just don't see it as important.

Just for information – it is possible to publish a DRM-free game on Steam. For example, Space Rangers HD: A War Apart [External Link] (a very good game, by the way) is DRM-free, as stated in a special notification - “Incorporates 3rd-party DRM: DRM Free!”. Even if this option is not well-advertised, it is still possible…

View this comment - View article - View full comments

Quoting: 14Were the older games a little over the top like this? This trailer made me think of Far Cry 5 or other games that extort culture.

The actual game might be different. On Youtube, under the trailer Brian Fargo wrote "Enjoy the video all and don’t be fooled by happy Scotchmo, the game is brutal and dark. We like the sarcastic juxtaposition."

View this comment - View article - View full comments

So, do I understand correctly that we need a 418.52.05-beta driver, and those on 418.56 need to wait a bit despite having a higher version number? Maybe it's good to mention this in the article...

Quoting: Pikolo

Quoting: GuestGood to see this re-release of DXVK 1.1, thanks :-) As a user of mesa-git on Arch I will benefit directly from this new version. But I wonder if Proton will integrate DXVK 1.1.1 then soon as well, I do hope so.

I doubt it. Proton won't see DXVK 1.1.1 until VK_EXT_host_query_reset makes it into an LTS branch of Nvidia drivers. I think Steam OS doesn't use Nvidia's beta drivers, and that's what they'll be synchronising the release of this feature with

Isn't 418 branch an LTS one? 418.56 (x86_64) is mention here [External Link] as both "Current official release" and "Current long-lived branch release".

View this comment - View article - View full comments

Well, some evasive bugs here. Both Steam and GOG versions works for me. Don’t know why.

P. S. Interesting – Steam and GOG share saves and settings between each other. Most likely from .local/share/Paradox Interactive/Imperator.

P. P. S. I don’t have a paradox account, so no login in in launcher and multiplayer not tested. Well, it unlikely to influence anything…

View this comment - View article - View full comments

Played yesterday for 2 or 3 hours. Launcher works, no problems at all with the game.

Specs: Linux Mint 19.1, AMD FX-6300 Six-Core, GTX 1070, 418 driver, Steam version.

Also have a GOG version, I think I’ll try it in the evening...

View this comment - View article - View full comments

Quoting: etonbears

Quoting: Purple Library Guy

Beginnings of a Vulkan backend for WineD3D.

I'm confused about just what this represents and how it interacts with or complements or duplicates DXVK and certain sister projects to DXVK.

It is complicated, but I'll tell you what I believe is true, though this requires some detail ( sorry! ).

The Wine Project contains a native OS library, called "winelib", that implements the lowest level layer of pure 'C' language Windows APIs that is generally known as WIN32. If you have the source code for an WIN32 application, you can compile directly against this "winelib" implementation, resulting in an entirely native binary that you can run directly on your OS.

Wine also provides a "virtual Windows" environment if, as is more usual, you do not have the source code. This environment knows how to read Windows-formatted executables/libraries, and load them into memory to run as if they are native-format for your OS. It also knows how to slectively combine Windows-formatted executables/libraries with the winelib implementation of any WIN32 function calls the executables/libraries make.

This "mixed mode" of Windows-format executable code, combined with the native winelib implementation of WIN32 is enabled by using a Wine virtual filesystem, better known as the "Wine Prefix".

If you look at "C:\windows\*" in your Wine Prefix ( the default location is "~/.wine/" under Linux ) you will see directories full of the same filenames you normally see on windows. But if you look carefully, you will note that all of the libraries ( C:\windows\system32\*.dll, for example ) are tiny files, and all the same size. This is becaus they do not contain any implementation, they are just entry points to winelib; these entry points are what wine refers to as "builtin" versions of windows libraries.

If you use wine to run a Windows-format executable, it uses these tiny "builtin" dlls to invoke the implementation in winelib. But what if you have problems, and the winelib implementation of a windows library does not work well with your Windows application? Well, you CAN try to replace the offending winelib library, by just overwriting the version in the Wine Prefix with one copied from a Windows installation, then run the "winecfg" command to tell wine you have replaced the builtin library. If you are lucky, it solves your problem. If you are unlucky, the problem gets worse, or you end up replacing half of your Wine Prefix trying to work out which combination of dlls works best.

Now, why did I go into that detail? The reason is that this is the mechanism by which DXVK is implemented. Wine does not actually contain a working implementation of D3D10 or D3D11 in winelib. The "correct" way to fix this would be to join the Wine project, learn all about the existing winelib code-base and coding practices, then design and implement a harmonious, bug-free, maintainable implementation of D3D10/11 within winelib. What Philip Rebohle decided to do was create a replacement for the set of DLLs that normally provide D3D10/11 in Windows, using Vulkan to implement the D3D features, then you simply drop these DLLs into a Wine Prefix, use winecfg to indicate you are overriding the builtin implementation for these DLLs, and magically your game works.

I can completely understand why Philip did it this way, as it means he does not impact the Wine Project at all, does not nead to learn how to be part of it, and can just get on with making DXVK work in a development environment he is comfortable with.

However, there is a problem with this. While 4 of the 5 DLLs DXVK replaces are stand-alone and independent, DXGI.DLL is not. DXVK will allow you to run D3D10 and D3D11 games, but breaks games using WineD3D, which also implements DXGI.DLL. This is why the Wine developer was trying to coordinate DXGI use with Philip Rebohle.

I'm sure this will get sorted out eventually.

One of the best explanation I've heard. Thanks!

View this comment - View article - View full comments

If anyone interested – it’s a game from the creator of Eador: Genesis [External Link].

View this comment - View article - View full comments