English Amiga Board


Go Back   English Amiga Board > Main > Retrogaming General Discussion

 
 
Thread Tools
Old 19 February 2019, 17:23   #121
guest.r
Registered User
 
guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 342
Quote:
Originally Posted by Retro-Nerd View Post
Something i noticed about "Raster Bloom %" is that is just zooms the image size and with "R Boom Overscan Mode" = 0 it zooms out (smaller image). Is this the intended behavior?
Yeah, it "emulates" the overscan settings of a crt display.

With 0 the image will shrink and get full on white screens.

With 1 there will be 50% overscan (like set by the "Raster bloom %") on white screens and 50% "underscan" on black ones. Sweet spot. Since with average screen brightness the image will be approximately full.

With 2 there will be 100% overscan on white screens and full image on black ones.
guest.r is offline  
Old 19 February 2019, 17:25   #122
Retro-Nerd
Missile Command Champion
 
Retro-Nerd's Avatar
 
Join Date: Aug 2005
Location: Germany
Age: 52
Posts: 12,447
Ah ok, thanks for the explanation.
Retro-Nerd is offline  
Old 20 February 2019, 12:24   #123
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 485
Quote:
Originally Posted by guest.r View Post
The raster bloom main shader which calculates the average value had also a minor change, it's going one more level with mip-maps now. But it shouldn't affect the blooming level. Before as many as 50 texture lookups were made on lowest original resolutions, going to 200+ with a basic hires setup. General performance increase is about 15% or like 50% with a 640x480 game. With a 4k display a crt shader is perfectly usable with these game resolutions. So i think mip level 6 is a sweetspot.
I'm again running into situations where the rasterbloom is not working like real CRT, in a way that is actually distracting.

Please look at below picture of metal slug x. In-game the "PRESS START" is continually blinking, but this also makes the ENTIRE screen bloom (zoom) ON and OFF in cadence with this press start blinking. This is not like on real CRT (on real CRT the "press start" blinking does NOT cause screen blooming).






Is there a way to fix this?

Quote:
Personally i think that raster bloom has a cool function now, bringing some dynamic on display.
I fully agree with you, on real CRT it brings pretty cool dynamic to the display. But the current shader implementation only works for situations where the entire screen gets brighter, it does not work right when only small parts of the screen change in brightness. Then it incorrectly blooms the entire screen which I find distracting. I think the r-type example / issue I mentioned some posts ago is also occuring because of the same issue.

I feel the answer lies in calculating brightness changes more locally (pieces / slices) , and have a threshold for the number of slices that need to be of higher brightness before the entire screen grows. This would prevent for example only small object changes (like the"press start" blinking) to influence the bloom for the entire screen.

Sorry to be a critic about this... I know already considerable effort has been spent on this. It's just that I would really like to have this enabled, but in its current form it's too unrealistic for me when these small changes in the screen make the entire screen bloom.

Hopefully there's something possible, maybe with what you mentioned about the segmented mipmap info?

Anyway, onto a simpler question...

I'm trying to get a consistent look across WinUAE, MAME and Retroarch. What "alternate scanlines" settings are you using in the MAME shader, is it alternate scanlines 1 or 2? ( I'm still on the fence whether using 1 or 2 in the retroarch setting )

Last edited by Dr.Venom; 20 February 2019 at 12:29.
Dr.Venom is offline  
Old 20 February 2019, 19:41   #124
guest.r
Registered User
 
guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 342
Quote:
Please look at below picture of metal slug x. In-game the "PRESS START" is continually blinking, but this also makes the ENTIRE screen bloom (zoom) ON and OFF in cadence with this press start blinking. This is not like on real CRT (on real CRT the "press start" blinking does NOT cause screen blooming).
I feel like a mailman with a traffic bill sometimes.

We are stuck in a hole here a bit. The 7 input frames (0.1s of frame history) is the only info we get and for proper "elimination" of blinking effects we would need like combined blink-in and blink-out duration (like 100 frames). OTOH other glitches would happen.

I spent some time to work on the issue a bit and there is even good news. I managed to eliminate some annoying bloomin effect on blinking "text" with screens with lots of black. I also implemented some blooming smoothing to avoid speedy jittering (optional).

