Skip to content
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

Merged
merged 4 commits into from
May 20, 2016

Conversation

unknownbrackets
Copy link
Collaborator

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]

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)
Copy link
Owner

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.

Copy link
Collaborator Author

@unknownbrackets unknownbrackets May 20, 2016

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]

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies, I missed that.

Copy link
Collaborator Author

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]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants