New CRT shader from Guest + CRT Guest Advanced updates

RetroArch Additions Shaders
#2624

The ntsc version requires a tad more tweaking regarding brightness, but i can easily find some settings which are quite pleasing. But i understand what seems maybe trivial to me is not this trivial for users who are still learning some tricks.

If you got some saturation surplus and lack of brightness then you can also raise output gamma np. It works differently compared with gamma correct and maybe you could like it better.

Using masks with strengths lower than 1.0 is also a decent option to gain brightness.

I assembled a sortoff normal ntsc preset with slotmasks:

bloom = "0.800000"
bloom_dist = "1.250000"
halation = "0.100000"
gamma_c = "1.200000"
brightboost = "1.250000"
brightboost1 = "1.250000"
shadowMask = "6.000000"
maskstr = "1.000000"
mask_layout = "1.000000"
slotmask = "1.000000"
slotmask1 = "1.000000"
slotwidth = "3.000000"
double_slot = "2.000000"

Looks like something i can use for gaming without much thoughts. But i also test it on a display set at about 380-400 nits and this can make a huge difference. Display gamma is also important, together with contrast. Assuming that all displays produce very similar results can lead to some sort of missunderstanding. A perfect example for this is the very nice megatron shader where the right display makes all the difference.

3 Likes
#2625

Ok. I’ll try, if it’s not working I’ll post images without scanlines, :sweat_smile:

2 Likes
#2626

Here is also an example of vanilla ntsc shader filtering:

test

it appears there is some sort of halo and it results from luma/chroma encoding/decoding and distribution the ntsc shaders do.

The effect is quite complex and has strong background in real hw signaling. It not something to be tackled though.

I also tested blargg’s ntsc composite filter with HD version and the results are similar:

test1

Shader without ntsc (hd version):

test2

The effect has not so much to do with brightness controls, although it migh be more pronounced with some settings.

4 Likes
#2627

My sanyo CRT, looks more like the HD version. It has not got those interferiences or halos, but blargg’s filter has got RGB and makes the colour better like RGB scart, Where can I get blargg’s filters, I know there are in Mega Drive and Snes versions, but there’s no option in 32, 64 or 128 Bits. I read about there’s an option in retroarch, but is not working properly, the aspect ratio comes really bad. :confused:

2 Likes
#2628

If I can I’ll post it later. I’ll want to try with the HD Version. i was trying with the NTSC… :grinning:

2 Likes
#2629

That’s just due to one of the filter settings plus I’ve seen that the filter generally creates a slight horizontal squishing of the image which I resolve by cropping 0.5% off the left of the screen and 0.3% off the right of the screen.

That correction is baked into my shader presets which are labeled “…for Blargg…”. I also use my “…for Blargg…” shader presets to pre-sharpen the output quite a bit before Blargg works its magic. I’m pretty satisfied with the results.

You can get my custom Blargg NTSC Filter Presets in my Shader Preset Pack here:

They don’t work with all cores’ outputs but the issue where on some cores the screen just looks all wrong is just a setting that needed to be changed and I think my filter presets (at least my Sega Genesis filter presets) addressed that.

It’s good to know that CRT-Guest-Advanced-NTSC produces an output that is so similar to Blargg NTSC filters. I’ll definitely keep trying it out from time to time to see if I can master it’s controls and settings.

There are a couple reasons I use Blargg though, one of which is that it is a CPU based filter so my theory is that it might free up precious GPU resources that can go towards the intense HSM Mega Bezel Reflection Shader and I also lament that most of the time my CPU is way underutilized at the same time.

Plus it allowed me to compartmentalize certain effects in a more modular fashion. To have custom Genesis output for example which might be slightly different from Turbo Duo and I can add de-dithering to HSM Mega Bezel Reflection Shader presets that don’t include it, such as the STD presets used by @soqueroeu.

Another reason is that I sometimes like doing things differently from the norm.

2 Likes
#2630

Well you got it pretty close already using the NTSC. Isn’t there an option to lower the N64 Core’s Internal Resolution to 320 x 240 to accomadate your scanlines?

1 Like
CyberLab Death To Pixels Shader Preset Packs
#2631

Thanks. and Yes, there is an option in the emulator. I will try it, and see what happens…:sweat_smile:

1 Like
#2632

The main difference I’m seeing is that the phosphors in the real CRT photo are much better saturated (particularly in the highlights) and don’t have any of that between-phosphor glow that you see in the shader.

Disabling glow and bloom would help close the gap. These lighting effects essentially blur the image in different ways to try to make it brighter, and are only really necessary with an SDR display.

3 Likes
#2633

I’ll have to see an actual example of the OLED subpixels looking like CRT phosphors before I’m ready to conclude that we’ve solved this problem. I think the spacing between active subpixels is going to be too much to be overcome by the displays’s natural bloom, and you’ll always have that very obvious grid. Hopefully, I’m wrong about this.

2 Likes
#2634

Thanks I’ll check that out…:grin::muscle:t3:

1 Like
#2635

Come one… it’s normal…it’s because you are using scart cable!!!

In this forum when there are speaking about NTSC i’m pretty sure its not with the scart cable… it’s more like with composite… (all video signal in yellow cinch cable…) isn’t it ?

This kind of halo and melt color is because the 3 colors is melting in the signal cable…

With scart RGB is separated so the video signal is clean.

