Yoooo, that was cool af, it was really interesting to see those drastically different phosphor decay times. (Ik that wasn’t the purpose of that post but damn boi)
6 Likes
Hey @guest.r
Great shader. I’ve been playing around with the down sampling. Some observations:
You’re using a 3 by 3 kernel somewhat similar to a gaussian to “pre-sample” i.e. blur the input in linearize.slang. The size of this kernel over the source image is controlled by the downsample_level params, but the colors weighted by the kernel here are nearest neighbor samples not linear right? So really you’re just kind of making the blur skip information, if I’m understanding the code correctly. Maybe better would be to increase the kernel size to “catch” more pixels as downsample level increases? Also might make sense to make downsample_level params move in increments of 1.0.
EDIT: Apparently, I must have misunderstood the code. Non integer values of downsample_level do indeed affect the blur.
Also, when downscaling 480p to 240p, I couldn’t get things to look quite the same as a photo of a BVM using hardware downscaler. The shader seems to be averaging every 2 lines, but the wrong two lines. Look at the first and third line of the green “1” from the top:
A review of the hardware downscaler used (http://retrogaming.hazard-city.de/mimo.html) writes about a different unit that required vertical shift tweaking to achieve the correct result:
The Benchmark to meet is an Emotia setup tweaked using an Extron interface with vertical shift function (see the two pics above). If set to 240p output, the Emotia will average two adjacent lines of the 480p source signal into one line. On a direct feed the Emotia begins with line 2 and merges it with line 3. The result will be a nice looking progressive 240p signal, but it will not offer perfect sharpness and won’t look 100% like the PCB. For perfect results, the incoming signal has to shifted by one line (up or down). Some games (like Cave’s XBox360 titles) have internal controls to do this and so does MAME. Overall it’s still easier to use an Extron interface to do this. The following two screenshots show the difference. Standard alignment on the left, tweaked alignment on the right (easy to see on the big “1” on the top left, which is originally three pixels high, but spread over four lines without the alignment adjustment)
EDIT: Giving this a little more thought, I don’t think it makes sense. Offsetting by one either way would make line 1 or 3 less green, but in the photo it looks as though both are more green, so maybe it’s a different issue altogether.
Nevertheless, maybe an offsetting feature would be valuable anyway. Do you think it belongs in the shader? I’ve already made a small adjustment to the masks (I added a reversed mask 8 for BGR displays as mask 9), and I’m thinking this sort of thing either belongs in the linearize pass or the main shader. Or, maybe this should be a core / front end feature instead? I think some cores’ overscan features work like this already, so maybe it shouldn’t be a shader feature.
3 Likes
EDIT: I’ll keep this post in case someone runs in to a similar issue, but tl;dr update your drivers
Oh @guest.r I have a bug to report. There’s a huge difference in masking behavior for me between the “vulkan” and “glcore” drivers for me on an Nvidia card. On “vulkan” everything behaves as it should. On “glcore”, it seems floating point precision is better, so e.g.
pos.x = fract(pos.x/3.0);
if (pos.x < 0.333) mask.r = 1.0;
else if (pos.x < 0.666) mask.g = 1.0;
else mask.b = 1.0;
Never goes down the second branch. It’s always just green and blue.
Not entirely sure what the cause is. Well, I do know something, which is in glcore pos.x ends up being 0.3333… 0.6666… and then some number bigger than those two. I know this cause when I changed the comparisons to < 0.334 and 0.667, it fixed it, but turns out only for glcore because in vulkan the number goes something smaller than 0.333, 0.3333… and 0.6666… which is what the code expects and makes sense.
It’s late where I am so I might think about it more tomorrow and see if I can find the actual issue.
EDIT: Updating my driver fixed it lol. Oh man that drove me nuts.
3 Likes
Hey there! I’m glad you’re having fun with the shader. 
If i talk about ‘dowsampling’ it might be also addressed as ‘fast approximate downsampling’ as i try to avoid some situations with it, like double filtering to output resolution. My motivation to introduce it is definitely nicer interlace/interpolation mode with increased original resolutions, where ordinary filtering would either need a much more complex filter or at least a consistent (horizontal and vertical) pre-filter.
If fast downsampling is combined with standard horizontal filtering and bilinear vertical filtering, then the results are quite nice, maybe some fine tuning is required.
For scanline mode it’s more advisable to use subtle vertical downsampling since any quality would also add some sort of ghosting regardless. HW downsampling is similar to no-dowsampling, it happens in the shader by default.
I adopted/copied this segmenting scheme from the ‘dotmask’ shader, which mostly consists from lottes masks and didn’t find any issues yet. Rounding the values to one digit should be bullet-proof though.
A BGR mask could be added, i guess it makes a difference on a appropriate display.
New Release Version (2021-09-04-r1):
Notable changes:
- Mask 9 added for BGR panels.
- Mask calculations ‘improved’. Should work as intended with some drivers now.
Download link:
https://mega.nz/file/R9ZywbxD#6wCfas_GMSuax2TaxRLGBtP94XfWIXyRMoIjWu1a6ts
8 Likes
Hello there. I have been messing around a little bit with your preset(s). It’s very cool for crt looking, thank you a lot for sharing !!
I have made this little modding but not really sure if may fit some of your taste guys, if you would have any suggestions to improve this little preset I’d appreciate it quite a lot !
CRT guest.r main folder shall be placed in shaders folder as well as the preset from above.
This is how would be looking in action:
3 Likes
Yeah, why not.
New Release Version (2021-09-07-r1):
Notable changes:
- OverscanX option added.
- Overscan range expanded to max. 100 px.
Download link:
https://mega.nz/file/tsYRnaLL#FFJdAyuHRmteDetE7dvTQ6_C3_IwAMYvvgl3pgf_eA4
6 Likes
Hey @guest.r! Here’s the video for C1201 monochrome dark amber gameplay, an exclusive sneak peek of homebrew Prince of Persia on Commodore 64 Breadbin from my work in progress Mega Bezel Commodore Pack just for you!
Once more, I’d like to thank you and mighty @HyperspaceMadness for your black magic dev support! 
4 Likes
That’s very nice! Not to mention the playing skill… 
I guess it will look even more interesting with the NTSC preset, even although i’m from a PAL region.
See no harm in it if we adopt the excellent NTSC shaders for a while. 
4 Likes
Sooner or later we will have NTSC and PAL passes in our Mega Bezel toolkit… I’d like to try and replicate those crossed artifacts we observed in our monochrome quest!
For now, we have to enjoy plasma hi-definition sharpness
5 Likes
It is amazing how much the imperfections increase the nostalgia. 
5 Likes
Once this PR is merged, we’ll be able to disable the automatic inverse-tonemapping in the new HDR stuff for d3d11/12, so we should be able to do our own tonemapping in the shaders.
you and @HyperspaceMadness were the first people who came to mind when I saw this 
8 Likes
This is so awesome 
looking forward to trying this!!!
Thanks for the heads up!
5 Likes
This is great news, i think some adjustments might be necessary, but i can test it with my new 500 HDR nits display.
Ofc. you are very welcome to create a preset or add a shader for the range control. Currently the main pass clamps to the 0.0-1.0 range, it might be some useful info.
2 Likes
You can try the ‘custom’ option (-1.0), where you can have better control over flickering regarding phase. Then you can enable ‘Merge Fields’. Custom artifacting and fringing are to be set to 1.0 for composite effect.
2-phase without ‘flickering’ has the ‘rainbowing’ effect nullified though, you can set to 3-phase for some coloring.
Phase is otherwise determined by horizontal input resolution with 300px as the threshold for 2-phase.
5 Likes
Couldn’t the differences in the 2 images be chalked up to differences in calibration, brightness, contrast or gamma settings or capabilities of the display and not necessarily the shader doing things wrong? If there was a problem with offsetting in the shader, wouldn’t it also affect the purple highlight adjacent to the 1 and other pixels in the same line? What I’m seeing are 2 images with very different qualities. Perhaps the lights are being a bit overblown in the hardware example, while the darks are being crushed in the software example?
3 Likes
Could you have a solution to stop flickering on the soccer field?
NTSC composite, standard setup.
1 Like
Yeah I agree. I think that smear of green on the third line of the 1 in the hardware photo might be an unrelated artefact of some kind, and I simply mistook not seeing the same with the shader for an offsetting issue. Overall I’m very happy with the result and wasn’t going for 1:1 replication of the photo anyway, was just using it as an overall guide to for how the downsampling should behave.
1 Like