Shader bug update

I made another shader today. Nothing that interesting as it's a variation on one I'd done before, but as I added it I uncommented out a line in the game which I must have disabled while trying to fix the shader bug two weeks ago. And the bug re-appeared. Thankfully as I knew it was a shader bug and knew the last change I'd done it was easy to undo, but it was surprising as I thought I'd fixed it in the shader code.


The change was uncommenting out the following line



gGradShader.precisionHint = ShaderPrecision.FAST;


where gGradShader is the shader. The precisionHint is supposed to trade precision for performance, but I've not noticed it making any difference to either. But as there's no discernible visual difference and I'm always after more performance I've been setting it to ShaderPrecision.FAST by default.


Except doing so for this shader causes the game to lock up. Thankfully its used where performance isn't so much of an issue, so I can comment out that line without concern. I've added a note on this to the bug report thread on Adobe's forums, where it will hopefully be spotted by anyone else encountering a similar problem.

The new shader is a slight modification of the one I did two weeks ago. I could have added the functionality to that shader, controlled by a switch, but its more efficient to create a separate shader.

The shaders are tiny, less than 2,500 bytes for both of them, so there's hardly any overhead in adding both to the game. But more importantly it's much more efficient to branch outside the shader than inside it on code that runs 100,000+ times, once per pixel. For an example of how not to do it the twirl.pbk example that comes with PixelBender passes an int which is used as a Boolean to decide which falloff method to use. Better to create two shaders, at least for use in Flash Player.