On 03/07/06, Ivan Gyurdiev ivg231@gmail.com wrote:
Demo #2: Many Per Pixel Lights, http://www.zanir.szm.sk/dx/017_Many_Per_Pixel_Lights.zip This is a d3d8 demo. The shader inputs are not marked with a semantic - the declaration data is mapped 1:1 to the shader inputs, so a specific register number is designated as the D3DVSDE_DIFFUSE register. Now, consider that we use the semantic to implement shader fixup - flipping red and blue on color inputs. Previously this fixup did not work at all on d3d8 shaders (as far as I can tell),
And it shouldn't. As you said, d3d8 shaders don't have a usage / semantic defined per register.
and I just made it work today, by storing a fake semantic for d3d8 shaders.
You can't do that. In d3d8 there's no way to figure out how a register is going to be used. For d3d8 the only way to determine if we need fixups is to look at the register's data type. That's exactly what the patch / hack I sent you a while ago did.
Therefore, how can we rely on a semantic tag for shader fixups? Seems we can't do that.
For d3d8 we can't, but for d3d8 the register shouldn't *have* that tag in the first place, since there's no way we can make up a correct one. The dolphin demo in the d3d8 sdk is another demo that breaks if you do this. (It stores texture coordinates in register 6, which happens to correspond to D3DVSDE_SPECULAR).
Also, I don't understand why we're applying fixups on shader input either. Can someone explain why this fixup is needed exactly? If we need to flip red and blue because the format is backwards, shouldn't this be done at the end of the pipeline, at the point of interpretation by GL. Flipping things at an intermediate point can affect all kinds of calculations in the shader. At the end of the pipeline we can also reliably tell what's to be interpreted as color data, instead of following semantic hints.
It's not an intermediate point, but rather how the data is visible inside the d3d shader. We don't look at the usage / semantic of the register as much as we look at the data type that usage implies (for d3d9 that is, d3d8 has an explicit data types and no usage). For the "color" datatype, the blue component of the color is the first component, x. We actually need to do it on input *because* of the calculations you talk about. Consider this: How would the data look if we did the fixups on the input data before sending it to the shader?