Under review

Too many output registers declared (12) on d3d9

behealed 8 years ago updated 8 years ago 10

Here's the error:

Image 708

And here's the code SF generated:

Image 709

Pretty sure this is an easy fix... the structure VertexOutput needs to pack a couple of the uv's into a float4, so that it can cut down on the number of outputs from 12 to 11. If I do this manually, then I won't be able to edit the shader in shader forge anymore. I kind of think shader forge should detect this, and automatically pack two of them into one float4 to avoid this error.

Another option is, I see that o.screenPos = o.pos. So both of those outputs are always going to be identical, which is a waste of an output. I'd suggest SF shouldn't output a screenPos at all. And instead, move screenPos entirely to the fragment by simply declaring it in the fragment. For example: float2 screenPos = i.pos. Unless there is some reason that wouldn't work, that I'm not seeing.

Here's what I had to do to get past this error. This of course makes my shader un-editable in shader forge. The alternative I suppose would be to drop support for d3d9, but I'd like to not do that.

Not meaning to nag but, this is an easy fix :)

And starting from today and moving forward, every time I release an update to my asset I'm having to break my shaders from being editable in shader forge because of this bug, and I'm linking my users to this post to explain why I'm having to doing that. :) So hopefully this can be fixed...

Under review

It can be fixed, but it's not an easy one, because combining multiple Vector2 interpolators into a single Vector4 is very expensive on some platforms, which is why I can't simply just implement it as-is

This gives a console error though. Expensive is better than an error? I would suggest that shader forge combine the vectors only if it would result in a console error (meaning they have 12+ output registers AND they want d3d9, etc). And otherwise, it wouldn't combine anything. I imagine anyone who actually needs 12 output registers is dealing with an expensive shader already, and so I can't imagine that the combining will add enough additional expense that we should prefer the error over it.

Of course it's better to have it fixed than not, I'm just saying that it's not an easy fix on my end. Your best bet for now is to reduce the amount of interpolators needed by removing features such as fog, if possible

o.pos and o.screenpos seem to output the exact same thing? Does this create a wasted output register? Perhaps one could be removed?