Re: [PATCH 2/2] d3dx9_36: Implement triangle filter when create textures
On 08.06.2015 10:02, Sergey Isakov wrote:
On 08.06.2015, at 9:48, Nikolay Sivov wrote:
On 07.06.2015 23:13, Sergey Isakov wrote:
It is probably not triangle filter but works with similar result so I place it in appropriate places. As well load surface and volume works with DXTn textures now. External conversion is a stub. The best test will be graphical. See two sscreenshots: textures made by DxTex.exe (from DirectXSDK), one with point filter, second with triangle filter my version. PS. About copyright. It is my mathematics. (c)Isakov S.L.
+#ifdef DXTN_COMPESSION_SUPPORTED + switch (format) + { + case D3DFMT_DXT1: + if (!wined3d_dxtn_supported()) return NULL; + return encode ? wined3d_dxt1_encode : wined3d_dxt1_decode;
This diff is not against wine-git tree, there's no wined3d_dxtn_supported() funtion in wine.
So why this is a stub. Sure, this diff against wine-git tree recent version.
You mean that's why it's #ifdefed? I don't know if we need this part, that can't be even built, as it's not clear how DXTN_COMPRESSION_SUPPORTED is supposed to be defined and where; but I leave this to actual wined3d devs to respond. P.S. please CC wine-devel next time you reply.
On 8 June 2015 at 09:08, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
You mean that's why it's #ifdefed? I don't know if we need this part, that can't be even built, as it's not clear how DXTN_COMPRESSION_SUPPORTED is supposed to be defined and where; but I leave this to actual wined3d devs to respond.
All other considerations aside, I don't think we want d3dx9 to link against wined3d.
On 08 июня 2015 г., at 22:13, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 8 June 2015 at 09:08, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
You mean that's why it's #ifdefed? I don't know if we need this part, that can't be even built, as it's not clear how DXTN_COMPRESSION_SUPPORTED is supposed to be defined and where; but I leave this to actual wined3d devs to respond.
All other considerations aside, I don't think we want d3dx9 to link against wined3d.
Is this the only reason to not accept any DXTn related patches? Should I remake them with this condition…. or no sense to bother?
2015-06-09 5:18 GMT+02:00 Sergey Isakov <isakov-sl(a)bk.ru>:
On 08 июня 2015 г., at 22:13, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 8 June 2015 at 09:08, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
You mean that's why it's #ifdefed? I don't know if we need this part, that can't be even built, as it's not clear how DXTN_COMPRESSION_SUPPORTED is supposed to be defined and where; but I leave this to actual wined3d devs to respond.
All other considerations aside, I don't think we want d3dx9 to link against wined3d.
Is this the only reason to not accept any DXTn related patches? Should I remake them with this condition…. or no sense to bother?
Thanks for the patch, it's been an interesting read. There are a lot of issues with the patch in addition to the DXTn stuff and that it doesn't apply to WineHQ git but I don't think it makes much sense to go into the details until you fix that. Just a question, mostly for my own curiosity: why did you go for fixed function math? Also the patch is not very compelling at the moment since you're implementing your own filtering algorithm which might be completely different from the MS one. If you're interested in figuring out the actual algorithm used by native you should write a test. For example you could pass a checkerboard pattern image to D3DXLoadSurface with a bunch of src / dest size combinations (e.g. 4x4 -> 8x8, 8x8 -> 4x4, 4x4 -> 12x12, ...) and manually observe the filtered image. There is some chance that it's simple to figure out the filtering formula from that.
2015-06-09 9:34 GMT+02:00 Matteo Bruni <matteo.mystral(a)gmail.com>:
2015-06-09 5:18 GMT+02:00 Sergey Isakov <isakov-sl(a)bk.ru>:
On 08 июня 2015 г., at 22:13, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 8 June 2015 at 09:08, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
You mean that's why it's #ifdefed? I don't know if we need this part, that can't be even built, as it's not clear how DXTN_COMPRESSION_SUPPORTED is supposed to be defined and where; but I leave this to actual wined3d devs to respond.
All other considerations aside, I don't think we want d3dx9 to link against wined3d.
Is this the only reason to not accept any DXTn related patches? Should I remake them with this condition…. or no sense to bother?
Thanks for the patch, it's been an interesting read. There are a lot of issues with the patch in addition to the DXTn stuff and that it doesn't apply to WineHQ git but I don't think it makes much sense to go into the details until you fix that. Just a question, mostly for my own curiosity: why did you go for fixed function math?
Make that "fixed POINT math" -_- Thanks to Stefan for spotting it.
Also the patch is not very compelling at the moment since you're implementing your own filtering algorithm which might be completely different from the MS one. If you're interested in figuring out the actual algorithm used by native you should write a test. For example you could pass a checkerboard pattern image to D3DXLoadSurface with a bunch of src / dest size combinations (e.g. 4x4 -> 8x8, 8x8 -> 4x4, 4x4 -> 12x12, ...) and manually observe the filtered image. There is some chance that it's simple to figure out the filtering formula from that.
participants (4)
-
Henri Verbeet -
Matteo Bruni -
Nikolay Sivov -
Sergey Isakov