-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Texture depal using CLUT loaded from framebuffers, and more. Fixes Burnout Dominator lens flare #16014
Conversation
d9b2f51
to
c2b52bf
Compare
Implement CLUT8 depal from 8888 textures. Hard to tell if working
…#11100. Compat flag for now.
c2b52bf
to
d6d7a15
Compare
Added CLUT loads from framebuffers, complete with color reinterpret support, as required by Burnout. So this now works without readbacks in Burnout Dominator, but Ridge Racer's framebuffer margin shenanigans currently break it when it tries to load a CLUT from the margin and we misdetect it as loading from the main framebuffer... EDIT: Never mind, that's fixed now. |
I can remove the CLUT download code entirely now, but can also keep it around in a disabled state. Can be useful for checking the read-back values without using RenderDoc... |
Opening for review, though I have one checkbox left to do so ignore that part if you look at this. |
…he same compat settings.
GPU/Common/TextureCacheCommon.cpp
Outdated
// First we use a blit (with nearest interpolation, so we don't mash pixels together) | ||
// to shrink to the correct size, if we are running with scaling. | ||
// We can always blit 512 pixels even if we only need less, the cost will be negligible. | ||
framebufferManager_->BlitUsingRaster( |
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.
Hm, ideally we'd do this on loadclut. I could totally see a game rendering a clut, loading it, and then rendering straight away on top of the rendered clut. In fact, Brave Story might even do this? I don't remember... well, probably not.
-[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.
Hm, there's one issue here, I think we then have to always copy to the temp here, and do the reinterpret (if needed) at the time of ApplyTextureDepal, since the specified clut format can change in between.
That does sound reasonable though, I will take care of that later. It's just an extra tiny copy in the case of matching formats.
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.
Done!
Thanks, will address these. I got another idea by the way. The CLUT framebuffer gets oversized because we look at viewport and stuff to determine the framebuffer size. I think that for framebuffers that only ever get small through-mode draws, we could keep them in a special mode where we pre-decode each draw to get the positions and only use those for the size - that should help for many oversized targets used in post-processing and similar. But that's out of scope for this one. |
OK so this is still not quite working properly on GLES (the depth masking stuff doesn't seem to work, and it's not about the range scaling, though that should be fixed too) and the heuristics aren't super clean. But I'd still like to get it in, so people can try it, and so that we can build on this, the last issues can be fixed separately. |
Mostly, this is what the "safe area" of framebuffers are already doing, although it's focused on clears. Sizing the actual framebuffer is harder because a lot of these temp buffers get used at different sizes throughout the frame. -[Unknown] |
Right, though extending the safe mechanism to non-clear draws that way might have some use. It indeed won't always fix things though, that's for sure... |
See #11100 .
Some of the stuff I'm doing here I'd really like to generalize better eventually, maybe not all in this PR.
TODO-list:
Will not try to implement this on D3D9, at least not initially. Biggest obstacle is the bitmasking (gonna need lookup table textures, or icky special casing...)
Burnout.Lens.Flare.mp4