https://bugs.winehq.org/show_bug.cgi?id=45375
--- Comment #18 from Paul Gofman gofmanp@gmail.com --- (In reply to Connor McAdams from comment #15)
if (ins->handler_idx == WINED3DSIH_RCP || ins->handler_idx == WINED3DSIH_RSQ)
in my patch posted above instead of just the check for RCP. I went through an apitrace dump to figure it out at the time. So, if you'd mind adding in the check for WINED3DSIH_RSQ and seeing if that fixes the other texture issues, that'd be helpful.
Please mind that staging patch already workarounds infinity in RCP, RSQ and LOG with multiply_special = 1. See https://bugs.winehq.org/show_bug.cgi?id=34266#c34 for details, and the patch itself: https://github.com/wine-staging/wine-staging/blob/master/patches/wined3d-zer...
Your patch is still different though as it replaces the result with 0 instead of FLT_MAX.
Comment #6 suggests that the staging workaround replacing inf with FLT_MAX in RCP / RSQ / LOG does not work here, while more generic workaround with multiply_special = 2 works, while some glitches remain, which might be unrelated. Given some problems observed regardless (maybe related to VM exhaustion), I personally don't have yet the confidence that the test results are not biased by the side problems. If it really the case when multiply_special = 1 does not workaround the problem while '... = 2' does, this is very interesting case.
At this point it would be great if someone could test it with the memory problem workaround from Comment #11, to see if this will remove remaining glitches. I don't have a confidence that this is the problem here yet. Yes, one of the logs has single GL_OUT_OF_MEMORY error listed, but it is yet hard to be sure that it is not caused by some other specific problem.
It would also be helpful if someone could describe the way how to get (legally of course) this version of the game and which is the quickest way to get to the glitches in game.