Back to the core of the problem. We start the shader chain with some input frames. We got some aditional size information. That's all that we got.

That's why it's impossible to eliminate longer duration blinking effects, because the "shader" doesn't know or remember what's blinking. OK we could eliminate some very quick explosion/firearm effects with some minimum color function applications, but i rather decided to smooth the blooming effect.

Personally i think this effect is a crude mathematically approximation of the real crt blooming. Sometimes the effects overlap, sometimes there are exceptions.

Something better would require a lot more of frame history.

Localizing the effect to rectangles would unfortunatelly bring tiling to the screen, something that doesn't happen on crt's.

Anyway, i think this version is a bit better in this regard.

Edit:
Quote:
Anyway, onto a simpler question...

I'm trying to get a consistent look across WinUAE, MAME and Retroarch. What "alternate scanlines" settings are you using in the MAME shader, is it alternate scanlines 1 or 2? ( I'm still on the fence whether using 1 or 2 in the retroarch setting )
With WinUAE and MAME shaders there are scanlines no. 2. They can be customized a bit if too thin on darker colors, but i like them a tad more with "trinitron" masks.
Attached Files
File Type: zip crt-guest-dr-venom-preset.zip (433 Bytes, 63 views)
File Type: zip guest.zip (12.5 KB, 70 views)

Last edited by guest.r; 20 February 2019 at 22:29.
guest.r is offline  
Old 20 February 2019, 22:00   #125
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 485
Quote:
Originally Posted by guest.r View Post
I feel like a mailman with a traffic bill sometimes.


Quote:
I spent some time to work on the issue a bit and there is even good news. I managed to eliminate some annoying bloomin effect on blinking "text" with screens with lots of black. I also implemented some blooming smoothing to avoid speedy jittering (optional).
Thanks for these changes, it's working very nice now.

Quote:
Personally i think this effect is a crude mathematically approximation of the real crt blooming. Sometimes the effects overlap, sometimes there are exceptions.
I see what you mean. Luckiliy with these latest changes the illusion is good enough to live with some of the exceptions

Quote:
Edit:

With WinUAE and MAME shaders there are scanlines no. 2. They can be customized a bit if too thin on darker colors, but i like them a tad more with "trinitron" masks.
Thanks. I had the impression it was to be 2, as it has that little bit of edge to make it real CRT like.

With regards to the MAME shader, one last question on the "MESS" side of MAME (the drivers that emulate home computers / consoles). Most of them use some hardcoded doubled horizontal and or vertical resolutions.

The snes driver in MAME for example uses a doubled horizontal resolution (512x225), does that negatively impact the shader output?

Then there's the MSX driver for which the vertical resolution is doubled also, i.e. it uses 544x466. The shader output looks definitely wrong with this one. Is there something that can be done? The MSX is a bit like the Amiga in the sense that 99% of games are using lowres (in case of MSX mostly 256x212). MSX driver can be started with any of the MSX machines, I use "mame64 nms8250j -cart1 <rom>".
Dr.Venom is offline  
Old 20 February 2019, 22:59   #126
guest.r
Registered User
 
guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 342
Thanks, i'll make the changes default then.

Regarding the SNES doubled x-resolution, the shader should do scanlines well, the horizontal filter is a bit sharp, but you can try to change the h_sharp #define for it to 1.0 and it will work normally.

I think it's best you try the "Hires" versions for MSX. As i mentioned i don't use MAME (ok i tried it a bit 20 years ago ), so i had to guess what to do. But if it really just doubless the pixels, then it should work nicely.
Attached Files
File Type: zip mame-hires.zip (4.8 KB, 62 views)
guest.r is offline  
Old 23 February 2019, 01:15   #127
Retro-Nerd
Missile Command Champion
 
Retro-Nerd's Avatar
 
Join Date: Aug 2005
Location: Germany
Age: 52
Posts: 12,447
Bsnes got a new release. Looks like byuu is finally back the roots. Loading zipped roms directly again, no more other Nintendo platforms. Any chance that you could convert your CRT Trinitron shader to this quark shader format? There are several for bsnes but they don't look good, some don't even work and editing parameters is sometimes a pain.

