There seems to be a problem with the new libs that arch has.
Someone said on reddit that they managed to get it working on ubuntu on amd hardware by using mesa.

I'll see if I can compile a folder with all the dependencies and write a small script to launch it without using any of the arch libs.

This will be a problem with more and more games as time moves forward.
Game devs need to start using flatpaks and bundle the game with all the required libs.

I have Dying Light: The Following Enhanced Edition on Debian 9 Stretch, with proprietary Nvidia driver. Launched it, and it started running the new Free DLC video (Axe, Revolver, etc). Then once the video finished, I went into the game, and whooped some zombies for a bit. Did that last night - All good for me.

Bought the game today and got quite embarrassed in front of my Windows Fan Boys.

It has been told that mesa 17.2 should fix the issue. I run 17.2.3 on Arch and it still exists. Someone said kernel 4.14 might help with some memory issues.

Why are the developers not interested in fixing this issue?

Quoting: kaymioBought the game today and got quite embarrassed in front of my Windows Fan Boys.

It has been told that mesa 17.2 should fix the issue. I run 17.2.3 on Arch and it still exists. Someone said kernel 4.14 might help with some memory issues.

Why are the developers not interested in fixing this issue?

First, Arch based distro is well know as game breaking distro. If you can, you can try other distro like Ubuntu - if issue still appears then it is not a distro / library bug.

Seconds, we know what Chrome Engine 6 games are broken on Mesa, this is because Mesa is buggy in someway. In Mesa 17.2 GIT we have confirmed that game work fine but after few new patches to Mesa, they broke game again. Even in stable Mesa 17.2 or new development 17.3 is still broken. Last time when I tested it on AMD with Mesa, it worked on 17.2 git but after month and few mesa git update - they broke it again.

Worth to ask Mesa developers about this Mesa regression.

Quoting: DamonLinuxPLSeconds, we know what Chrome Engine 6 games are broken on Mesa, this is because Mesa is buggy in someway.

In this case it was actually due to a known bug in the engine.

This isn't the first time I've heard about the game not running on Arch currently. Nothing to do with Mesa I think. And Techland doesn't seem interested as long as it runs on supported distributions, namely Ubuntu 14.04 or later. EDIT: All of this has been said earlier in this thread. I guess none of us actually read through the discussion very carefully.

Quoting: tuubiIn this case it was actually due to a known bug in the engine.

Nope. When two young Techland developers porting Dying Light to Linux they follow with official Khronos Specification and they create two similar branch - one for NVIDIA and second very similar for closed source AMD driver. When they porting it, Mesa was not enough fast (poor performance) and lack of many opengl extansion. So they just following with khronos and not create third branch for mesa. Now, when Mesa is able to handle Dying Light, Mesa not have all features from official khronos spec. So for Mesa 17.2 git, mesa devs prepare patches to run game (patches allow mesa to compiling shaders). It also needed to use "MESA_GL_VERSION_OVERRIDE=4.5 MESA_GLSL_VERSION_OVERRIDE=450 %command%" command. And it works for some time. After few new mesa patches, mesa devs broke it again, and it is still broken (until today).
Also calling this as game bug is misunderstanding. Even Mesa devs, sometimes ago considering adding missing features from khronos spec, but they chose to finish first more important things and in near future (maybe in next year) add missing features from khronos. So pls, don't blame game.

.

Quoting: DamonLinuxPLAnd it works for some time. After few new mesa patches, mesa devs broke it again, and it is still broken (until today).

Not sure if you meant that it should work from today onward, but it's still broken for me today (29-10-2017) on arch.

Quoting: ysblokje

Quoting: DamonLinuxPLAnd it works for some time. After few new mesa patches, mesa devs broke it again, and it is still broken (until today).

Not sure if you meant that it should work from today onward, but it's still broken for me today (29-10-2017) on arch.

No. I mean it worked few months ago, when mesa developers released patch for this and then it worked. After few patch they broke it again and still is broken. So if u trying it today it is still broken.

Quoting: DamonLinuxPL

Quoting: tuubiIn this case it was actually due to a known bug in the engine.

Nope.

Yep.

Quoting: DamonLinuxPLAlso calling this as game bug is misunderstanding.

Did you even read the link I gave you? Here's the relevant quote from the Mesa patch notes:

This fixes the long-standing problem with Dying Light where the game would produce a black screen when running under Mesa. This happened because the game's vertex shaders redeclare gl_VertexID, which is a GLSL builtin. Mesa's GLSL compiler is a little more strict than others, and would not compile them:

error: `gl_VertexID' redeclared

The allow_glsl_builtin_variable_redeclaration directive allows the shaders to compile and the game to render. The game also requires OpenGL 4.4+ (GLSL 440), but does not request it explicitly. It must be forced with an override, such as MESA_GL_VERSION_OVERRIDE=4.5 and MESA_GLSL_VERSION_OVERRIDE=450.

The game isn't perfect, and neither is its OpenGL (or GLSL) code. I can't blame Techland for not supporting a distro they never promised support for though. Also not supporting Mesa is a damn shame, but they're not the only ones.

This said, I'm currently playing through the game and having tons of fun. Too bad not everyone gets to enjoy it.

Quoting: tuubi

Quoting: DamonLinuxPL

Quoting: tuubiIn this case it was actually due to a known bug in the engine.

Nope.

Yep.

Quoting: DamonLinuxPLAlso calling this as game bug is misunderstanding.

Did you even read the link I gave you? Here's the relevant quote from the Mesa patch notes:

This fixes the long-standing problem with Dying Light where the game would produce a black screen when running under Mesa. This happened because the game's vertex shaders redeclare gl_VertexID, which is a GLSL builtin. Mesa's GLSL compiler is a little more strict than others, and would not compile them:

error: `gl_VertexID' redeclared

