Re: [PATCH 2/5] d3dx11: Made texture loader use wined3dformat instead of d3dformat.
2016-09-13 22:11 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>:
Signed-off-by: Fabian Maurer <dark.shadow4(a)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.
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 it shouldn't be too hard to make it a good generic version. It would make both d3dx9 and d3dx11 simpler, while providing modular abstraction. Just loading a texture or texture information is something that can be standalone. I'm open to change of course, but I'd like to understand the reason behind it. It's not linked to wined3d anymore, only uses the intermediate imageformat. Since a generic imageloader can't rely on DX9 types nor on DX11 and since I didn't want to reinvent the wheel, I just used the implemenation at hand: wined3dformat.
2016-09-20 2:35 GMT+02:00 Fabian Maurer <dark.shadow4(a)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.
Just to make this clear, this patch was my example on how to implement the dx11 functions with d3dx9 code:
Fabian, if you want to send patches for D3DX11CreateShaderResourceViewFromFileW "duplicating" the relevant code for the time being, that is fine to me. It might even be easier to decide how to share the code at that point.
My plan was to pull the code out of of d3dx9, make it generic and put it into a place where both d3dx11 and d3dx9 can use it. Once these helpers worked with d3dx9, I'd implement the d3dx11 functions using them. This patch series was a working implementation - like you wanted to see - which duplicates the relevant code so I would know how to share it between versions. But now we're mostly at "write it from scratch". It's fine if you'd rather want a complete rewrite instead of copy&paste with modifications, but I think I made it pretty clear from the beginning this wasn't my intention. I'd make the generic helpers less "hacky" or rewrite parts of them, but I fear I'm not the person to do a good complete rewrite of all this.
participants (2)
-
Fabian Maurer -
Matteo Bruni