New CRT shader from Guest + CRT Guest Advanced updates

By my criteria, i managed to improve it significantly, now it’s the default method. :smile: Brightness is very nice, contrast between frames strong and scanline traces very mild. It should do i think.

Also gamma_correct now works with interlacing.

Download link (23.12.2020-r1):

https://mega.nz/file/l8Z1XIxb#9T75nwxYCHmkjTZdqhhU6FJh_wKFJ6gdSIh39-uOPeU

7 Likes

Thanks for the further improvement :slight_smile:

I’m noticing a slight “information loss” for some situations still which doesn’t seem to happen with your “2.0 mode 3”.

I hope you’re open to some more finetuning if possible?

I made a testimage for myself and loaded it up in the image viewer. By pressing “p” looking at output of odd and even frames. Below is the testimage and shader output for both odd and even frames, using the default preset.

As you can see for the bright contrast there’s “leakage”/ blending of odd and even frames (shader output on the left) while this doesn’t happen for the dark contrast squares (see output on the right) .

Importantly when I do the same exercise with the “r2.0 - mode 3” (from yesterday) this discrepancy (?) between bright and dark contrast does not happen.

Could the above be related to the fact that I still see some small information loss in some situations with the latest mode 2?

SHADER OUTPUT for the blue and red squares

TESTIMAGE (640x480) testimage-new8

1 Like

you should see 50% information loss on each frame, right? Like, that’s what interlacing is/does?

1 Like

The ‘information loss’ is in fact my top priority for interlacing. The current ‘Normal’ implementation ‘2.0’ is achievable on static images or surfaces with ‘buffered interlacing’ with no frame delay. It would be stupid though to fake progressive image with halved frame rate or other quirks.

Guys, forget about the term information loss.

Let’s try to remain constructive. I’m very well aware that the output of the emulator is a 480p image and that “unweaving” it results in odd and even fields of both 240p (or in the linedoubled case 960 is unweaved to 480p twice).

When I say information loss, I’m seeing less sharpness on the interlaced mode 2.0 than the progressive output of mode 4.0. This should not happen, as 2.0 is the unweaved version of 4.0. So please forget about the term information loss, but re-read it as the following:

With the release of yesterday version 2.0 mode 3.0 (out of 5) I am seeing the same information in interlaced mode as current mode 4.0. However with the latest mode 2.0 of the release of today, I see some instances where the sharpness of the interlaced mode is less than that of mode 3 (out of 5) from the 2,0 release of yesterday.

So for me this code in linearize-ntsc.slang:

current mode 2.0: //if (interm == 2.0) { res = clamp( res1 * max(ii, 0.5) - res1*min(1.0-ii, 0.5), 0.50*min(res1,res2), 1.0.xxx); }

is losing some detail in some intances versus the old mode 3.0:

`	if (interm == 3.0) { res = res1 * max(ii, 0.5); }`

Since I cannot capture what I’m seeing (because of the alternating fields) I try to come up with a test case that somehow illustrates it. However it seems I keep getting the feeling of not being understood and that this issue will remain in the current mode 2.0. Again I’m not critisizing, I just would like to end up with a satisfactory outcome for the interlaced mode.

