[PATCH 1/5] d3dx11: Copied functions and defines from d3dx_36 related to texture loading
Fabian Maurer
dark.shadow4 at web.de
Mon Sep 19 19:11:46 CDT 2016
> Yeah, that's certainly not acceptable. Also in general introducing
> dead code (i.e. code that's unused until a later patch) is not okay.
Well I see. It's just that I didn't want to commit the whole thing as single
patch, since that would make it way less understandable. So I split it up to
show where exactly I changed lines. Regarding "introducing dead code", I
thought it was fine if it was part of a patchset? Obviously all patches in this
set depend on the others. They aren't supposed to be on their own, it's just
way more overseeable like that.
> You can probably start from a simple implementation of
> D3DX11CreateTextureFromMemory(), without any scaling or format
> conversion and without DDS support. Something like
> 258dba1a521cff3226db523b012ef3de2599e578 but for d3dx11. Notice how
> that calls D3DXGetImageInfoFromFileInMemory(); similarly it might make
> sense to implement D3DX11GetImageInfoFromMemory() first.
>
> Then you should introduce the various other pieces incrementally, as
> they become necessary. You don't want to actually duplicate the code
> keeping all the d3d9-isms, you'll have to rewrite those helpers in a
> way that makes sense for d3d11 (incidentally, that's what I meant with
> this being a useful step before figuring out how generic helpers would
> look like).
Actually, this is my attempt at a generic helper.
"load_imagedata_from_file_in_memory" and "load_imageinfo_from_file_in_memory"
should be usable for both DX9 and DX11.
The point is, that this is mostly C&P from d3dx9 code. I didn't change too
much, so I figured it would be a bad idea to cut out functionality to add it
later again. It's about extracting the functionality from d3dx9 into something
that's reusable. I could have extracted and used it for d3dx9 first, but we
don't know yet where to put it..
> Most importantly, you need to write some tests for all the functions
> you are implementing. The related d3dx9 tests are probably a decent
> starting point, although there are a few new bits that should be
> tested as well (e.g. it would be interesting to test various
> combinations of BindFlags, CpuAccessFlags and MiscFlags). You want to
> do that even before starting to work on the implementation, there
> might be some surprising results.
Yeah, I don't have tests yet. First I wanted to give you an implementation so
we could decide on where to put the helpers. Also, I kinda don't know how to
write a proper test without running windows (except for a VM).
More information about the wine-devel
mailing list