Add support for D3DTEXF_FLATCUBIC and D3DTEXF_GAUSSIANCUBIC

[elishacloud]

I put this "fix" in because of #153. It did not fix the issue, but I think it is still a valid update for this project.

Basically, we can see that texture filtering on Direct3D8 filters has two types (D3DTEXF_FLATCUBIC and D3DTEXF_GAUSSIANCUBIC) that are not supported by Direct3D9 filters. This just substitutes those two for another two in Direct3D9, specifically D3DTEXF_PYRAMIDALQUAD and D3DTEXF_GAUSSIANQUAD.

[CookiePLMonster]

What happened to the commit history here? Should be just one commit.

[elishacloud]

Good question, I am not sure how to get rid of those with GitHub. I tried merging the latest from d3d8to9 but the old commits still show up. If you know what I am doing wrong let me know. BTW: crosire can just squash these into a single commit when he accepts.

Also, every time I open another PR the list of check-ins my repository is ahead in will grow. I thought about deleting my repository and starting over, but then I lose all my history as well as my other branches.

[crosire]

I suspect this is because I'm not doing merge commits, I'm always squasing PRs to get a linear history, but since you also did your commits in the main branch, the two get out of sync. This can probably be solved by working in feature branches rather than working in the main branch, since the main branch can then just follow that of this repository.

Do D3DTEXF_PYRAMIDALQUAD/D3DTEXF_GAUSSIANQUAD actually do something? I doubt these is hardware these days that supports these natively, but could be that it's just falling back to D3DTEXF_LINEAR silently, considering this remark in the documentation: "However, applications that enable anisotropic filtering will receive the best available filtering (probably linear) if anisotropic filtering is not supported." Just want to make sure using these doesn't break texture filtering altogether.

[elishacloud]

Good idea about using a branch. I can try and use a branch next time for a PR. But, I suspect it is too late at this point since any branch I create now will just have all the check-ins from my main trunk.

Do D3DTEXF_PYRAMIDALQUAD/D3DTEXF_GAUSSIANQUAD actually do something?

I just tested this. With my laptop hybrid Nvidia GPU and using those just causes my GPU to fallback to D3DTEXF_NONE, which is probably not desired. I don't want to use anisotropic filtering here because that complicates things. There is a way to check if Gaussian quad filtering or pyramidal filtering is enabled. But maybe it is better to just use D3DTEXF_LINEAR for this.

[WinterSnowfall]

@elishacloud I realize I'm "a little late to the party", but if you want to do this translation, it would make sense to also apply it on D3DTSS_MINFILTER and D3DTSS_MIPFILTER. I have a feeling d3d9 will fallback to perhaps D3DTEXF_NONE or even to D3DTEXF_LINEAR on its own in such cases, but that would be very difficult to verify, so sadly we can only speculate.

[elishacloud]

@WinterSnowfall, min and mip filter don't support cubic or gaussian. So no need to do anything for those. Only mag filter supports those. See here.

[WinterSnowfall]

@WinterSnowfall, min and mip filter don't support cubic or gaussian. So no need to do anything for those. Only mag filter supports those. See here.

Fair enough. I doubt the runtime validates their use with min/mip, but if the filters are only intended for magnification, perhaps games won't abuse this. As I previously said, there's most likely some form of fallback on d3d9 end anyway, so indeed it's highly unlikely for this to be a problem.

[elishacloud]

I doubt the runtime validates their use with min/mip, but if the filters are only intended for magnification, perhaps games won't abuse this.

I don't think it matters if games abuse this. If a game puts the wrong value then DirectX will just accept the wrong value, but it will be ignored when actually drawing to the screen. As far as I know, this is the same between Direct3D 8 and 9.