As said “{ res = res1 * max(ii, 0.5); }`” this one is working very well for me. Maybe I should try to show the difference between the outcome of that and the current 2.0?

@guest.r Again don’t take this as a criticism. Could you load up the below testimage in the image viewer and look at the odd and even frame output of the shader in interlace mode 2.0 by pressing “p”.

Is there anything particular you notice about the output of the shader. Again, please don’t take this as criticism, I’m just trying to get a step ahead illustrating where my issue lies. I just need to know whether you see anything strange.

TEST IMAGE 640x480

testimage-new9

EDIT:

below is the shader output enlarged. -only- output of the odd frame of interlaced mode 2.0 (even field output illustrates a similar case for the blue squares)

I’ve put the remarks below in the image. I’ll keep stressing this: it’s not meant as a criticism. So when it says “why?” I’m genuinly interested in the why? (It’s not some underwater criticism).

I think there are too different priorities with test cases.

My priorities are:

  • smooth output
  • regular distinction between odd and even frames
  • acceptable brightness loss
  • recognizable isolated pixels
  • antialiasing effect
  • visually appealing combined temporal effect on static parts of the image
  • no unnecessary artifacts on with combined temporal effect
  • suitability for rl usage a.k.a. gaming
  • fast effect, not too complicated, but still probably achievable with a couple of frames of frame history, with original image resolution.
  • etc.

I’m not programming the effect with real interlaced input, where my goal would be to create as real as possible progressive approximation, so i like it a bit messy. Comparable, like with crt emulation rf/composite is more appealing compared with svideo emulation. :wink:

I think i have gone trough many situations and found o couple of good compromises. But i’m not including a more appealing effect if it’s too fake.

2 Likes

Thanks for the answers. I clearly see where you’re coming from and your shader is nothing short of amazing. It let’s us all relive retro gaming as it is meant to be. Let’s reiterate that, and let there be no doubt about it. You’ve obviously invested a ton of time getting it where it is. The latest improvements to the interlacing are a significant improvement to the previous version, no doubt about it.

It’s highly appreciated :smiley: :smiling_face_with_three_hearts:

So the thing with the interlacing is only about some tiny artifacts. It’s 99% great, and maybe 1% there are some tiny artifacts. Since they are only slightly bothering when you know where they are, I tried to make it clear and see if we could polish out that last 1%.

Below is my last illustration of these tiny artifacts with your latest change. First is the emulator output full image. The interest for the artifacts is with this tiny 1 pixel wide “no copy” and the 1 pixel diagonal black line on the “Z”. Note that these are in the original 1 pixel wide.

Below is also the cutout of the shader with the two interlace modes that matter. It’s the latest 2.0 and below that the one from yesterday, the “3.0” you removed later again. Odd and even field output put next to each other. The enlarged image shows how there are small artifacts produced with the current 2.0 version when there are tiny black details, like with the 1 pixel “no copy” and the diagonal of the “Z”.

It could be that the clamping or substraction is cutting of some values to black with the current 2.0. Anyway, maybe it’s something that shines a light on possibly how these small artifacts can be polished out with the current implementation or not.

In the latter case, could you possibly consider to (re-)add the interlace mode 3.0 from yesterday as a separate mode? (if (interm == 3.0) { res = res1 * max(ii, 0.5); })

I think I like your current 2.0 better overal, but in some situation the tiny artifacts are sticking in the eye when you know them :wink: Yes I agree this is completely category OCD, but hey haha :slight_smile:

Original

Illustration of small artifacts on odd and even field output

1 Like

I’ll probably have to introduce modifications to interlacing and i have to explain a bit, that interlacing should be also considered trough the temporal effect. These ‘smal artifacts’ are actually strengthening isolated pixels/lines in many cases, therefore producing a bit crisper appearance - but only trough the interlacing effect with full frame rate. Screenshots of odd/even frames can’t show the final perception, which is a bit sad, but a part of reality.

And why i shouldn’t keep old mode3 ? Because there is too much leakage between frames and is therefore too fake. I also test the effects on quite small samples and the combined artifact effect is beneficial for better contrast, which is quite nice.

4 Likes

I have a problem with the newer versions of CRT Guest, and no matter what I try I can’t seem to resolve it unless I choose to stick with the older version.

When I use version 25.11.2020 Release 1, the colors in my games look as they should. Here is a screenshot of the Sony Logo on the PS1 Bios for an example.

Now when I delete the old “guest” folder in Release 1 and replace that folder with the “guest” folder and its contents from 25.11.2020 Release 2, all of a sudden the colors instantly become excessively bright and blown out of proportion.

I can’t figure out the culprit of this issue and this is why I haven’t updated to the latest version of this shader as this issue occurs with every new update from that point on. I have noticed that Release 2’s default preset includes an extra pass from the default seven passes, the fifth pass being a “linearize” pass that I don’t use with Release 1. When I try to modify my current .slangp file for my custom configurations of this shader, it will not load and it tells me that Retroarch failed to load the shader, so I can’t even diagnose if this is the issue or not. I can’t just edit the .slangp file to add an extra pass; if I am doing something wrong I am not aware of what as I have tried to format it as such so that Retroarch would properly read it.

If I load the old shader preset that looks whitewashed, add an extra pass within Retroarch, and rearrange the passes so that the Linearize pass is the fifth shader pass in the eight passes, it will still tell me that Retroarch failed to load the shader. Because of this issues I am currently sticking to version 25.11.2020 Release 1. If someone could be, I would greatly appreciate it :slight_smile:

I have a custom configuration setup for this shader and I don’t want to mess that up, and so I would like to just update the shader to the latest version and have it still work with my custom .slangp presets so that I can just drop in the update and test it on the fly. I’m not sure if this makes any difference but in place of the stock.slang that is set in the default preset, I am use grade.slang, so I can calibrate each game’s colors based on region.

1 Like

@ProfessorBraun i think found a bug with curvature, which is in fact caused by a coordinate shift if using mipmapping, so linearization best happens in an extra pass after the pass with mipmapping. Prior it was happening in the ‘pre-shaders’ pass.

The best strategy to use the newest version, which works well standalone, is to use it completely, including presets and just copy the parameter values to it from the old saved preset. You should add grade to the preset though before doing this.

Looks like gamma is not set correctly. It can be set with shader parameters, but i think if you use the preset upgrade method described above, it should work from the start.

2 Likes

New release version (24.12.2020-r1 -> 25.12.2020-r1).

Notable changes:

  • interlacing color artifacts removed
  • interlacing options simplified, smoothing option added, as well as contrast/scanline
  • some optimizations with interlacing

Feedback is welcome, hopefully there are no annoying bugs.

Download link:

Edit: new download link, a situation with metal removed.

https://mega.nz/file/5lolUYiL#vyu1BZCGE_SU9EsvRCHx7nF8V2Qk47eZnoiWYyz2kUw

9 Likes

Thank you and happy holidays :partying_face:

5 Likes

Thank you!

And also happy holidays to everyone. :partying_face:

8 Likes

Merry Xmas :christmas_tree: :cake: :gift:

5 Likes

Doesn’t seem to work at all, in either RetroArch or OpenEmu.

Are you placing the files under \RetroArch\shaders\shaders_slang\crt ?

1 Like

A more detailed description of the problem is necessary. I could also guess you copy over the files to the shaders/slang/crt … and run the old preset…which doesn’t work.

@guest.r I thought you might find this odd bit of settings interesting. I can get scanlines on higher res games if I mess with Tate, interlacing, and mask size at 4k but on a 1080 monitor. I’m not sure what’s happening but it kinda works. The second shot is Vagrant Story for the PS1 upscaled 8x. Everything is sharp but still has scanlines.

shaders = "8"
shader0 = "shaders_slang/sharpen/shaders/fast-sharpen.slang"
filter_linear0 = "true"
wrap_mode0 = "clamp_to_border"
mipmap_input0 = "false"
alias0 = "StockPass"
float_framebuffer0 = "false"
srgb_framebuffer0 = "false"
scale_type_x0 = "source"
scale_x0 = "1.000000"
scale_type_y0 = "source"
scale_y0 = "1.000000"
shader1 = "shaders_slang/crt/shaders/guest/crt-gdv-new/afterglow0.slang"
filter_linear1 = "true"
wrap_mode1 = "clamp_to_border"
mipmap_input1 = "false"
alias1 = "AfterglowPass"
float_framebuffer1 = "false"
srgb_framebuffer1 = "false"
scale_type_x1 = "source"
scale_x1 = "1.000000"
scale_type_y1 = "source"
scale_y1 = "1.000000"
shader2 = "shaders_slang/crt/shaders/guest/crt-gdv-new/pre-shaders-afterglow.slang"
filter_linear2 = "true"
wrap_mode2 = "clamp_to_border"
mipmap_input2 = "false"
alias2 = "PrePass"
float_framebuffer2 = "false"
srgb_framebuffer2 = "false"
scale_type_x2 = "source"
scale_x2 = "1.000000"
scale_type_y2 = "source"
scale_y2 = "1.000000"
shader3 = "shaders_slang/crt/shaders/guest/crt-gdv-new/avg-lum.slang"
filter_linear3 = "true"
wrap_mode3 = "clamp_to_border"
mipmap_input3 = "true"
alias3 = "AvgLumPass"
float_framebuffer3 = "false"
srgb_framebuffer3 = "false"
scale_type_x3 = "source"
scale_x3 = "1.000000"
scale_type_y3 = "source"
scale_y3 = "1.000000"
shader4 = "shaders_slang/crt/shaders/guest/crt-gdv-new/linearize.slang"
filter_linear4 = "true"
wrap_mode4 = "clamp_to_border"
mipmap_input4 = "false"
alias4 = "LinearizePass"
float_framebuffer4 = "true"
srgb_framebuffer4 = "false"
scale_type_x4 = "source"
scale_x4 = "1.000000"
scale_type_y4 = "source"
scale_y4 = "1.000000"
shader5 = "shaders_slang/crt/shaders/guest/crt-gdv-new/gaussian_horizontal.slang"
filter_linear5 = "true"
wrap_mode5 = "clamp_to_border"
mipmap_input5 = "false"
alias5 = ""
float_framebuffer5 = "false"
srgb_framebuffer5 = "false"
shader6 = "shaders_slang/crt/shaders/guest/crt-gdv-new/gaussian_vertical.slang"
filter_linear6 = "true"
wrap_mode6 = "clamp_to_border"
mipmap_input6 = "false"
alias6 = "GlowPass"
float_framebuffer6 = "false"
srgb_framebuffer6 = "false"
scale_type_x6 = "viewport"
scale_x6 = "0.500000"
scale_type_y6 = "viewport"
scale_y6 = "0.500000"
shader7 = "shaders_slang/crt/shaders/guest/crt-gdv-new/crt-guest-dr-venom2.slang"
filter_linear7 = "true"
wrap_mode7 = "clamp_to_border"
mipmap_input7 = "false"
alias7 = ""
float_framebuffer7 = "false"
srgb_framebuffer7 = "false"
scale_type_x7 = "viewport"
scale_x7 = "1.000000"
scale_type_y7 = "viewport"
scale_y7 = "1.000000"
parameters = "SHARPEN;CONTR;DETAILS;bogus_afterglow;PR;PG;PB;AS;sat;bogus_color;TNTC;CP;CS;WP;wp_saturation;lsmooth;GAMMA_INPUT;bogus_interlacing;inter;interm;bogus_glow;SIZEH;SIGMA_H;SIZEV;SIGMA_V;bogus_brightness;glow;bloom;gamma_c;brightboost;brightboost1;bogus_scanline;gsl;scanline1;scanline2;beam_min;beam_max;beam_size;vertmask;scans;spike;bogus_filtering;h_sharp;s_sharp;smart_ei;ei_limit;sth;bogus_screen;TATE;IOS;OS;BLOOM;csize;bsize;warpX;warpY;bogus_masks;shadowMask;maskstr;masksize;maskDark;maskLight;mcut;mask_gamma;slotmask;slotwidth;double_slot;slotms;mclip;gamma_out"
SHARPEN = "0.250000"
CONTR = "0.250000"
DETAILS = "1.000000"
bogus_afterglow = "0.000000"
PR = "0.140000"
PG = "0.140000"
PB = "0.140000"
AS = "0.070000"
sat = "0.100000"
bogus_color = "0.000000"
TNTC = "0.000000"
CP = "5.000000"
CS = "1.000000"
WP = "-25.000000"
wp_saturation = "1.500000"
lsmooth = "0.750000"
GAMMA_INPUT = "2.400000"
bogus_interlacing = "0.000000"
inter = "0.000000"
interm = "4.000000"
bogus_glow = "0.000000"
SIZEH = "25.000000"
SIGMA_H = "3.999997"
SIZEV = "1.000000"
SIGMA_V = "0.500000"
bogus_brightness = "0.000000"
glow = "0.010000"
bloom = "0.000000"
gamma_c = "0.920000"
brightboost = "1.999999"
brightboost1 = "2.099999"
bogus_scanline = "0.000000"
gsl = "0.000000"
scanline1 = "0.000000"
scanline2 = "25.000000"
beam_min = "2.499999"
beam_max = "0.650000"
beam_size = "0.900000"
vertmask = "0.000000"
scans = "1.000000"
spike = "1.000000"
bogus_filtering = "0.000000"
h_sharp = "5.200000"
s_sharp = "0.500000"
smart_ei = "0.000000"
ei_limit = "12.000000"
sth = "0.200000"
bogus_screen = "0.000000"
TATE = "1.000000"
IOS = "0.000000"
OS = "1.000000"
BLOOM = "0.000000"
csize = "0.000000"
bsize = "600.000000"
warpX = "0.000000"
warpY = "0.000000"
bogus_masks = "0.000000"
shadowMask = "7.000000"
maskstr = "0.500000"
masksize = "2.000000"
maskDark = "0.500000"
maskLight = "1.000000"
mcut = "1.500000"
mask_gamma = "2.400000"
slotmask = "0.500000"
slotwidth = "6.000000"
double_slot = "1.000000"
slotms = "1.000000"
mclip = "0.500000"
gamma_out = "2.400000"
textures = "SamplerLUT1;SamplerLUT2;SamplerLUT3"
SamplerLUT1 = "shaders_slang/crt/shaders/guest/lut/sony_trinitron1.png"
SamplerLUT1_linear = "true"
SamplerLUT1_wrap_mode = "clamp_to_border"
SamplerLUT1_mipmap = "false"
SamplerLUT2 = "shaders_slang/crt/shaders/guest/lut/sony_trinitron2.png"
SamplerLUT2_linear = "true"
SamplerLUT2_wrap_mode = "clamp_to_border"
SamplerLUT2_mipmap = "false"
SamplerLUT3 = "shaders_slang/crt/shaders/guest/lut/other1.png"
SamplerLUT3_linear = "true"
SamplerLUT3_wrap_mode = "clamp_to_border"
SamplerLUT3_mipmap = "false"
3 Likes

Lol, that’s mask 7 doing scanlines. :rofl:

1 Like