Tony Hawk mipmapping problems on Android, leading to blurry textures.

[Blacob777]

Two games Tony Hawk undeground 2 and project 8 on version 1.4.2 started with soap instead of textures experienced on several nightgown.
version 1.3.0.1 everything is fine with the texture but not so smartly all on a fresh version

[hrydgard]

Soap? Nightgown? Automatic translation? :)

Yes these games have problems, but mostly they just crash after a while, didn't know there were texture issues too. Screenshots?

[LunaMoo]

I guess by soap he ment "washed out", some problem with mipmaps starting from #9678 causes that game to use very tiny textures(I mean they're still same size, but game uses tiny mipmaps for things that are close).

Screenshots:

[unknownbrackets]

Is that at 1x? I guess we could bias mipmaps by something, not sure if it'd need it.

-[Unknown]

[LunaMoo]

Rendering resolution doesn't really affect it ~ texture scaling does since the mipmaps get generated from higher res texture, both of those screenshots were made without it through / using same settings.

[hrydgard]

@unknownbrackets if it was resolution related, you'd expect the mipmaps to be wrong the other way around (too sharp relative to the real thing). So this is probably some unhandled case or bug in the mipmap bias/const code.

[unknownbrackets]

Yeah, I realized it was the opposite problem right after and edited. D'oh.

What are the mipmap settings it's using to render the shrubs? If it's using something like AUTO+4, then previously we were not using the bias, and now we correctly are... does it also look the same in the software renderer? If it looks fine in software, it's probably another generated mipmap issue...

-[Unknown]

[LunaMoo]

SoftGPU looks same ~ buggy, here's a texture tab from one of the affected textures:

Name	Value
Tex U scale	16.000000
Tex V scale	8.000000
Tex U offset	-16.000000
Tex V offset	-8.000000
Tex mapping mode	gen: tex coords, proj: pos
Tex shade srcs	s: 3, t: 1
Tex mode	swizzled, 4 levels
Tex format	CLUT4
Tex filtering	min: linear, mipmap linear, mag: linear
Tex wrapping	wrap s, wrap t
Tex level/bias	slope + bias: 0.000000
Tex lod slope	7.126709
Tex func	modulate, RGBA, color doubling
Tex env color	000000
CLUT	095423a0, w=0
CLUT format	ABGR 8888 ind & ff
Texture L0 addr	095423e0, w=64
Texture L1 addr	09542be0, w=32
Texture L2 addr	09542de0, w=32
Texture L3 addr	09542ee0, w=32
Texture L4 addr	00000000, w=0
Texture L5 addr	00000000, w=0
Texture L6 addr	00000000, w=0
Texture L7 addr	00000000, w=0
Texture L0 size	64x64
Texture L1 size	32x32
Texture L2 size	16x16
Texture L3 size	8x8
Texture L4 size	1x1
Texture L5 size	1x1
Texture L6 size	1x1
Texture L7 size	1x1

The game also uses "auto + bias: -0.500000", but on characters textures and those look correct.

[unknownbrackets]

Okay, so there's definitely more to slope (as in #8481.) We could disable it for now, but I'd like to better understand what it's calculating based on. It's good there are samples now. Maybe we can test using the GE recorder when it's in...

-[Unknown]

[hrydgard]

Yeah, it would be awesome to be able to play back the GE recorder traces on an actual PSP as well...

[unknownbrackets]

Should be doable - that's why I'm allocating everything into PSP RAM. I thought about doing it as an ELF, but the trouble is, then it's a pain to replay a recording in PPSSPP. Anyway, it should be doable the same way.

-[Unknown]

[LunaMoo]

Rename to ppdmp for use with #9780 ~ btw nice feature:)

[hanooty]

I have also this problem
I this from mipmap
I wrote post about this problem before many days but no reply 😢😢

[hrydgard]

You guys with black stuff problems, what Android devices do you have?

[Blacob777]

xiaomi mi5s plus, I noticed that under the adreno emulator is less optimized

[hanooty]

My android device is Samsung Galaxy NOTE_3
RAM 3GB
CPU 2.6 GH

[hanooty]

But in old versions that have a mipmap option working fine

[hrydgard]

Thanks for the info.

Black textures is usually OpenGL's way to warn about an incomplete texture (like, not all specified mip levels uploaded). We did make some changes to the mipmap code so there might be some new edge cases?

[unknownbrackets]

I've added more questions to #9733 - should discuss textures showing as black since the mipmap changes there instead. This issue is (potentially) separate.

-[Unknown]

[LunaMoo]

This is actually same on all platforms. I was testing it above on PC. The only workaround currently is to enable texture scaling since that's the last way available without modifying PPSSPP to disable mipmapping.

Maybe a good solution would be to restore mipmap setting as a compat.ini and force disable it for this game?

Edit: Oh, there was one change I missed - Vulkan shows high res textures without anything. Different mipmap code?

[hrydgard]

Actually I think I'm gonna go for a different approach - I'm gonna disable the LOD bias in "slope mode" which this game uses for mipmaps. Using the direct slope as a bias is wrong anyway.

[unknownbrackets]

Two of the more obvious draws in that dump are 1724/6214 and 5782/6214.

It seems like 1724 (slope = 7.222778) should correctly be level 0 (or at least, below 1.) But it seems like 5782 (slope = 14.864502) should be closer to 1.5 maybe. Both are drawn at similar depth levels, etc.

There's a suggestion that the slope formula may actually be based on Q, or maybe dq?

Correct rendering:

Current GLES:

Software using auto for slope:

Software forcing 1.5 for the Arcade sign:

-[Unknown]

[unknownbrackets]

From further testing, the slope calculation is close to this:

detail = TexLog2(2.0f * w * gstate.getTextureLodSlope());

Note: if w is 1, this is effectively identical to the previous formula (with some minor mantissa difference possibilities), but 2.0f was simply moved inside with the other multiply.

Where w is the projected w. Initially interpolating a flat w (just using the projection matrix to map z into w was the simple way to control it pretty easily) produces values that are close, but still wrong.

For example, with a slope of 23.0f and a w of 0.1f, you get TexLog2(4.6). Notably, TexLog2 ignores the hidden mantissa bit (which was intentional to match AUTO afaict), which makes it calculate 0x22, while the correct value is 0x24.

But there's more to it: using my w adjusted (but entirely flat) triangle, AUTO is also producing invalid values. In my case, AUTO + 0x70 should produce 0x63, but instead produces 0x61, though 0x62 with the correction below. In this case, it's TexLog2(0.568878), which turns into -221. Maybe it's just down to an unrelated difference in ds/dt, or maybe it points to a bug.

That said, I'm thinking AUTO should be TexLog2(std::max(std::abs(ds * width), std::abs(dt * height))) after some testing, though I'm not certain (and this doesn't fix the error above.)

Anyway, using this not-quite-accurate formula with a hacked together w interpolate produces this:

Which has about the right arcade sign, so I do think it's close.

-[Unknown]