Open daniel229 opened 10 years ago
2.another issue is the slowdown since https://github.com/hrydgard/ppsspp/pull/5150
4X resolution
before
after
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.
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. 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
psp
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
I think I broke something in either framebuffer upload or download in that framebuf change...
-[Unknown]
I think fcb70a00b3de3b8c7c2e249dc5f28932b36a39ef will fix that. It fixed a certain spot in Valkyrie Profile.
-[Unknown]
That does not help any of the game.
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]
It does not log anything.
Okay, I think this will do it maybe: d111a8d3ff21efaf7cc14ab25cd79c74dce861c0
-[Unknown]
Yes,that fixes it.
So, #6117 and this are basically about the same thing: blitting the full framebuffer multiple times per frame makes it slow.
-[Unknown]
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
Any solution to this after 3 years? It's impossible to play on phone, and the controls for PC are hard 🌵
there are a lot of GE_PRIM_TRIANGLE_STRIP
and GE_PRIM_RECTANGLES
draw for post process, and these can safely remove.
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;
}
}
//}
...
}
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]
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.
Will look at this again for 1.8.0 but might bounce it to 1.9.0 if time runs out.
Here's a GE Dump for title screen DUMP.ppdmp.zip
This game is the most lag games on ppsspp? Updated GE Dump killzone.ppdmp.zip
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:
But in 2x resolution the GPU hits 99% and the game lags.
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...
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...
But it seems the light effects are missing
I'll have a look at that, might be only on the title screen. The effect is definitely working in-game at least.
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 :(
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.
Unfortunately still not fixed the light effect as of v1.13.1-633-g437d6d30a
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.
Nice improvement 😁
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.
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.
Update: Tested with 1.0-1 build,issue 2 , 4 and 5 is still present.
since the framebuffer-clut merged https://github.com/hrydgard/ppsspp/pull/5767 last working build is v0.9.8-865-g585050dbefore(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)