-
Notifications
You must be signed in to change notification settings - Fork 892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
D3D9: Handle binding mismatching texture types #4513
Conversation
Fun game bug in Alpha Protocol:
|
0d8fae0
to
e664f96
Compare
I also tried it with Star Wars Force Unleashed 2 with forceSamplerTypeSpecConst disabled and didn't see any issues. But at the same time I don't remember how difficult it was to hit the bug that made me enable that option for the game in the first place so idk, I think I'll just keep the option for it for now. |
e664f96
to
c5b2384
Compare
Tested a few games without issue |
c5b2384
to
313a399
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nits
313a399
to
7ae2304
Compare
The texture type check makes this redundant.
7ae2304
to
98e74eb
Compare
Done. |
Fixes #4387
Alpha Protocol binds a cube texture to a slot which is declared as a 2d texture in the shader. Binding a mismatching texture type leads yields (0,0,0,0) (yes, alpha 0, unlike binding NULL) on native D3D9. See the table inside the issue.
I also checked that this is checked at draw time, not at the time of the SetTexture call. So binding a shader with a correct texture type afterwards results in correct rendering and the other way around as well.
Because if there's one thing the D3D9 frontend needed, it is more bit field tracking... :)