MotorStorm: Arctic Edge ghosting issue

SolidSnake013 commented 2 years ago

Game or games this happens in

UCES-01250 - MotorStorm Arctic Edge

What area of the game / PPSSPP

Screenshot_20211219-124218_2f85358b2198d26f8aca533d68bee793

Using boost causes a static image to float on screen. Doesn't appear while regular driving, only appears when using boost.

What should happen

It shouldn't appear.

Logs

No response

Platform

Android

Mobile phone model or graphics card

OnePlus 7

PPSSPP version affected

V1.12.3

Last working version

No response

Graphics backend (3D API)

OpenGL / GLES

Checklist

[X] Test in the latest git build in case it's already fixed.
[X] Search for other reports of the same issue.
[x] Try resetting settings or older versions and include if the issue is related.
[X] Try without any cheats and without loading any save states.
[X] Include logs or screenshots of issue.

ghost commented 2 years ago

Can you try the latest ppsspp build? https://buildbot.orphis.net/ppsspp/index.php?m=fulllist

unknownbrackets commented 2 years ago

Does it happen with:

Render resolution set to 1x PSP?
Lower resolution for effects set to Maximum in settings, while render resolution is higher than 1x PSP?

Typically, those settings may help ghosting. I can imagine during a boost, they may have wanted to show a "trail" of the car to emphasize how fast the boost was making it go.

-[Unknown]

SolidSnake013 commented 2 years ago

Can you try the latest ppsspp build? https://buildbot.orphis.net/ppsspp/index.php?m=fulllist

Does it happen with:

Render resolution set to 1x PSP?

Lower resolution for effects set to Maximum in settings, while render resolution is higher than 1x PSP?

Typically, those settings may help ghosting. I can imagine during a boost, they may have wanted to show a "trail" of the car to emphasize how fast the boost was making it go.

-[Unknown]

Tried, no luck. Also tried a bunch of other settings and combinations. I think I'll just accept it and play. Thank you guys anyway.

ghost commented 2 years ago

This is only can reproduce on OpenGL? how about Vulkan?

glitchengineer commented 2 years ago

