Corrected shaders for WinUAE

[Dr.Venom]

Originally Posted by guest.r

I think there is no built-in option for mask strength.

I used this simple program for masks:

http://www.heliospaint.com/

The higher the trensparency, the subtler the effect.

Thanks, that's helpful.

Originally Posted by guest.r

If you want a stronger mask though, you could use some other rb mask.

I'm not sure I'm after a stronger mask. It may be there is some missing element to the mask that makes it feel slightly unnatural.

Hopefully you can help a bit with this (at least for my understanding).

If I look for example at my Sony CRT (Triniton) monitor which has an aperture grille I see A) clear scanlines, and B) on each scanline I see the individual Amiga pixels, each separated by a really tiny black space. The black extra space between the "pixels" / RGB lines can be seen on the Wikipedia explanation on Aperture grille ( https://en.wikipedia.org/wiki/Aperture_grille ) , see also the picture at the bottom of this post: I guess it's the larger black area after each three phosphor lines.

Would it be possible to achieve similar effect through a mask? I shortly experimented with a mask containing a black / darker pixel, but it doesn't look very good as it cuts through the scaled "pixels". So I guess for it to work the screen size need to be an integer multiple that is matched with the mask size that contains "black" space. (E.g. 4x width scaling would mean mask with every fourth pixel darker?)

It seems this effect is implemented in CRT-Geom for Retroarch, do you know by any chance if it's done through a mask or something else? Would it somehow be possible to implement with the WinUAE shader?

[guest.r]

I re-checked the crt-geom code from Retroarch, it's calculated phosphor mask, not an aperture lookup texture:

// dot-mask emulation:
// Output pixels are alternately tinted green and magenta.
float3 dotMaskWeights = lerp(
float3(1.0, 1.0 - DOTMASK, 1.0),
float3(1.0 - DOTMASK, 1.0, 1.0 - DOTMASK),
floor(fmod(VAR.mod_factor, 2.0))); 
mul_res *= dotMaskWeights;

The difference between crt-geom RA and WinUAE mask is that there the mask is applied in gamma space and looks a bit differently, darkens less overall.

Another problem is that only a png mask will work properly in WinUAE. There are two reasons, first is output resolution isn't defined in shaders in if it were, it would not match the output resolution but internal resolution before final resize. But it's OK since we got png masks.

Second problem is clumsy masks look odd on 1080p or smaller displays, you can try this out too, even aperture looks less appealing (looks better in here unavailable gamma space though). A 4k resolution would imo allow more complex masks to look nice, but that is far future for me.

[Dr.Venom]

Originally Posted by guest.r

I re-checked the crt-geom code from Retroarch, it's calculated phosphor mask, not an aperture lookup texture:

// dot-mask emulation:
// Output pixels are alternately tinted green and magenta.
float3 dotMaskWeights = lerp(
float3(1.0, 1.0 - DOTMASK, 1.0),
float3(1.0 - DOTMASK, 1.0, 1.0 - DOTMASK),
floor(fmod(VAR.mod_factor, 2.0))); 
mul_res *= dotMaskWeights;

The difference between crt-geom RA and WinUAE mask is that there the mask is applied in gamma space and looks a bit differently, darkens less overall.

Another problem is that only a png mask will work properly in WinUAE. There are two reasons, first is output resolution isn't defined in shaders in if it were, it would not match the output resolution but internal resolution before final resize. But it's OK since we got png masks.

Second problem is clumsy masks look odd on 1080p or smaller displays, you can try this out too, even aperture looks less appealing (looks better in here unavailable gamma space though). A 4k resolution would imo allow more complex masks to look nice, but that is far future for me.

I see, thanks for looking into it.

I can imagine this has already been discussed somewhere, but I haven't really been following all the shader discussions until just now (your CRT-Geom is the first I really like / find usable for WinUAE). With regards to future shader support for WinUAE, if we would want to get support for things like calculated phospor mask and curvature, what support would additionally need to be added? Are there specific shader extensions that need to be ported to WinUAE? (I'm also looking toward the current D3D11 beta developments for WinUAE..)

[guest.r]

Focusing on D3D11 could be important imo, if things get improved shader-wise too, that would be excellent.

The required changes which would allow good shader ports from Retroarch are not too demanding, only a couple of handover parameters and a scaling option:

1. inputSize param
2. outputSize param
3. textureSize param

4. an perfect output resolution internal scaling option, needs some explanation:

We can now select internal scaling like 1x, 2x, 3x or 4x. Very nice for scaling shaders. But crt shaders require a scale-to-output option for a perfect mask (could be tagged as 0x like 0 for Output ).

If this could be improved over D3D9 to D3D11 then it's a very good improvement.

[Dr.Venom]

Originally Posted by guest.r

