Star Wars Force Unleashed character model regression due to revision 9.6.340

[psennermann]

In Star Wars Force Unleahed starting with PPSSPP 9.6.340 sometimes sprites partially disappear as you can see here:

Here's instead the correct behaviour of 9.6.338:

[psennermann]

Forgot to write that it's on Windows XP 32-bit - Amd Hd4850

[dbz400]

Confirm on my NV system as well .

[dbz400]

Just tested .It is still happening

[hrydgard]

Hm, those aren't sprites, those are 3D models as far as I can tell. Looks weird though, the shadow is properly occluded but still the rest isn't drawn right... Some bizarre depth or transparency problem.

[unknownbrackets]

What are the buffers it's copying depth between? Just want to know their addresses and sizes. Can log them write where it does the blit.

-[Unknown]

[psennermann]

You mean this?

20:49:984 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1597 Decimating FBO for 00164000 (128 x 128 x 0), age 6
20:50:687 System_GameT I[G3D]: GLES\ShaderManager.cpp:146 Linked shader: vs 70 fs 121
20:51:500 System_GameT I[SCEGE]: GLES\Framebuffer.cpp:794 Creating FBO for 00164000 : 128 x 128 x 0
20:51:500 System_GameT W[SCEGE]: GLES\Framebuffer.cpp:814 FBO reusing depthbuffer, 00164000/00110000 and 00000000/00110000

[dbz400]

@unknownbrackets here it is

INFO_LOG(HLE,"source = %08x with size %i x %i , target = %08x with size %i x %i ", 
    sourceframebuffer->z_address, sourceframebuffer->renderWidth, sourceframebuffer->renderHeight , 
    targetframebuffer->z_address, targetframebuffer->renderWidth, targetframebuffer->renderHeight);

22:37:998 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256
22:37:998 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544
22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256
22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544
22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256
22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544
22:37:999 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 951 x 544 , target = 00110000 with size 253 x 256
22:38:000 System_GameT I[HLE]: GLES\Framebuffer.cpp:922 source = 00110000 with size 253 x 256 , target = 00110000 with size 951 x 544

[unknownbrackets]

I thought it didn't blit when the sizes were different? So theoretically, it should not blit between any of those.

-[Unknown]

[dbz400]

Looks like the video is also stretched/duplicated somehow

[dbz400]

If remove linesize != 512 check fix it .This issue happened in other games as well .

[psennermann]

If I may, i have a "simple" question: usually when it doesn't get found the exact revision that caused an issue, it is very difficult to find the origin of the problem, but in this case the revision that caused the issue has been spotted, so I wanted to ask if there is a particular reason why it is so complicated/takes so much time to fix this regression?
Thank you

[psennermann]

Strange, I found out that just changing resolution on the fly fixes the "3d models diseappering" problem of the buffered rendering...

[dbz400]

Originally i expect the video issue to be fixed as well that like Prince of Persia but apparently not

@psennermann , we can fix it but we know it break others at the same time.Probably need more testing and investigation before we can propertly fix it here.

[unknownbrackets]

Is there another FBO that is created right before the video starts, but then isn't rendered to?

-[Unknown]

[dbz400]

@unknownbrackets , there are only two FBO created before the video start .

56:03:740 System_GameT I[SCEGE]: GLES\Framebuffer.cpp:824 Creating FBO for 00154000 : 256 x 128 x 3
56:03:740 System_GameT W[SCEGE]: GLES\Framebuffer.cpp:844 FBO reusing depthbuffer, 00154000/00110000 and 00000000/00110000
56:03:780 System_GameT I[SCEGE]: GLES\Framebuffer.cpp:824 Creating FBO for 00164000 : 256 x 128 x 0
56:03:780 System_GameT W[SCEGE]: GLES\Framebuffer.cpp:844 FBO reusing depthbuffer, 00164000/00110000 and 00000000/00110000

[unknownbrackets]

Well, they are both 256. So if it is writing the video buffer directly to either of those addresses, then it would probably assume the wrong width.

I guess we can change it to more specifically send the width of the framebuffer, from at least psmfplayer.

-[Unknown]

[dbz400]

One interesting thing , if switching resolution let say from 2x -> 3x , the video will be correct .

[unknownbrackets]

Switching resolution forces framebuffers to be deleted and recreated (it also makes the screen flicker.) Since nothing is recreating it, in this case, that makes it go away. But deleting it will cause problems for games that render e.g. subtitles on top of the video.

-[Unknown]

[dbz400]

Probably it is the vfb->stride get wrong when used in UpdateMemory()

     DrawPixels(Memory::GetPointer(addr | 0x04000000), vfb->format, vfb->fb_stride);

[dbz400]

Force vfb->fb_stride to 512 fixed the video here therefore obviously it is the wrong width passing by

[unknownbrackets]

That's what I said an hour ago.

-[Unknown]

[dbz400]

Yep , i also checked videoData->frameWidth is 512 (psmf)