No I use it in SDR mode as most phones (or at least my phone) are more than bright enough in SDR - they’re designed to work outside in the sunlight so need to be very bright. Switch the shader to SDR in the shader parameters and then whack your phones screen brightness up to max!
1 Like
So I’m looking at getting a new phone and as always have an eye on the display for using this shader on. Whilst reading about the OnePlus 12 I noticed a mention of 2160Hz PWM dimming.
I’d never really thought about dimming OLEDs before but Ive since found out that because the OLED elements are self emitting AND produce the colour simply reducing the power into them isn’t an option as otherwise if you turned down the brightness you also turn down the colour i.e. as it gets darker they essentially would get greyer (this effect is fine for tvs as they dont get very low brightness but smart phones do). So the clever folk at phone manufacturers around the world hit upon dimming by switching the display on and off rapidly - a technique that we otherwise know as essentially black frame insertion or more correctly(?) backlight strobing.
So essentially mobile phones have BFI built into them as standard and this is presumably the reason why my OnePlus 8 Pro has the best image in motion out of all the OLED/LED displays I’ve seen.
I say presumably because I have my phone up at peak brightness and so theoretically this feature is essentially turned off at this point but I’m wondering whether it works like that as otherwise you’d get a distinct shift change in ‘flicker’ as the mode changed (any ideas people?). I’m reading most phones do 240hz or 480hz PWM dimming whereas the latest and greatest does 2160hz as I said above.
I’m wondering whether this higher frequency actually starts to negate the motion clarity as we’re back to the eye being in multiple locations for a lit pixel per frame. Anybody have a phone that has this high backlight strobing frequency and can test its effect on motion clarity in retroarch. This is the list of phones with 2160hz PWM dimming - a fair few Chinese models basically:
https://www.epey.co.uk/phone/screen-features/2160hz-pwm-dimming/
Thanks for any info!
2 Likes
I was thinking this myself as I read. There has to be a limit or at least some point of diminishing returns where you end up with the same image persistence problem as before.
1 Like
It does. Mark(Blurbusters) explained that years ago. You need to match the PWM rate to the framerate for good motion just like on a CRT. Sample and Hold/DC Dimming is superior to PWM, but you can do BFI on Displays with PWM too provided they support sub-refresh strobe.
2 Likes
Here are some examples of my latest Sony Megatron presets in action.
1 Like
Beautiful. Are you packs updated with the latest settings used in the screenshots?
2 Likes
Thanks for taking the time to view!
You can compare the dates of the screenshots and the dates of my releases. These latest screenshots contain screenshots from a couple different recent iterations of my preset pack.
On another note @MajorPainTheCactus, @Azurfel, @guest.r, @GPDP1, @hunterk. Would it be possible to add this to Sony Megatron Color Video Monitor?
I’m referring to the Base (Black) Mask feature of CRT-Guest-Advance which allows the user to control the visibility of the unlit phosphors/mask.
1 Like
Is this that you want to control whether the mask is black? If so then probably not - on a CRT its always black as it doesn’t emit light so this is more a feature to lighten up the overall image. I’d prefer not to add to the already large and complex set of settings in this shader if possible. However if there is a really good reason or I’ve misinterpreted what you want then I’m all ears.
1 Like
No, this is really about the phosphor stripes. On a CRT, they’re still slighty visible even when not excited by the electron beam.
I’ve tried to include examples but I can add some more or better ones if you wish.
This is something that can be seen on almost any good quality CRT photo once it’s bright and zoomed in enough.
That’s understandable.
It’s just to add to the realism/accuracy of the shader. Currently the edges of the colours from the phosphors fade or transition to a black void, whereas on a CRT this isn’t actually the case. The darkest part of the screen would be the unlit phosphor stripes, which weren’t quite jet black and can be seen under the right circumstances, especially in photos.
If it’s expensive performance wise and cumbersome settings wise, I’m wondering if @GPDP1 can work his/her magic once again and implement it in a modular fashion as was done with the CRT-Guest-Advance-NTSC section, provided that it’s okay with Mr. @guest.r of course.
Here’s another beautiful example of what I’m talking about but tastefully implemented via a shader preset by @RetroGames4K.
You have to zoom in on the dark areas and your screen needs to be bright enough to see the unlit phosphor stripes.
3 Likes
The easiest way to do something like that would be to just clamp the image before the mask is applied to something like clamp(img, vec3(0.05), vec3(1.0)). However, that’ll only look right on aperture grille masks, since it’s simulating ambient light shining on the phosphor mask rather than light coming from the phosphors themselves.
That is, you wouldn’t see the crossbars of the shadowmask, since that’s behind the phosphor layer, and this light would be coming from in front.
2 Likes
This is how it’s supposed to look on both aperture grille and slot mask screens.
You’re not supposed to see the crossbars while seeing the unlit phosphors.
Yeah, that’s what I meant. If you just clamp to raise the minimum before the mask is applied and are using a slot mask, it’ll show those crossbars, which isn’t what you want.
1 Like
Here’s a photo of a CRT corraborating what @Cyber is saying
Credit to @ruuupu1 from Twitter
Model is Sony Trinitron KV-AF1 14 Inch CRT
5 Likes
Preliminary decoupling of the NTSC passes from guest.r’s most recent crt-guest-advanced-ntsc update for use with Megatron:
shaders = "8"
shader0 = "shaders_slang/crt-guest-advanced-2024-02-17-release1/shaders/guest/advanced/stock.slang"
filter_linear0 = "false"
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-guest-advanced-2024-02-17-release1/shaders/guest/advanced/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-guest-advanced-2024-02-17-release1/shaders/guest/advanced/pre-shaders-afterglow.slang"
filter_linear2 = "true"
wrap_mode2 = "clamp_to_border"
mipmap_input2 = "false"
alias2 = "PrePass0"
float_framebuffer2 = "false"
srgb_framebuffer2 = "false"
scale_type_x2 = "source"
scale_x2 = "1.000000"
scale_type_y2 = "source"
scale_y2 = "1.000000"
textures = "SamplerLUT1;SamplerLUT2;SamplerLUT3;SamplerLUT4"
SamplerLUT1 = "shaders_slang/crt-guest-advanced-2024-02-17-release1/shaders/guest/advanced/lut/trinitron-lut.png"
SamplerLUT1_linear = "true"
SamplerLUT1_wrap_mode = "clamp_to_border"
SamplerLUT1_mipmap = "false"
SamplerLUT2 = "shaders_slang/crt-guest-advanced-2024-02-17-release1/shaders/guest/advanced/lut/inv-trinitron-lut.png"
SamplerLUT2_linear = "true"
SamplerLUT2_wrap_mode = "clamp_to_border"
SamplerLUT2_mipmap = "false"
SamplerLUT3 = "shaders_slang/crt-guest-advanced-2024-02-17-release1/shaders/guest/advanced/lut/nec-lut.png"
SamplerLUT3_linear = "true"
SamplerLUT3_wrap_mode = "clamp_to_border"
SamplerLUT3_mipmap = "false"
SamplerLUT4 = "shaders_slang/crt-guest-advanced-2024-02-17-release1/shaders/guest/advanced/lut/ntsc-lut.png"
SamplerLUT4_linear = "true"
SamplerLUT4_wrap_mode = "clamp_to_border"
SamplerLUT4_mipmap = "false"
shader3 = "shaders_slang/crt-guest-advanced-2024-02-17-release1/shaders/guest/advanced/ntsc/ntsc-pass1.slang"
filter_linear3 = "false"
wrap_mode3 = "clamp_to_border"
mipmap_input3 = "false"
alias3 = "NPass1"
float_framebuffer3 = "true"
srgb_framebuffer3 = "false"
scale_type_x3 = "source"
scale_x3 = "4.000000"
scale_type_y3 = "source"
scale_y3 = "1.000000"
shader4 = "shaders_slang/crt-guest-advanced-2024-02-17-release1/shaders/guest/advanced/ntsc/ntsc-pass2.slang"
filter_linear4 = "true"
wrap_mode4 = "clamp_to_border"
mipmap_input4 = "false"
alias4 = ""
float_framebuffer4 = "true"
srgb_framebuffer4 = "false"
scale_type_x4 = "source"
scale_x4 = "0.500000"
scale_type_y4 = "source"
scale_y4 = "1.000000"
shader5 = "shaders_slang/crt-guest-advanced-2024-02-17-release1/shaders/guest/advanced/ntsc/ntsc-pass3.slang"
filter_linear5 = "true"
wrap_mode5 = "clamp_to_border"
mipmap_input5 = "false"
alias5 = ""
float_framebuffer5 = "false"
srgb_framebuffer5 = "false"
scale_type_x5 = "source"
scale_x5 = "1.000000"
scale_type_y5 = "source"
scale_y5 = "1.000000"
shader6 = "shaders_slang/crt-guest-advanced-2024-02-17-release1/shaders/guest/advanced/custom-fast-sharpen.slang"
filter_linear6 = "true"
wrap_mode6 = "clamp_to_border"
mipmap_input6 = "false"
// alias6 = "NtscPass"
alias6 = "LinearizePass"
// alias6 named incorrectly for compatibilty with unaltered crt-guest-advanced-ntsc-pass1.slang
float_framebuffer6 = "false"
srgb_framebuffer6 = "false"
scale_type_x6 = "source"
scale_x6 = "1.000000"
scale_type_y6 = "source"
scale_y6 = "1.000000"
shader7 = "shaders_slang/crt-guest-advanced-2024-02-17-release1/shaders/guest/advanced/crt-guest-advanced-ntsc-pass1.slang"
filter_linear7 = "true"
wrap_mode7 = "clamp_to_border"
mipmap_input7 = "false"
alias7 = "Pass1"
float_framebuffer7 = "false"
srgb_framebuffer7 = "false"
scale_type_x7 = "viewport"
scale_x7 = "1.000000"
scale_type_y7 = "source"
scale_y7 = "1.000000"
PR = "0.000000"
PG = "0.000000"
PB = "0.000000"
AS = "0.000000"
sat = "0.000000"
CP = "-1.000000"
(presumes the “crt-guest-advanced-2024-02-17-release1” folder is extracted to shaders_slang)
I’m aiming to ultimately make this decoupling a little more futureproof than our previous attempt, so there are a number of settings that aren’t necessarily of any use to us, and alias6 is intentionally misnamed to allow use of the unmodified version of crt-guest-advanced-ntsc-pass1.slang.
I left in afterglow0.slang and pre-shaders-afterglow.slang because i wanted to be able to use the Sega Brightness Fix/Sega Luma Fix effect. As far as i can see, they are completely inert with the included settings.
4 Likes
Thanks very much @Azurfel! Is there any chance we could also get the new Sega Genesis and Master System palettes from the new Grade as well? I’m not sure if they’re integrated into the new CRT-Guest-Advanced-NTSC shader yet.
Over at the Mega Bezel thread we compared Grade’s and Guest’s implementation of the Sega Luma Fix/Genesis Brightness Fix and we choose one over the other because one seemed slightly more neutral.
1 Like
Ok so yes I see what you’re talking about but its not accurate to simply raise the mask colour from black. The mask is black specifically what youre pointing out is that the horizontal parts (cross bar pixels) of the mask on a slot mask is non black as the phosphor runs over the top of it and we see the non lit phosphor instead of the underlying mask. We can certain do that but its a bit fiddly and I’m not 100% sure it contributes that much when the screen is turned on - certainly camera’s can deceive so that photo maybe a bit deceptive in its prominence but also I dont have a slot mask CRT to make an informative decision.
Regardless what is way more important in the photo you show is that the blacks of the phosphors aren’t black and have a non-zero base to them. I’ve actually had versions of this shader that had a non-zero black and I got a lot of complaints - you can change this by changing the gamma cutoff point in the shader arguments this should give you 90% of what youre seeing in the photo admittedly without the non zero ‘horizontal pixels’ of the slot mask but aperture grille will look perfect.
When looking at my PVM’s, the base black (because the black mask is interleaved with the slightly reflecting phosphors) is not of the level of the base black on my OLEDs so it is more accurate to have a non zero black.
There is definitely more to this off phosphor colour though when the CRT’s are turned on, as on my PVM it does look like the phosphor strips are transmitting light up them from the lit pixels kind of a little like optic fibre. I do see faint light that fades off as it gets away from the lit pixels but it only seemingly effects one of the phosphor strips - possibly green? I need to investigate a bit further.
Does anybody know what happens on a shadow mask? presumably the dots are not strips of phosphor?
1 Like
Ah fantastic - yes the shader parameters become a bit of a mess when we apply the NTSC passes currently. Thanks for this greatly appreciated!
1 Like
I’d actually say that photo shows there’s a mid way house as the crossbars are slightly visible underneath the phosphor strips. Again the most important feature isn’t the crossbars its instead that the phosphors have a non zero ‘black’. This can be achieved in the shader already by putting up the gamma cutoff to the standards as described at the top of the shader parameter blurb on the megatron.
1 Like
Yeah, off-black is technically caused by the CRT screen not being tinted black and CRT blacks not being perfect like OLED.
1 Like