Focusing on D3D11 could be important imo, if things get improved shader-wise too, that would be excellent.

Thanks for listing the required changes for possible improved shader support in WinUAE. I referred to them in the D3D11 development thread.

Now for some comparison time . I've ran Addams Family SNES with CRT-Geom in Retroarch and Addams Family Amiga with CRT-Geom in WinUAE. Both versions were scaled 4x without any additional stretchings, so sizes match. Both were set to their sharpest setting. I also adjusted the CRT-Geom parameters a bit, purely for the purpose of getting the images to match good enough for comparison. See bottom of post.

After the picture loads, click it once to see it at 100% / true size.



The phospor mask works out pretty similar if you ask me..

Upon inspection there seems to be one really noticable difference when you compare a zoomed in part, as I did below:

(click)


The dark and bright (scan)lines in CRT-Geom for WinUAE are less clearly defined than compared with the Retroarch counterpart. Disabling bilinear filter in WinUAE makes no difference to this picture.

Any idea what could be the cause of this? Is the maximum sharpness setting of 4.0 in CRTGeom for WinUAE possibly different from the sharpest sharpness setting in Retroarch (i.e. more filtering in the WinUAE shader)?

#define CRTgamma 2.4
#define monitorgamma 2.2 // default = 2.6 
#define brightboost 1.0
#define saturation  1.1 
#define sharpness   4.0   // 1.0 to 4.0
#define scanstr     0.35  // 0.3 dark, 0.4 bright

[guest.r]

The dark and bright (scan)lines in CRT-Geom for WinUAE are less clearly defined than compared with the Retroarch counterpart. Disabling bilinear filter in WinUAE makes no difference to this picture.

There are two possible differences between WinUAE and RA implementation here (and their combination). In RA the scanlines are calculated in the exact output resolution while in WinUAE in scaled internal one. The fractional pixel beam values are therefore somewhat different resulting different strength. The next one might be that the scanline parameters differ, with 0.3 as a RA default and 0.4 (0.38) as in WinUAE.

Regarding the mask, the mask in RA is applied in gamma space, mitigating the spikes. In WinUAE, the mask is applied in linear space, looks more spiky and darkens a bit more, but it can look nice also.

Is the maximum sharpness setting of 4.0 in CRTGeom for WinUAE possibly different from the sharpest sharpness setting in Retroarch (i.e. more filtering in the WinUAE shader)?

Horizontal sharpness is smarter implemented in WinUAE since you can have an arbitrary value defined (like 1.0, 1.35, 1.5, 1.75...even 10.0). In RA an offset hack is used, only numbers 1.0, 2.0 and 3.0 (no interpolation) are valid.

Vertical sharpness isn't supported in neither versions, it's hard coded since it determines the scanlines itself.

[Toni Wilen]

I need real world example and test case first, not just "add these variables". (Like "this config with this shader would make texture with this size and it should be in this variable and it would make this kind of result")

[Dr.Venom]

Originally Posted by guest.r

There are two possible differences between WinUAE and RA implementation here (and their combination). In RA the scanlines are calculated in the exact output resolution while in WinUAE in scaled internal one. The fractional pixel beam values are therefore somewhat different resulting different strength. The next one might be that the scanline parameters differ, with 0.3 as a RA default and 0.4 (0.38) as in WinUAE.

I had the scanline parameters already the same (both at non-default 0.35). Just to be sure I made the comparison again with scanline strength 0.3 for both. The difference remains the same (see picture below), so I guess we can rule that out as the cause.

(click)



Which leaves your first suggestion (that in RA the scanlines are calculated in the exact output resolution while in WinUAE in scaled internal one).

Originally Posted by guest.r

4. an perfect output resolution internal scaling option, needs some explanation:

We can now select internal scaling like 1x, 2x, 3x or 4x. Very nice for scaling shaders. But crt shaders require a scale-to-output option for a perfect mask (could be tagged as 0x like 0 for Output ).

@Toni, do you need a real world example / test case for this also, or was that mainly aimed at the other suggested additions?

Would be great of we could get this fixed..

Originally Posted by guest.r

Horizontal sharpness is smarter implemented in WinUAE since you can have an arbitrary value defined (like 1.0, 1.35, 1.5, 1.75...even 10.0). In RA an offset hack is used, only numbers 1.0, 2.0 and 3.0 (no interpolation) are valid.

Ah, that's cool. Does this mean that we can use higher values than 4.0 for the sharpness in the shader, or is 4.0 still the suggested maximum (like commented in the shader):

#define sharpness 4.0 // 1.0 to 4.0

[Dr.Venom]

@guest.r

Just to have all information complete, at the end of this post are the settings used both in RA and in WinUAE for the zoomed in comparison shot from previous post.

