Have you tried using xbrz-freescale/-multipass? In my experience, it’s much faster than the ones with specific scale factors.
Thanks hunterk - xbrz-freescale multipass and fakelottes.slangp drops me from 96% to 25-26% GPU
\o/
I guess now i have the budget to play with bloom. /frolic
1 Like
Looking at stock.slang - how would i force it to double the resolution of the previous stage of shading?
Setting Shader #3 Scale to 2x doesn’t achieve the desired effect.
I’d like to try 2x scaling any input chain of shaders with nearest-neighbor.
depending on what you’re trying to accomplish, I think you would be better suited adding the stock shader pass before the one you’re wanting to blow up. Prescaling does break pixel detection algos, like those used for xbr, though, and some CRT shaders don’t like it, either.
There are also some video filters that run on the CPU and do a quick pre-scale before the shader step, so that might be easier/better than adding scaling shader passes.
1 Like
Thanks hunterk, but i don’t want to scale before the shaders, i’d like the output - final stage - to be 2x nearest, cause this monitor has silly high resolution.
I’ll just play with variations on the fastlottes mask - bigger ‘phosphors’ is what i really want.
Thanks!
ah, ok. In that case, you would set a specific scale factor in the last “normal” pass and then it will do the rest of the scaling according to your bilinear filtering (or not) setting.
For example, if you set a CRT shader to 3x, it’ll do the remaining scaling to fit your screen based on that setting.
Note: post-scaling mask and scanline effects looks like hot garbage.
Thanks for the reply hunterk,
with regard to the ‘broken’ fakelottes.slang (and .glsl), I see now that in general, CRT shaders appended after a scaler like xbrz fail to apply scanlines.
Why is this?
They’re typically designed to blank out (to varying degrees) every other line of the input texture. So, if you double the number of input lines, the lines it draws are going to be half as large as expected and 2x as close together. On top of that, most scanline effects don’t do a full blank-out of the line, so that already small line is getting averaged into the regular image, making it even harder to see. This effect is amplified with each successive increase in scale.
@hunterk : The effect you describe is not what i’m seeing:
Should we move this to its own thread?
[EDIT] Changing scaling on crt-apterture.slang to 1 and 3 give same result, 2 and 4 give following result.
It’s getting averaged out because the lines are so small. If you go to settings > video > scaling and set the aspect ratio to custom and then blow it up to 8x or so, you should start to see some tiny lines (this is with input scale of 4x and the SCANLINE_COMP_B value maxed out to maximize visibility):
EDIT: oh, I see that you’re using xbrz-freescale, and that one causes different effects, yeah. I believe it’s tied to the output size, so it’s always going to be super-tiny, I think. The vertical lines you see in your shot are the mask lines from crt-aperture, which are tied to the physical monitor pixels rather than the input texture’s texels.
Does this convince you that i’m not seeing any scanlines at all?
Is there a combination of upscaler plus crt effect that you know works? glsl or slang?
I may have hit a bug? I have latest git master compiled, nearest neighbor scaling for the window. glcore driver.
It’s not a bug, no. Shaders interact in different ways, and that’s just how xbrz-freescale interacts with scanline shaders. If you replace xbrz-freescale.slangp with this:
shaders = 2
shader0 = shaders/xbrz-freescale.slang
filter_linear0 = false
scale_type_x0 = viewport
scale_type_y0 = source
scale_x0 = 1.0
scale_y0 = 1.0
shader1 = ../scanlines/shaders/scanline.slang
you get this result, which is smooth on the x-axis but chunkier on the y-axis to prevent screwing up the scanline effect:
The other option is to use a scanline overlay in conjunction with the scaling shaders, which looks something like this (the current scanline shaders expect full-frame uncropped 240 height):
1 Like
Thanks so much @hunterk! This viewport/source is my ticket.
scale_y0 = 3.0 gives me results i want for scanlines.
1 Like
hey @hunterk - ty for the help again. I still don’t understand the shader chain . I had to write modified shader.
Oddly modulo division gave me weird errors so i had to use fract.
Now i have user-settable scanline width. \o/
requires xbrz-freescale-pass0 and 1
Also it behaves sanely at 3x, 4x and 5x scaling. 21% GPU at 3x, 29% GPU at 4x, and 45% GPU at 5x on the Jetson Nano at 10watts.
Since the scanline is a branch, perhaps i can also pull-in some luminosity into the horizontal dark lines from above and below with a smartly scaled pow() or somesuch, without expensive math or blending everything globally.
2 Likes
