Don't even understand such requests;p. Unless it means making a shader that turns graphics into pixel dump as most ps4 titles are probably indie games with pixel art by now;p.
Postprocessing shaders are very limited in affecting graphics and what they can do will always come at a price of loosing original information, so can only be treated as more or less subtle addition. Definitely not increasing definition and turning ancient gen handheld into current gen stationary console.

//====================================

Made some new effect that might be nice for people with stronger hardware ~ dithering + other blurry debanding, I think it's kind of nice to counter xBRZ which tends to only look good on UI:

xBRZ:

same xBRZ with dithering shader:

Probably better at this point to just use texture replacements, but I'm lazy;p.

It's a simple multiplier, so just set it to 1.0 and it will not exist;p.

The point of it's existence is simple - even nearly transparent scanlines will make the screen darker and most people will want to compensate the colors - separate - from scanlines.

I belive scanline filters will usually do similar thing, without even providing an option, through by smaller value or some more complex math. I'm not really a fan of scanline filters, made this one just to provide a basic scanlines that doesn't suffer from sinusoidal pattern(every x line doubled) and I really disliked how dark it get's.

Edit: I had to check those scanlines to remember how it works and instead of removing an option, I added new one to it;p "noGradient". The way I made it initially was really simple via gradient affecting both scanlines and space between which possibly required a bit higher color compensation, so now it can be disabled turning every "scanline" into a sharp line without affecting the space between them, it's still too dark through ~ I just don't like scanlines;p.

Just tried em out. And I dunno. Still looks like it's merging with other shaders blurring together even with the new option. It also seems like the scanlines over bright objects disappear. Lastly, seems to make a sorta Street Fighter 4 esque posterization effect (water color painting) while they are on. You've solved the scanline thickness problem that most devs have a prob with but they kinda do seem a lil off. Even when putting them at 25% it's super dark. I've tried the scanlines on espxe at 25% and even on retroarch and they don't become this dark at that level.