Have you tried to change the Rendering mode from Buffered rendering to Skip buffered effects (reset the game if it's on during the change)? I had something similar happen in my own issue #15232 changing that settings seems to have fixed it.

SolidSnake013 commented 2 years ago

This is only can reproduce on OpenGL? how about Vulkan?

I tried both. Didn't notice any difference..

SolidSnake013 commented 2 years ago

Have you tried to change the Rendering mode from Buffered rendering to Skip buffered effects (reset the game if it's on during the change)? I had something similar happen in my own issue #15232 changing that settings seems to have fixed it.

Tried, no luck.

SolidSnake013 commented 2 years ago

FIXED: Fixed the issue by creating a fresh new save and using the following settings: OpenGL Skip Buffered Rendering Lower resolution for effects to Aggressive.

Thank you everyone for your help!

ghost commented 2 years ago

I don't think skipp buffered rendering is the right solution. This issue should be reopen.

ghost commented 2 years ago

I have a likely similar issue about this but can only reproduce on vulkan. See https://github.com/hrydgard/ppsspp/issues/12363#issuecomment-1008552835

SolidSnake013 commented 2 years ago

I have a likely similar issue about this but can only reproduce on vulkan. See #12363 (comment)

The over-bright issue you're facing can be fixed by using a cheat that disables bloom.

ghost commented 2 years ago

I have a likely similar issue about this but can only reproduce on vulkan. See #12363 (comment)

The over-bright issue you're facing can be fixed by using a cheat that disables bloom.

Cheat and not using default settings on ppsspp is not a proper fixed.

My issue there is not over bright, watch my screen recording.

71knight commented 2 years ago

That's weird! I'm using the same version of ppsspp on my OnePlus 7T with latest Android 11 version. Everything is working fine on my phone, but then again I'm using the European version of motostorm that fixes the broken shadows. Plus I'm not using any cheats or hacks/fixes.

ghost commented 2 years ago

Try my work around fix @SolidSnake013 https://github.com/hrydgard/ppsspp/issues/15016#issuecomment-1100120282

ghost commented 2 years ago

@SolidSnake013 no feedback?

hrydgard commented 1 year ago

How is this now?

ghost commented 1 year ago

Screenshot_20221129_220057_2f85358b2198d26f8aca533d68bee793

Cannot reproduce this in the recently build.

hrydgard commented 1 year ago

You do still seem to have a corrupt speedomoter graphic though :/

ghost commented 1 year ago

Software rendering also behave like that in speedometer. Screenshot_20221129_221815_2f85358b2198d26f8aca533d68bee793 UCES01250.ppdmp.zip

unknownbrackets commented 1 year ago

Everything looks okay up until 815/896, which looks like this (512x296, the game has some internal AA):

Then through 845/896, it scales it down to 480x272, which still looks fine. 846/896 seems to use a capture of the previous frame at (0x0417c000) to apply the motion effect. 847/896 through 862/896 then update that screenshot for the next frame.

That's when it goes to draw the speedometer from 0x041b4c00, at 863/896. The texture is CLUT4, bufw=128, 128x128, so it's 8KB. It looks completely corrupt:

The CLUT looks maybe believable, though.

Just to map out VRAM a bit:

0x04000000 - 0x04098000: presumably other framebuffer? (extra 8 height to align height to 16, no gap) 0x04098000 - 0x04130000: primary framebuffer in this framedump (extra 8 height to align height to 16, no gap) 0x04130000 - 0x0417C000: primary depthbuffer (extra 8 height to align height to 16, no gap) 0x0417C000 - 0x0419C000: boost framebuffer (no gap) 0x0419C000 - 0x041A4000: car decal (looks corrupt...) 0x041A4000 - 0x041A4400: car decal CLUT (also looks questionable...) 0x041A4400 - 0x041AC400: car decal, left side edition (also doesn't look very convincing) 0x041AC400 - 0x041AC800: left side CLUT (looks the same as the other, both are 8888) 0x041AC800 - 0x041B4800: front/back decal, I think 0x041B4800 - 0x041B4C00: front/back decal CLUT, again looks the same 0x041B4C00 - 0x041B6C00: corrupted (?) speedometer backing 0x041B6C00 - 0x041B6C40: speedometer backing CLUT 0x041B6C40 - 0x041B6C80: perhaps waste, maybe alloc always aligns to 128 for some reason? 0x041B6C80 - 0x041C6C80: speedometer itself (mostly corrupt, maybe until 0x041BFB00 or so?) 0x041C6C80 - 0x041C7080: speedometer CLUT 0x041CBF80 - 0x041CC380: BG for pos 0x041CC380 - 0x041CC3C0: BG for pos CLUT 0x041CC3C0 - 0x041CC400: CLUT alloc waste? 0x041CC400 - 0x041CC800: BG for lap 0x041CC800 - 0x041CC840: BG for lap CLUT 0x041CC840 - 0x041CC880: CLUT alloc waste? 0x041CC880 - 0x041CD480: BG for time (height is 48) 0x041CD480 - 0x041CD4C0: BG for time CLUT 0x041CD4C0 - 0x041CD500: CLUT alloc waste? 0x041CD500 - 0x04200000: Mystery, there's some other texture starting here, but it's not used in this frame... around 202 KB left...

The front/back looks quite funny. I almost wonder if only the CLUT is wrong:

The speedometer itself looks also quite corrupt:

What's interesting here especially is you can mostly see the corruption ends at a certain point 2/3 through the texture. Basically it looks like everything after the boost framebuffer is corrupted. Mapping out the VRAM makes it easy to see that the corruption lasts from the boost framebuffer (0x0417C000) until about 0x041C0000, which happens to be 256 272 4 later. And that's exactly the region/scissor setting for that framebuffer.

Based on verts, the game only ever draws to 256x128, and in fact textures from it using 256x128.

My guess is that:

Somewhere, a block transfer is causing the boost framebuffer to be read to VRAM.
This read is using the detected size (272 height) which is incorrect, and corrupting later VRAM.
If I'm right, this would only happen in software rendering from a save state, but not from savedata.
It's possible this is related to Hook_motorstorm_pixel_read if the game is reading pixels for environment effects.
Hook_motorstorm_download_frame looks suspicious too if it's called here at all, because of the hardcoded framebuffer size (the corruption in our case is 0x00044000 bytes where it should be only 0x00020000 bytes, so a read of 0x000880000 would do it.)
It's also possible there's some framebuffer-as-CLUT or texture-from-framebuffer funny business here, but that wouldn't explain software getting it wrong.

I'm not sure what's reading the frame, we may be able to use the block transfer create framebuf thing to avoid a copy if the CPU doesn't need it, but I think it does for those environmental effects.

Does this render correctly in the software renderer without using a save state?

Edited framedump without any bloom issues (but the VRAM is already corrupt here, looks wrong on PSP as well): #15241_UCES01250_motorstorm_speedometer_edit.zip

-[Unknown]

ghost commented 1 year ago

Yes render correctly in software without using savestate. Screenshot_20221205_163851_2f85358b2198d26f8aca533d68bee793

ghost commented 1 year ago

Looks alright also using vulkan and opengl without savestate. VK Screenshot_20221205_164038_2f85358b2198d26f8aca533d68bee793 OGL Screenshot_20221205_165109_2f85358b2198d26f8aca533d68bee793

hrydgard / ppsspp