Killzone liberation - slow framebuffer CLUT effects, similar to Sonic #6207
Comments
|
2.another issue is the slowdown since #5150 4X resolution before after |
daniel229
changed the title
|
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. 4.the light is wrong and moving faster. psp |
|
5.opening video hangs at the end since #5245 01:04:420 user_main I[KERNEL]: HLE\sceKernelThread.cpp:2244 sceKernelStartThread(thread=315, argSize=0, argPtr=00000000) |
|
I think I broke something in either framebuffer upload or download in that framebuf change... -[Unknown] |
|
I think fcb70a0 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 -[Unknown] |
|
It does not log anything. |
|
Okay, I think this will do it maybe: d111a8d -[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: Sunday x Magazine Shuuketsu Choujou Daikessen hangs after video same as killzone,since #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 |
|
find a dirty hack for this. just skip prim that draw offscreen or copy from offscreen. 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. |
ghost
mentioned this issue
|
Will look at this again for 1.8.0 but might bounce it to 1.9.0 if time runs out. |
hrydgard
changed the title
|
Here's a GE Dump for title screen |
|
This game is the most lag games on ppsspp? |
hrydgard
added
GE emulation
|
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 standard clear of the left 480x272 Now, first clearing, then texturing from 44000 while writing to 44000, but only The clear is a rect draw, then there are two triangle strips. Rect draw, easily found (x1 = 480, etc). 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. 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... |
Greatly improves performance. See issue #6207
|
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. |
…hes. Need more fixes though to fix the shimmer effect. See #6207 comments
|
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 Color-convert framebuffers that are bound as CLUT textures #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)
The text was updated successfully, but these errors were encountered: