2015-06-09 9:34 GMT+02:00 Matteo Bruni matteo.mystral@gmail.com:
2015-06-09 5:18 GMT+02:00 Sergey Isakov isakov-sl@bk.ru:
On 08 июня 2015 г., at 22:13, Henri Verbeet hverbeet@gmail.com wrote:
On 8 June 2015 at 09:08, Nikolay Sivov bunglehead@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.