pcsx2
pcsx2 copied to clipboard
[BUG]: Dave Mirra Freestyle BMX 2 - Severe texture corruptions
Describe the Bug
When playing the game at any time, many textures will become corrupted and garbled for a few seconds here and there. Some levels are really bad, most textures doing this very frequently. This game does have automatic gamefixes in GameIndex.yaml that appear to address this specific issue - if I disable automatic gamefixes, the issue gets SIGNIFICANTLY worse, every single texture constantly corrupted. It appears the issue wasn't completely fixed. Software renderer doesn't have this issue. Doesn't appear to be an upscaling issue as it happens at 1x Native.
Reproduction Steps
- Boot up the game.
- Go into any level.
- Ride around for a bit.
Expected Behavior
No garbled textures.
PCSX2 Revision
v1.7.5470
Operating System
Windows 10 (64bit)
If Linux - Specify Distro
No response
CPU
Intel Core i9-10900K
GPU
NVIDIA RTX 2080 SUPER
GS Settings
Deinterlacing set to "Adaptive (Top Field First)"
Emulation Settings
No response
GS Window Screenshots
https://github.com/PCSX2/pcsx2/assets/58268914/b396020f-5183-440a-bfff-d4403ae79605
Logs & Dumps
No response
Please post a multiframe gs dump of the issue.
This is incredibly hard to get a GS dump of because it almost always happens when moving around, hopefully one of these captured the issue, as I bound it to a key and tried pressing it whenever it happened: gs_dumps.zip
Dave Mirra Freestyle BMX 2_SLUS-20159_20240116120528.gs.zip
The first one shows it, attached above.
It looks to be an indexed texture problem. framebuffer conversion hack fixes it, but adds readbacks. Not sure if it's the conversion, or pointing to the wrong place or what.
Can confirm. After disabling automatic gamefixes, applying them manually instead, and turning that option on, the textures are corrected. Are readbacks bad?
yes, readbacks are slow, as it requires reading back from the GPU, which is not quick, so weaker hardware will be impacted.
Something I found that I need to add to this - the texture replacement option can't dump textures properly, even with Framebuffer Conversion enabled:
That's not surprising. The base level pointing to the target would mean the hash changes every time. Working as intended.
Working as intended due to the texture bug anyways. Those textures don't actually look like that ingame, but they dump like that. Additionally, looking at some textures with texture dumping enabled suddenly causes the game to rapidly generate new ones at 50 per second for all textures in the game world, even ones that were dumping fine previously. Restarting emulation fixes it until you look at those textures again.
Yes. The effective LOD is something like 0.9, so that means 10% base level, 90% first mipmap level. Dumping only dumps the base level by default. The developers just screwed up, it'll be like this on console too.
Trilinear:
Forced to LOD 1:
I was playing through the game with Framebuffer Conversion enabled because that fixes the issue for now, however I came across another texture that still does it:
Seems not even that fully fixes it, just reduces it even further. GS dump:
That's also wrong on PS2, see screenshot from my PS2 below.
As Sten previously explained, the first level of the mipmaps (known as the base), is actually pointing at the framebuffer (the main picture) instead of a part of the texture, and it will be using an LOD of 0.7ish, meaning about 30% of what you see, is garbage.
This is a game design problem, not an emulator issue.
That is insane. This game was released on GameCube and Xbox as well, those releases having more content and being overall more polished. I didn't realize it was so unfinished that there's actual software-side texture glitches.
there is a chance it's a core issue, but honestly it's quite unlikely, the way they've designed their mipmapped texture to work just behaves like this.
The game files were recently cracked open to reveal that every base texture has pre-made mipmaps, they all look completely normal, meaning they're loading and then all this happens to them.
That's not how the PS2 game works. The PS2 has 3 register it uses to point to different parts of the texture.
TEX0.TBP0 = base texture (full quality) MIPMAP0.TBP1 = Mip level 1 MIPMAP0.TBP2 = Mip level 2 MIPMAP0.TBP3 = Mip level 3 MIPMAP1.TBP4 = Mip level 4 MIPMAP1.TBP5 = Mip level 5 MIPMAP1.TBP6 = Mip level 6
What the game is doing is this
TEX0.TBP0 = the framebuffer (the picture you see of the game, reinterpreting C32 format as P8 indexed textures) MIPMAP0.TBP1 = texture level 1 MIPMAP0.TBP2 = texture level 2 MIPMAP0.TBP3 = garbage MIPMAP1.TBP4 = garbage MIPMAP1.TBP5 = garbage MIPMAP1.TBP6 = garbage
Then when it displays it on the screen, the LOD of the texture lowest is about 0.7, so it trilinear blends 30% of the framebuffer with 70% of the texture level 1, so you see some of the garbage.
Now if there's a game bug so it doesn't set TEX0 correctly? I have no idea, maybe, it's not impossible, but all I can tell you is that the base level texture is never used in this situation.
My guess is they don't upload the base level because some approximation says the geometry is too far away, kinda like Jak. And thus they just leave TBP0 as 0.
I guess we could look for EE transfers to see if it is being written.
FWIW, BMX XXX has very similar issues. I assume that it's running on the same engine, so not surprising really.