Created attachment 54112 [details] Screenshot of bug Static lightning is broken in the game CoreBreach. This happens with all the drivers I have tried, so it's probably a general Mesa problem. This is not a problem on git master. I bisected to find the commit which fixed this problem, hoping it could be cherry picked for the next stable release: commit 719909698c67c287a393d2380278e7b7495ae018 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Tue Oct 18 16:01:49 2011 -0700 mesa: Rewrite the way uniforms are tracked and handled Considering the size of the change it seems unlikely to be suitable for this. Maybe someone could have a look at this and see if a smaller fix is possible for 7.11? CoreBreach is so far only available as beta for Linux: http://corebreach.corecode.at/CoreBreach-1.1-beta4-linux32.tar.bz2 http://corebreach.corecode.at/CoreBreach-1.1-beta4-linux64.tar.bz2
hello, i'm the developer of the game in question. i've had a look at this problem to see if there is an easy workaround - however even simplifying the shader in question very much the problem persists and indeed is quite weird. the problem occurs in the shader "phong_shadow.frag" with the codepath #define SHADOW 1 and without LIGHT being defined. the shader is long, i've made a simple version that still exhibits a problem on MESA: uniform vec4 color; uniform sampler2D texUnit; varying vec2 texcoord; varying vec3 position; #ifdef SHADOW uniform sampler2DShadow shadowMap[1]; varying vec4 shadowTexCoord[1]; float lookup(vec2 xy) { return shadow2DProj(shadowMap[0], shadowTexCoord[0]).x ; } #endif void main (void) { vec4 tmp = texture2D(texUnit, texcoord); #ifdef SHADOW float s = lookup(vec2(0.0,0.0)); gl_FragColor = vec4(tmp.r, tmp.g, tmp.b, s); gl_FragColor.a = 1.0; // gl_FragColor should be (tmp.rgb, 1.0), but its BLACK. when changing s to 1.0, the problem is gone. #else gl_FragColor = tmp; #endif } this doesn't render the same thing as the normal shader, but still exhibits the basic problem. in the SHADOW case we should be writing out the same thing to the color as in the other case, just the contents of the texture lookup. however, just the fact that the shadow texture lookup is performed and used (written to glFragColor.a, but overwritten just one line later) makes everything go nuts and the result is just BLACK for the parts of the geometry where SHADOW is defined. the weird thing is that although the more complicated "dynamic" lighting shader (also phong_shadow.frag in the game, but with LIGHT defined to 1) also performs the shadow lookup, it isn't completely broken - and thats although the shader is a more complicated superset of the static lighting shader ... just weird. there are 3 other problems with the game on MESA/ATI: • with the normal (dynamic lighting) shader, the shadows don't show up, so there seems to be a general problem with shadow-maps that either manifests itself as the shadows just not showing up (dynamic light) or making everything black (static light) • i can't seem to be able to create a context with FSAA enabled, the game automatically falls down to no-FSAA • the "videowalls" are grey instead of containing a colorful animation. something in mesa seems to break the shader "plasma.frag"
sorry not sure about the videowall (plasma.frag) thing anymore, there seems to be one "disabled" videowall in this racetrack ;-)
So... this bug occurred on Mesa 7.11, but it does not occur on later versions?
(In reply to comment #3) > So... this bug occurred on Mesa 7.11, but it does not occur on later > versions? Correct, I doubt anyone has plans for more updates for 7.11 so let's just close this.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.