One other idea I would like to try. Could you do a quick implementation of a shader that takes a png/gif file and places it on screen? I would like to make a fullscreen scanlines png/gif to see if it looks any differently (and for others, it could be used to makes watermarks, gun cursors, bezels, etc for more usage). Either this or try making an option that makes the space between the lines editable (that's because if I put my nose 1 pixel away from the screen, seems like the lines are thicker than the spaces between them even at 1 pixel). Either/or I would like to try. If it is at all possible to make the scanlines sit on top of all of the other shaders isntead of at the same level?, that would be cool too

The problem with them disappearing over bright objects is due to compensated colors getting too high values to mix properly;p, I clamped it now, but only for noGradient option since it will loose a lot of depth with too high compensation and needs more transparent scanlines to avoid darkness without poor colors.

Scanlines shouldn't really do anything like posterization, unless it was due to high color compensation or something, maybe it ends up different on different hardware as I don't see any problem with it. Posterization is generally result of xBRZ texture scaling as well as 5xBR and some other effects, there's nothing in scanlines that would do that, it really is just some basic math to recognize "every other" line, nothing fancy.
As for the order, scanlines are pretty much last, not counting the other set of scanlines and vignette, as well as tests. Which means they ARE on top of everything, if you set them to a bigger size it should be clear that it's not getting any blur or anything else used before it. See here applied on half screen with some other effects:
^such big size also makes it clear the lines as same as the space between them, through it's even easier to just zoom into sl with size of 1 which will fill just every other line of pixels. By general rule human brain is really bad at perceiving repeated patterns, so maybe you're just seeing things, or you used that "ReShade on top of everything as while I never used it I belive it's a third party software which applies effects to the whole screen, so yeah those would come on top of everything that ppsspp would produce.

PPSSPP post process shaders doesn't allow loading any files and I don't see doing that myself unless I end up having lots of free time and nothing better to do;p, it's open source project, so if you really need such feature, feel free to try, it's not like you need some super coding skills to implement new features and all ppsspp code(well all except adhoc;p) is very clean and filled with comments.

Movies still look pixelated. I can use gaussian blur from other sources but that will blur everything. MDEC Filter is from the Petes Opengl 2.9 plugin for epsxe. It blurs videos only so that they won't be so pixelated.

ScaleFX x9 would replace your current hq and xbr filters currently in your shader suite. I've tested this in the retroarch common shaders and the effects are much more smoother than xbr and hq. And I can honestly say it looks just like 6xbrz. So that would counter act xbrz not covering sprites. Plus, it would clean up the shadersuite a bit, getting rid of 2 options in the place of this. Or in the case of FFTactics, it can be used instead of xbrz because the limits of ppsspp's xbrz make spell text unreadable on an interval in that game.
Github info is here: https://github.com/libretro/common-shade...alefx9.cgp

From the end:
- "Guest AA filter" was ported to ppsspp already by naoan in a bunch of different versions, his post should be linked in the first post, to me it doesn't look any different from the fast approximated fxaa implementation that's already included, it also weights about same, so not much point in it,
- upscaling filters are all about style, not power, they invent new pixels which can't universaly fit every game and be better in any way, "xBRZ" is also not a post process, it works on textures and there's many cases where that will look way better than any post process could ever do doesn't matter who would claim what and seriously comparing apples to oranges as they say does not work, anyway PPSSPP does not support multi pass shaders, so you can forget about any effects that requires it including that scale FX and many other shaders from projects that use multi pass shaders,
- ppsspp does not pass any information about video playback to post process shaders either, probably more likely to happen in the future than multi-pass support as it might just need one extra uniform, but not even sure if it would work as expected as psp games tend to do lots of weird stuff with videos aside of just "playing a movie".

About wanting to remove things so badly, I should probably mention that unused effects don't make the shader heavier in any way, everything which isn't activated or overrided by different effect is pretty much skipped and compiled shaders would be as light/heavy with or without unused effects.

If it's only about config visual lenght, then I just added some checks which should now allow removing unused effects from the config part, the downside of that is that it will not validate the code of undefined effects at all, meaning I will have to activate effects I wish to debug, on the other hand, one broken effect will not affect whole shader compilation anymore so I guess it's fine.

Nah, not about that. I don't want to remove anything so badly. If scalefx was able to be inserted, there would be no need for the hq or xbr effects because it is a better version of the same thing. And if it was included, it would be more like a preventing redundancy thing. That's all. Yes I know xbrz is not a shader. But scalefx is right?
Here is my thing, scalefx x9 looks identical to 6xbrz and it doesn't have the fps cost to achieve the visual desire:

Many games stretch textures, if you use xBRZ it will be scaled with choosen power and then stretched, if you use post process, even similar effect will have to work with already stretched texture, in other words the effect will NOT be the same, this get's very obvious in "pixel art" any effects that zoom-in and out as well as for anything which starts blurry.
Another thing when you scale a texture that's it, if game uses a surface with that texture it moves exactly same pixels, if however same surface get's processed in real time via post process effect, algorithm will work slightly differently around the edges causing nasty pattern movements.

As far as stretching goes, these images stem from the nes. Heavily cropped on the left. A bit cropped on the right. And decent croppings on the top/bottom. Afterwards, it is stretched to fill the fullscreen area to prevent those glitchings that happen on the sides of the screen on said nes games.

Easy practical experiment to show what I mean - use a standalone xBRZ software(like the one in texture scaling thread) and some other software for simple resizing like irfan view or whatever to scale some tiny texture three times:
- one at native res scaled with xBRZ,
- another first pre-scaled with nearest filtering, then xBRZ,
- and last also pre-scaled but with bilinear filtering(best with non integer multiplier), then xBRZ.

Results of scaling will look differently because a "pixel", a square that looks like pixel and a blurry cloud that doesn't have any sharp edges are completely different things. The results will also differ depending on the background so if some object is not animated, but moves on the screen, the edges ~ especially if object has some complex shapes ~ will "travel" in similar fasion to aliasing in 3D games, through that would be a bit harder to show without observing an example in-game.

For a shader to produce same result as texture scaling doesn't matter how badly game filters it's textures and what weird effects it uses, it definitely couldn't be a "post process", because such shaders as the name suggests deal with final graphics after all original information of the texture was already lost.

I post here regarding the AA shader 4.o mr. Shinra would like to test. Hey no problem, it's a very fine xBRZ support shader and it can do nice downsampling AA also (the internal resolution should be set to 8x for example).

The "scale" variable in the fragment file should be edited to suit specific tastes, but i guess i found a good compromise with 7x.

(Darn, the cartoon shader could use an update also).

PS: IMO it could replace the AA-color shader and the HQ one.
They are a bit outdated.