A future OLED generation that can get at high brightness+BFI will be pretty fantastic. I’m happy with my S95b OLED for a good while, and while I’m quite happy with the state of emulation right now the future is looking pretty glorious
2 Likes
I tried adding in some really slight tex_coord noise and I like the result. On all of my CRTs, if I get super-close to them, there’s some subtle movement in the scanlines and it looks pretty much like this (just a couple of lines added to the base megatron shader file): https://pastebin.com/Xvd3CL7r
I’m not going to bother with a screenshot because it wouldn’t really show anything.
2 Likes
This is interesting. I used to add subtle noise to all Mega Bezel Presets for the same reason.
Is it possible for you to add this as a separate module/shader that can be appended and have it behave in exactly the same way?
I wasn’t clear where the noise code started so I would have to compare the existing shader code with the code you posted. Perhaps a comment might assist the uninitiated like myself.
Right now I’m really satisfied and happy with the refinement in my latest Megatron Slot Mask presets. Something like this might just add some further polish or rather some icing to the cake.
1 Like
I forget, is there a reason why this shader doesn’t use the built-in HDR setting? I wanted to use Cyber’s presets but I need to edit every single preset individually
1 Like
You can try Notepad++ or even WinMerge to append the new lines of code to the existing shader.
Also, did you replace the actual Sony Megatron Color Video Monitor base shader in the Shaders/Shaders_Slang/HDR Folder?
2 Likes
Unfortunately, no. The noise has to happen where the scanlines are sampled, which is what makes it so subtle and mimics really tiny perturbations in the electron beam. Luckily, the way megatron is structured, we can apply this to the scanline sampling without touching the mask, which should be rock-solid.
The noise functions are lines 229-242:
float rand(vec2 n) {
return fract(sin(dot(n, vec2(12.9898, 4.1414))) * 43758.5453);
}
float noise(vec2 p){
vec2 ip = floor(p);
vec2 u = fract(p);
u = u*u*(3.0-2.0*u);
float res = mix(
mix(rand(ip),rand(ip+vec2(1.0,0.0)),u.x),
mix(rand(ip+vec2(0.0,1.0)),rand(ip+vec2(1.0,1.0)),u.x),u.y);
return res*res;
}
And the sampling offset happens on lines 1627-1630:
float offset_x = noise(sin(gl_FragCoord.xy) * float(mod(global.FrameCount, 361.)));
float offset_y = noise(cos(gl_FragCoord.yx) * float(mod(global.FrameCount, 873.)));
tex_coord = tex_coord + vec2(offset_x, offset_y) * 0.0005;
EDIT: whoops, forgot to include the ‘rand()’ function. Added it just now.
4 Likes
I should clarify that everything is working correctly! Great presets, BTW 
What I meant was I needed to edit the presets each to match my displays peak white and paper white. 800 and 350 respectively.
2 Likes
That’s par for the course with Sony Megatron Color Video Monitor. You can use Notepad++ Find in Files (and Replace) function to do this as a batch operation.
Also, feel free to share your Peak and Paper White Luminance to settings so that others who have the same model display may benefit.
Thanks, I’m really loving what I’m seeing. Too bad I don’t have all the free time in the world to just sit down and play while also trying to make better presets. Lol
Unfortunately this and “game watching” has become the game for me.
2 Likes
Ill have to try this out! Yeah even I have to admit there is a subtle softness you get from phosphors that you dont get from using pixels. I think its back to the whole continuous vs discrete thing we were talking about above. I guess 8K is the solution here but then again when using ntsc signal filter the image is very soft so maybe Im wrong and its more a pre process thing. Lets give this a whirl!
1 Like
Yes it tries to output directly HDR values (R10G10B10A2) from linear space (RGBA16) instead of essentially going to SDR (R8B8G8A8) and then out to a HDR backbuffer. But how much of a difference that actually makes Im not too sure. Maybe you can set the shader in SDR mode and change the format in the main Megatron shader file - comment out the #pragma format line. You should then be able to have this the same as other shaders when turning on hdr in retroarch.
1 Like
Ooo I see what youre trying to mimic - I like that idea. Maybe we can add it as an option - the only down side might be added processing - I want this shader to run on the Pi5 when Lakka eventually supports Vulkan for it.
1 Like
Ah I see - you should be able to change the master settings for that - there are includes where you should be able to change hdr settings globally - hmm is it sony_megatron_hdr.slangp or something? Can’t quite remember iff the top of my head.
1 Like
Is this for use on an LG OLED TV using the HDR Game picture setting?
1 Like
Yes, this is on my LG C9. BTW, mask gamma has a tremendous effect on how punchy the HDR is.
2 Likes
yeah, it’s pretty expensive. Looks like somewhere between 15% and 20% additional cost on my system, and you can claw back around half of that while it’s disabled using a branch.
2 Likes
Im going to wait until I can test and profile on the Pi5 before I add any more to the shader. Who knows when the Pi5 gets Vulkan support though.
2 Likes
@MajorPainTheCactus I remember you saying several times in the post that you use your phone with these shaders in HDR and they are super bright. I picked up the Samsung S24 Ultra and for the life of me I can’t get it to look good at all, everything is washed out like on the PC before the fixes. I also noticed no matter if you select GL or Vulkan, there are no options for HDR in Retroarch on Android. Can you give me a quick “how-to” for what you do to make these shaders look good on your phone?
Ty!
1 Like
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