Good to hear! What scanline attack are you talking about and I’ll try and do a detailed description. Generally a higher value means more of an attack and moves the first control point.
Here’s an interactive 1D cubic berzier curve demo:
You might need to run this on desktop. Place the first point at 0,0 and the last at 1,1, the third at 0.666,1 and then the attack value will usually straight effect the y coord of the second control point 0.333, y.
At least that’s usually what it’s doing.
How that maps onto the scanline is if you imagine the last point is at the peak of the middle of the scanline and the first is the middle of the black empty space between the scanlines then this graph shows the shape of the scanline in the vertical direction i.e the vertical scanline attack.
Thanks for the description on the scanline attack, it’s really neat to get this in-depth explanation on the inner workings of your shader.
I was triggered by the bezier curve demo of a book that I recently came across that is very detailed on everything related to a CRT display. It’s called Image Performance in CRT Displays by Kenneth Compton and it has a chapter that I thought may interest you. It’s called “Generating the Pixel” and goes into detail on the shape of the pixel, including manufacturing/design targets for pixel shape and factors that influence the idealized pixel shape. I included the part from that chapter below, it’s intriguing stuff.
Based on my experience with the Megatron shader I’m thinking your shader may already be nailing it, also accounting for the factors impacting the idealized pixel shape as described in the book. Nonetheless, looking at the gaussian shape, see the referenced 5.1 image “gaussian profile” below, I was trying to replicate this in the 1D bezier curve demo and noticed it seems to need different values for the control points to achieve the gaussian roll-off in the scanline than the ones you mentioned for B and C. It may even need a positive value for A also. See my snap of the 1D bezier curve below.
Would be great if you could share your thoughts on what’s described in the quoted part of Chapter 5 below and more specifically how that ties in with current Megatron. Do you think scanline modelling is nailing it already or close enough (I think any of the two ) or could maybe some parts be improved based on what is written in this chapter 5?
Here’s the snap of the Cubic Bezier demo with custom control points:
Hi @MajorPainTheCactus, have you ever thought about putting in a switch for a tate mode so that we could switch to vertical scanlines (and rotated mask) for vertical games?
This would be great in the Mega Bezel where we have control over the scanlines normally with other shaders.
I’m currently working on finishing up getting HDR working for Megatron in the Mega Bezel, it’s almost done!
Thanks Rafan great chapter! So what I would say is that although we roughly want to get close to that diagram there’s a number of things our side (as well as on the CRT side) that will always stop us getting that close to that perfect luminance distribution. Not least we’re dealing with individual sub pixels rather than continuous strips of coloured phosphor. As in they will have their own luminance lobes.
Then add on there’s no dimensions to the diagram and youre starting to fight a losing battle. What I will point out is that cubic berzier demo stretches the curve over a square and what I do stretch or squeeze that square onto a rectangle which has an effect on the curve shape. See min max scanline lengths.
The way I tackle it is to get close up images of CRTs and just eye ball what the different characteristics of the beam are and then change the values to as closely match that taking photos of the LCD to match and compare i.e use empirical methods and not so much theoretical (although a bit of both are key)
@Jamirus kindly submitted these close up shots of Soul Calibur 2 on GameCube which is a 480p game (or rather 528 because of GameCubes dreadful upscaler (at least I think it’s the GameCubes and not Dolphins).
So I decided to match it which showed up some quite glaring bugs in the higher resolution. That I’ve now fixed. Anyway here’s a comparison shot of where I got to…
Oh yeah I forgot about this. Dolphin is quite possibly not accurate about resolution output, much like N64 emulation is somewhat lacking in this regard.
My understanding is that the GameCube has an internal maximum framebuffer size of 640x528 and scaling hardware that can scale it further. 528 is thus a limit for the internal resoluton, not actual pixels to be rendered and the final output which needs to conform to NTSC and PAL standards (thus 480/576 max).
The wiki for the GameCube utility “Swiss” has a list of actual resolutions that games use, Soul Calibur II uses 640x448 and scales it to 528 height when using PAL 50 Hz.
Yeah we really need a way of getting rid of that horrid upscale - it’ll make the image much better. So can we do this with Dolphin on RetroArch? I can see an option for PAL60 but turning it off doesn’t seem to do much - I presume that just changes the refresh rate not region.
So I looked into how to get the native resolution out of the GameCube Dolphin emulator and found the whole rendering for RetroArch of Dolphin is borked ATM. Basically the libretro version of the dolphin emulator upscales the final console image to the display resolution (4k in my case) and then down-samples that to 640x528 and then passes that image to our slang shader pipeline. Looks like a bit of work to fix it sadly. Hmm one day…
Yes probably! Probably they all need a re-going over. I’ll submit my latest fixes and then I’ll go over these. I’m tempted to try and fix the GameCube’s output but I’m still juggling multiple projects. I’ve got local changes that partially fix the DirectX drivers in TATE mode as well. Too many things to do and not enough time.
Is there any difference so far from the ReShade ver to the RetroArch one? I converted the presets marked SDR to HDR on my side for use in ReShade but i would like to know if the RS version still holds well enough for me to try it.
I sadly don’t have a HDR monitor, but still find this shader really pretty.
1.) How feasible would it be to create a CRT shader with an arbitrary TVL like say 292TVL?
Now why 292? Because SNES, Genesis/MD, PSX etc. when they stretch/squish according to their PAR are about 292 horizontal lines wide(with 0 overscan).
Conversely would other arbitrary TVLs be possible like 256TVL(SNES with no stretching, many Genesis games with no stretching, Master System, other consoles etc.), 240TVL(GBA 240x160 though a pixel grid LCD style would be better for this), 160TVL(Game Boy/Color 160x144) etc.
Basically my idea is to match the TVL to the visible horizontal lines on screen.
Conversely the idea of say lowering the TVL to 250 or lower to emulate a small cheap blurry CRT is also interesting to test out with various games etc.
2.) What do you think about the prospect of a universal desktop shader where you load the shader separately from the emulator(Retroarch etc.)?
Basically what I’m talking about is some kind of dedicated CRT Emulator program where you open the program and then select a CRT you want to emulate(and also of course being able to load your own presets) and then just apply that and have the monitor basically starting to act exactly like the CRT monitor you selected.
At a certain point it would be nice to have a guide to the shader explaining scanline attack for those of us who aren’t as mathematically-inclined. I need it explained to me the way you’d explain it to a small child, preferably with pictures
So what better way to make the cost of living crisis really hit home than to buy a bloody expensive new TV! Yes I’ve told the bailiffs to go f*#k themselves whilst I get pictures for you all of my new Samsung 65" S95B QD-OLED TV (temporarily mine at least until my wife comes home at which point she’ll be divorcing me for spending the children’s shoe money on new AV equipment).
Anyway here are the first few pictures (and yes I need to update all my presets now as the values are radically different to my LCD). More to come tomorrow.
Hi @Matsilagi yes there are now quite a lot of differences - mainly fixes. I need to port this all over to the ReShade version. It shouldn’t take too long but it’s the time issue again (it doesn’t help that I brought a new toy - S95B - also 🤦🤣). I’ll get there though. Glad you like the SDR version - I’ve found it works pretty good on my laptop.
) or could maybe some parts be improved based on what is written in this chapter 5?
