hrydgard / ppsspp

A PSP emulator for Android, Windows, Mac and Linux, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues. For discussion use the forums at forums.ppsspp.org.
https://www.ppsspp.org
Other
11.41k stars 2.19k forks source link

Killzone liberation - slow framebuffer CLUT effects, similar to Sonic #6207

Open daniel229 opened 10 years ago

daniel229 commented 10 years ago

Update: Tested with 1.0-1 build,issue 2 , 4 and 5 is still present.

  1. fixed since the framebuffer-clut merged https://github.com/hrydgard/ppsspp/pull/5767 last working build is v0.9.8-865-g585050d before (https://cloud.githubusercontent.com/assets/3481559/3141008/15f10410-e95c-11e3-9b45-15dc9b750324.png)

after (https://cloud.githubusercontent.com/assets/3481559/3141007/15ec311a-e95c-11e3-983e-22144e12721f.png)

daniel229 commented 10 years ago

2.another issue is the slowdown since https://github.com/hrydgard/ppsspp/pull/5150

4X resolution

before 07

after 08

ppmeis commented 10 years ago

Tested latest build. With new option "Force Real Clock Sync" game works much better. Please try again and tell us if it works for you too.

daniel229 commented 10 years ago

That palisading problem is fixed,speed still slow.And other problem or regression.with "Force Real Clock Sync" the game would be slower

3.videoes have a border.When I resize the window,that border gone. 06 log for video 9:42:009 idle0 N[G3D]: GLES\Framebuffer.cpp:706 Est: 44000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:00000000 = 480x272 9:42:009 idle0 N[G3D]: GLES\Framebuffer.cpp:706 Est: 44000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:00000000 = 480x272 9:42:009 idle0 N[G3D]: GLES\Framebuffer.cpp:706 Est: 44000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:00000000 = 480x272 9:42:010 idle0 N[G3D]: GLES\Framebuffer.cpp:706 Est: 44000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:00000000 = 480x272 9:42:010 idle0 N[G3D]: GLES\Framebuffer.cpp:706 Est: 44000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:00000000 = 480x272 9:42:010 idle0 N[G3D]: GLES\Framebuffer.cpp:706 Est: 44000000 V: 480x272, R: 480x272, S: 480x272, STR: 512, THR:1, Z:00000000 = 480x272

4.the light is wrong and moving faster. ppsspp 02

psp 01

daniel229 commented 10 years ago

5.opening video hangs at the end since https://github.com/hrydgard/ppsspp/pull/5245

01:04:420 user_main I[KERNEL]: HLE\sceKernelThread.cpp:2244 sceKernelStartThread(thread=315, argSize=0, argPtr=00000000) 01:04:420 user_main I[ME]: HLE\sceMpeg.cpp:334 Stream offset: 2048, Stream size: 0xB09000 01:04:420 user_main I[ME]: HLE\sceMpeg.cpp:335 First timestamp: 90000, Last timestamp: 7402305 01:04:420 user_main I[ME]: HLE\sceMpeg.cpp:334 Stream offset: 2048, Stream size: 0xB09000 01:04:420 user_main I[ME]: HLE\sceMpeg.cpp:335 First timestamp: 90000, Last timestamp: 7402305 01:04:421 user_main I[ME]: HW\MediaEngine.cpp:85 FF: Format mpeg detected only with low score of 25, misdetection possible! 01:04:424 user_main I[ME]: HW\MediaEngine.cpp:85 FF: No accelerated colorspace conversion found from yuv420p to rgba. 01:09:353 user_main W[ME]: HLE\sceMpeg.cpp:1576 Audio end reach. pts: 7337413 dts: 7312305 01:09:401 user_main I[ME]: HW\MediaEngine.cpp:85 FF: error while decoding MB 8 9, bytestream (td) 01:09:401 user_main I[ME]: HW\MediaEngine.cpp:85 FF: Cannot use next picture in error concealment 01:09:411 user_main W[MM]: MemmapFunctions.cpp:92 ReadFromHardware: Invalid address 00000000 01:09:411 user_main W[MM]: MemmapFunctions.cpp:92 ReadFromHardware: Invalid address 00000088 01:09:411 user_main W[MM]: MemmapFunctions.cpp:92 ReadFromHardware: Invalid address 0000008c 01:09:411 user_main E[MM]: MemmapFunctions.cpp:56 Unknown GetPointer 00000000 PC 00000000 LR 08a15518

unknownbrackets commented 10 years ago

I think I broke something in either framebuffer upload or download in that framebuf change...

-[Unknown]

unknownbrackets commented 10 years ago

I think fcb70a00b3de3b8c7c2e249dc5f28932b36a39ef will fix that. It fixed a certain spot in Valkyrie Profile.

-[Unknown]

daniel229 commented 10 years ago

That does not help any of the game.

unknownbrackets commented 10 years ago

Hmm, so the videos still have borders? If you replace return logOnceUsed.insert(identifier).second; in Core/Reporting.cpp with return true;, does it log anything interesting while the wrongly sized video is showing?

-[Unknown]

daniel229 commented 10 years ago

It does not log anything.

unknownbrackets commented 10 years ago

Okay, I think this will do it maybe: d111a8d3ff21efaf7cc14ab25cd79c74dce861c0

-[Unknown]

daniel229 commented 10 years ago

Yes,that fixes it.

unknownbrackets commented 10 years ago

So, #6117 and this are basically about the same thing: blitting the full framebuffer multiple times per frame makes it slow.

-[Unknown]

daniel229 commented 9 years ago

Update: for killzone tested with 1.0-1 build,issue 2 , 4 and 5 is still present.

Sunday x Magazine Shuuketsu Choujou Daikessen hangs after video same as killzone,since https://github.com/hrydgard/ppsspp/pull/5245

BinkanSalaryman commented 6 years ago

Any solution to this after 3 years? It's impossible to play on phone, and the controls for PC are hard 🌵

weihuoya commented 6 years ago

there are a lot of GE_PRIM_TRIANGLE_STRIP and GE_PRIM_RECTANGLES draw for post process, and these can safely remove.

weihuoya commented 6 years ago

find a dirty hack for this. just skip prim that draw offscreen or copy from offscreen. and then it run 30fps on my phone, still can't run full speed 60fps.

void GPUCommon::Execute_Prim(u32 op, u32 diff) {
    ...
    void *verts = Memory::GetPointerUnchecked(gstate_c.vertexAddr);
    //if (PSP_CoreParameter().compat.flags().KillZoneHack) {
        if (prim == GE_PRIM_RECTANGLES) { // this for game scene
            short* pos = (short*)verts;
            if (pos[0] > 479 || pos[2] > 479) {
                return;
            }
        }
        else if (prim == GE_PRIM_TRIANGLE_STRIP) { // this for game menu
            if (0x12000183 == gstate.vertType) {
                return;
            }
        }
    //}
    ...
}
unknownbrackets commented 6 years ago

But isn't it drawing off screen for a reason? I remember seeing something at some point that suggested to me that it was using the area between strides to render temporary effects, and then texturing that to the screen.

The effect might not be working, and might also be why the light animation doesn't move at the correct pace.

I really hope we don't go the route of PCSX2 and add a library of "skip code" hacks to make games render faster / hack around graphics issues... that's like when we've given up.

-[Unknown]

hrydgard commented 6 years ago

It's a sliding scale between purity and speedhacks but I like the Sonic Rivals-style command list post-processing I did for Vulkan better than skip-hacks, at least as we try to preserve behaviour completely, just rearrange things to not be ridiculously inefficient with modern APIs. It might be possible to do one of those for this game too.

hrydgard commented 5 years ago

Will look at this again for 1.8.0 but might bounce it to 1.9.0 if time runs out.

Panderner commented 3 years ago

Here's a GE Dump for title screen DUMP.ppdmp.zip

ghost commented 3 years ago

This game is the most lag games on ppsspp? Updated GE Dump killzone.ppdmp.zip

Panderner commented 2 years ago

Killzone menu screens are GPU intensive for reasons i tested from my GTX 1050 Ti:

in 1x resolution the GPU usage is average of 60% using DirectX 11: Screenshot (7)

But in 2x resolution the GPU hits 99% and the game lags. Screenshot (6)

hrydgard commented 2 years ago

Killzone general rendering process

Title Screen 5551 framebuffer at 0 (displayed), 8888 Framebuffer at 44000, Z buffer at cc000 (unused). format 8888

standard clear of the left 480x272 rect draw of logo to left 480x272 Some simple text drawn.

Now, first clearing, then texturing from 44000 while writing to 44000, but only writing to the stride gap (rightmost 32x272 pixels).

The clear is a rect draw, then there are two triangle strips. x-range 480-512, y-range 0-135.997925 (half of 272)

Rect draw, easily found (x1 = 480, etc).

X   Y   Z   U   V   Color   NX  NY  NZ
480.000000  136.997803  32767.000000    480.046875  136.500000  00000000    0.000000    0.000000    1.000000
512.000000  136.997803  32767.000000    512.046875  136.500000  00000000    0.000000    0.000000    1.000000
480.000000  270.995850  32767.000000    480.046875  270.500000  00000000    0.000000    0.000000    1.000000
512.000000  270.995850  32767.000000    512.046875  270.500000  00000000    0.000000    0.000000    1.000000

The Y and U coordinates vary a bit (1-2 pixels). X coordinates stay the same (exactly 480, 512).

After doing this a bunch of time, texture from this margin and draw back to the main part of the framebuffer. Scissor is used nicely, 0,0->480x272 for the main, 480,0->32x272 for the border.

In-game, rendering the scene within a 480x272 scissor, then it's doing black-and-white copies to the margin using CLUT32, but never reading them? When doing this, the scissor is 512x272.

Anyway in conclusion, I think with a compat flag and some scissor rect checks, and a negative curRTOffsetX, we can fairly easily do a hack that splits the main framebuffer, which should make this way, way faster. Not sure it'll work in all parts of the game though, it might be that we have to go peek in vertex coordinates. Will give it a shot soon.

Gonna need hacks in DoSetFramebuffer and possibly also in texture matching, or at least fixes there. Actually the texture matching might get tricky... Though we can maybe nudge it away from choosing the current framebuffer...

hrydgard commented 2 years ago

Have something that kinda works but needs a bit more tweaking.

Also noticed that this game seems to have broken timing and renders each frame multiple times, similarly to GoW making it extra slow, but our ForceMax60Fps isn't working because it never moves the display pointer, instead it blits from an 8888 framebuffer onto a 5551 one for display. Will need another tweak...

Panderner commented 2 years ago

But it seems the light effects are missing UCUS98646_00000

hrydgard commented 2 years ago

I'll have a look at that, might be only on the title screen. The effect is definitely working in-game at least.

hrydgard commented 2 years ago

Yeah, I failed to notice that the title screen's method of drawing is actually quite different, and even uses vertices not in through-mode. Will require some additional tweaks. Hopefully there are not even more margin rendering paths later in the game :(

hrydgard commented 2 years ago

Title screen is going to be harder to fix, due to the use of non-through drawing. Still very doable, but I'm gonna do some other things in between I think. At least in-game is perfect now.

Panderner commented 2 years ago

Unfortunately still not fixed the light effect as of v1.13.1-633-g437d6d30a

hrydgard commented 2 years ago

Yeah that's known, it'll be tricky to fix fully (but totally possible). Taking a short break from Killzone right now as we achieved playability and perfect graphics in-game.

ghost commented 2 years ago

Screenshot_2022-09-01-10-46-22-455_org ppsspp ppsspp

Nice improvement 😁

hrydgard commented 2 years ago

Noting to self that when this Vulkan extension is available: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_attachment_feedback_loop_layout.html we can just disable all this hackery and do it directly, becuase with that extension (and that image layout) it becomes permitted to render to a different part of the same texture we're reading from, which is exactly what this game does.

hrydgard commented 2 years ago

I had another look at this and decided to push it to the next version or something - getting the title screen right and performant will actually be a lot trickier than in-game was. Plenty of higher priority stuff to do.