The allow_glsl_builtin_variable_redeclaration directive allows the shaders to compile and the game to render. The game also requires OpenGL 4.4+ (GLSL 440), but does not request it explicitly. It must be forced with an override, such as MESA_GL_VERSION_OVERRIDE=4.5 and MESA_GLSL_VERSION_OVERRIDE=450.

The game isn't perfect, and neither is its OpenGL (or GLSL) code. I can't blame Techland for not supporting a distro they never promised support for though. Also not supporting Mesa is a damn shame, but they're not the only ones.

This said, I'm currently playing through the game and having tons of fun. Too bad not everyone gets to enjoy it.

Can you help me with this one? I'm not sure how do I use the said directive "allow_glsl_builtin_variable_redeclaration" ? Is it a launch option in steam? What's the syntax then?

Quoting: FuriousCan you help me with this one? I'm not sure how do I use the said directive "allow_glsl_builtin_variable_redeclaration" ? Is it a launch option in steam? What's the syntax then?

That's not something you should have to deal with yourself. But if you're on Mesa 17.2 or later and the rule is missing from your /etc/drirc, I guess you should add it there. According to the patch it should look like this:
        <application name="Dying Light" executable="DyingLightGame">
            <option name="allow_glsl_builtin_variable_redeclaration" value="true" />
        </application>

If something else has broken since the patch like DamonLinuxPL suggests, this won't help you at all. And remember, this is only relevant if you're running an AMD GPU on Mesa.

Someone on [reddit](https://www.reddit.com/r/linux_gaming/comments/7i94w1/dying_light_battle_royal_mode/dqxe1zr/) suggested using the Steam snap to run Dying Light, as it bundles all the runtime dependencies from ubuntu.

I haven't tested it yet, but it appears to work.

about to try on a fresh install of fedora27. if this is going to work i really need to get snapd running on gentoo :P

the good news: its really playable

the bad news: changing settings ingame causes a crash to desktop, so i'm stuck with medium settings.

right now i'm running with radeon module on 4.13 kernel. performance is quite ok (75fps was a higher spike. it tends to hover at about 50)

i'll see what i can do about settings, if savegames work and how it runs with amdgpu on 4.15_rc2

stay tuned ;)

UPDATE:
after several tries i was able to adjust my settings to 1080p and everything maxed out.
getting avg 60fps with my r9 290 (overclocked bios with 1150gpu/1550mem) and never dips below 40 so i would say it's pretty playable. can't say how performance will be in other areas, this is in the slums.

savegames are working as well

thanks so much for the tip ;)

UPDATE2: sadly my steam controller is not working with this methode
here's with 4.15_rc2 kernel: https://imgur.com/a/hsKJ9

if anyone knows how to get steamcontroller or at least xbox360 controller working with steam snap package, pls let me know ;)

can confirm the LSI snap pack runs the game perfectly fine.
you will still need this in the launch options:
MESA_GL_VERSION_OVERRIDE=4.4 MESA_GLSL_VERSION_OVERRIDE=440 %command%

for controller try enabling joysticks for steam snap. I wrote how to do the entire process on my blog:

https://www.gloriouseggroll.tv/having-steam-game-problems-on-your-distro-try-the-snap-pak-of-steam/

for the short and sweet:
sudo snap connect linux-steam-integration:joystick core:joystick

you may also need steamos-xpad-dkms kernel from the aur, I use this.

Im able to run dying line on arch with mesa-git and linux-git kernel only via the snap.

linux-steam-integration on the AUR acts the same as normal (segfault after loading bar),ive informed ikey on the lsi github

Thanks a lot. Will give it a shot in the days ahead.

Still trying to figure out, how to get it running natively but running as snap is a good fix for distros compatible with it. But i'm not quite willing to switch to a different distro for one single game ;-)

I can confirm that GloriousEggroll's method works. :D
I'm curious, though... how does the snap work? Does it provide ubuntu specific dependencies that Arch Linux is lacking?

If you run "ldd DyingLightGame", you'll see that the snap is actually missing some of the required dependencies. So it only adds the right ones?

It would be interesting to see what changed between ubuntu 16.04 and later versions that broke dying light on mesa.
i'm thinking about downgrading glibc to 2.23 and try again.

if i understand it correctly, snap packages run in a sandboxed enviornmet, that bundle all libraries needed for the specific programm.

if i'ts just about some libraries, we could try to extract them from the snap package (don't know how to be honest) but i guess it's not that simple

maybe the devs of souls' steam snap packages can give some insight what "fixes" the problem

edit: ah just saw the post about glibc on github. interesting

edit2:

i'm running against a wall here:

{23:27:04.794} INFO: [INFO] > [OpenGL] Video memory detected: 0 [MB]!
{23:27:04.797} INFO: [INFO] > Caught signal 11 (Segmentation fault).
[...]
{23:27:04.794} INFO: [INFO] > [OpenGL] Video memory detected: 0 [MB]!
{23:28:11.741} INFO: [INFO] > Caught signal 2 (Interrupt).

Bug is known and closed as it "only affects lesser used distros" [source](https://www.spinics.net/lists/dri-devel/msg143217.html)

as i like to tinker with other distros now and then i now gave debian-testing a shot and can tell you Dying Light works natively with the same drawbacks as tested with snap package, i.e. you can't switch to window mode or the game will crash.

that's with Linux 4.13 (stock kernel) and Mesa 17.4.0-devel (Oibaf PPA)

really gotta find out why the Game can't detect vram on gentoo and if there is anything else that has to be fixed (besides copying some libs)