Software: Remove texinfo.sourcerow == SourceRow::Colors assert #9832
+0
−2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These asserts were removed for the hardware renderer in dolphin-emu#3684.
|
FifoCI detected that this change impacts graphical rendering. Here are the behavior differences detected by the system:
automated-fifoci-reporter |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
The sourcerow asserts were removed for the hardware renderer in #3684, which was hardware tested. Currently ssbm-mod-lloyd fails the
texinfo.sourcerow == SourceRow::Colorsassertion (sourcerow is set to Tex1).There never was an equivalent for the input form asserts in the hardware renderer (I looked at VertexShaderGen as of 9b16c36 and it didn't exist then). As far as I can tell, nothing hits them (including the Lloyd test), but it does seem suspicious that the z-component is set to 1.0f with the assumption that AB11 is used. I've left the assert since there's a chance that some game uses it, but I haven't hardware tested it myself and don't currently plan on doing so.
Even with the assert fixed, the Lloyd test looks incorrect, see bug 9268. Lloyd is too bright, but also, Sonic looks incorrect. The Lloyd appearance issue applies to the hardware renderer too, but the Sonic one is unique to software and I don't know why it's happening. I think it's still useful to merge this so that the Lloyd test actually runs on fifo.ci because the failed assert currently blocks that.
EDIT: The sonic appearance problem is not related to the assertion in question; the affected objects are 421/422 (counting EFBs separately, they will be 425/426) and are parts of LLoyd's face (I think).