https://higan.readthedocs.io/en/stable/guides/shaders/
Retro-Nerd is offline  
Old 23 February 2019, 02:43   #128
guest.r
Registered User
 
guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 342
Yeah, can do. The shader format itself is preety good, seen some complex shaders there too...
Anyway, off to bed now.
Attached Files
File Type: zip bsnes-trinitron.zip (5.2 KB, 82 views)
guest.r is offline  
Old 23 February 2019, 03:17   #129
Retro-Nerd
Missile Command Champion
 
Retro-Nerd's Avatar
 
Join Date: Aug 2005
Location: Germany
Age: 52
Posts: 12,447
Thanks. But i'm afraid it's not that simple anymore. Higan/bsnes seems to use an internal hires resolution for some time, so it doesn't look right. Maybe you could check it with the newer v1.07?


https://download.byuu.org/bsnes_v107-windows.7z

Looks fine though in older versions e.g. (higan) v.097.

Last edited by Retro-Nerd; 23 February 2019 at 03:26.
Retro-Nerd is offline  
Old 23 February 2019, 09:09   #130
guest.r
Registered User
 
guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 342
Nah, tested it with 1.07, maybe it's some queer setting in work. It would be also a shot in the leg from the author, since all the other shaders would stop to work properly.
Nevertheless, updated shaders force a low resolution.
Attached Files
File Type: zip bsnes-trinitron.zip (5.7 KB, 66 views)
guest.r is offline  
Old 23 February 2019, 14:23   #131
Retro-Nerd
Missile Command Champion
 
Retro-Nerd's Avatar
 
Join Date: Aug 2005
Location: Germany
Age: 52
Posts: 12,447
Ah, new version looks great. Denise (new C64 emulator) works also fine with the first version.

Last edited by Retro-Nerd; 23 February 2019 at 14:46.
Retro-Nerd is offline  
Old 25 February 2019, 13:06   #132
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 485
Quote:
Originally Posted by guest.r View Post
I think it's best you try the "Hires" versions for MSX. As i mentioned i don't use MAME (ok i tried it a bit 20 years ago ), so i had to guess what to do. But if it really just doubless the pixels, then it should work nicely.
Thanks, works like a charm


Now that Trinitron is looking so good, I wondered what difference there is with slotmask, so I hooked up my Philips slotmask 14" monitor and made a high resolution shot of the same part in Lomax as I did for Trinitron (see here). I've attached the full high resolution (3888x2592) image.

Below I made a cutout showing the phosphor formation and mask in detail. Interestingly the phosphor dot formation is basically the same as Trinitron, but with the slotmask "shadow" layered on top. De beam dynamics are also very similar, although the seperation between the scanlines are much less visible (possibly because this monitor has a lower TVL than the Trinitron one?)

I've added an approximation of the slotmask for 4K / 2160p resolution in the image. Since the phosphor dot arrangement (mask 5!!) and scanline dynamics look so much like Trinitron, I wondered whether you could take Mask 5 and layer this slotmask on top of it. Maybe it's a combination that could beat Lottes mask in accuracy on 4K and possibly look better on 1080p? Just curious

Of course this would lower the brightness of the image a bit, but I guess it could be compensated for by having scanline dark lowered by some margin, similar to the detailed shot of the 14" Philips slotmask monitor.

click for full size:

Last edited by Dr.Venom; 17 May 2019 at 00:27.
Dr.Venom is offline  
Old 25 February 2019, 21:52   #133
guest.r
Registered User
 
guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 342
I've produced some slotmasks to test in WinUAE, since it can show what they would look like calculated in RA.

I think there is a reason for a cautious use of them at this time and especially with 1080p.

They like very mild scanlines and dislike curvature (like all of the heavier masks with stronger scanlines).

Personally i think that the most 1080p compatible crt mask is apreture grill(e), but even here most folks like a compressed size 2 version of it (green/magenta).
Attached Files
File Type: zip slotmask-test.zip (998 Bytes, 60 views)
guest.r is offline  
Old 26 February 2019, 16:19   #134
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 485
Thanks for looking into it...

