Depal: Reapply texture when bounds change #10956
Conversation
Since we need each slice of the texture when we use bounds to reduce the size. Fixes hrydgard#10951.
| @@ -483,7 +487,7 @@ void TextureCacheGLES::ApplyTextureFramebuffer(TexCacheEntry *entry, VirtualFram | |||
|
|
|||
| framebufferManagerGL_->BindFramebufferAsColorTexture(0, framebuffer, BINDFBCOLOR_SKIP_COPY); | |||
| render_->BindTexture(TEX_SLOT_CLUT, clutTexture); | |||
| render_->SetTextureSampler(TEX_SLOT_CLUT, GL_CLAMP_TO_EDGE, GL_CLAMP_TO_EDGE, GL_NEAREST, GL_NEAREST, 0.0f); | |||
| render_->SetTextureSampler(TEX_SLOT_CLUT, GL_REPEAT, GL_CLAMP_TO_EDGE, GL_NEAREST, GL_NEAREST, 0.0f); | |||
There was a problem hiding this comment.
Hm, does it matter how we access the CLUT (do we go out of bounds somehow)?
There was a problem hiding this comment.
I just copied this from before (the wrapping was lost in the GL render manager changes) - it didn't fix it but I figured I'd keep it.
The actual PSP does wrap access to the CLUT (in the case of using an offset with 32 bit colors in the CLUT, since it's 1024 bytes.) It's an edge case for sure.
-[Unknown]
|
Hm, yes, a bit unfortunate. And I think I see what you mean but that case does not sound common.. might be worth dealing with though. |
|
I guess it's something we could eventually post-process by combining back together, if the juice is worth the squeeze. It'd be ideal to dirty texture image on every return to the CPU, though, as well (since it might change it.) I guess that'd probably have significant performance impact, though. -[Unknown] |
Since we need each slice of the texture when we use bounds to reduce the size. Fixes #10951.
I'm slightly worried we might not be dirtying TEXTURE_IMAGE if the texture is drawn to (e.g. a clear with texturing disabled), which would also potentially use the wrong texture. But this fixes the much more common case.
That said, this case is unfortunate - it's using update stall for each slice of the framebuffer bloom blit, so we can't combine into one draw.
-[Unknown]