English Amiga Board


Go Back   English Amiga Board > Main > Retrogaming General Discussion

 
 
Thread Tools
Old 19 February 2019, 18:23   #121
guest.r
Registered User

guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 200
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, 18:25   #122
Retro-Nerd
Missile Command Champion

Retro-Nerd's Avatar
 
Join Date: Aug 2005
Location: Germany
Age: 47
Posts: 11,372
Ah ok, thanks for the explanation.
Retro-Nerd is online now  
Old 20 February 2019, 13:24   #123
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 435
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 13:29.
Dr.Venom is offline  
Old 20 February 2019, 20:41   #124
guest.r
Registered User

guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 200
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, 3 views)
File Type: zip guest.zip (12.5 KB, 2 views)

Last edited by guest.r; 20 February 2019 at 23:29.
guest.r is offline  
Old 20 February 2019, 23:00   #125
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 435
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, 23:59   #126
guest.r
Registered User

guest.r's Avatar
 
Join Date: May 2017
Location: EU
Posts: 200
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, 4 views)
guest.r is offline  
Old Today, 02:15   #127
Retro-Nerd
Missile Command Champion

Retro-Nerd's Avatar
 
Join Date: Aug 2005
Location: Germany
Age: 47
Posts: 11,372
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 online now  
 


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
Shaders Zeraphine support.Amiga Forever 0 24 May 2016 00:23
CG Shaders Enverex support.FS-UAE 2 05 October 2014 19:51
fx Shaders in WinUAE 2.6.0 crazy46guy support.WinUAE 8 16 June 2013 15:30
Love Emulators? - Dgen & Hatari emulators Paul News 17 19 January 2012 19:28

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 02:52.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07538 seconds with 15 queries