From b1df18be85d1ca6a9904be05420f975f6933b030 Mon Sep 17 00:00:00 2001 From: Stefan Doesinger stefan@codeweavers.com Date: Fri, 23 Mar 2007 19:03:58 +0100 Subject: [PATCH] WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders
Isn't there a function to handle modifiers? "get_modifier_line"...
Am Samstag 24 März 2007 15:36 schrieb Ivan Gyurdiev:
From b1df18be85d1ca6a9904be05420f975f6933b030 Mon Sep 17 00:00:00 2001 From: Stefan Doesinger stefan@codeweavers.com Date: Fri, 23 Mar 2007 19:03:58 +0100 Subject: [PATCH] WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders
Isn't there a function to handle modifiers? "get_modifier_line"...
Oh indeed, you're right. I'll fix the patch.
On 24/03/07, Stefan Dösinger stefan@codeweavers.com wrote:
Am Samstag 24 März 2007 15:36 schrieb Ivan Gyurdiev:
From b1df18be85d1ca6a9904be05420f975f6933b030 Mon Sep 17 00:00:00 2001 From: Stefan Doesinger stefan@codeweavers.com Date: Fri, 23 Mar 2007 19:03:58 +0100 Subject: [PATCH] WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders
Isn't there a function to handle modifiers? "get_modifier_line"...
Oh indeed, you're right. I'll fix the patch.
The tex instruction can have these modifiers as well.
Am Samstag 24 März 2007 16:01 schrieb H. Verbeet:
On 24/03/07, Stefan Dösinger stefan@codeweavers.com wrote:
Am Samstag 24 März 2007 15:36 schrieb Ivan Gyurdiev:
From b1df18be85d1ca6a9904be05420f975f6933b030 Mon Sep 17 00:00:00 2001 From: Stefan Doesinger stefan@codeweavers.com Date: Fri, 23 Mar 2007 19:03:58 +0100 Subject: [PATCH] WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in arb shaders
Isn't there a function to handle modifiers? "get_modifier_line"...
Oh indeed, you're right. I'll fix the patch.
The tex instruction can have these modifiers as well.
In 1.X shaders too? I see that in 2.0+ shaders this is the way to use projected textures, but in 1.X there is the D3DTTFF_PROJECTED projected flag.
On 25/03/07, Stefan Dösinger stefandoesinger@gmx.at wrote:
In 1.X shaders too? I see that in 2.0+ shaders this is the way to use projected textures, but in 1.X there is the D3DTTFF_PROJECTED projected flag.
No, 2.0+ has the D3DSI_TEXLD_PROJECT, 1.4 has _dw/_dz modifiers and pre-1.4 has the fixed function D3DTTFF_PROJECTED flag.
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.
No, 2.0+ has the D3DSI_TEXLD_PROJECT, 1.4 has _dw/_dz modifiers and pre-1.4 has the fixed function D3DTTFF_PROJECTED flag.
Oh oops, its a < ps_2.0 check, not a >= :-) Anyway, I think that should go into a different patch :-)
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?
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 don't plan to add any tricky 2.0 or 3.0 features to the arb shader path(unless MacOS forces me to try)
(*) 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?
On 25/03/07, Stefan Dösinger stefandoesinger@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
-
H. Verbeet -
Ivan Gyurdiev -
Stefan Dösinger -
Stefan Dösinger