DXTn textures in D3DX9

[Mike Kaplinskiy]

I believe mesa looks for libtxc_dxtn @
http://homepage.hispeed.ch/~rscheidegger/dri_experimental/s3tc_index.html
and then enables full s3tc support. The library itself is tiny and in
(ugly) C, so that is already good news. But as stated on the website,
you cannot use the code due to legality. Maybe there would be a way to
do on-demand loading as with mesa and output a warn/fixme if the
library is not found? It seems like the approach would be similar to
the way the font bytecode interpreter was handled (turn on if
available).

On a sidenote, I may not know what I'm talking about so feel free to
completely disagree.

Mike.

On Sat, May 23, 2009 at 4:48 PM, Henri Verbeet <hverbeet at gmail.com> wrote:
> 2009/5/22 Tony Wasserka <tony.wasserka at freenet.de>:
>> Hi everyone,
>> I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now,
>> but I've got a problem. The function
>> most convert a loaded surface's data to a user specified surface format
>> (I did not yet find a way to do it elsehow,
>> UpdateTexture and StretchRect are to limited for that task, suggestions
>> welcome if I missed anything).
>> Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8
>> surface to DXT1 (or to save a surface to a
>> DXTn compressed DDS file), I'm not sure wether I can implement that
>> behavior; on #winehackers I was told that
>> the (de)compression part is coverered by S3's patents, but the Gimp DDS
>> plugin and this
>> (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS
>> solutions for it anways.
>> So... Can anybody tell me for sure wether I may implement this code or not?
>>
>
> What it comes down to is that I don't think we want to take that risk,
> so essentially "No".
>
>
>