Even with Do Overscan 0.00.
Seems okay here. Tell me which version has the problem (and what the “problem” actually is) and I’ll take a look.
Shader downloaded by RetroArch:
Shader downloaded with guest.r’s link:
The screen zoom is intentional. That’s the raster bloom effect. Changing the “bloom percentage” parameter to 0.0 should disable it. It also works in conjunction with the overscan parameter, so setting it to 0.0 should eliminate the overscan cutting, as well.
@hunterk I think he’s referring to the castlevania video posted here: Please show off what crt shaders can do! which shows a broken raster bloom effect. I don’t think that effect can be intentional (just look at the video )
Ah, yeah, you’re right. I’ll see what I can do on that.
EDIT: blegh, it’s related to trying to cut out mipmaps, which seem to be broken on GLES (I know, I know, using mipmaps was my own suggestion…). Anyway, it’ll just have to be broken on GLES.
guest.r’s shader seems to do some weird stuff to Beetle PSX’s (software) scaling: http://screenshotcomparison.com/comparison/127938
The STR on the left if probably the most noticeable thing off.
This is with the shader’s warp, bloom percentage and Do overscan options set to 0. I’m using the slang version. I thought maybe it had to do with the scanline cropping and image offset core options I’m using, but it still looks off with those set to default: http://screenshotcomparison.com/comparison/127939
I didn’t notice the same type of scaling problem with GPGX, SNES9x or PCE Fast. Even using scanline cropping in PCE Fast didn’t seem to have a problem.
Maybe try changing the filtering to linear on all of the passes? There might be some rounding issues with scaling of the passes.
How could be fixed?
Try it now. I added the mipmaps back in a few hours ago.
I updated the shader, but still the same problem…
RetroArch 1.7.5 (01/15/19), MAME 0.205, MK1.
I tested the shader with Street Fighter II: The World Warrior (MAME) without problem.
But continues with MK1, MK2, UMK.
Well, I reverted the version in the GLSL repo back to guest’s original version with zero changes, so if it’s still happening, it’s not anything I’ve done.
The most significant difference between the previous version in the repo and guest’s original is that the repo version had the bloom parameter at 5% instead of guest’s original 0% (not really sure why; might have been committed accidentally from when I was testing some things): https://github.com/libretro/glsl-shaders/commit/493e6bb8550695eb87b632bc109f10f46bdc7cf4#diff-75339648f4af5b33c228f673a1fb8165L24
Did you test with MK1?
No, I haven’t really tested much with it. I noticed Sonic 2’s attract mode crawl showed the issue pretty well in the Chemical Plant zone, so that’s what I’ve been using.
If you load the preset and then remove passes until avg-lum is the last one and then hit ‘apply changes’, it should result in a gray screen that gets slightly lighter/darker over time. If, instead, you see a pixellated black and white version of the game image, that means it’s not decimating the image far enough, and that’s what leads to those harsh transitions.
On the slang version, I used the feedback feature (not available in GLSL, unfortunately) to smooth the transitions with or without mipmaps (I did the same trick with my ‘ambient glow’ border shader).
Regardless, in the version that’s giving you trouble with MK1, is the bloom percentage parameter set to 0 or 5?
Using the slang version, reducing the bloom to 0 like hunterk suggested works fine with my setup. Haven’t had any problems so far.
Bloom percentage 0. This effect was perceptive only after I increased and decreased the “Do Overscan”.