It’s like on PSX… when you connect with composite the result is fucking bad… but with scart it’s clear. I think there is something confuse between NTSC and PAL on the subject… Pal have more lines but 50hz (before the PAL60 appeared with dreamcast) NTSC have less lines (so a little bit less resolution) but 60hz… Also the colorimetry is changing between PAL or NTSC…

Now people can correct me… if i said some big mistake.

2 Likes
#2636

Ah, my bad, I misinterpreted then. I thought he was recommending Mask Bloom for all cases.

Sure, but that’s not what I’m going for. I have no practical way of constantly raise/lower my TVs brightness so I want to keep it at a normal level. I know I need bloom to have enough brightness with a CRT mask. That’s not the problem.

From my experience, keeping, mclip at 0.5 and Bloom at 0.5 looks the same as mclip at 0 and Bloom at 1. Or at least, very similar. So I still don’t know the purpose of mclip. I imagine it might interfere with other parameters though.

Thank you for the preset! I’ll try it as soon as I can :slightly_smiling_face:

Not sure how many nits my TV is set to output, but it’s probably lower than 400. It’s calibrated by a colorimeter though, and I verified that it’s gamma tracking is spot-on.

Please post the NTSC version too. It’s the one I’ll be using.

2 Likes
#2637

I recommend you use the Mupen64 core. Parallel is kind of deprecated and Mupen64 absorved it’s features, such as Parallel RSP and RDP.

Most Nintendo 64 games output 240p, but some are 480i. I’ve tested both 240p and 480i N64 games with this shader and they work perfectly with guest’s default parameters. I use Mupen64 with ParallelRDP and ParallelRSP. Hit me up if you need help setting it up! :slightly_smiling_face:

That depends if you’re using 2 or 3 swapchain images and how your driver handles them. Typically, with 2 swapchain images, the CPU and GPU processing is sequential, to reduce input lag, while with 3, the CPU is preparing 1 frame in advance while the GPU is rendering the previous frame in parallel. In the former case, both CPU and GPU contribute to the time it takes to render a frame, but in the latter case, only the slower of the 2 is the limiting factor.

Now, it depends a lot on what GPU you’re using, but I would say any modern GPU will always be faster at processing the NTSC calculation than your CPU.

Your CPU will always seem underutilized with emulators because they’re mostly single-threaded. Even multi-threaded ones typically have one heavy main thread, and light auxiliary threads. You can check this easily by enabling fast-forward and check the CPU usage. For example, Mesen at fast-forward (producing frames as fast as possible) uses only 7% of my CPU. That’s because it uses 1 or 2 cores and cannot make use of the remaining resources.

And don’t forget that the Blaarg processing will only happen sequentially, after the core’s frame is ready, so it will not be more efficient to run it on the CPU.

Now, this obviously depends on the hardware you’re running it on, and how heavy the HSM Mega Bezel Reflection Shader is. I’m talking about a modern CPU with a modern GPU. And ofc, I might be wrong, but I think that’s how things work on RetroArch. But please feel free to correct me if I’m wrong! :sweat_smile:

2 Likes
#2638

Oh no, it’s okay, I believe you. Lol

Actually, my (now possibly debunked) performance theory was kinda low on my priority list as to why I use Blargg NTSC. I mainly use it because I think it’s cool. Lol

I’ve always wished I could’ve tweaked it and made it work well with certain cores, for example Mednafen/Beetle, so when I learned that I could through a post by @Juandiegous, I eventually went to town on it and was really satisfied with the results and the simplicity of the parameters. The only thing I’m not 100% sure about are some of the parameter ranges but I trial and error’d my way till I got the results I have right now.

2 Likes
#2639

I just tested your preset and here’s the problem I mentioned earlier showing itself again:

Here’s the preset you just posted: image

And here’s your base NTSC preset:

image

As you can see, Mario has a very ugly glow around him on the slotmask preset that is not an NTSC artifact, because it is not present in your base NTSC preset. This glow is even more distracting in motion than in the screenshot.

Another problem I found is that you have a bit of clipping on the highlights:

image
image600×1117 367 KB

#2640

I can still see it in the base ntsc preset. It just manifests itself a bit differently. :grin:

Here is an example of crt-geom-ntsc:

test3

Clearly something ntsc shaders produce in this specific case. But you can try GTU, crtsim, mame-ntsc…

The highlights aren’t acutally ‘clipped’, just the contrast is manifesting a bit differently. Bloom applies a smoothing effect which in counjuncture with ntsc smoothing, washes out the transitions. (ntsc smoothing is quite aggressive, it can dissolve dithering, transparancy effects etc.).

The main deal is that the implementation is probably not going to change.

But you can reduce the Substractive sharpness parameter from filtering option to mitigate the effect. Increasing NTSC resolution scaling helps here also.

Edit: at least with my display the color bars (R,G,B) are clipped even without any shader:

240pSuite-220726-082524
240pSuite-220726-0825241440×1080 10 KB

2 Likes
#2641

That probably means you’ll need to fix your display’s settings then. Try using this: http://www.lagom.nl/lcd-test/

Might need to go back through and check everything again once it’s corrected. I wonder if this explains why your presets always look washed out for me.

3 Likes
#2642

Yeah, my vibrance was 1 point too high.

I didn’t post any ‘official’ presets, just some templates. You can still correct them to your liking.

2 Likes
#2643

People!! it’s very good all your work about NTSC ugly preset… but when you will be finish to play… it will time to work on the “ultimate CRT GUEST very light clear neat shader” (joke inside)

Really your shader is awesome already …

3 Likes