[PATCH] d3dxof: Add string expansion extension to d3dxof and make d3dx9_36 use it.

Christian Costa titan.costa at gmail.com
Thu May 9 17:08:20 CDT 2013


Le 09/05/2013 23:01, Alexandre Julliard a écrit :
> Christian Costa <titan.costa at gmail.com> writes:
>
>> Le 09/05/2013 22:05, Alexandre Julliard a écrit :
>>> Christian Costa <titan.costa at gmail.com> writes:
>>>
>>>> @@ -677,6 +677,7 @@ HRESULT WINAPI D3DXFileCreate(ID3DXFile **d3dxfile)
>>>>    {
>>>>        ID3DXFileImpl *object;
>>>>        HRESULT ret;
>>>> +    const char expand_string[] = "expand_string";
>>>>          TRACE("(%p)\n", d3dxfile);
>>>>    @@ -701,6 +702,11 @@ HRESULT WINAPI D3DXFileCreate(ID3DXFile
>>>> **d3dxfile)
>>>>        object->ID3DXFile_iface.lpVtbl = &ID3DXFile_Vtbl;
>>>>        object->ref = 1;
>>>>    +    /* Enable string expansion extension in d3dxof */
>>>> +    ret = IDirectXFile_RegisterTemplates(object->dxfile, (void*)expand_string, sizeof(expand_string));
>>>> +    if (ret != DXFILE_OK)
>>>> +        ERR("Native d3dxof.dll used. Use builtin one to avoid problem.\n");
>>> That's really ugly. You have to find a better way.
>>>
>> The d3dxof extension itself or how it is enabled ?
> Adding private extensions is not allowed, unless you can make a very
> convincing argument that there's no other possible option.
>
d3dxof puts pointers to strings in data retreived by applications while 
d3dx puts the strings directly into data.
Applications know how objects are made because they registers the 
templates associated with them. In d3dx we cannot do any assumption 
about templates as we don't control them at all.
To do the conversion d3dx needs to parse the templates to retreive where 
strings are located to do the conversion. This implies to do what d3dxof 
already does that is duplicating all the code.
I think a lot about this but the only solutions I saw were:
1) duplicate the code between d3dxof and d3dx
2) create a library shared between d3dxof and d3dx
3) create an extension in d3dxof

First solution is very ackward. Second one can be done at a cost of 
another lib.
I chose the third one because, APIs apart, d3dx and d3dxof have the same 
functionality except this string issue and also because d3dxof is 
complete enough so we don't have to use the native version.
I chose RegisterTemplates to avoid adding another exports to the spec 
file or using a flags in some other functions but this can be changed.







More information about the wine-devel mailing list