[PATCH] d3dx9_36: Implement D3DXCheckTextureRequirements + tests

[Christian Costa]

> 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.
>
>   

I was thinking about something like this. I put a FIXME if 
CheckDeviceFormat fails until
there is a real implementation.