Juiced 2: Hot Import Nights, screen artifacts and missing half of race tracks

[issuer]

The game has problems with light sources blurring the image, staying forever on screen, also the game is missing half of the asphalt on some tracks. Gameplay-wise is perfectly fine, just graphical issues.
As suggested by unknown, here is the GE Debugger for the game right when the bug happens (after the loading screen and right at start of the race) with all the tabs screenshotted, i've stretched the windows as high as i could:
http://expirebox.com/download/c04b80309ba636314960c73b81fd00c7.html

EDIT: Also the menu is broken in Vulkan:

[hrydgard]

Could the missing asphalt be another spline or bezier issue? Does changing the spline/bezier quality affect it?

[issuer]

Negative. Low, Medium or High quality doesn't seem to have any effect.

[issuer]

Tested it a bit and discovered that Read framebuffers to memory (GPU) or (CPU) fixes the alpha/stencil issue completely, however there is a noticeable speed drop (50%).
The asphalt issue still persisted as well.

Also forgot to tell you this but the cars don't fall through the missing asphalt. The asphalt is there, only we cannot see it. Almost as if it was upside-down.

[unknownbrackets]

Hmm. Most likely if "read framebuffers to memory" resolves it, then it involves one of these things:

• Copying framebuffer data via the CPU in a way we don't detect.
• The game is texturing from the framebuffer in a way we don't support, e.g.
  • Using it with an offset that looks invalid / unreasonable.
  • Treating it as a 4 or 8 bit texture.

I suppose it's likely these:
http://report.ppsspp.org/logs/game/ULUS10312_1.02
Ignoring possible render to texture at 00154000 +0x136 / 256x272 <-- most recent
Ignoring possible render to texture at 04154000 +0x64 / 512x272
Ignoring possible render to texture at 04154000 +0x64 / 512x128

in GPU/GLES/TextureCache.cpp, search for this line:

