English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 18 November 2017, 16:40   #41
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 344
Quote:
Originally Posted by guest.r View Post
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.

Quote:
Originally Posted by guest.r View Post
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?


Dr.Venom is offline  
AdSense AdSense  
Old 18 November 2017, 18:18   #42
guest.r
Registered User

 
Join Date: May 2017
Location: EU
Posts: 85
I re-checked the crt-geom code from Retroarch, it's calculated phosphor mask, not an aperture lookup texture:

Code:
// 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.
guest.r is offline  
Old 19 November 2017, 10:34   #43
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 344
Quote:
Originally Posted by guest.r View Post
I re-checked the crt-geom code from Retroarch, it's calculated phosphor mask, not an aperture lookup texture:

Code:
// 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..)
Dr.Venom is offline  
Old 19 November 2017, 13:08   #44
guest.r
Registered User

 
Join Date: May 2017
Location: EU
Posts: 85
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.
guest.r is offline  
Old 19 November 2017, 18:29   #45
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 344
Quote:
Originally Posted by guest.r View Post
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)?

Code:
#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
Dr.Venom is offline  
Old 19 November 2017, 19:36   #46
guest.r
Registered User

 
Join Date: May 2017
Location: EU
Posts: 85
Quote:
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.

Quote:
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.
guest.r is offline  
Old 19 November 2017, 19:49   #47
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 20,153
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")
Toni Wilen is offline  
Old 20 November 2017, 12:37   #48
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 344
Quote:
Originally Posted by guest.r View Post
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).

Quote:
Originally Posted by guest.r View Post
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..

Quote:
Originally Posted by guest.r View Post
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 is offline  
Old 21 November 2017, 13:49   #49
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 344
@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):

Code:
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

Code:
// 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
Dr.Venom is offline  
Old 21 November 2017, 18:12   #50
guest.r
Registered User

 
Join Date: May 2017
Location: EU
Posts: 85
Quote:
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.

Quote:
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.
guest.r is offline  
Old 24 November 2017, 11:37   #51
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 344
Quote:
Originally Posted by guest.r View Post
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.

Quote:
Originally Posted by guest.r View Post
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..
Dr.Venom is offline  
Old 17 December 2017, 17:12   #52
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 20,153
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.
Toni Wilen is offline  
Old 23 December 2017, 15:34   #53
guest.r
Registered User

 
Join Date: May 2017
Location: EU
Posts: 85
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.
Attached Files
File Type: rar xBR Shaders.rar (8.4 KB, 18 views)

Last edited by guest.r; 23 December 2017 at 17:47. Reason: Shader update.
guest.r is offline  
Old 23 December 2017, 17:22   #54
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 20,153
Plain ps_4_0 and vs_4_0 should also work and work with lower D3D hardware level (10 vs 11)
Toni Wilen is offline  
Old 23 December 2017, 17:51   #55
guest.r
Registered User

 
Join Date: May 2017
Location: EU
Posts: 85
Thumbs up

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".
guest.r is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Multipass shaders craig64 support.FS-UAE 20 10 July 2017 23:45
HLSL/CG Shaders and xBR Enverex support.FS-UAE 11 19 July 2013 17:44
fx Shaders in WinUAE 2.6.0 crazy46guy support.WinUAE 8 16 June 2013 15:30
[FS-UAE] Optimized or corrected Amiga Game Database Entrys nexusle support.FS-UAE 3 24 August 2012 22:30
Subpixel-corrected lines and polygons on Amiga Scali Coders. Asm / Hardware 9 11 January 2012 13:37

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 07:27.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Page generated in 0.50763 seconds with 12 queries