[PATCH] d3d10: Implement D3D10CompileEffectFromMemory().

[Matteo Bruni]

2018-04-20 13:53 GMT+02:00 Valentin Gabriel Mitrea <mitrea.valentin at gmail.com>:
> As MSDN documentation recommends, one should use D3DCompile()
> instead of D3D10CompileEffectFromMemory(). So, execution was
> forwarded to that function.
>
> This implementation is a possible fix for this bug:
>
> https://bugs.winehq.org/show_bug.cgi?id=36538
>
> At the moment, there are no d3d10 tests written for shader and
> effect compilation functions.

This is probably okay in principle, for the time being (but adding a
small test would be even better). Did you actually try it with the
application in the bug and native d3dcompiler (our d3dcompiler doesn't
do much yet)?

A couple comments / nitpicks below.

> diff --git a/dlls/d3d10/d3d10_main.c b/dlls/d3d10/d3d10_main.c
> index f2fbb41..0081e8f 100644
> --- a/dlls/d3d10/d3d10_main.c
> +++ b/dlls/d3d10/d3d10_main.c
> @@ -253,17 +253,14 @@ HRESULT WINAPI D3D10CompileEffectFromMemory(void *data, SIZE_T data_size, const
>          const D3D10_SHADER_MACRO *defines, ID3D10Include *include, UINT hlsl_flags, UINT fx_flags,
>          ID3D10Blob **effect, ID3D10Blob **errors)
>  {
> -    FIXME("data %p, data_size %lu, filename %s, defines %p, include %p,"
> -            " hlsl_flags %#x, fx_flags %#x, effect %p, errors %p stub!\n",
> +    TRACE("data %p, data_size %lu, filename %s, defines %p, include %p, "
> +            "hlsl_flags %#x, fx_flags %#x, effect %p, errors %p\n",
>              data, data_size, wine_dbgstr_a(filename), defines, include,
>              hlsl_flags, fx_flags, effect, errors);

Period at the end of the TRACE message, please (before the \n, of course).

> -    if (effect)
> -        *effect = NULL;
> -    if (errors)
> -        *errors = NULL;
> -
> -    return E_NOTIMPL;
> +    /* Forward to d3dcompiler */
> +    return D3DCompile(data, data_size, filename, defines, include,
> +            NULL, "fx_4_0", hlsl_flags, fx_flags, effect, errors);

You probably have to pass a valid entrypoint name. For d3dx9 / fx_2_0
that would be "main", no idea if that also applies to d3d10 / fx_4_0.
The comment isn't necessary IMO, but it doesn't hurt I guess.