2016-09-13 22:28 GMT+02:00 Fabian Maurer dark.shadow4@web.de:
I don't think this is acceptable. It should be done in a way that doesn't introduce mess like this.
I split the patches but I didn't know how to do it . For not breaking compilation, I added these temporary defines. The later patch removes those again.
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.
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).
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.