i assume ATTR0.xyz is attribute 0 which is always vertex for nvidia cards
with nvemulate u can turn on generate asm output (which i just did + got from one of my shaders) #var float4 gl_Vertex : $vin.POSITION : ATTR0 : -1 : 1
btw this forum needs to fix up displaying code of one line
In addition to the error I posted, I also got a warning in the fragment shader about the use of fragTexCoord1. That is, it is a vec2 and texture2D takes a vec3. However, it was just a warning.
Here’s the change to the fragment program that made the vertex program error go away (and yes, I’m sure the error appeared in the vertex program):
The best guess I can make is that when the fragment shader compiled, it silently changed the varying fragTexCoord1 from a vec2 to a vec3 (why it should believe that silently changing the type of a varying is ever OK is beyond me). Of course, when I go to link it to a vertex shader that thinks fragTexCoord1 is a vec2, it breaks. With a very obtuse error. That doesn’t actually point to the problematic line.
I’m grateful for nVidia having a half-way decent glslang compiler, but it would be more decent if the error messages for that compiler actually spoke glslang and not ARB_vertex_program or HLSL.
I just tried your original shader and it compiles fine 162.18 drivers Geforce 8600
That’s the thing. I got an 8800GT a few days ago. Before then, I was running a 6600. It compiled perfectly fine on the 6600, but once I installed the 8800GT with new drivers it stopped liking it.
I’m guessing that this is some kind of driver bug.
In Cg, a semantic is a label applied to an input or output variable telling the GPU where that value comes from or how it should be used. Some semantics are TEXCOORD0, COLOR, TEXUNIT0, POSITION, etc.
I don’t know GLSL, but I suspect they’re essentially the same as “attributes” based on the usage in this thread.