Here’s the code I tested with…
GLfloat purple[]={1.0f, 0.0f, 1.0f, 1.0f, ‘\0’};
glBeginFragmentShaderATI();
glSetFragmentShaderConstantATI(GL_CON_0_ATI, (GLfloat*)purple);
glPassTexCoordATI(GL_REG_0_ATI, GL_TEXTURE0_ARB, GL_SWIZZLE_STR_ATI);
glColorFragmentOp1ATI(GL_MOV_ATI, GL_REG_0_ATI, GL_NONE, GL_NONE, GL_ONE, GL_NONE, GL_NONE);
glAlphaFragmentOp1ATI(GL_MOV_ATI, GL_REG_0_ATI, GL_NONE, GL_ONE, GL_NONE, GL_NONE);
//Second Pass Start Here//
glPassTexCoordATI(GL_REG_0_ATI, GL_REG_0_ATI, GL_SWIZZLE_STR_ATI);
glColorFragmentOp1ATI(GL_MOV_ATI, GL_REG_0_ATI, GL_NONE, GL_NONE, GL_CON_0_ATI, GL_NONE, GL_NONE);
glAlphaFragmentOp1ATI(GL_MOV_ATI, GL_REG_0_ATI, GL_NONE, GL_ONE, GL_NONE, GL_NONE);
glEndFragmentShaderATI();
Using the 7.72 drivers (Catalyst)
I believe that the problem exists somewhere in the use of the second pass of a shader and the use of a MOV_ATI command in the first pass.
If I leave off the second pass of the shader, my objects all get rendered white like their supposed to be. When the
glPassTexCoordATI(GL_REG_0_ATI, GL_REG_0_ATI, GL_SWIZZLE_STR_ATI);
is run, it’s as though REG_0 never contained the 1’s to begin with, it’s like it has 0’s. Another MOV_ATI in the second pass doesn’t seem to have any problems, just in the first pass (and the glAlphaFragmentOp*ATI(…) commands don’t seem to help resolve it.) I’ve never been a fan of using the MOV_ATI command anyways, I’d say stay away from it as much as possible (why waste a whole fragment op on just moving data around?!) Do like what Ysaneya said, make sure you’ve got the latest drivers (although, these are the problems I’m having with the latest drivers
.) Also, it never hurts to make sure you’ve checked the shader spec and made sure your #define’s are up to date.
Dan