[PATCH 6/7] d3d10/effect: Make it clear which assignment types are supported in state groups.

[Matteo Bruni]

On Fri, Oct 1, 2021 at 10:28 PM Nikolay Sivov <nsivov at codeweavers.com> wrote:
>
>
>
> On 10/1/21 11:08 PM, Matteo Bruni wrote:
> > On Fri, Oct 1, 2021 at 10:07 PM Matteo Bruni <matteo.mystral at gmail.com> wrote:
> >> On Fri, Oct 1, 2021 at 8:14 AM Nikolay Sivov <nsivov at codeweavers.com> wrote:
> >>> Signed-off-by: Nikolay Sivov <nsivov at codeweavers.com>
> >>> ---
> >>>  dlls/d3d10/d3d10_private.h |  8 +++++---
> >>>  dlls/d3d10/effect.c        | 25 ++++++++++++++++++-------
> >>>  2 files changed, 23 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/dlls/d3d10/d3d10_private.h b/dlls/d3d10/d3d10_private.h
> >>> index f980007427f..3fd17c7400d 100644
> >>> --- a/dlls/d3d10/d3d10_private.h
> >>> +++ b/dlls/d3d10/d3d10_private.h
> >>> @@ -60,9 +60,11 @@ enum d3d10_effect_object_type_flags
> >>>
> >>>  enum d3d10_effect_object_operation
> >>>  {
> >>> -    D3D10_EOO_VALUE = 1,
> >>> -    D3D10_EOO_PARSED_OBJECT = 2,
> >>> -    D3D10_EOO_PARSED_OBJECT_INDEX = 3,
> >>> +    D3D10_EOO_CONST = 1,
> >>> +    D3D10_EOO_VAR = 2,
> >>> +    D3D10_EOO_CONST_INDEX = 3,
> >>> +    D3D10_EOO_VAR_INDEX = 4,
> >>> +    D3D10_EOO_INDEX_EXPRESSION = 5,
> >>>      D3D10_EOO_ANONYMOUS_SHADER = 7,
> >>>  };
> >> I like the changes, although now D3D10_EOO_ANONYMOUS_SHADER sticks out
> >> like a sore thumb (it's still more of a "what it is" rather than "how
> >> is the state computed"). How does that fit D3D10_EOO_ANONYMOUS_SHADER
> >> in that?
> > Last minute change broke the sentence :/ The question was supposed to be:
> > how does D3D10_EOO_ANONYMOUS_SHADER fit in that?
> I'm not sure if I see exactly what you mean. Is it purely naming that is
> concerning?
>
> I can explain motivation of the ones I did change. VALUE is too generic,
> because all of them specify how destination value changes,
> PARSED_OBJECT is inaccurate in a sense that we call parsed objects
> things like state objects, when in fact assignment 2 applies to any
> variable,
> you can have AddressU = floatvar1; and that would use type 2. Same for
> existing name for type 3.
>
> Type 7 is used exclusively for Set*Shader( CompileShader() ) construct,
> not even for Set*Shader(NULL), because it does not reference any
> existing object (aka how the state is computed), but instead defines
> anonymous shader itself, as well as assigning it. Being anonymous you
> obviously can't switch it later, or reuse it anywhere. So in a way it is
> a sore thumb, closest to CONST case probably.

Right. Yes, that was my question / concern basically. The old names
referred to specific entities while the enum seems to be more about
how the value to be assigned to the variable is generated. The new
names go in that direction and, thinking about it,
D3D10_EOO_ANONYMOUS_SHADER could be seen as a D3D10_EOO_CONST_SHADER
of sorts.

Thanks for indulging me in this digression :D

> >> Related question, what is the value used for FXLVM-computed states?
> It's 5 for sure, and most likely 6. Five represents a[<expression that
> resolves to an index>]. I have an actual case when 5 is used in a game,
> but I haven't found non-index one yet, nor have I tried to compile one
> myself.

If it works in any way like d3dx9, 6 might be for precomputing some
constant buffer values that depend solely on effect variables (e.g.
sin(angle * pi/6) is used in the vertex shader, that computation is
moved out of the shader proper and put into an FXLVM program).