Bug 84155

Here is a link to the discussion on the Wasteland 2 forums:

https://wasteland.inxile-entertainment.com/forum/viewtopic.php?f=34&t=8553

Reproduced this on Haswell, it looks like the "fog of war" layer gets projected in wrong position. Will check how GLSL looks like.

(In reply to comment #2)
> Reproduced this on Haswell, it looks like the "fog of war" layer gets
> projected in wrong position. Will check how GLSL looks like.

and perhaps in way too low resolution (?) with sw rendering the resolution seems much much more crisp

(In reply to comment #3)
> (In reply to comment #2)
> > Reproduced this on Haswell, it looks like the "fog of war" layer gets
> > projected in wrong position. Will check how GLSL looks like.
> 
> and perhaps in way too low resolution (?) with sw rendering the resolution
> seems much much more crisp

It might not be a low resolution issue, it could just be the fact that camera is now way too close to the layer.

Also this bug affects the normal gameplay outside of travel mode. The edges of the map also seem to use this effect to darken its boundaries. If the camera strays too close to the map edge, the incorrectly-projected dark layer will block the camera.

For some reason I cannot get the game to launch from cmdline and therefore cannot make an apitrace, would be cool to get one to see what is happening from API perspective. I did not spot anything obvious in the first glance to the shaders, they are written for compatibility profile (using gl_ModelViewProjectionMatrix and so on), GL_ARB_shader_texture_lod extension is enabled in many of them.

(In reply to comment #5)
> For some reason I cannot get the game to launch from cmdline and therefore
> cannot make an apitrace, would be cool to get one to see what is happening
> from API perspective. I did not spot anything obvious in the first glance to
> the shaders, they are written for compatibility profile (using
> gl_ModelViewProjectionMatrix and so on), GL_ARB_shader_texture_lod extension
> is enabled in many of them.

I can launch it from the command line no problem. How are you trying to launch it?

(In reply to comment #6)
> (In reply to comment #5)
> > For some reason I cannot get the game to launch from cmdline and therefore
> > cannot make an apitrace, would be cool to get one to see what is happening
> > from API perspective. I did not spot anything obvious in the first glance to
> > the shaders, they are written for compatibility profile (using
> > gl_ModelViewProjectionMatrix and so on), GL_ARB_shader_texture_lod extension
> > is enabled in many of them.
> 
> I can launch it from the command line no problem. How are you trying to
> launch it?

I have Steam running on the background, I'll set LD_LIBRARY_PATH for Steam libraries and just launch it. Mono prints a few lines indicating that correct paths are found and I see X window created but then it just exits without any erorr.

Having the very same problem here, if you need tracebacks, logs, whatever, just ask, hardware is haswell with intel HD 5200.

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > For some reason I cannot get the game to launch from cmdline and therefore
> > > cannot make an apitrace, would be cool to get one to see what is happening
> > > from API perspective. I did not spot anything obvious in the first glance to
> > > the shaders, they are written for compatibility profile (using
> > > gl_ModelViewProjectionMatrix and so on), GL_ARB_shader_texture_lod extension
> > > is enabled in many of them.
> > 
> > I can launch it from the command line no problem. How are you trying to
> > launch it?
> 
> I have Steam running on the background, I'll set LD_LIBRARY_PATH for Steam
> libraries and just launch it. Mono prints a few lines indicating that
> correct paths are found and I see X window created but then it just exits
> without any erorr.

Try running it with gdb on the off chance it catches the error. 

I have the correct dependencies installed on my system so that I can run it without steam.

I would have provided you with an apitrace but I have to first cross compile it for 32 bit along with all of the dependencies, which is annoying. I will look into it.

Created attachment 106782 [details]
Wasteland 2 Apitrace

I am attaching a dumped to text copy of the apitrace output for running Wasteland 2 (Steam version).

Started, loaded game, moved in and out of problem fog area a few times and quit.

I have the full trace if required, but it is 812 MB

If somebody is interested in full trace output mine is available at http://www.tworaz.net/downloads/wasteland2/WL2.trace.xz.

There’s also a Steam thread with several affected users :
http://steamcommunity.com/app/240760/discussions/1/613936673392885026/

There is a notable information on the forum linked above: there is a workaround for the problem: MESA_EXTENSION_MAX_YEAR=2002
Works for me, though there is not fog of war and graphics is a bit worse, as expected.

(In reply to comment #13)
> There is a notable information on the forum linked above: there is a
> workaround for the problem: MESA_EXTENSION_MAX_YEAR=2002
> Works for me, though there is not fog of war and graphics is a bit worse, as
> expected.

Looking at src/mesa/main/extensions.c's table of extensions, these two extensions from 2003 seem like plausible culprits:

GL_ARB_fragment_program_shadow
GL_ARB_shading_language_100

Running the apitrace shows no GLSL programs (except for driver internal clear shaders). We do, however have a couple instances of GL_ARB_fragment_program_shadow.

(In reply to comment #14)
> Running the apitrace shows no GLSL programs (except for driver internal
> clear shaders).

Spoke too soon. I was searching for #version, which GL_ARB_shading_language_100 doesn't need.

Could someone test with

 MESA_EXTENSION_OVERRIDE=-GL_ARB_shading_language_100

 MESA_EXTENSION_OVERRIDE=-GL_ARB_fragment_program_shadow

and see which (if either) affects the bug?

Neither of the extensions have any effect for me.
But exporting MESA_EXTENSION_MAX_YEAR=2002 does let the travel mode display without being all black.

By the way the interface is always displayed, even when the game world is all black if that’s of any use.

Created attachment 106974 [details]
Game world displayed all black in Wasteland 2 travel mode

I noticed that MESA_EXTENSION_OVERRIDE='-GL_ARB_texture_non_power_of_two' is a minimal workaround for this (this happens also when limiting extension to year 2002). This way the fog of war does not get rendered and you can use Mesa master to run the game. Unfortuntately I haven't been able to spot what the actual bug is so far :/

Guys pleaes explain where i should insert this paremeters? (howto?) 

MESA_EXTENSION_MAX_YEAR=2002
or
MESA_EXTENSION_OVERRIDE='-GL_ARB_texture_non_power_of_two'

(In reply to comment #19)
> Guys pleaes explain where i should insert this paremeters? (howto?) 
> 
> MESA_EXTENSION_MAX_YEAR=2002
> or
> MESA_EXTENSION_OVERRIDE='-GL_ARB_texture_non_power_of_two'

The easiest way is to put it into the startoptions of wasteland 2 inside your steam client like this...

MESA_EXTENSION_MAX_YEAR=2002 %command%

or

MESA_EXTENSION_OVERRIDE='-GL_ARB_texture_non_power_of_two' %command%

Then simply run the game.

Both the proposed workarounds break the energy weapons shooting effect: instead of a distorsion some black geometric figures are displayed.

I play a game which is also using unity3d to render fog of war, where a similar bug appears only with intel graphicscards. The Games name is War for the Overworld. Maybe we could get information from the unity3d developers, which function they use, to isolate the problem of the driver.

Seems to me that this problem may have been fixed either by changes to the game or changes to Mesa (tested using current Mesa git head abf3fef).

Could someone else verify? It is probably enough to try with latest oibaf-ppa if using Ubuntu.

(In reply to Tapani Pälli from comment #23)
> Seems to me that this problem may have been fixed either by changes to the
> game or changes to Mesa (tested using current Mesa git head abf3fef).
> 
> Could someone else verify? It is probably enough to try with latest
> oibaf-ppa if using Ubuntu.

Huh sorry, this was not true, I just realized I had following environment variable turned on:

UNITY_DISABLE_GRAPHICS_DRIVER_WORKAROUNDS=yes

This seems to make the bug disappear, this means the bug is most probably in Unity engine. Could someone else try if this fixes the issue for you?

(In reply to Tapani Pälli from comment #24)
> (In reply to Tapani Pälli from comment #23)
> > Seems to me that this problem may have been fixed either by changes to the
> > game or changes to Mesa (tested using current Mesa git head abf3fef).
> > 
> > Could someone else verify? It is probably enough to try with latest
> > oibaf-ppa if using Ubuntu.
> 
> Huh sorry, this was not true, I just realized I had following environment
> variable turned on:
> 
> UNITY_DISABLE_GRAPHICS_DRIVER_WORKAROUNDS=yes
> 
> This seems to make the bug disappear, this means the bug is most probably in
> Unity engine. Could someone else try if this fixes the issue for you?

I tested it on a different unity3d game with a similar fog of war bug and it worked. Unfortunately I don't have wasteland2 to test it there.

Tested the env :

UNITY_DISABLE_GRAPHICS_DRIVER_WORKAROUNDS=yes

on a GNU/Linux box on which this FOV bug was clearly visible : it did fix the problem. Saw no side effects so far, but OTOH just ran the game for 3 minutes.

Thanks for the tip, did help me.

Per the recent comments I'm resolving this as NOTOURBUG.

Could we add a driconf workaround?

I'm not really sure how - the fix isn't changing our behavior, it's asking Unity to change it's behavior.  Unity loads libGL, so it seems unlikely we could setenv() and have it affect them even if we wanted to.

Unity 4 based games could include this in their shell wrappers, while waiting for a proper fix:

if glxinfo | grep -q 'Intel Open Source Technology Center'; then export UNITY_DISABLE_GRAPHICS_DRIVER_WORKAROUNDS=yes; fi