if (fbInfo.yOffset > MAX_SUBAREA_Y_OFFSET_SAFE && addr > 0x04110000) {

Replace it with:

if (false) {

This will prevent that heuristic. I'm fairly sure this will break certain other games as-is, but it should verify if this is actually causing problems here and whether it's the overlay issue or the asphalt or what.

The basic problem is that we have no way to know the height of framebuffers, so we have to guess. Sometimes we guess too high, especially for framebuffers above 0x04110000, which results in us texturing incorrectly from the framebuffer (render) rather than from memory (loaded texture data.) They're hard to tell apart.

-[Unknown]

[issuer]

I see... i will try it.
Also, i've just noticed something that may be important. Take a look at the picture in the OP, it's not only the asphalt that is missing, the right side track barriers are also missing.
The emulator is rendering the left side track barriers and the right side asphalt but isn't the other way round.

UPDATE: Nope, the light sources still bug the image with light trails. Didn't work.

I took these two screenshots right after the loading screen:

Buffered rendering (the game cutscene is moving to the left)

Render framebuffers to memory (GPU) or (CPU) (the game cutscene is moving to the left)

Software rendering (missing both sides of the track)

[unknownbrackets]

Has this improved at all?

-[Unknown]

[daniel229]

Looks same as before.

[daniel229]

The game flickers since 44cee09 in #8743

[unknownbrackets]

Anything logged?

You can try changing framebuf.stride = 512; back to framebuf.stride = 480; (which is an invalid, impossible value, btw.) Or, change latchedMode == PSP_DISPLAY_SETBUF_NEXTFRAME back to latchedMode == 1 && framebufIsLatched (which is incorrect.)

Hmm.

-[Unknown]

[daniel229]

a log for it

12:54:343 vmemtransfer I[IO]: HLE\sceIo.cpp:940 stdout: transferThreadFunction awake ...
12:54:385 user_main    I[SCEGE]: Common\FramebufferCommon.cpp:414 Creating FBO for 00154000 : 256 x 272 x 0
12:54:387 user_main    I[SCEGE]: Common\FramebufferCommon.cpp:414 Creating FBO for 00165000 : 256 x 272 x 0
12:54:387 user_main    W[SCEGE]: Common\FramebufferCommon.cpp:447 FBO reusing depthbuffer, 00165000/00110000 and 00000000/00110000
12:54:387 user_main    W[G3D]: GLES\TextureCache.cpp:309 Ignoring possible render to texture at 00154000 +0x136 / 256x272
12:56:468 vmemtransfer I[IO]: HLE\sceIo.cpp:940 stdout: transferThreadFunction finished transferring ...
12:56:469 atrac        I[ME]: HLE\sceAtrac.cpp:1898 0=sceAtracSetDataAndGetID(08400000, 001646d0): atrac3+ stereo audio
12:56:469 vmemtransfer I[IO]: HLE\sceIo.cpp:940 stdout: transferThreadFunction sleeping ...
12:56:469 atrac        W[ME]: HLE\sceAtrac.cpp:1601 80630022=sceAtracGetSecondBufferInfo(0, 09fb1a4c[00000000], 09fb1a48[00000000]): not needed
12:56:824 atrac        I[ME]: HLE\sceAtrac.cpp:1898 1=sceAtracSetDataAndGetID(08c1a700, 00020000): atrac3+ mono audio
12:56:824 atrac        W[ME]: HLE\sceAtrac.cpp:1601 80630022=sceAtracGetSecondBufferInfo(1, 09f99a4c[00000000], 09f99a48[00000000]): not needed

latchedMode == 1 && framebufIsLatched helps it,framebuf.stride = 480; doesn't.

[unknownbrackets]

What if you instead change this part:

        // If we update the format or stride, this affects the current framebuf immediately.
        framebuf.fmt = latchedFramebuf.fmt;
        framebuf.stride = latchedFramebuf.stride;

To:

        // If we update the format or stride, this affects the current framebuf immediately.
        if (framebuf.fmt != latchedFramebuf.fmt || framebuf.stride != latchedFramebuf.stride) {
            framebuf.topaddr = latchedFramebuf.topaddr;
            framebuf.fmt = latchedFramebuf.fmt;
            framebuf.stride = latchedFramebuf.stride;
        }

-[Unknown]

[daniel229]

Not help.

[VIRGINKLM]

This bloom bug looks like a framebuffer effect that doesn't get flushed/flushed on time/properly for whatever reason. Am I right? It just keeps adding pixels to the already existing effect.

[LunaMoo]

The "vulkan black menu issue" is actually not about Vulkan, but similar thing to #9545, affects all 3 non OGL backends, and it's also possibly related to depth ~ failing to show after "Clear mode: 000401 (on, depth)", however it's not exactly same because neither the workaround of disabling accurate depth nor the hack mentioned #9545 (comment) affects it in any visible way.

Here's a dump from that, first draw is that background(a movie frame)
ULES00928_0001.zip

I think the "missing road parts" issue does not happen anymore, at least I couldn't find any road with missing parts, it's using bezier curves so maybe it was fixed long ago. I think hardware tesselation might be proving to be glitchy here, but my gpu is too slow for it, so didn't really tested it much.
The buggy effect is still happening althrough I did recently made a cwcheat to remove it, from what I can tell it's just a motion blur that many people would want to turn off anyway.

Here's a dump from in-game that should show problems with hardware tesselation(shadows on the road) and might show how the glitchy motion blur layer is made, however doesn't display it when playing dump:|.
ULES00928_0002.zip

Since I'm updating that might as well mention some video decoding issue:P there's a fragment in the intro:

Gist with log, glitchy frame starts at 34:39.
https://gist.github.com/LunaMoo/800cf094502795fa22947ef747208e8d

[unknownbrackets]

See #8867 for the video frame - it's likely related, it looks similar.

Does the draw after the depth clear have anything strange with depth? If you disable the depth test in the GE debugger, does it prevent the issue?

-[Unknown]

[LunaMoo]

Disabling depth test doesn't help, the only way I found to fix this was decreasing depth of the vertices from FFFF to FFFE.
~ Depth of that framebuffer is set between 0.625 to 65534.984375 so that's probably why FFFF is bad, soo close and yet soo far.:]

[GuilhermeGS2]

I'd like to report some issues I'm having with this game here.

-No car or road reflections
-Motion blur doesn't work, we only have dark borders
-Random slowdown in races (no hardware fault)
-Random crashes

Here are some reports that should help: http://report.ppsspp.org/logs/game/ULES00928_1.00

[LunaMoo]

@GuilhermeGS2 if you're using experimental settings like hardware tesselation - disable it. As I mentioned above, it's glitchy and it's used a lot in this game. It's also very slow(at least for me) and could be the cause of your crashes(dunno as I don't use it, software implementation is many times faster on my hardware even on high).

For most of us motion blur is causing the glitchy layer seen on the very first screenshot of this issue, so if you see it differently, that might also be caused by some non default setting.

[GuilhermeGS2]

@LunaMoo I disabled the non-default settings now I have car reflection, but have those "ghosts" on screen. The performance is fine here, 60 FPS at 4x resolution, but sometimes I have some quick slowdown.

[GuilhermeGS2]

The dark borders I mentioned, but it happens when I use non-default settings:

https://imgur.com/2EdniW3

[LunaMoo]

So I can tell you're using read to memory rendering mode - you really shouldn't, it's unsafe and causes memory corruption that will preserve in savestates, most likely causes crashes you have. That option should and most likely will be removed ~ #6261.

It doesn't even help in this game, it merely breaks the same effect in different way. Best way to get rid of the effect without causing other problems is to just use cwcheat for it. I posted one in game's thread ~ here.

[GuilhermeGS2]

I never used read framebuffer to memory rendering option, the only non-default settings I used was those in "Performance" list in Graphics settings, I enabled all them.

EDIT: And thank you, your cheat works very well here.

[LunaMoo]

Oh sorry, that was only setting I was able to reproduce this, but now I guess it also happens with hardware tesselation, just not where I was checking.
Anyway tesselation problems are just breaking final draws, aren't really causing the motion blur problem.

Basically what happens is game is drawing the road to 0x04000000 and copying it later to 0x04154000 using it to draw all reflections, first on car, then later on the road, later on - it draws lights also to 0x04000000, then moving them to 0x04154000. All of that is good so far, but then it changes target to 0x04165000, disables a texture and uploads some glitchy trash which looks like all what should become part of the motion blur layer, just accumulated from all previous frames(which clearly is wrong), and dark rectangle at the top left corner and moves it on top of 0x04154000 which previously had correct lights before finally drawing it on the screen.
So this effect is most likely broken by some bad/undetected download as the data from previous frame has to be stored somewhere, don't get any triggers when checking what writes to any of those framebuffers through.

[GuilhermeGS2]

The graphic of this game is really beautiful, even on high resolution. This game is one of the most demanding on PPSSPP, to run it on Android you'll need to use Vulkan and have a decent hardware.

[unknownbrackets]

Where does it upload it from? Is it a texture or a memcpy or what?

The source could even be a depth buffer.

-[Unknown]

[LunaMoo]

@GuilhermeGS2 yeah it is one of the prettier games, it's demanding mostly because of 3 things:

• significant amount of draw calls(varying from like 3k to above 12k depending what happens and how much of it you see)
• abuse of bezier curves,
• 60fps.
  Can't do much about draw calls, but setting bezier curves to low and frameskip to 1 should make it much easier on smartphones with small quality reduction.

@unknownbrackets don't really know how to check that as breakpoints doesn't trigger anything. The framebuffer just get's glitchy stuff after this draw:

settings it's using: https://gist.github.com/LunaMoo/b68dc1ecf19b338147d2aba9f8d3f0ce

I guess it might be uploading from transfer dst?

Transfer src	04154000, w=512
Transfer src pos	0,0
Transfer dst	097c7680, w=512
Transfer dst pos	0,0

makes sense since src here is where game draws lights earlier and this glitch literally looks like lights captured from all frames before.:] Why it draws that small rectangle through? That's the small part of the screen which doesn't get glitchy(althrough doesn't get any effect either).
No read or write triggers at that address either through.

[unknownbrackets]

Is it right after - like if you step into until it switches? Whatverts is it using - full screen?

It's doing a draw in 5650, maybe the issue is framebuffer format switching. Maybe this is it trying to clear alpha...

-[Unknown]

[LunaMoo]

Yeah the framebuffer changes right after that draw as you can see:

from the top it shows a dark rectangle from that empty draw, but unless my monitor has a small fly travelling together with me moving the window it doesn't actually look completely empty.:P Seems like those are lights from just the previous frame and then game is blending those with lights from current frame, that would somehow make sense I guess. But why it's not covering everything and just a small area.

Edit: Oh sorry, I copied that after draw;p, heh real size is small and it does use it:

X	Y	Z	U	V	Color	NX	NY	NZ
0.000000	0.000000	0.000000	0.000000	0.000000	00000000	0.000000	0.000000	1.000000
120.000000	27.000000	0.000000	120.000000	27.000000	00000000	0.000000	0.000000	1.000000

[LunaMoo]

What happens later seems to be interesting as well, it follows with many tiny draws like this to cover all framebuffer and moves it slightly around to create blurry image, I think this isn't whole motion blur, which I think actually does exist in game even with this removed, but separate more noticeable motion blur specially for lights.
It probably would work if whole texture was cleared the way that small rectangle does, or maybe more likely if each of those small rectangles would trigger it's own upload of a small portion of the image and was building it piece by piece.

[Panderner]

PPSSPP v1.6.0 Removed read framebuffers to memory, and no way to fix it in latest versions

[Panderner]

Here's what happens when i use save states or minimize PPSSPP for this game:

When i driving the car the light artifacts worse:

When i use save states or minimize it cleans out the lights artifacts:

[LunaMoo]

A reminder:

1. Read Framebuffers to memory was never fixing it, just breaking the game in different way, hiding one thing, but causing other issues as seen even here in the discussion above.
2. For performance problems, lower quality of tesselation, through hardware tesselation was buggy in this game. so if it still causes issues(might be hardware dependant), medium curves with hardware tesselation off is the best performance wise setting(since low enforces hardware solution).
3. I made a cheat long ago to remove the glitch, it's in the game's thread and on my PPSSPP_workarounds repo, only for EU version, but at least there's a way for some people to play it without glitches.

[Panderner]

I remembered that video running PPSSPP (https://www.youtube.com/watch?v=4UHNQG459GI&t) that Skip buffer effects fixes light glitches but has road glitches as mentioned in #11630

But now cars are now invinsible and does not display menus when Skip buffer effects is set as rendering mode:

[ghost]

I remembered that video running PPSSPP (https://www.youtube.com/watch?v=4UHNQG459GI&t) that Skip buffer effects fixes light glitches but has road glitches as mentioned in #11630

But now cars are now invinsible and does not display menus when Skip buffer effects is set as rendering mode:

I also mentioned that issue about skip non buffered rendering here #8171 (comment)

[ghost]

I added this game id fo [AllowLargeFBTextureOffset] but no luck graphics issue still there:(

Latest GE Dump
ULES00928.ppdmp.zip

[hrydgard]

This is some weird framebuffer overlap trickery, which requires both enabling AllowLargeFBTextureOffsets, and also checking for Y offset overlaps when creating framebuffers to work properly (this enables us to create one joint framebuffer out of the two overlapping ones, that works correctly).

[hrydgard]

Okay, fixed, finally :)