New CRT shader from Guest + CRT Guest Advanced updates

RetroArch Additions Shaders
#921

Absolutely loving the convergence feature in the shader :+1: :smiling_face_with_three_hearts:

I watched some youtube videos on convergence settings in real CRTs (the retro tech guy has some great videos adjusting stuff, like this one: https://www.youtube.com/watch?v=LvJC6f2dhww) and read a bit further about convergence in real CRTs, amongst others here: Convergence and purity in color CRTs

From what I understand there’s this separation between “static convergence” and “dynamic convergence” and in a real CRT both have their distinct adjustment methods / circuitry.

The wikipedia link above differentiates between static as being in the middle of the screen and dynamic as being towards the edges and corners.

Am I correct in thinking that your current simulation is simulating static convergence fully and dynamic convergence partly?

In my understanding dynamic convergence would add the possibility to be able to adjust individual color beams towards each of the four sides and corners individually. It would be as if you have a magnet on each of the four sides that can be controlled invididually per color. As a result convergence error could (as an example!) be different on the left and right side of the screen, because for example one beam has “inward” error and one “outward” landing error, as painted below for green and red for dynamic convergence.

I appreciate that your current implementation is already catching 95% of the visual convergence impact, so adding more of this dynamic convergence would only be cherry on the pie :slight_smile:

Would love to hear your take on this. Thanks again for creating such a realistic simulation.

beam landing error 3

3 Likes
#922

Seems similar to the “zoom” settings in the glass shader. Except, you mean blue and yellow could theoretically be “inner” and “outer” along the Y-axis in that image, right? So it would be like a sort of monoaxial “zoom” that affects the color channels along selectable axes?

2 Likes
#923

Sounds like it to me, sounds fancy AF

2 Likes
#924

Deconvergence can take many forms and it’s not really feasible to get them all. That is, there’s radial deconvergence, misalignment of the individual electron guns, deconvergence from funky geometry and magnetic stuff, etc., etc.

I think to really cover everything, you’d need to do something like Photoshop’s “warp” tool on each color channel.

4 Likes
#925

This is something I hope to see accurately represented sometime.

3 Likes
#926

I’m really rounding the current development version up and i’m quite content with current deconvergence options, including those from the fine glass shader. With current implementation the vignette effect adds a nicer crt experience, so i rather included this with the current version. Some effects probably won’t be included, it’s nothing unusual though for a shader. :wink:

As it can be seen, downsampling options were already included in the standard version. This makes the shader usable with for example 720p and 1080p content without much speed loss, it also works fine with possible texture scalers.

Honorable mentions go to 240p scanline mode and TATE, looks quite nice.

New Release Version (12.02.2021-r2.1):

Notable changes:

  • Vignette effect/options added.
  • Edit: more vignette options for Syh…
  • Edit: vignette parameter options tuned

Download link:

https://mega.nz/file/olxQmDbb#YYQ_NWmQTXJujPdKfh2wlwrwCtQaF8Yyn1nx5Xgcf3s

9 Likes
#927

Well damnit, now I have to try it today -_-

Be forewarned I’m picky AF about vignette, mainly the controls are an issue, but hopefully this goes well XD.

3 Likes
#928

How do you like your vignettes @Syh? If you’re as picky as you say then I’d like to know.

I think Aero Blasters for the PC-Engine is a good game to test this on because it’s lives counter is at the very edge of the screen.

1 Like
#929

How it gradients, how it handles the hotspot or if it even has a hotspot, how natural it looks.

Personally I try and go for a lighter effect with it but settings are hard sometimes XD (sometimes it’s the codes issue as well sorta, as you literally can’t get what you’re trying to accomplish out of it)

2 Likes
#930

It seems the easiest way to configure vignette here is to…

  1. Max out “Vignette Strength” creating a sort of “corner” effect.
  2. Adjust “Vignette Definition” so that the opaque shadow covers the desired area.
  3. Readjust “Vignette Strength” to preference.
2 Likes
#931

I was just playing with this it this morning, very nice job on the downscaling options!

The sort of blur/resampling switch you have is really helpful to avoid the scintillating/popping pixels effect when down-sampling something with sharp details.

1 Like
#932

@guest.r, i was going to ask you to include the vignette in your shader. Really help to increase the CRT simulation. The flicker is a good option too.

Thanks.

2 Likes
#933

Thanks for this addition :heart_eyes:

I understand you’re rounding up the development version… Hopefully you can still give your thought on the below :grimacing: :upside_down_face:

In previous discussion we sometimes saw people mention that they were very happy with shader output, bet then when they played a “dark” game that the image was too dark for example.

The main reason for that could be that there are quite some aspects in the shader that influence the “darkness” of dark parts and the "brightness "of bright parts, like brightboost dark and bright, scanline shape thickness for dark and bright, scanline saturation etc. that all influence the balance between dark and bright. So if you set brightboost dark “too” low the shader output could look great for an average luminance game (because there’s not much dark) but could look way too dark for a “dark game”. Same with setting scanline shaper dark pixels, if you go for very thin scanlines, but don’t adjust enough with bright boost dark pixels for the lost luminance, you can end up with the same disbalance.

So in the previous user setting the “dark / bright balance” is distorted / unbalanced versus real CRT.

It got me thinking for my own settings too whether there could be an easy way to check this balance.

My current thought is whether it would be possible to overlay a number on the shader output that shows for each individual frame:

  1. average luminance of the raw emulator input image
  2. average luminance of the shader output image
  3. the RATIO between 1 and 2.

The logic would be that in a balanced shader setting this ratio 3 will be constant.

For example if I have 10 grayscale images that increase in 10 equal luminance steps from dark (black) to bright (white) and I feed it in the image viewer, then for each grayscale image this ratio 3 should the same.

Because the relative luminance between the images should stay unaltered with the shader output.

The opposite case would be when a user has lowered bright boost dark too much or raised scanline shape dark pixels too much (too thin dark scanlines) then the average luminance for the shader output of the darker grayscale images will fall more, and the ratio of 3 will show this imbalance by changing ratios for each of the 10 images.

It would be super nice if this ratio could be plotted in realtime on the shader output. Could this make sense in the context of finetuning / balancing shader settings?

1 Like
#934

I invested some time to these issues with brightness while developing crt-guest-sm and development versions had fully implemented automatic brightness correction features, but there is always a catch, since ‘contacts’ between bright and dark colors were oddly interpolated, clipping became an issue and contrast looked artificial.

When it comes to calculating the average brightness of very large buffers i think mip-mapping might even not be supported beyond a certain resolution and if then it might cause a notable slowdown. Mip-mapping is sort-off the only fast way to calculate the average brightness of a buffer containing color information.

I guess the only thing i’m seeing as a good compromise here is the ability to display the original unprocessed image with a parameter, which should give some relevant feedback though.

Edit: The best universal method to compare shaders with original input is to load the stock preset, save it as ‘retroarch1’ for example and then switch between presets with the ‘N’ and ‘M’ keys on the keyboard.

3 Likes
#935

Ah yes, this is something that I’ve been using. Does give some relevant feedback indeed, but “eyeballing” things always has the drawback of not knowing how accurate you are.

I see. Apart from the speed issue, is it something that would be doable? Personally I would not use the feature in normal gameplay, but use it only to check up on testcases, so speed would not be an issue for me. I would probably use it to do some testcases with the image viewer, like the 10 grayscale images, and maybe one or two other testcases to “dot the i’s” on my eyeballed shader settings . So in that sense even if it runs at 1 frame per second it would still be OK :grin:.

Maybe if it’s not too much hassle it’s worthwhile to do a test? IF it would prove to be a useful feature, it could be be implemented as an easter egg / hidden feature in the code for users to enable like the darken scanlines feature? I understand you don’t want to pollute the code, so understand if you would not be happy with that. I think I’m mostly curious to the outcome and whether it could be a helpful tool for “advanced users” to finetune their settings.

Edit: I’m all for the manual settings and highly appreciate the route you’ve taken by removing automatic brightness compensation in the shader. It makes things much more predictable and finetuning has becomes easier because of that. The above should be read in that context, I’m not after any automatic things, it’s purely meant as a tool for further manual finetuning / tweaking. Which is out biggest hobby after all :slight_smile:

1 Like
#936

I’m

I’m getting some noticeable banding in Assault Suits Valken (aka Cybernator). Could some dithering be applied? Or is there a better solution? Or is there no solution?

1 Like
#937

I think it will get solved, probably quite soon. :slightly_smiling_face:

@rafan: last time i tried mipmapping with large output buffers i got no effect, so brightness comparison is sort of hard to do and even if, it would probably not produce accurate results. It’s quite inaccurate unless counting hundreds / thousands of pixels at the same pass towards the result. Not to forget it would be compared with reference emulator output frames and not considering user display, neither any kind of crt displays. Nice idea though, as i mentioned, i also did some heavy brightness related stuff.

New Release Version (13.02.2021-r2):

Notable changes:

  • Vignette effect smoothed at output resolution.
  • Prescale shaders supported, downsampling with pre-scalers supported! (standard version only), two parameters can/must be switched though.
  • Edit: Glow fixed with pre-scaling.

Download link:

https://mega.nz/file/RpgyTRjJ#GcZzBeg9VoN7yRQwK1jym1nVB22ULaDuxtSiXkeFKl4

9 Likes
#938

Hi,

I’m still using the custom xbr preset by modifying the included ntsc preset as you suggested in an earlier post. Really happy with the results when I applied more aggressive values to some of the parameters :smiley:

Screenshot 2021_2_14 上午 12_46_29
Screenshot 2021_2_14 上午 12_46_291920×1080 1.92 MB

I was wondering if you could provide a more properly optimized xbr preset because:

  1. The performance of the custom preset isn’t that great. Around 455fps for nes games. I get 570fps with crt-royale.

  2. I lost access to a few options like noise, more detailed deconvergence settings, smart edges effect, etc that can be found in the other included presets.

I’d be happy if there’s an xbr preset that solves just either one of the issues for me, which would be a slower xbr preset but with all the bells and whistles included in the standard version, or a faster preset with a bit more limited options and/or slightly worse picture quality, probably based on the current fast/fastest version.

IMHO xbr does more good than harm if I’m going for a more heavily textured look with high sharpness. Rarely noticed any over-smoothing or artificially-looking issues in that case.

2 Likes
#939

I’m already running a test version, looks quite nice. :partying_face: Link above updated!

Edit: downsaple parameter can be set to 2.0, for x-scaling see Screen parameters section.

1 Like
#940

If your working on brightness then perhaps I should bring up again that whenever I max out input gamma and output gamma to 5.00 I always get a perfect image in terms of tonal balance.

The way this amplifies the sigma of glow and halation, of course, renders this “trick” unusable. As far as I can tell, however, this seems to be the only drawback.

Perhaps if the “aura effect” of glow and halation were made more independent of the gamma settings, being applied afterward, then maybe the result would be a reliable means of tone correction.

Or, then again, maybe I’m way off base; it’s not like I’ve ever gotten close to the image in my head editing screenshots in GIMP. Either way, if what I’m thinking of were actually accomplished it might mess with contrast levels of @rafan’s earlier noted PVM project.

1 Like