Refactor framebuffer attachment. Fixes Test Drive Unlimited performance

[hrydgard]

Turns on virtual framebuffer copies for Test Drive Unlimited. With this, the game now runs great even on mobile (with Vulkan, at least - haven't yet tested other backends).

Switches framebuffer attachment to a scoring model, where we add a little bonus for matching stride.

Unfortunately, there's some banding, as can be seen in this screenshot, look at the shadow:

Explanation for the banding:

The slow thing the game is doing (which, with this change, no longer requires CPU readbacks) is color correction. It does this by tiling the display, and for each tile look up R, G and B of the rendered framebuffer in a table, separately, adding the outputs of the lookups together. Now, on the real PSP it renders to a 16-bit buffer (565) with dithering, and the dither kind of comes along for the ride through the lookup so the banding isn't so bad.

Now, in PPSSPP, we always render at full 8888 color resolution. When the game uses channels of the framebuffer to look up in a palette, we simply downgrade the (undithered) color and use that for the lookup. No dithering, so we get banding.

We could either dither the converted color values during the lookup according to the pixel coordinate, or we could linearly filter the palette with the extra precision. The latter would not work in many situations though so would require a game specific flag.

The dithering on the original PSP can be seen clearly in this screenshot I found:

Anyway, this at least makes the game very playable without any cheats.

Test Drive has another problem too - the vertex range culling is inaccurate with this game (as we've seen in some other games too), leading to missing triangles. I think we might have to add a compat.ini setting for that unless we can figure out the PSP's clipping once and for all.... (this only affects a beta version of TDU).

[unknownbrackets]

In theory, the dither should be very easy to apply in the shader.

ppsspp/GPU/Software/Rasterizer.cpp

Line 901 in e33c31e

// Dithering happens before the logic op and regardless of framebuffer format or clear mode.

So basically we'd end up with a 4x4 for the displacements converted from 4 bit signed (applied equally to each of rgb), and then we'd just need to get the X/Y to index into that 4x4. Really, we should probably be applying this even on a CPU download, I guess? Correctly, we should use the dither matrix that was used on draw, but I don't think I've ever seen a game change the dither matrix during drawing.

-[Unknown]

[unknownbrackets]

If we're uploading the palette from the CPU anyway, we can detect if it's linear, right?

-[Unknown]

[unknownbrackets]

Ideally, I'd like to get as many cases of range culling working inaccurately as I can to narrow down the use cases. What would really help me is a simple pspautotest with parameters I could tune, so I could find the break off points. I suspect there's just some case the hardware doesn't cull for, but the behavior has seemed wonky so far and to me that just means I need more data.

-[Unknown]

[hrydgard]

Good idea to detect CLUT ramps on upload - we can do some heuristic (such as "always incrementing values") and decided to interpolate the palette in that case indeed.

Anyway, I'll do that later.

[hrydgard]

I'm leaving the dither and/or filtered CLUT lookups to future PRs.

[hrydgard]

I checked the CLUT ramps used - they are indeed nice and consistently increasing up to white, where it stays after the first 32 entries (5 bit lookups since the source image has 5 bit color components). So they are detectable.