Flickering block in ATV Offroad Fury Pro (mipmapping)

[daniel229]

Also in the demo.
demo download (NOTE: broken link)
https://drive.google.com/file/d/0BzGZGDfFE68zUG9KT2YxV1J1azg/view?usp=sharing

savestate for demo
https://drive.google.com/file/d/0BzGZGDfFE68zNHZ3eVluOEtTZ3c/view?usp=sharing

GE debugger

https://gist.github.com/daniel229/170dce2a1478697b6c8b

[unknownbrackets]

Pretty sure this is an issue with mipmapping.

Tex filtering min: linear, mipmap linear, mag: linear
Tex level/bias slope + bias: 0.000000
Tex lod slope 0.199997

Because it's grayscale, and using add src * dst + src * dst, the lower mipmap levels are darker. Without the slope bias, we sometimes use the wrong miplevel.

-[Unknown]

[unknownbrackets]

It's currently flickering in softgpu - and using slope. So this probably indicates that slope is more complicated after all (maybe it takes into account w or something?)

Here's a video, just so we can be sure it's not a game bug. It's clearly not flickering:
https://youtu.be/QRkLhrftxZc?t=3m4s

The texture is 0x040e5b40. It's pretty clear that from far away, it should be using the higher (smaller) mip levels, and closer it should be using the nearer ones, which fixes it. Otherwise, it looks far too grainy and flickers (in GLES and in softgpu.)

-[Unknown]

[ghost]

So this is still can reproduce
#14984 (comment)

[hrydgard]

How does this look with "Auto Max Quality" texture filtering? (not that that would be a fix, but at least a workaround)

[ghost]

How does this look with "Auto Max Quality" texture filtering? (not that that would be a fix, but at least a workaround)

My screen recording here #14984 (comment) is already using "Auto Max Quality" vulkan backend.

[ghost]

ge dump in case you needed.
ppsspp dump.zip

[hrydgard]

OK, thanks. Will look into this after the 1.12.x releases are done..

[ghost]

Still flickering and the driver graphics is now pink.

Record_2022-09-14-17-49-16.mp4

[ghost]

I can also reproduce this issue on software mode.

UCES00786.ppdmp.zip

[ghost]

ppsspp v1.13.2 driver is not pink 🤔

Software

Hardware

[unknownbrackets]

That frame dump, on a PSP, also produces a pink driver:

Which might mean some previous drawing or CPU thing caused it? Or frameskip?

The demo does not reproduce this - I just ran it in software and the drivers were the correct colors.

-[Unknown]

[ghost]

Now it's black using the latest build 4b165f9

UCES00786.ppdmp.zip

[ghost]

Software is correct now using the latest build 913ba9d

[ghost]

The driver still black using the recently build.

OPENGL

VULKAN

[hrydgard]

Alright, what's actually going on (barring all the z fighting issues and stuff above, which I do not see):

It draws the level in chunks, first the base layer which is a low resolution texture of the whole level, then it applies a repeating detail texture on top, which brightens things - and this is a problem because it only applies it on blocks that are up to a certain distance from the camera, it seems. So this brightening is visibly flickering into existence.

ATV.Offroad.popping.textures.mp4

These detail textures are drawn on top using the following rather odd blend setup:

We can ignore alpha here since it's not used as a color factor. But the colors themselves are, and effectively this means:

srcCol * dstCol + dstCol * srcCol, or 2 * srcCol * dstCol. If the average of the detail texture was a 0.5 gray, this would work fine and wouldn't look off against the distance where the blending doesn't happen, but, well, it's not, at least not the top mipmaps, which look like this:

The fourth mipmap, however, at 8x8, is full with color 128. So if the game uses trilinear filtering, and makes sure that at the distance where the fourth mip kicks in is less than the distance at which is culls these draws, then the brightness mismatch would at least just fade in instead of pop. And this seems to be what's happening - in the software renderer, the ground is unnaturally brighter close to the camera using this effect. It doesn't look bad actually, might even be intended.

Fixing this in higher resolutions in a way that looks good is non-trivial - if we just push the mip bias to match, we'll pick very low resolution mipmaps and the ground will look blurry.

The best fix here is likely to be a texture replacement. In the meantime, playing on a fast PC using the software renderer will be the best experience here.

[unknownbrackets]

I'll note that we do have a slightly inaccurate slope implementation in software that is not implemented in hardware rendering. See #16276 (d18fc5c.)

In hardware, we force it to auto. It doesn't have to be a fixed push of the mip bias, the game is already providing the slope to indicate that.

-[Unknown]

[hrydgard]

Yeah, that's true - implementing the slope should help - though hopefully the game will only use it on this detail texture and not the base texture, which will in such a case still be condemned to blurriness in the distance.