Created attachment 84820 [details]
The image appears dark, showing the bug
In Europa Universalis IV, when using an Intel HD 3000 with Mesa 9.1 or 9.2, the screen get very dark. See attached image. This bug does not appear with the radeon driver. We suspect this is an Intel GLSL problem. The code triggering the bug is the following.
float GetShadowScaled( float fScaler, in float4 vBlurTexCoord, in sampler2DShadow ShadowSample )
fScaler = saturate( fScaler );
float vShadowValue = tex2Dproj( ShadowSample, vBlurTexCoord ).r;
//Hide shadow after a certain distance
vShadowValue += (1.0f-vFoWOpacity_Time.x);
vShadowValue = saturate( vShadowValue );
return ( 1.0f-fScaler ) + fScaler * vShadowValue;
At the suggestion of one of the game developers, replacing the return with "return 1.0f" solves the problem at the expense of some shadows. If it is any useful, the saturate function is defined this way:
float saturate( float x )
return clamp( x, 0.0, 1.0 );
It is the first time I report a potential GLSL issue. Please let me know if there is anything else I could provide.
Created attachment 84821 [details]
Image showing what it looks like after having applied the workaround suggested by the developer
Created attachment 84822 [details]
The image appears dark, showing the bug
Somehow the initial image was identified as text/plain.
I do not know why I said it works with the radeon driver. I actually do not know yet. I can provide that information in a week. Though it does work with the proprietary nvidia driver.
Knowing whether or not it works with any other Mesa driver would help narrow down the source of the problem.
Is tex2Dproj an overload function for textureProj2D or shadowProj2D depending on the type of the sampler?
It appears that tex2Dproj is defined this way:
#define tex2Dproj shadow2DProj
textureProj2D or texture2DProj do not appear to be used anywhere.
I finally managed to test with the radeon driver. It exhibits the exact same problem as with the intel card, the image being very dark. I hope it helps.
In case it is useful, here is the apitrace trace from the game start until experiencing the bug. http://medericboquien.eu/eu4.1.trace (400MB)
Just confirming I experience same issue with radeon on mesa 9.2. Provided workaround also helps.
Well, I am using radeonsi (2GB Radeon HD 7870, mesa 10.0~git1310251530.980755, llvm 3.4~svn193504) on Kubuntu 13.10 64 bits and I am experiencing the same problem. In my case the image gets correctly lit if I scroll out.
I am attaching two screenshots that depict the bug when zoomed in and no bug when zoomed out a bit more than the first shot.
Please, tell me if I should open a bug report on the radeonsi driver.
Created attachment 88324 [details]
Image showing the black lightning
Created attachment 88325 [details]
Image showing the correct lightning
Note however, that from a certain zoom level the image changes and thus the reason why once you zoom out more the image shows with the correct lightning.
This bug also applies to r600g.
Confirmed on R600g, same situation as José's.
The problem is still present with the current Mesa 10.1rc2 (r600g).
It's still there too with git 10.2 (radeonsi).
I'm also observing this issue on the Brix Haswell machines with 10.0.1. Ian, do you guys already have access to this title? Please have your staff drop me a line with their Steam account if not, I'd be glad to purchase licenses to help with this.
(In reply to comment #0)
> float GetShadowScaled( float fScaler, in float4 vBlurTexCoord, in
> sampler2DShadow ShadowSample )
> fScaler = saturate( fScaler );
> float vShadowValue = tex2Dproj( ShadowSample, vBlurTexCoord ).r;
> //Hide shadow after a certain distance
> vShadowValue += (1.0f-vFoWOpacity_Time.x);
> vShadowValue = saturate( vShadowValue );
> return ( 1.0f-fScaler ) + fScaler * vShadowValue;
ShadowSample actually points to a texture of format GL_RGB, and GL_TEXTURE_COMPARE_MODE is GL_NONE. It results in undefined behavior.
The correct fix is for the game to
on this function, and declare tex12 as sampler2D instead of sampler2DShadow in both VS and FS.
Médéric, do you already have a line of contact with the developer to relay that information or do you need help from our side?
(In reply to comment #19)
> Médéric, do you already have a line of contact with the developer to relay
> that information or do you need help from our side?
A Paradox developer is aware of comment 18 and agreed (on a quick glance) to the proposed solution.
fixed by Paradox Interactive with latest update to their game (Europa Universalis IV v1.6). A big thank you to all people involved here.