ATV Offroad Fury Pro , a green flash right after boot up

[daniel229]

Since PPSSPPWindows64v0.9.5-860-g3983144 ,even it does display in screen in PPSSPPWindows64v0.9.5-859-gd1f054e ,still can see that texture in GE debugger

The video (rename jpg to mp4)

GE debugger

https://gist.github.com/daniel229/ffc8b196817734433970

[daniel229]

I don't see it in PSP and jpcsp. in PPSSPP OpenGL D3D9 software rendering all display that frame.

[unknownbrackets]

Well, the draw you have is a clear. That's just it blanking the screen out, so the flash is something before that - probably whatever is put there before the clear?

The PSP's LCD is kinda sluggish, so maybe it happens and just isn't noticeable...

It's not supposed to show any video or anything there right?

It's also possible that it runs some savedata thing that's supposed to render in some way, I suppose.

-[Unknown]

[daniel229]

That should be nothing there,right after that is Memcpy fbo upload

17:48:088 Init:Main    I[KERNEL]: HLE\sceKernelThread.cpp:1943 299=sceKernelCreateThread(JobManager, 0880dc50, 00000046, 49152, 00004000, 00000000)
17:48:088 Init:Main    I[KERNEL]: HLE\sceKernelThread.cpp:2014 0=sceKernelStartThread(299, 4, 09ffd9d0)
17:48:113 Init:Main    N[COMMON]: GEDebugger\GEDebugger.cpp:632 Waiting at 08ef8aec, FogColor 000000
17:54:545 Init:Main    N[COMMON]: GEDebugger\GEDebugger.cpp:632 Waiting at 08ef8bf4, DRAW PRIM RECTANGLES: count= 16 vaddr= 08ef8b78
19:06:372 Init:Main    I[SCEGE]: Common\FramebufferCommon.cpp:416 Creating FBO for 00048000 : 480 x 272 x 1
19:06:372 Init:Main    W[G3D]: Common\FramebufferCommon.cpp:615 Memcpy fbo upload 04448000 -> 04048000
19:06:375 Init:Main    I[G3D]: GLES\ShaderManager.cpp:160 Linked shader: vs 16 fs 17
19:06:375 Init:Main    I[G3D]: GLES\ShaderManager.cpp:160 Linked shader: vs 19 fs 20

[unknownbrackets]

Yeah, the Memcpy fbo upload is probably a bit unclear in the log. We always upload whatever is in memory to newly created framebuffers.

-[Unknown]

[daniel229]

Also happen in the demo
https://drive.google.com/file/d/0BzGZGDfFE68zUG9KT2YxV1J1azg/view?usp=sharing

[unknownbrackets]

In 088DBD24, it's copying the value passed in a1 (0xDEADBEEF) to the screen. Obviously, 0xDEADBEEF is suspicious. That value is read at 0891503C, from 08C38E50. It's just a little DEADBEEF sitting there in memory.

It seems like that value is even being loaded from the ELF. The ELF occupies 08804000 - 08c91700.

The game never writes to that address, at least not in PPSSPP.

0=sceDisplayGetFrameBuf(09ffd8b0[04000000], 09ffd8b4[000001e0], 09ffd8b8[00000003], 0)
0=sceDisplaySetFrameBuf(04002000, 512, 1, 1)

Basically it does this:

1. Get the current framebuf, which is on.
2. Set a latched framebuf to 0x04002000.
3. Draw black to 0x00048000 over DEADBEEF.
4. Next frame, get framebuf (now 0x04002000.)
5. Replace with 04048000, immediate.
6. Draw black to 0x04002000.

It could be something related to this. I also think I've seen validation stuff happen on the PSP with setting the framebuf - maybe this initial call is supposed to fail?

I tried setting the display params to 0 initially, but this didn't help. It seems to ignore these values anyway.

If the first sceDisplaySetFramebuf were to fail, this would fix it. Should test on a PSP to get the validation right... a JpcspTrace might show it too.

-[Unknown]

[unknownbrackets]

The checks were added in #8743, but didn't help.

It could be that the logic of sceDisplaySetFramebuf is still a bit off. There's IMMEDIATE and NEXTFRAME... but realistically, it seems like "immediate" would happen at next vblank (since the screen won't refresh until then.)

It does fix this to delay all operations until the next vblank start, essentially:

	if (framebufIsPending) {
		gpu->SetDisplayFramebuffer(framebuf.topaddr, framebuf.stride, framebuf.fmt);
	}
	if (framebufIsLatched) {
		DEBUG_LOG(SCEDISPLAY, "Setting latched framebuffer %08x (prev: %08x)", latchedFramebuf.topaddr, framebuf.topaddr);
		framebuf = latchedFramebuf;
		framebufIsLatched = false;
		framebufIsPending = true;
	}

It's kinda hard to test this, but it makes sense. Also, worth noting, the sceDisplayGetFrameBuf calls are happening during the vblank. Moving the latched check to leave vblank doesn't help.

-[Unknown]

[hrydgard]

Actually, if you're willing to accept some frame tearing, switching framebuffers mid-frame is not such a strange concept. Seems IMMEDIATE would be made for that. Though how you'd best emulate that I'm not sure, checking which line we're on and making sure at the end of the frame to blit from the old framebuffer from the top until that line and the new framebuffer down from there?

[unknownbrackets]

Hmm, well, then how do we explain the flash of green here? It happens in the demo, but shouldn't happen.

-[Unknown]