Maybe a silly question, but with regards to your comment on a perfect scale-to-output addition. If there's already an internal scaling option of 4x, and I set the WinUAE scaling options to be exactly 4x without any additional stretching or aspect correction etc - like the settings pictured below - then what would the shader with a "scale-to-output" option do differently?

Would it be possible to make a little example / testcase that could help Toni implement the feature?


(click)
NB these settings were also used in all the previous comparisons shots.




Retroarch (crt-geom.cg):

filter_linear0 = "false"
wrap_mode0 = "clamp_to_border"
mipmap_input0 = "false"
alias0 = ""
float_framebuffer0 = "false"
srgb_framebuffer0 = "false"
parameters = "CRTgamma;monitorgamma;d;CURVATURE;R;cornersize;cornersmooth;x_tilt;y_tilt;overscan_x;overscan_y;DOTMASK;SHARPER;scanline_weight;lum;interlace_toggle"
CRTgamma = "2.400000"
monitorgamma = "2.200000"
d = "1.500000"
CURVATURE = "0.000000"
R = "2.000000"
cornersize = "0.005000"
cornersmooth = "1000.000000"
x_tilt = "0.000000"
y_tilt = "0.000000"
overscan_x = "100.000000"
overscan_y = "100.000000"
DOTMASK = "0.300000"
SHARPER = "3.000000"
scanline_weight = "0.300000"
lum = "0.000000"
interlace_toggle = "1.000000"

WinUAE

// Tweakable options
        
#define CRTgamma 2.4
#define monitorgamma 2.2 // default = 2.6 
#define brightboost 1.0
#define saturation  1.1 
#define sharpness   4.0   // 1.0 to 4.0
#define scanstr     0.30  // 0.3 dark, 0.4 bright

[guest.r]

Maybe a silly question, but with regards to your comment on a perfect scale-to-output addition. If there's already an internal scaling option of 4x, and I set the WinUAE scaling options to be exactly 4x without any additional stretching or aspect correction etc - like the settings pictured below - then what would the shader with a "scale-to-output" option do differently?

Scanlines look perfectly even with integer scale. If somebody is happy with this setting then it's OK.

Why is perfect output important for crt shaders:
Mask could be applied in gamma space and calculated in the first place.
Very good for shaders like crt-lottes or crt-aperture (very nice crt shader), all other crt shaders would look authentic also.
InputSize and TexureSize are needed.

Perfect curvature needs the latter.

Would it be possible to make a little example / testcase that could help Toni implement the feature?

InputSize and TexureSize might be trivial since these are already calculated:

InputSize: size of the portion of the amiga buffer assigned to a d3d buffer
TexuteSize: since the buffer is generated it has to have this attribute.

Anyway even if there are some resizes, InputSize can be still calculated from the buffer rectangle meant to be displayed.

I'm worried about OutputSize though. Because there might be a resizing/shifting stage after the shader is applied and all these aspect options...bilinear resize does it's job well for scaling shaders. Unfortunately good mask needs the shader output match the final output to the pixel.

I think everything needed for a D3D9 upgrade would be a uniform connection btween the main program and the shader.

[Dr.Venom]

Originally Posted by guest.r

Why is perfect output important for crt shaders:
Mask could be applied in gamma space and calculated in the first place.
Very good for shaders like crt-lottes or crt-aperture (very nice crt shader), all other crt shaders would look authentic also.
InputSize and TexureSize are needed.

Perfect curvature needs the latter.

Definitely looking forward to WinUAE getting support for this. My experience with RA is that the curvature option (when applying it subtle) adds a great deal to the authentic CRT experience. I was also positively surprised how well it works in RA, very crisp looking.

Originally Posted by guest.r

I'm worried about OutputSize though. Because there might be a resizing/shifting stage after the shader is applied and all these aspect options...bilinear resize does it's job well for scaling shaders. Unfortunately good mask needs the shader output match the final output to the pixel.

I think everything needed for a D3D9 upgrade would be a uniform connection btween the main program and the shader.

Judging from Toni's comments in the D3D11 thread, shader support will be added after the next official release. Let's keep the fingers crossed he'll get around looking into this a bit more by then..

[Toni Wilen]

