-
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
Allows "merging" render targets that overlap on the Y axis. Fixes Juiced 2 #15717
Conversation
…7295 (Juiced 2) To be safe, gating this behind the related AllowLargeFBTextureOffsets, which is also required for the effect to work. Additionally, fixes the offset check for X offsets, which I guess is a very small risk.
cf985f4
to
04a85b1
Compare
Nice 👍 |
Does Breath of Fire 3 still work (or maybe that was the other kind of overlap only?) I think there was some Silent Hill game triggering this too with 1024 wide buffers in a framedump? I feel like the biggest risk for a change like this being global is that some games will switch between two large 4 byte buffers (for videos or something) to two smaller 2 byte buffers and we get misdetections during that. Not sure how bad it would be to render both frames on the same actual framebuffer... -[Unknown] |
Breath of Fire 3 still works fine, and doesn't seem to trigger this kind of x offset. Don't remember which game did... I guess could find out with some git digging. But I think I'll just revert that particular check to remove the concern entirely. |
Looks like it was originally #6324. I remember some game having interleaved renders, though, pretty sure it was a Silent Hill. -[Unknown] |
I reverted the x-offset bpp change, but the shadows in GoW do work fine even pre-revert. Let's re-apply after 1.13. |
Well, the 4 iirc was just to skip the checks inside if it definitely didn't overlap, the actual x offset and height were checked afterward. I don't think it can break it either way. -[Unknown] |
Hmm, indeed :( Letting the two overlapping render targets merge into one fixed the correctness issue, but as a result, instead we detect "self-texturing" (the render target being drawn into is also the texturing being used) which currently forces us into making a copy of the whole render target, about 30 times... Not great. There are ways to fix this, but it'll have to wait for after the release. In the meantime, the old cheats to turn off the effect probably work. |
Fixes #7295.
Juiced 2 bloom works fine with this. It does some tricky overlap between two render targets.
To be safe, gating this behind the related
AllowLargeFBTextureOffsets
compat flag, which is also required for the effect to work.Also improves logging of multiple matches when binding framebuffers as textures (which was the main clue).
Additionally, fixes the offset check for X offsets to take bytes-per-pixel into account, which I guess is a very small risk.