Support us on Patreon
PayPalTechland continue to improve their 2015 game, Dying Light. Another patch went out this week and it's a nice one for Linux owners of Dying Light too.
For some people, an issue that has plagued Dying Light on Linux is a crash when using the Drop Attack ability. Techland said with Patch 1.22, that's actually been finally fixed. Additionally they said the overall stability of the game has been improved.
Testing it again today, Drop Attack as expected works nicely:
Pictured: Just landing a Drop Attack in the Linux version of Dying Light.
I never saw an issue with it before, but good to see their official fix for those who did see it hasn't caused any other problems in my testing.
A Borderless Window Option is also supposed to be in there, but it seems that's missing from the Linux build, which I've let them know about today. Would be great to see that added in, odd it's not there.
Dying Light is currently on sale with 66% off across Humble Store and Steam.
Curiously, Dying Light 2 which is due next year is still listing Linux in the platforms list as you can see on SteamDB. That was added 6 months ago and they haven't removed it, so that plus them still updating the Linux version of the original is hopefully a good sign.
Article taken from GamingOnLinux.com.
Linux native version of Dying Light runs well with AMD Mesa, even with a Radeon VII. Doesn't need a special build of libGL.so.1. Any recent Mesa version, say 19.x should be fine. The performance last time I tried was actually pretty good, not at all the horror show it has been. Definitely playable with a good experience. DXVK still performs better and the Windows version has additional graphics options.
I played the native version on an AMD card back when the 17.x series just managed to get it working. Since then there's been ups and downs with the Mesa versions but today it should be fine. The black screen bug happens for Nvidia users as well as in Windows too, not Mesa specific.
The granary bug is also not related to Mesa. Unfortunately The Following has only 3 quests from which you can start again, it's basically start, middle and end.
I strongly recommend backing up saves for any game where you really care about the progress. Even if the game itself behaves, Steam cloud can bork saves now and again. Not specific to Dying Light.
Quoting: dpanterUh... this thread is derailing into false information territory.
Linux native version of Dying Light runs well with AMD Mesa, even with a Radeon VII. Doesn't need a special build of libGL.so.1. Any recent Mesa version, say 19.x should be fine. The performance last time I tried was actually pretty good, not at all the horror show it has been. Definitely playable with a good experience. DXVK still performs better and the Windows version has additional graphics options.
I played the native version on an AMD card back when the 17.x series just managed to get it working. Since then there's been ups and downs with the Mesa versions but today it should be fine. The black screen bug happens for Nvidia users as well as in Windows too, not Mesa specific.
The granary bug is also not related to Mesa. Unfortunately The Following has only 3 quests from which you can start again, it's basically start, middle and end.
I strongly recommend backing up saves for any game where you really care about the progress. Even if the game itself behaves, Steam cloud can bork saves now and again. Not specific to Dying Light.
I thought that the needed fixes for EXT_direct_state_access was to be in v20.x and not v19?! Without it and if your version of mesa is compiled with glvnd the game sefaults (that is the fix in the special build of libGl that it removes glvnd).
And yes I know that the granary is not due to mesa, it's not even Linux-specific since there are reports from PS4 players crashing there.
For any one interested in why DL segfaulted here on mesa:
QuoteFirst, some background. The game uses __GLEW_EXT_direct_state_access to detect whether the EXT_direct_state_access OpenGL extension is available. In experimental mode (glewExperimental=GL_TRUE), GLEW implements those macros by calling glXGetProcAddress() for every function that an extension is supposed to provide. If the driver returns non-NULL for every function in that set, then the macro evaluates to true. And if the macro evaluates to true, then the game will use EXT_direct_state_access functions such as glMapNamedBufferRangeEXT.
Mesa does not implement EXT_direct_state_access, and returns NULL when its functions are queried with GetProcAddress(). GLVND, however, provides stubs for all OpenGL functions, and returns the stub in glXGetProcAddress(). The stub will eventually end up calling out to the vendor's (Mesa's) implementation of the function when a context is created and the vendor becomes known. The upshot of this is that glvnd will return a stub for every function in EXT_direct_state_access, leading the GLEW macro to return true, and the game will attempt to use those extension functions.
The trouble begins when the game tries to use glMapNamedBufferRangeEXT(). This function is supposed to return a pointer to a memory area that maps to an OpenGL buffer. Since Mesa does not implement EXT_direct_state_access, the GLVND stub for glMapNamedBufferRangeEXT remains a no-op, and the return value is undefined. The game tries to write to the pointer that is returned (which of course is not valid as the function was a no-op), and it segfaults.
See more from me