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.