New CRT shader from Guest + CRT Guest Advanced updates

What’s the vertical resolution, you’re running your N64 Core at? If it’s 240p, you’ll get visible scanlines, if it is 480p or in other words if you’re upscaling the internal resolution somewhere, you won’t get clearly visible scanlines.

I already tried early brightness control but it clips immediately as soon as I raise it a bit, so I can’t make it useful.

Post brightness has a weird effect where it hides the scanlines in the mid-range, the same way as Bright Boost Dark/Bright Pixels do if I crank them up too much. I don’t know why this happens, so I’ve been avoiding those settings.

Bloom distribution helps a bit, but it’s just a small amount of how much brightness needs to be corrected.

But thanks for the help! :slightly_smiling_face: I’ll try to control saturation with the controls you suggested and keep fiddling to try and calibrate brightness and gamma.

I don’t understand the purpose of mclip. It doesn’t change anything in my picture until the moment where it starts clipping the highs to show the mask. Clipping completely ruins the picture so I don’t know what it’s meant to be used for. I also saw @guest.r lowered it on his slot mask preset.

Also, I’m using Mask Bloom because @guest.r recommended it a few posts back. And it’s also the kind of bloom he’s using on his slot mask preset. But maybe I should use standard bloom instead?

1 Like

Please do! I need to see how others deal with brightness and gamma adjustments on slot masks.

2 Likes

He recommended regular Bloom for Slot Masks and Mask Bloom for other Mask Types.

So far, every time I set Mclip to 1 it looks similar to Bloom at 0 in my presets. Although the "phosphors’ look purer, the image looks worse so I live with my Bloom and leave Mclip alone at 0.50.

In the past I was able to get rid of the whitish haze that Bloom applies to the " phosphors" by using relatively low Gamma In/Out settings but overall I prefer how things look with Bloom enabled and higher Gamma In/Out.

I think if you want a 100% accurate experience by disabling Bloom in order to try matching the look of a real CRT, you’ll end up with issues where brightness is concerned, so you’ll need to compensate by having an extra bright screen with the brightness cranked all the way up, which seems to be par for the course with “accurate” CRT Shaders and Presets.

If you want great looks which can look virtually identical to a real CRT from reasonable viewing distances without having to simulate the Sun using your backlight, using a touch of regular Bloom with MClip at 0.5 works wonders.

When I read your mclip @ “000000”, I actually thought that it was at 1 instead eh. My apologies for any confusion. I haven’t tried it at 0 so I wouldn’t know what to expect, I doubt it would mess up the Bloom at 0. If it’s at 1 it will kill the bloom in my experience, using my settings.

2 Likes

I’m runing Nintendo 64 with ParaLLEI N64 core.It’s in it’s default resolution 640x480. I set the internal resolution Y: 224p/240p option in the shader to number 1. Sorry I forgot to mention that this Super Mario 64 is emulated on the Dreamcast. I haven’t got an original N64, and that’s the result. So maybe Dreamcast is emulating it bad too. But that’s how it looks on the dreamcast. And I want it to look the same. But if that’s not correct, I’ll do it in the original way…:sweat_smile:

1 Like

This is a significant factor in the scanlines and phosphors looking different. You’ll have to set it to a lower resolution if possible if you want to get similar scanlines to the Dreamcast + Sanyo CRT TV combination.

Not sure if this will do the trick. It doesn’t seem to be.

https://www.reddit.com/r/Games/comments/4vgd91/contrary_to_popular_belief_very_few_n64_games_ran/?utm_medium=android_app&utm_source=share

Screenshot_20220725-111509_Wikipedia

Based on these articles the Dreamcast seems to be doing a good job at least where the resolution is concerned because you can clearly see the scanlines which is reminiscent of 240p mode running on a CRT TV.

2 Likes

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

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

2 Likes

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

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

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

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

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

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

1 Like

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

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

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

1 Like

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

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

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