D3D11 mode now supports at least some D3D9 custom shaders. (http://www.winuae.net/files/b/winuae.7z)

(Yes, I said this can wait for next version but I said that before I knew that D3D11 effect compiler still supported D3D9 and there is free to use and license compatible MS code that does most of the dirty work, "only" required change was "porting" D3D9 effect code to D3D11. Surprisingly D3D11 code is much easier to understand and less messy than D3D9)

- D3DCompiler_46.dll or D3DCompiler_47.dll required (Not sure if it only comes with SDK)
- WinUAE does some automatic in-memory renaming of fx file contents to fix some basic compatibility problems: technique -> technique10, ps_2_0/ps_3_0 -> ps_4_0_level_9_3 and vs_2_0/vs_3_0 -> vs_4_0_level_9_3. For some reason D3D11 effect compiler completely ignores D3D9 technique format but lots of other features have backwards compatibility.
- Check log, all warnings and errors from shader/effect compiler is logged.
- At least AlphaBlendEnable, ColorWriteEnable, SRGBWRITEENABLE inside pass is not supported. I don't know (at least not yet) replacement functions. But it seems most shaders just disable alpha blending which is disabled by default anyway.
- Not restricted to level 9. Level 10 and 11 effect format is supported.

[guest.r]

Thanks Toni, it's quite usable already.

I can confirm crt shaders work as intended.
There were some problems with xBR shaders, either linear filtering was forced or an "output exceeds limits" occured (PS 5.0 compiles it though).

So i rather ported some xBR shaders to work with D3D11 only and we aren't missing much i guess, maybe some shaders that use workingtexture or/and multipass, but that's bonus already.

Edit: Now only one shader needs D3D11. Previous xBR shaders don't work well with d3d11.

[Toni Wilen]

Plain ps_4_0 and vs_4_0 should also work and work with lower D3D hardware level (10 vs 11)

[guest.r]

Good you mention it. I did the checks before i updated the bulky vertex part because of line bugs. Turns out 2 of 3 shaders can be universal and one can run on "4_0".

[Zandig]

With WinUAE 3.6.0 the CRT-Geom-Lo-Res.fx filter shader is producing a pinkish, blurry view when using Direct3D 11, Direct3D 9 works properly.

Click the images below and then zoom to full to see in full-size

Direct3D 9 (working properly):


Direct3D 11 (pinkish hue and blurry):


Filter settings:


Anyone else experiencing this, or know how to fix?

EDIT:

It seems to be tied to the Aspect Ratio Correction in the Filter panel.
If I select Disabled, 5:4, or 4:3 it displays the blurry, pinkish hue. Selecting the other aspect ratios display properly.
I'm using an Asus VG248QE 1920x1080 monitor and prefer the 4:3 settings as the other ratio stretch the image.

[Dr.Venom]

Hi guest.r,

When it comes to plain filtered output I'm quite charmed by the MAME solution, which allows a point prescale factor to be set before filtering is done. Usually with "prescale" factor at 2 or 3, the filtered (bilinear) output is quite sharp (sharp enough to be alike real pixel output, but without the pixel wobbles of straight non-integer linear scaling).

The idea is that we just have a "simple" shader that applies does 2x or 3x of point scaling before the bilinear pass.

I wondered if you could take a look at the prescale.fx from MAME and see whether it can be ported to WinUAE?

The source of "prescale.fx" is here: https://github.com/mamedev/mame/tree/master/hlsl

[guest.r]

Hi there!

I think i can help a bit.
MAME solution is unfurtonately not helpful here, but there are other.

For 2x prescale (games...) Hires/double line mode should be selected. Works very well if bilinear filtering is selected from the filter panel.

For higher prescale ratios a shader must be used.

Bilinear must be ON, multiplier selects the prescale level.

[Dr.Venom]

This is great, it does exactly what the prescale in MAME also achieves (i.e. sharp bilinear filtering). Works very well indeed, thanks!

There seems to be one smaller issue with the point-prescale + bilinear filtering that I noticed though.

I've attached two screenshots, the one is from null filter + bilinear filtering and the other uses point_prescale 2x + bilineair filtering. If you look at the blue canvas of the whdload splash, you'll see there are irregularities in the output when using point prescale at 2x.

Any idea what could be causing this?

I also compared just the plain non-filtered output of WinUAE and a point_prescale 1x non filtered output, and surprisingly the output is different. See attached cropped examples for both (scaled 2x with MS paint). Shouldn't the point 1x prescaled output be exactly the same as the default null filter output?

P.S. the above was all done with "hires" and "double" setting in display panel.

[guest.r]

I've attached two screenshots, the one is from null filter + bilinear filtering and the other uses point_prescale 2x + bilineair filtering. If you look at the blue canvas of the whdload splash, you'll see there are irregularities in the output when using point prescale at 2x.

Any idea what could be causing this?

I also compared just the plain non-filtered output of WinUAE and a point_prescale 1x non filtered output, and surprisingly the output is different. See attached cropped examples for both (scaled 2x with MS paint). Shouldn't the point 1x prescaled output be exactly the same as the default null filter output?

I tested it (JimPower) with FS-UAE sharp bilinear shader and the irregularities are very similar. So it's about as it gets here i guess.

The difference is because WinUAE filter multipliers are shifted by at least of two. So 1x could mean 3x, 2x could mean 4x etc. It's negotiable with Toni i guess but higher multipliers (1x-4x -> 3x->6x) are in fact better for scaling and CRT shaders.