Created attachment 34165 [details] screenshot of the bug The shaders in the game Yo Frankie isn't rendered correctly, the player and the signs in the first level are mostly black. This is only a problem if graphics is set to "high" in the options. I'm attaching screenshots of the problem with a comparison from running the game with the software rasterizer. I'm also attaching two python scripts which includes the shaders the game is using.
Created attachment 34166 [details] correctly rendered in software
Created attachment 34167 [details] shader_lava.py
Created attachment 34168 [details] shader_uvtx.py
From the debugging I'd done before, I don't think those are the only shaders the game uses, and unlikely to be the ones on the signs. For example, the previous failure was with sqrt() which doesn't appear there.
I see, then I guess those shaders are internal to the Blender Game Engine, which probably makes it much harder to track down...
It's probably possible to make tracking this down a lot easier by opening the parts of the game effected by the bug in Blender and then dump the shaders. But this will have to wait until bug #27034 is resolved.
I tried removing everything except the character from the scene, and then logging the shaders, but still ended up with over 15k lines of code, so clearly that's not the way to go.
MESA_GLSL=dump now dumps shader source. I've used it for looking at Yo Frankie's shaders and optimizing some of the things that it does, but it's really hard to make sense of what would be going wrong in a 1500-line shader.
This is fixed in the new FS backend.
commit a81d423d93f22a948f3aa4bf73dc6b1a3b70192f Author: Eric Anholt <eric@anholt.net> Date: Thu Oct 14 12:23:29 2010 -0700 i965: Enable the new FS backend on pre-gen6 as well. It is now to the point where we have no regressing piglit tests. It also fixes Yo Frankie! and Humus DynamicBranching, probably due to the piglit bias tests that work that didn't on the Mesa IR backend. As a downside, performance takes about a 5-10% performance hit at the moment (e.g. nexuiz 19.8fps -> 18.8fps), which I plan to resolve by reintroducing 16-wide fragment shaders where possible. It is a win, though, for fragment shaders using flow control.
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.