Techland have updated Dying Light again, Drop Attack should be fixed on Linux

N I C E

I still wonder how... or rather, who fixed it. Did Techland hire a Linux developer? :O

Oboy, here:s to hoping that they have fixed the game breaking bug for me where the game always crashed a few minutes after I reach the grainary in one of the last chapters of The Following. I had a solid 116 hours solo gameplay until that one struck.

Does Dying Light work on AMD GPUs with Mesa?

Does Dying Light work on AMD GPUs with Mesa?

It did not the last time I tried about 3-4 Months ago (Radeon VII). Just launched to a black screen. Played the Proton version afterwards, which works perfectly.


Last edited by marcus on 29 November 2019 at 7:55 pm UTC

Does anyone know if this game plays better native or using Proton?

The big news to me is the news about DL2 possibly coming to Linux because I hadn't encountered that particular bug before. (It wouldn't have now, either, since I replaced the Linux version with the SteamPlay version because the OpenGL version ran at 20-30 fps and the SP version runs 3-4 times that. It's embarrassing.)

Oboy, here:s to hoping that they have fixed the game breaking bug for me where the game always crashed a few minutes after I reach the grainary in one of the last chapters of The Following. I had a solid 116 hours solo gameplay until that one struck.

Same happens for me. Never had a single problem with the game up until this. I read somewhere someone suggesting restarting from a previous point, which I did. Now of course I have to redo all those previous missions again, which is a bit tedious. Luckily the game is a lot of fun!

Oboy, here:s to hoping that they have fixed the game breaking bug for me where the game always crashed a few minutes after I reach the grainary in one of the last chapters of The Following. I had a solid 116 hours solo gameplay until that one struck.

Same happens for me. Never had a single problem with the game up until this. I read somewhere someone suggesting restarting from a previous point, which I did. Now of course I have to redo all those previous missions again, which is a bit tedious. Luckily the game is a lot of fun!

Yeah that is the dreaded solution, problem with "restarting from a previous point" is that as far as I can see in the menu for The Following that is basically to restart from the very beginning.

Does Dying Light work on AMD GPUs with Mesa?

Does Dying Light work on AMD GPUs with Mesa?

It did not the last time I tried about 3-4 Months ago (Radeon VII). Just launched to a black screen. Played the Proton version afterwards, which works perfectly.

It does but it requires a special build of libGL.so.1 that is compiled without what it now was that Techland uses wrongly in OpenGL. See this post: https://www.gamingonlinux.com/forum/topic/2766/post_id=18057

Don't know if they fixed that problem with the latest update or not but the fix from that post above fixed it for me and many others.


Last edited by F.Ultra on 30 November 2019 at 8:49 pm UTC

Uh... 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.

Uh... 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:

First, 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.