-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Save FBOs on decimate when a safe size is known #8757
Conversation
Verified that scissor affects clears as well. This allows a clear to be detected in Katamari Damacy.
return false; | ||
if (i > 0 && transformed[i].x != transformed[i - 1].x) | ||
return false; | ||
} else { | ||
if ((i & 1) && (transformed[i].color0_32 != matchcolor || transformed[i].z != matchz)) | ||
if (transformed[i].color0_32 != matchcolor || transformed[i].z != matchz) |
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.
Why remove "i & 1"? It's there because only the color of the 2nd of every pair of vertices used to draw rectangles matter in clear-mode.
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.
if ((i & 1) == 0) {
/// stuff
} else {
if ((i & 1) != 0) {
// other stuff
}
}
It's not needed, we're already in the else condition for that check. To me it just makes the code more confusing because it's in the else and makes me have to do a double-take on the code to make sure it's an always-true condition.
-[Unknown]
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.
Apologies, I missed that.
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.
FWIW i > 0
is also always true since the loop starts at 1, but that one isn't confusing.
-[Unknown]
We can know that if an FBO is cleared up to scissor, the size of the clear is definitely <= the size of the FBO. That means we can safely write out the bytes of the clear.
This may help games in #8359 and #6261 as well. I've classified it under a "slow effect", but it mainly makes FBO decimation slower which ought not be common.
-[Unknown]