[PATCH 2/5] d3dx11: Made texture loader use wined3dformat instead of d3dformat.

Matteo Bruni matteo.mystral at gmail.com
Mon Sep 19 21:03:53 CDT 2016


2016-09-20 2:35 GMT+02:00 Fabian Maurer <dark.shadow4 at web.de>:
>> It was already mentioned but, at the cost of being annoying, let me
>> reiterate: d3dx* DLLs can't directly use wined3d data types or APIs.
>> They have to go through the respective d3d* client library functions.
>>
>> I suspect that code sharing between d3dx* versions will eventually
>> happen in a somewhat different fashion and trying to build the "final
>> solution" from the ground up is going to be hard. Porting the various
>> pieces of code to d3d[x]11 as necessary, even at the cost of
>> "duplication" in the short term, is probably a better plan.
>
> I somewhat doubt it. It wasn't too hard to use the d3dx9 parts for d3dx11

And that's exactly the problem. That that's not the proper way of
doing it, what your patches do is to take d3dx9 code and hammer it
until it works for d3dx11. The result is that it "works" but it isn't
pretty, both for the process (you can see the hammering right in the
patch series) and the end result (the resulting code in d3dx11 is
ugly). BTW, notice that the d3dx9 code isn't particularly nice either,
result of years of additions / fixes / changes done by multiple
people. It could use a rewrite, if only there was a good reason...

For the time being, you have to trust my judgment on the matter (or
escalate things, but I'm pretty sure you'll find more of the same).
Let me list my main issues with the current patch series:
- 2K lines code drop
- copying d3dx9 code to d3dx11 while adding a bunch of defines and
definitions to make it compile
- using wined3d types in d3dx because they happen to match the use case at hand
- no tests

Each of them is reason enough to reject the series right away. I
imagine that it isn't obvious to you why is that and I'm not sure how
to convince you in detail, I feel like I'm doing a terrible job at
that. I'll try to reply to specific questions (and gladly accept help
from other fellow devs).

I'll repeat myself to conclude. IMHO the easiest way to generate
acceptable patches for this stuff is to follow the "plan" I expressed
in my last few emails: start from scratch, adding a small piece at a
time, with tests.



More information about the wine-devel mailing list