Latest Comments by Shmerl
Wine 2.9 released with support for Direct3D tessellation shaders
26 May 2017 at 9:33 pm UTC
26 May 2017 at 9:33 pm UTC
Quoting: CyrilI've heard the Linux version is broken anyway (that's why GOG didn't accept it), so not a big deal I suppose.Quoting: Comandante ÑoñardoJust for curiousity. Can the DRMFREE version of Metro Redux run with this?Such a shame that the Linux version isn't on GOG... (Like many others too)
Wine 2.9 released with support for Direct3D tessellation shaders
26 May 2017 at 5:10 pm UTC Likes: 3
26 May 2017 at 5:10 pm UTC Likes: 3
Feel free to try. I didn't buy it yet. Even TW3 I was reluctant to buy, because of how CDPR failed to port it, but someone gave me a spare GOG key, so I could test it in Wine.
Thinking of it, I actually prefer that if the game isn't really native, that it should use open wrappers (like winelib), rather than closed ones (eON, Feral's, etc). In this sense, CDPR could partner with CodeWeavers, and sponsor their DX11 development efforts, then at least they wouldn't be breaking their promises.
Thinking of it, I actually prefer that if the game isn't really native, that it should use open wrappers (like winelib), rather than closed ones (eON, Feral's, etc). In this sense, CDPR could partner with CodeWeavers, and sponsor their DX11 development efforts, then at least they wouldn't be breaking their promises.
Wine 2.9 released with support for Direct3D tessellation shaders
26 May 2017 at 3:10 pm UTC Likes: 2
26 May 2017 at 3:10 pm UTC Likes: 2
Not sure about others, but I've heard Skyrim runs very well already. At least the classic one (was there a remaster)? I'm not keeping track of Bethesda games. The last good TES game was Morrowind, and for that we have OpenMW. :)
Regarding general progress, DX11 is pretty big, so I guess it might take a while before it all will be implemented. But still, some games can work well even before that. TW3 is a good test case, because it's using really a lot of DX11 features and quite heavy ones.
Regarding general progress, DX11 is pretty big, so I guess it might take a while before it all will be implemented. But still, some games can work well even before that. TW3 is a good test case, because it's using really a lot of DX11 features and quite heavy ones.
Wine 2.9 released with support for Direct3D tessellation shaders
26 May 2017 at 8:53 am UTC Likes: 5
By the way, to run the game you either need Wine staging, or apply at least these two patches to regular Wine:
* https://github.com/wine-compholio/wine-staging/blob/master/patches/ntdll-Grow_Virtual_Heap/0001-ntdll-Remove-memory-limitation-to-32GB-on-64-bit-by-.patch [External Link]
* https://github.com/wine-compholio/wine-staging/blob/master/patches/wined3d-buffer_create/0001-wined3d-Do-not-pin-large-buffers.patch [External Link]
Without the first it simply crashes, and without second it runs at around 1 - 5fps.
26 May 2017 at 8:53 am UTC Likes: 5
Quoting: LeflWell Shmerl has a decent computer, but 43 FPS in a AAA Game in Wine that is using DX11(?).That's on max settings (except for hairworks and ambient occlusion). On min settings I get 50-60fps (1920x1200). And that's with RX480. Vega probably will allow playing it at 60fps proper even on max settings (since it looks GPU bound here).
Quoting: liamdaweHe's using an AMD card with the open source driver, while Mesa has come a long way, there's tons of performance improvements left to do. Not only that, but you have to remember this is being run in Wine and Wine is not even remotely finished itself.Yes indeed, I hope Mesa and Wine will still improve further.
By the way, to run the game you either need Wine staging, or apply at least these two patches to regular Wine:
* https://github.com/wine-compholio/wine-staging/blob/master/patches/ntdll-Grow_Virtual_Heap/0001-ntdll-Remove-memory-limitation-to-32GB-on-64-bit-by-.patch [External Link]
* https://github.com/wine-compholio/wine-staging/blob/master/patches/wined3d-buffer_create/0001-wined3d-Do-not-pin-large-buffers.patch [External Link]
Without the first it simply crashes, and without second it runs at around 1 - 5fps.
Planet Nomads officially lands into Early Access
26 May 2017 at 4:59 am UTC
26 May 2017 at 4:59 am UTC
@Areso: I suppose it's not. But Unity with OpenGL really isn't optimized for heavy graphics.
Planet Nomads officially lands into Early Access
26 May 2017 at 2:35 am UTC Likes: 1
26 May 2017 at 2:35 am UTC Likes: 1
Quoting: ZeloxLike you say, the game isnt running that great atm.Yeah performance is abysmal for me with anything but lowest settings (RX480). Looks like it's using Unity 5.4.2f2, so it's OpenGL only (no Vulkan yet). Hopefully they'll switch to Vulkan at some point (for which they need Unity 5.6).
And I was hoping for a better frame rate at release.
SteamOS updated, Valve drops AMDGPU-PRO for Mesa
24 May 2017 at 1:49 am UTC
One of the libraries that's affected by this is Mesa-DRI. Example:
Note how it depends on libstdc++. And it's an important part of the graphics stack.
GNU C++ ABI guarantees (mostly) forward compatibility. I.e. if you are using application built against older libstdc++, dynamic linking with new one will work. But, there is no backwards compatibility. If you are using something built against newer libstdc++, and it dynamically links against older one, stuff can go haywire.
And that what happens, if in Steam runtime (or any other such bundle) you have a stale libstdc++, the game links against that, and then system library like Mesa-DRM links against newer one, and in result both envs are mixed, and something ends up calling stuff from new and from old in a sequence that causes a segfault (consider for example allocating memory with new one, and then deallocating with old one or any other such scenario).
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html [External Link]
24 May 2017 at 1:49 am UTC
Quoting: sr_ls_boyWhile they're at it, they could update the copy ofthe std c++ liblibstd++ should not be bundled in the runtime, it's an abysmally bad idea (unless you make sure all linking is limited to exactly the same version, like for example using static linking).
in their runtime.
One of the libraries that's affected by this is Mesa-DRI. Example:
ldd /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
...
libLLVM-3.9.so.1 => /usr/lib/x86_64-linux-gnu/libLLVM-3.9.so.1 (0x00007f4a0c254000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4a0bed0000)
...Note how it depends on libstdc++. And it's an important part of the graphics stack.
GNU C++ ABI guarantees (mostly) forward compatibility. I.e. if you are using application built against older libstdc++, dynamic linking with new one will work. But, there is no backwards compatibility. If you are using something built against newer libstdc++, and it dynamically links against older one, stuff can go haywire.
And that what happens, if in Steam runtime (or any other such bundle) you have a stale libstdc++, the game links against that, and then system library like Mesa-DRM links against newer one, and in result both envs are mixed, and something ends up calling stuff from new and from old in a sequence that causes a segfault (consider for example allocating memory with new one, and then deallocating with old one or any other such scenario).
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html [External Link]
Versioning gives subsequent releases of library binaries the ability to add new symbols and add functionality, all the while retaining compatibility with the previous releases in the series. Thus, program binaries linked with the initial release of a library binary will still run correctly if the library binary is replaced by carefully-managed subsequent library binaries. This is called forward compatibility.
The reverse (backwards compatibility) is not true. It is not possible to take program binaries linked with the latest version of a library binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible.
Feral have released the Linux requirements to run Shogun 2 with NVIDIA, AMD & Intel supported
21 May 2017 at 4:45 pm UTC Likes: 1
21 May 2017 at 4:45 pm UTC Likes: 1
If it's not related to deals with partners which they can't discuss, usually those reasons are related to the fact that they exclude some people ;) I personally don't see anything wrong with admitting that fact though.
Feral have released the Linux requirements to run Shogun 2 with NVIDIA, AMD & Intel supported
21 May 2017 at 4:20 pm UTC Likes: 1
21 May 2017 at 4:20 pm UTC Likes: 1
Explained, but not satisfactory IMHO. Feral are probably reading this thread, and if it's something as simple as provided guesses, they can confirm or correct them.
Feral have released the Linux requirements to run Shogun 2 with NVIDIA, AMD & Intel supported
21 May 2017 at 3:30 pm UTC
21 May 2017 at 3:30 pm UTC
Quoting: liamdaweIf Feral do port a game that is on both Steam and GOG I'm sure the Linux version will get on GOG too. I wouls hope so at least.Yes, it's something I implicitly expect too. So it's not about "why Feral's Linux version isn't on GOG while Windows one is", but about their preference of porting Steam only games.
- The "video game preservation service" Myrient is shutting down in March
- Discord delay global rollout of age verification to improve transparency and add more options
- Steam Next Fest - February 2026 is live with tons of demos
- Firefox 148.0 arrives with AI controls
- FINAL FANTASY VII arrives on GOG with a new edition live on Steam too
- > See more over 30 days here
- steam overlay performance monitor - issues
- Xpander - Nacon under financial troubles... no new WRC game (?)
- Xpander - Establishing root of ownership for Steam account
- Nonjuffo - Total Noob general questions about gaming and squeezing every oun…
- GustyGhost - Looking for Linux MMORPG sandbox players (Open Source–friendly …
- Jarmer - See more posts
How to setup OpenMW for modern Morrowind on Linux / SteamOS and Steam Deck
How to install Hollow Knight: Silksong mods on Linux, SteamOS and Steam Deck