MotorStorm: Arctic Edge ghosting issue

[SolidSnake013]

Game or games this happens in

UCES-01250 - MotorStorm Arctic Edge

What area of the game / PPSSPP

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

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

[ghost]

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

[unknownbrackets]

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]

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]

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

[glitchengineer]

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]

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

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

[SolidSnake013]

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]

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]

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

[ghost]

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

[SolidSnake013]

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]

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]

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]

Try my work around fix @SolidSnake013
#15016 (comment)

[ghost]

@SolidSnake013 no feedback?

[hrydgard]

How is this now?

[ghost]

Cannot reproduce this in the recently build.

[hrydgard]

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

[ghost]

Software rendering also behave like that in speedometer.

UCES01250.ppdmp.zip

[unknownbrackets]

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]

Yes render correctly in software without using savestate.

[ghost]

Looks alright also using vulkan and opengl without savestate.
VK

OGL