Workaround for some SOCOM games' misuse of CLUT8 to texture from framebuffer

[hrydgard]

Emulating this correctly would be possible too but would only work at 1x rendering resolution.

Quick summary: The game is doing a CLUT texture lookup from the main framebuffer, and adding the result on top of itself to do a super minor brightness adjustment (maybe different in different parts of the game). This isn't really legal but in practice works since it does it in vertical strips that match whatever cacheline size, etc etc.

Anyway, the bad part is that instead of using CLUT16 which is designed for what it's doing (treating a chosen 8 bits of each pixel of a 16-bit texture as a CLUT index and look it up), it instead configures the texture as a double-width CLUT8 texture, then carefully adjusts the texture coordinates and uses nearest filtering so that it that way picks up the correct half of every pixel. This doesn't work when rendering at higher resolutions, so instead, I'm here adding a compat flag to actually follow the intention of the game and treat the texture as CLUT16, which has the exact same effect, but will work at higher rendering resolution.

Previously we rejected this framebuffer texturing case, so instead it'd pickup whatever was in memory and draw that on top of the scene, which caused #16210.

I have to gate this behind the flag, so that we don't catch any other intentional use of this hacky trick.

(Pretty sure this code must have been ported from the PS2, ugh).

Fixes #16210 .

[unknownbrackets]

Yeah, I described this behavior also in the software renderer bugs issue, because it currently has some minor position or texturing issue that makes it render half the scene incorrectly (texturing from the wrong half.) Really annoying trick it uses...

-[Unknown]

[hrydgard]

Oh, I missed/forgot that. Just for the sake of posterity, here's the link: #16131 (comment)