WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders

[H. Verbeet]

On 25/03/07, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> > You do bring up another issue though... I think we should decide on
> > what the ARB backend is supposed to implement. Right now it's a bit of
> > a mess with some parts only supporting up to ps_1.3, other parts doing
> > ps_1.4, and some broken support for vs_2.0 added in. (eg. mova). I
> > think that if we're going to say we don't support anything higher than
> > ps_1.3 there, we shouldn't try to compile shaders with higher versions
> > either.
> How much does ARB_fragment_program support? AFAIK it does up to and including
> ps_1.4, for 2.0 some features like loops are missing. Is there anything in
> 1.4 that isn't supported by arb fp?
>
I think 1.4 should be possible to support.

> IMO we should support at least ps_1.4, and if there is something that arb fp
> does not support write an ERR to tell the user to switch to glsl. If we have
> support for 2.0 things like mova(*) or someone contributes 2.0 features we
> shouldn't refuse that as long as it fits nicely into the code. I personally
Well, for one, the rounding for mova is wrong with ARB. I think one of
the problems with the ARB backend is that it's not clear what it's
supposed to support. In particular with instructions that behave
differently between 1.3/1.4/2.0, that can lead to nasty bugs.

> don't plan to add any tricky 2.0 or 3.0 features to the arb shader
> path(unless MacOS forces me to try)
While supporting OS X is cute, I don't think we should be adding hacks
and workarounds to wined3d to support broken OpenGL drivers. (That
goes for ATI/AMD Linux drivers as well).

> (*) If we do not advertize 2.0 shaders with arb how come that some of Andras'
> games used mova with arb? Did the game ignore the limit and we do not
> complain if it violates them?
Probably