Quote:
I think there is a reason for a cautious use of them at this time and especially with 1080p.
I know what you mean, I think we can agree that this kind of "overlays" don't look stellar. But to be honest it was not what I was looking for.

To be clear, I am not asking "can you make a slotmask and make it look good on 1080p". I meant "Can you take the RA shader with Mask 5 and add (blend!) the 4x1 slotmask arrangement on top so that we 1) possibly have the very best slotmask solution for when 4K / 2160p comes around, 2) maybe looks good on 1080p if scales down / blends well (probably not, so 1. remains most important).

Hopefully below explains it a bit more (sorry to be longwinded with this..)

Issues with testing the masks in WinUAE are:

- With the WinUAE setup plain masks need the plain _WinUAE.fx, but without the hacked _winUAE.fx the trinitron style dot arrangement is lost (no mask 5 cutoff).
- Your example masks seem to be created with 1080p in mind? For what I can see the width / height and spacing of the slots is a bit too far off to be "accurate" for 2160p (which would be logical because of the too low pixel density of 1080p)
- The dark "slots" in the mask don't "darken" the slots given their surrounding pixels, but just make them plain black. Which is, as we probably agree, pretty unnatural looking.

Because of the above, it's like looking at the video through some black raster, with wrong dimensions.


I'm not sure if it's doable or really worth the effort, but I'm thinking of the following testcase:

1. Take the RA Trinitron shader with mask 5 or 6.*
2. Create the 4x1 slotmask - from my calibrated example in previous post for 2160p - on top of 1.
3. Have the black slots actually not being black but blend in with underlying color. Close to white the slot will be less visible, for darker color the slots will be very visible. (configurable?)
4. Run Beetle PSX in Retroarch, set scaling to 9x (yes nine times vertically); this will simulate 4K / 2160p.
5. Take a screenshot of the shader output from Lomax loading / map screen, crop it to the same section as my example below and compare the output:
- are there about 5 to 6 slots vertically per 3 scanlines?
- are the slots horizontally spaced the same as the real slotmask snapshot?
- is the brightness for the slots (glow from surrounding dots) comparable to the brightness of the slots in the cutout?

If all the above is yes, could it then be that it's about the most accurate slotmask simulation one could wish for? And / or beat the Lottes versions on 4K / 2160p?

I know this is very different and probably miles more difficult / more work than the WinUAE example, so I would really understand if it would not have your interest right now. Possibly we could have another look when we actually own 4K monitors to test this on

It's just because the similarities between Trinitron and Slotmask / Cromaclear are so big, and the Trinitron shader setup with RA so good, that I'm quite curious whether the Trinitron shader with a small slotmask "twist" would not instantly create the best slotmask simulation for 4K out there.






* Note that Trinitron and Slotmask (NEC Cromaclear) are basicly the same in their dot arrangement, and Cromaclear is essentially taking Trinitron's best (brightness), while doing away with the disadvantage of the sensitivity to vibration and the darkened horizontal line in the middle (stabilizing wire). So I see it as being Trinitron, but with a twist .
That's why I think it's essential to take your Trinitron mask 5 and 6 as starting point, and layer / blend the slotmask in correct dimension for 2160p on top of it.


Quote:
Personally i think that the most 1080p compatible crt mask is apreture grill(e), but even here most folks like a compressed size 2 version of it (green/magenta).
Yes I couldn't agree more, the Trinitron mask is super on 1080p. We really only need the Trinitron shader, but I guess curiousity got the best of me..
Attached Files
File Type: zip slotmask vs trinitron shader ouput v2.zip (619.1 KB, 60 views)
Dr.Venom is offline  
Old 26 February 2019, 19:05   #135
guest.r
Registered User
 
guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 342
OK, thanks for some details. I gave it a thought and produced a "working" version for a start.

It doesn't look to bad when upscaled/downscaled...

You can select mask 7 now, based on mask 5, since mask 6 seems a litle coarse for testing.

Edit: a seperate parameter now.

