Am 19.04.2010 20:48, schrieb Christian Costa:
Well, it's your code, correct ? I suggest to simply remove these checks. There does not bring any added values.
It's my own code, but I noticed this flaw some time after GSoC was over, it can be quite disturbing. Additionally, the checks might not be useful in this case, but when/if D3DXCreateTexture gets implemented it'll make it easier to spot subtle memory leaks (like not Release()ing some buffer surface the function might use internally) which otherwise would go unnoticed.
Could you be more specific on what's need to be implemented ? The if statement catches several errors. Maybe you want to catch an error on CheckDeviceFormat, correct ?
Yeah, I was refering to this particular error. I just saw I didn't commit the remaining code to my public git repo (... because it's a bit ugly), this ( http://tonwas.freefronthost.com/gsocwork.tar.gz ... early snapshot of my work, which I vastly cleaned up lateron) tarball provides the remaining code at snapshot/texture.c. What this code does is if the requested format is not supported, try to find some other format which hopefully won't reduce image quality. This is done by using some heuristics, i.e. rules (some of which are more important than others). Generally speaking, FourCC and 24-bit formats are avoided unless directly requested. Also we won't change format _types_, e.g. no ARGB to DXT conversion. Then, we try to not remove any color component channel; then we try to not reduce the number of bits per requested channel; then (of the few remaining formats) we pick the one with the lowest INCREASE in number of bits per channel (i.e. the best would be the same bpc); the last heuristic is the increase in number of channels, which ofc should be kept to a minimum. btw note that the heuristics given on the MSDN site of this function aren't the real ones; they have similiarity with the real ones, but my version of them is closer to actual native behavior. I've thoroughly tested this code and it works in almost 99% of all possible cases for ARGB/QWVU/Paletted/Luminance (i.e. "simple" uncompressed formats)) and in the very few cases it doesn't copy native behavior it at least returns a usuable fallback format.
Anyway, I strongly advise you to add this stuff in a later patch and replace it with a FIXME message or some comment for now.
BTW, you are reviewing your own patch (albeit slighty modified) ;-) , does that mean you plan to make your work go into mainline ?
I'm glad someone picks up my patches, so I try to support this work as far as I can. I just have no time on working on this stuff myself anymore, i.e. no (direct) further work on this planned...
By the way, IMO the function documentation is pretty useful, at least description and the stuff about the return values (and additional NOTES), since it kind of verifies that the behavior is intended and not the result of some ugly coding..