Regression in Outrun's environment mapping, assert hit

[hrydgard]

Outrun builds a sphere map by first drawing most of a cube map and then converting to a sphere map which PSP's env map can handle. The middle map seems to get stuck with some noise, which isn't very pretty.

There's also an assert that we hit, the new FB_USAGE_COLOR_MIXED_DEPTH flag prevents downsizing buffers but not completely, this fails for example:

			if (vfb->usageFlags & FB_USAGE_COLOR_MIXED_DEPTH) {
				ResizeFramebufFBO(vfb, vfb->width, vfb->height, true);
				_assert_(vfb->renderScaleFactor != 1);
			}

We hit the assert since Resize ends up its force1x path, so the image remains 1x after the resize, hitting the assert.

In this case, it's about a 64x64 texture, and FB_USAGE_COLOR_MIXED_DEPTH comes from DrawPixels with channel == DEPTH, which happens on the first frame for this texture due to lack of clearing it seems. There's no actual color/depth mixed usage going on.

Here's where the code was added that sets FB_USAGE_COLOR_MIXED_DEPTH:

e5d67119a8#diff-66fdbd9653ac45b624beb6fb8f2259fc5a13b83a25f48a89383145cafd58ba43R1155

I guess that's needed for the Burnout lens flare effect...

[unknownbrackets]

Well, this is caused by #16908 because it made the assert stop passing. The goal of that assert was to ensure we're not needlessly resizing the framebuffer all the time, so it's a good thing it tripped.

-[Unknown]

[hrydgard]

Oh yeah, good point that the assert did catch something really undesirable! And thanks for pointing out the real break.

[hrydgard]

The garbage in the environment map is because of some noise that the depth buffer of it (which it makes no use of, but tests against with GREATER_EQUAL, probably a bug) gets initialized with. The Z and W of the vertices are all set to 1, so would figure it would always pass but it doesn't... It looks like it's using a compressed depth range (ACCURATE_DEPTH style), but the depth buffer initialization doesn't match it. So that's a bug - if the depth buffer noise was in the correct range, it would work, so that's what we should fix.

And/or it could be that we're switching from full depth range to depth rounding, without converting existing depth buffers... because this one is sitting around unchanged between frames.

[hrydgard]

#16947 will fix it once finished.

[hrydgard]

Actually, this is at least superficially fine now with clearing, so I'm closing this specific issue. A depth calculation cleanup is coming.