On 30 March 2018 at 04:34, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote:
I would like to hear about support for DTXn. (as long as someone records it for me). Since the patent on this format has expired. It's now officially part of mesa(17?), and since a large number of bugs depend on this missing feature. How could we get implement it quickly?
I don't know about a large number of bugs depending on d3dx9 DXTn support, but it would probably be good to resolve the issue regardless. You'll probably want to look into libsquish [1], either making sure the upstream API is suitable for usage in d3dx9, or perhaps just importing it into the Wine tree. [1] http://sjbrown.co.uk/2006/01/19/dxt-compression-techniques/
2018-03-30 14:41 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>:
On 30 March 2018 at 04:34, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote:
I would like to hear about support for DTXn. (as long as someone records it for me). Since the patent on this format has expired. It's now officially part of mesa(17?), and since a large number of bugs depend on this missing feature. How could we get implement it quickly?
I don't know about a large number of bugs depending on d3dx9 DXTn support, but it would probably be good to resolve the issue regardless. You'll probably want to look into libsquish [1], either making sure the upstream API is suitable for usage in d3dx9, or perhaps just importing it into the Wine tree.
[1] http://sjbrown.co.uk/2006/01/19/dxt-compression-techniques/
I have some patches for that. In the current version libtxc_dxtn is put under libs/, so that it's also usable from wined3d. I also have (previous) versions of the patch just storing the code under dlls/d3dx9_36/ or loading it as a .so but, having seen all of them, I think I prefer the libs/ solution. That said, I'm totally open to discussion about which library to use, how to integrate it and which patches to pick. I haven't looked into libsquish a lot but I thought it was C++?
Hi Matteo, On 31/03/18 04:23, Matteo Bruni wrote:
I have some patches for that. In the current version libtxc_dxtn is put under libs/, so that it's also usable from wined3d. I also have (previous) versions of the patch just storing the code under dlls/d3dx9_36/ or loading it as a .so but, having seen all of them, I think I prefer the libs/ solution. That said, I'm totally open to discussion about which library to use, how to integrate it and which patches to pick. I haven't looked into libsquish a lot but I thought it was C++? libsquish is C++, so it's not going to be of much use. I like the idea of having it in lib, it will solve the issue of distro's not having that package available any more. (Debian, Arch).
Current we have three patchset in staging for DXTn support. https://github.com/wine-staging/wine-staging/tree/master/patches/wined3d-DXT... https://github.com/wine-staging/wine-staging/tree/master/patches/d3dx9_36-DX... https://github.com/wine-staging/wine-staging/tree/master/patches/d3dx9_36-Te... These rely on loading libtxc_dxtn dynamically, so if we start by getting your patch to store it in lib. Then we can update the other patches to reflect this direction. Alistair.
On 31 March 2018 at 04:20, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote:
On 31/03/18 04:23, Matteo Bruni wrote:
I have some patches for that. In the current version libtxc_dxtn is put under libs/, so that it's also usable from wined3d. I also have (previous) versions of the patch just storing the code under dlls/d3dx9_36/ or loading it as a .so but, having seen all of them, I think I prefer the libs/ solution. That said, I'm totally open to discussion about which library to use, how to integrate it and which patches to pick. I haven't looked into libsquish a lot but I thought it was C++? libsquish is C++, so it's not going to be of much use. I like the idea of having it in lib, it will solve the issue of distro's not having that package available any more. (Debian, Arch).
While we may question the choice of language, for an external library that shouldn't be an issue, as long as we can get the upstream project to provide a C API. It would be a minor inconvenience when importing the source into the Wine tree, but libsquish is not a large library. A motivated developer could probably get rid of the C++ bits over a weekend.
Hi Henri, On 31/03/18 11:04, Henri Verbeet wrote
While we may question the choice of language, for an external library that shouldn't be an issue, as long as we can get the upstream project to provide a C API. It would be a minor inconvenience when importing the source into the Wine tree, but libsquish is not a large library. A motivated developer could probably get rid of the C++ bits over a weekend. After having another look, only the one header would possible needed to be changed (squish.h). Which would need to suppress the namespace when compiling with C. All the other other files(headers) are used internally, so aren't an issue.
Alistair.
participants (3)
-
Alistair Leslie-Hughes -
Henri Verbeet -
Matteo Bruni