In the preset (if someone else wan't to test it), set the last pass as posted here:

Code:
shader7 = shaders/guest/crt-guest-dr-venom.glsl
filter_linear7 = true
scale_type7 = viewport
scale_x7 = 1.0
scale_y7 = 2.0
I started with a "4x1" slot configuration, which means 4 lines total, one of them is darkened, as i understood. I can make it "6x1"... to, but the number has to be even because of symmetry.

Suggestions are welcome, since this version is rather something to begin with.

Edit:

OK i think i got it better now. We can have a compressed slotmask with 1080p also, looks about the same as downscaled from 2160p, but without the annoying preset editing. I think it could take some tweaks, but the uncompressed version of it may look fine with 4k only.

You can switch between compressed (1080p) and uncompressed (2160p) look by editing the menu parameters - maybe some gameboy game can take the uncompressed version at 1080p also because of low y resolution, dunno.

Anyway, the meaning of "compressed" and the utilization of such technique got my understanding now. With other words, it's a compromise to get some diversity with masks.

Edit2: Small update. SlotMask is now a seperate function, looks better.
Attached Files
File Type: zip crt-guest-dr-venom.zip (4.9 KB, 68 views)

Last edited by guest.r; 26 February 2019 at 23:02. Reason: New shader version.
guest.r is offline  
Old 27 February 2019, 18:52   #136
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 485
Quote:
Originally Posted by guest.r View Post
OK, thanks for some details. I gave it a thought and produced a "working" version for a start.

It doesn't look to bad when upscaled/downscaled...
That's an understatement surely! The compressed version is looking great on 1080p! Stoked about this, it really adds that final touch of CRT realism

Quote:
I started with a "4x1" slot configuration, which means 4 lines total, one of them is darkened, as i understood. I can make it "6x1"... to, but the number has to be even because of symmetry.

Suggestions are welcome, since this version is rather something to begin with.
I think you may already have hit the sweetspot with the current one, given 1080p limitations. But for completeness I did some comparisons versus the real deal. I'll focus on the compressed slotmask, since that's the one we'll actually be seeing for some time.

Compared to the real deal, horizontally the current compressed slotmask seems a -tiny- bit too wide and vertically the spacing could be wider (almost double).

The alternatives below have a tiny adjustment, either horizontally (alt 1), vertically (alt 2), or both (alt 3). One of them is the 6x1 you already mentioned.

It would be great if these alternatives could be added as selectable parameters for the time being, such that we can easily switch during runtime and get a feel of the differences etc..? Maybe it will just confirm that we'll want to stick with the current one

Btw, I hope I understand compressed / uncompressed correctly. I'm guessing compressed means that it is a "smart" interpolated version of the uncompressed one? (As with blind linear rescaling some "shadow lines" for certain slotmask formations would disappear?)

Current slotmask
(* = darkened pixels)

Code:
compressed:
***---***---
---***---***
***---***---

uncompressed:
******------******------
------------------------
------******------******
------------------------
******------******------
Alternative 1 (this may be slightly more accurate in horizontal slot count)
Code:
compressed: 2 pixel horizontal shadow instead of 3
**--**--
--**--**
**--**--

uncompressed: 4 pixel horizontal shadow instead of 6 pixels
****----****----
----------------
----****----****
----------------
****----****----
Alternative 2
(vertical spacing is more correct, but the compression creates uneven spacing so may not look as good on 1080p as uncompressed will on 2160p; I think this is the 6x1 version you already mentioned)

Code:
compressed:
***---***---
---***---***
------------
***---***---
---***---***
------------

uncompressed:
******------******------
------------------------
------------------------
------******------******
------------------------
------------------------
******------******------
------------------------
------------------------
------******------******
------------------------
------------------------
Alternative 3 (alt 1 and alt 2 combined, may not look so good on 1080p?)

compressed:
Code:
**--**--
--**--**
--------
**--**--
--**--**
--------

uncompressed:
****----****----
----------------
----------------
----****----****
----------------
----------------
****----****----
----------------
----------------
----****----****
----------------
----------------
Oh and what is the new parameter "smart horizontal smoothing" doing?
Dr.Venom is offline  
Old 28 February 2019, 12:16   #137
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 485
In addition to my previous post, there may be a more elegant solution for the slotmask configuration and sizing. If this could work it will be possible to simulate slotmask sizing for everything CRT out there. Please bear with me below


Calculating number of slots (and thus shadows) in real CRT

I looked up the manual of the slotmask 14" CRT that I took the photograph of and its specification says
  • TVL 600
  • Dotpitch 0.42mm

TVL = the number of distinguishable vertical lines it's capable of displaying
Dotpitch = the distance between two phosphor dots of similar color. This should be very close to "RGB triple" phosphor width, i.e. single slot, which should thus approximate single shadow width in slotmask!

The width of a 14" 4:3 screen is 28.4cm / 284mm. (I used screen size calculator here: http://screen-size.info/ )

Number of slots in real CRT = (width of CRT screen in mm / dotpitch) -> Nr of slots for Philips 14" monitor = 284 / 0.42 = 676

Theoretically it should thus (?) be capable of 676 distuingishable vertical lines (TVL), but the manual says 600. Possibly this is some safe margin number?


Formula relevant for the shader

(note I'm assuming 4:3 screen dimension for CRTs)

Pixelwidth of shadows from slotmask = (1.333 x vertical_resolution_of_host_pc) / (width of simulated CRT screen in mm / dotpitch of simulated CRT screen)

So for our example should the width be 2 or 3 pixels?


Accurate shadow pixel width = (1.333 x 1080) / (284 / 0.42) = 1440 / 676 = 2.1 pixels

If we would take the TVL instead of the dotpitch it would be: 1440 / 600 = 2.4 pixels.

So I guess for 1080p the width must be between 2 and 3 pixels, for which 2 is theoretically slightly more correct.

I'm not yet sure what the implication would be for the vertical spacing, but I think we should be able to deduce the dimensions from the high resolution screenshot and real slotmask picture like this one: https://en.wikipedia.org/wiki/File:Schlitzmaske.jpg


Implications


Can above sort of calculation be done in the shader? There would no longer be a hardcoded slotmask size for 1080p and 2160p, but instead it would take these parameters:
  1. Slotmask: Diameter Size of simulated CRT screen (Range 13" to 32") -> this would need conversion from diameter in inch to width (in mm) like formula behind http://screen-size.info/
  2. Slotmask: Dotpitch of simulated CRT screen (Range 0.20mm to 0.90mm)

With these parameters and above formula all possible CRTs could be simulated, from big CRT TV's with low dotpitch to small(er) VGA monitors with high dotpitch, to our beloved small (14") CRT monitors with medium dotpitch etc!

It could be a shader first? Would love to hear your opinion on this
Dr.Venom is offline  
Old 28 February 2019, 17:09   #138
guest.r
Registered User
 
guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 342
About your first post, yeah i though about this too and now a seperate parameter is added to adjust the slotmask horizontal dimension.

My first impressions were that size of two goes with size of 2 dotmasks and size of 3 with other ones, but it's not a rule, so i rather made it optional.

Compressed means, hmm, a good exampe of it are the 0 or 5 phosphor masks. Due to integer nature of crt to lcd display emulations compression is polular, mostly because of chromodynamical and other differences (like signal processing etc.) combined with human perception. I mean used with a decent (=far) viewing distance the crt could take a lot of crap and still look operational.

Modern displays with digital signals, fixed standard resolutions, crisp pictures and small viewing distances show every crap/artifacts/wrong coding concepts and this spoiled some rather correct representaions of crt's on them.
The only thing that helps here is higher resolution, like 4k.

A good example of it is calculating the "dotmask" with curvature. A correct representaion would take the curved coordinates for dotmask representaion, but normally flat original coordinates are used. I thought the concept might work with curved coordinates too, but artifacts shew up and i discarded it.

Another way how to show the disadvantages of modern displays is to use crt shaders (with masks) with a non-native resolution. Or to scale the last pass to a custom arbitrary resolution (i.e. 1920x1080 works with 4k displays, 1366x768 looks crap with 1920x1080 display and masks).

I'm trying to say that integer stuff works well, but there are problems with arbitrary sizes and even some sort of interpolation can't help. 4k makes the integer options 2x and 2x better though.

I hope i could explain a bit why some things are rather problematic to solve with interpolation (like crt mask triads for example).

But i see some decent solutions here. If we want to display a correct number of phosphor triads for a resolution, it's best to use a custom aspect ratio. With some calculation the pixels and dots will line up.

Shaders are OK, can take a lot of crap also, but our modern displays aren't. Unfortunatelly.

To sum up what would it look like to emulate custom dot pitch sizes on 1080p displays is to use a custom fullscreen resolution.

Fortunatelly it works a bit with the slotmask only, so i included arbitrary sizes, to show the concept behind.

Quote:
Oh and what is the new parameter "smart horizontal smoothing" doing?
Ehh, it's a candy i like too look at.
I like crisp edges and some silkiness and this comes in.
Now it's still in a fast/early/hack stage and it blends similar looking colors a bit. I'm thinking a bit about an extended version, but this mean a slower shader and lot's of testing. Dunno...i would still need a bit of an Intel gpu feedback at 1080p not to make the shader too slow.

Anyway, here is a new version, nothing removed, good things added.

PS: if someone else would like to test it, you first need to download the preset and other shaders from http://eab.abime.net/showpost.php?p=...&postcount=124
Attached Files
File Type: zip crt-guest-dr-venom.zip (5.0 KB, 58 views)
guest.r is offline  
Old 02 March 2019, 00:09   #139
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 485
Thanks for explaining on the meaning of compressed, I think I got a better picture now

I tried the new version, but there's something different with how the 3 pixel mask looks compared to the version you created previously. It's a bit hard to describe, but it's doing something now that I sort of dislike in the Lottes masks too, somehow the mask is appearing stronger in the darker part between the bright scanlines, and/or is less visible for the brighter part? It's hard to describe in words, hopefully examination of both pictures below show the difference enough.

It compares the version from 26-02 (top) and 28-02 (bottom). In the enlarged part you can see the masks looking different. The brightness has also changed? Again this is very subtle and most people wont notice, but for me it's a kind of a dealbreaker and makes the new version less realistic. I assume that you have made a change in the mask appearance for this to occur?

Would it be possible to revert to the slotmask appearance and brightness from the 26-02 version while maintaining the possibility for the slotmask width setting?




Quote:
Ehh, it's a candy i like too look at.
I like crisp edges and some silkiness and this comes in.
Now it's still in a fast/early/hack stage and it blends similar looking colors a bit. I'm thinking a bit about an extended version, but this mean a slower shader and lot's of testing. Dunno...i would still need a bit of an Intel gpu feedback at 1080p not to make the shader too slow.
That's cool, I think I like it. Will be doing some more comparisons in different games to more fully get a feel for the difference

Last edited by Dr.Venom; 02 March 2019 at 00:27.
Dr.Venom is offline  
Old 02 March 2019, 12:13   #140
guest.r
Registered User
 
guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 342
Yeah, i see what you mean. The "new" version was a tad brighter, but the tradeoff is probably a bit worse.

Current version has reverted to old behavior. Now slotmask isn't 0.0/1.0 anymore, but strength can be selected. Think it's better this way. I also put the "4k" version on ice, since i can't test it properly and it slowed the shader, even unused.

About smart smoothing, current implementation is more a hack, but quite fast. I tested the full version of it, and it slowed the shader down. As i'm considering even intel igpu users, this might get a bummer (still need an intel tester with 1080p ).

You might want to test it with games with more colors, as it blends near standing ones and games with few colors also use greater color differences, so no change here.

Edit: Slot Mask strength of 0.5 reflects the old version.
Attached Files
File Type: zip crt-guest-dr-venom.zip (4.9 KB, 53 views)

Last edited by guest.r; 02 March 2019 at 12:27.
guest.r is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Love Emulators? - Dgen & Hatari emulators Paul News 18 14 January 2023 20:56
Multipass shaders craig64 support.FS-UAE 21 08 December 2020 11:01
Shaders Zeraphine support.Amiga Forever 2 15 March 2020 18:46
CG Shaders Enverex support.FS-UAE 2 05 October 2014 18:51
fx Shaders in WinUAE 2.6.0 crazy46guy support.WinUAE 8 16 June 2013 14:30

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 09:14.

Top

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Page generated in 0.14468 seconds with 14 queries