Am Montag 12 März 2007 13:16 schrieb H. Verbeet:
No, but the hash table functions in utils.c should be generic enough to help at least a little bit with keeping track of the different states.
I am thinking more about completely removing a compiled shader rather than having 2 or more gl shaders for one d3d shader.
If we want to manage multiple compiled shaders with fog on/off then we should extend that to the whole parameter set. We already have sampler type(2D, 3D, cube), texture transform flags(D3DTTF_PROJECTED) and now fog and pixel format coming. My concern is that managing this will get too expensive and grow the amount of linked glsl programs vastly.
Up to a certain point. This should only be an issue for pre-2.0 shaders, and MSDN does hint that changing some states (like eg. the sampler type) might cause a shader recompilation, so applications doing that will probably be in trouble on Windows as well.
Ah, good to know :-)
I think it's important here to know what exactly is the problem, and under which conditions this happens. It would be a shame if we started adding lots of complexity because of this, only to find out later that it could have been avoided by eg. simply always using per vertex fog when a pixel shader is used.
Well, it won't be the always per vertex fog thing because we were doing that up to a patch my Vitaly, but agreed in general :-) . Its test case time :-)