Support for more past frames in post process effects

[LunaMoo]

What should happen

#14528 but for multiply frames, I suppose 8 being max textures in GLES 2.0 so similar to the other project we could have 7 past and one current as max with no other textures bound.

Who would this benefit

More past frames just means smoother motion blur.
Well I only saw 1 person: https://forums.ppsspp.org/showthread.php?tid=6594&pid=143733#pid143733
but maybe people are just shy to ask, requesting just to eventually have parity with libretro past frame support as with most other stuff PPSSPP shader support(and everything else really) is superior and way more user friendly already.

Platform (if relevant)

No response

Games this would be useful in

not related / all

Other emulators or software with a similar feature

libretro

Checklist

• Check the latest git build in case it's already implemented.
• Search for other requests of the same feature.

[iota97]

I don't think we can get 7 past frames (if we get limited to 8) as we are already binding a sampler to get the original sampler in multi-pass shaders. I would also like to have a spare one for depth buffer eventually.

That being said I'm not qualified to talk about this from a technical stand point.

[hrydgard]

On Vulkan the limits can (with some work) be raised to much higher than 7 frames. Not sure about OpenGL ES or D3D9 though...

[LunaMoo]

I said 7 past frames max if no other textures would be bound, but maybe it could just have lowest priority and use whatever there's left if other features are used.

Or since in higher API versions the limits are also much higher, potentially it could just use less for gles 2.0/d3d9 and more for modern ones.

No idea how much would be too much, but surely at some point we get diminishing returns. The idea of effects that would use it is that the older the frame, the less visible it's set to be, so 7 is possibly an overkill already.

[unknownbrackets]

Yeah, on GLES we'd be limited to closer to 4 more (if we included depth.)

According to this (which seems well researched and thus probably correct):
https://www.reddit.com/r/PSP/comments/cyfuod/psp_lcd_comparison_and_some_stuff_about_the/

The PSP 1000 speed was 30ms each way (rise/decay.) The 3000 has 16/8 and was reportedly "twice as fast" as the 2000.

Outside of complex effects, the most interesting use of this would probably be trying to accurately model the PSP 1000 screen. It seems like even having two previous (at 59.94 Hz) would be sufficient for that. Doesn't seem like four would be all that limiting.

It would be even better, though, if it could render at 120 Hz, and have access to the last 3 (at 59.94) pre-processed (before this processing stage, at least) frames + each of their timestamps, to most accurately simulate the rise/decay.

Currently it provides the last frame post-processed, which I think is better for accumulated effects, but not as good for "triangulating" as above. I feel like generally, the utility of having multiple previous post-processed frames isn't very high. Are there effects that would benefit from that?

-[Unknown]

[LunaMoo]

Yeah it's probably not very high, the forum post I linked has a person loving how smooth it is and those are basically shaders from https://github.com/libretro/glsl-shaders/tree/master/motionblur/shaders
Mainly response-time.glsl, wasn't curious enough how it look's to try libretro >.<

[xunkar]

I'd like to say I am interested in this. But my interest lies in the accurate simulation of a PSP display. Not sure if that requires all 7 frames to achieve, although response_time in RetroArch does seem pretty accurate. I understand demand is low, but I believe the very essence of shaders is precisely to be able to accurately simulate the console's display, which is why it's as as much a legitimate interest as aiming for cycle accurate emulation.

I am however not against setting up a bounty for this particular feature, along with the port of the whole psp shader from RetroArch aptly called "lcd-grid-v2-psp-color-motionblur", which consists of a chain of 3 passes:

response_time (https://github.com/libretro/glsl-shaders/blob/master/motionblur/shaders/response-time.glsl)
lcd-grid-v2 (https://github.com/libretro/glsl-shaders/blob/master/handheld/shaders/lcd-cgwg/lcd-grid-v2.glsl)
psp-color (https://github.com/libretro/glsl-shaders/blob/master/handheld/shaders/color/psp-color.glsl)

I believe this perfectly captures the visual of a PSP display

[LunaMoo]

I believe this perfectly captures the visual of a PSP display

There are like 4-5 different LCD screens + a bunch of replacement screens all varrying in colors, response time and other artifacts, soo much about "perfectly faking PSP display".
The screenshot looks like one of the worse screens with brightness turned down also I think it's really bad idea to keep artifacts enlarged, it will only ever look close to real artifacts when playing at small window which size would depend on the user display pixel density. Playing at full screen on full size monitor with things like that is like using magnifying glass on the real thing or at least placing your eye almost touching the screen, not at all a simulated experience, LCD artifacts weren't that bothersome when experienced on tiny screen held in a comfortable distance.

[xunkar]

I mean, if I grab my PSP, the output is like that, or close enough that it's indistinguishable. Admittedly the screenshot is only for reference, the shader gives a better result live (shouldn't have compressed the image) and on a 2160p monitor.

But that's the thing. It doesn't matter that a realistic shader requires a high end monitor, or only works at a given resolution. As long as it's legit. It's like saying "let's not bother with accurate emulation because it requires too much realtime computations and most computer won't be able to handle it." The goal is 1:1 recreation of the platform. Now, you may not agree with the look of the screen I posted, but emulation the actual LCD of the console is still desirable.

Note that this topic is about a specific component of LCD emulation, which is response time. All I am saying is that implementing this request is meaningful, and I am ready to place a bounty for this AND, on a different but related topic, another to port this particular shader, that I believe (personal opinion here) works best. Your answer felt a little harsh, but let's chalk it down to miscommunication between us. If you think you can develop a more accurate shader for LCD emulation, I'm putting my money towards that too. But my point stands, about response time, and about LCD emulation as a whole.

The thing is, an image will rarely do a shader justice. But the code should. Hopefully, LCDs have specific, controllable behaviors that can be observed and reproduced. It should be possible to recreate that. Sometimes though with visuals it may be that some trickery is required to make it look real, even though it's not the exact behavior, but that remains to be seen. And yes, there are different kind of LCDs depending on which model of the console you're looking at. But the only one you need to concern yourself with is the reference display. Replacement, modded LCDs, emulating wear and tear… Sure, why not. But for a given PSP model there is still only one reference LCD that we should be aiming at emulating as close as possible I believe.