ShaderGlass v1.2.1-bfi-alpha3

[mausimus]

Important

ShaderGlass/BFI has been superseded by a new app, ShaderBeam. Check it out here

UPDATED ALPHA VERSION OF BFI / BLUR BUSTERS CRT BEAM SIMULATOR EXPERIMENT

This is an experimental branch of ShaderGlass dedicated to BFI & Blur Busters CRT Beam Simulator shaders.
Visit https://blurbusters.com/ to find out more about the shaders and their authors.
All other RetroArch shaders have been removed in this branch; use the mainline version of ShaderGlass for those.

This is alpha3, big thank you to everyone for testing previous alphas.

DOWNLOAD
https://github.com/mausimus/ShaderGlass/releases/download/v1.2.1-bfi-alpha3/ShaderGlass-1.2.1-bfi-alpha3-win-x64.zip

How to test:

• start up ShaderGlass, it will launch in a window
• it should default SubFrames to refresh rate / 60, double check in Output -> Sub-frames
• start up your game in borderless full-screen and limit to 60 fps if possible (using in-game limiter or RTSS)
• press Ctrl+Shift+G to bring ShaderGlass fullscreen while keeping focus in-game
• press Ctrl+Shift+A to toggle shader on/off to make sure it's active (if anything, image will be slightly darker); if you're seeing desync (hard flashing) you can use this hotkey to reset
• you can use Output menu to try different shaders and change some of their Parameters

For best results:

• disable "Hardware accelerated GPU-scheduling" (HAGS) in Windows if you have the option to (System -> Display -> Graphics -> Advances graphics settings; computer restart required)
• alternatively, use Process Lasso (https://bitsum.com/) to set ShaderGlass' both CPU and GPU priorities to Always Real-Time (works just as well as disabling HAGS for me)
• use latest version of Windows 11 (24H2) so that you are able to utilize Max Capture Rate
• set Windows Power Mode to Best Performance (every little helps)
• disable any other apps, overlays, disconnect additional monitors etc.
• start with lower graphics quality or older games: the more GPU headroom there is, the easier it will be to avoid desyncs

With all of the above, desyncs (i.e. flashing) and capture stutter are minimal on my setup (13600k, 5060Ti 581.08, 240Hz 1080p). I recommend starting with older games like Quake or Trackmania before trying newer titles (these can be a mixed bag; UE games in particular often flash in menus but work decently in-game).

As usual, feel free to give this a shot and report your experience. This is really just an experiment to see if using capture method is a viable approach to running beam simulation shaders (it's far from ideal, but nevertheless worth trying). Since we are dealing with the black box of Windows' GPU scheduling, any correlation with your settings or specs can reveal meaningful info.

Changes in alpha3:

• improved timing circuits to reduce capture stutter
• Max Capture Rate is now enforced when available (please update to Win11 24H2)
• merged in mainline fixes around device capture

Subframe specific options

You can adjust subframe-specific options to see if it makes a difference on your setup:

• Sync first sub-frame: when set, this will capture at 60 Hz and use the same input frame for all subframes (as is the intention); if you disable this you might get less stutter and lower latency but get some color/tearing-like artifacts from the shader
• Internal VSync: rather than using driver VSync, ShaderGlass can try to time frames to its internal VSync clock (older method kept for posterity/experiments only)

FREQUENTLY ASKED QUESTIONS

> What do I need to try this?

You need a high-refresh monitor which can run at a multiple of 60Hz (120, 240 etc.)

> I see slow moving scanlines or color banding on screen

This is a feature of CRT Beam Simulator to prevent temporary image retention. You can open Shader -> Parameters window and either set Scan Direction to 0 to disable, or adjust Gamma so that it's less visible.

> I started a game but it's flashing a lot

Try lowering quality settings in-game, you need a lot of GPU headroom; and make sure you did what you can from the best results list above.

> Every 10 or 20 seconds there's a "stutter wave"

Try to set your monitor to exact multiple of 60 Hz, not 239.76 Hz or something like that.

Previous alpha and testing feedback:
#200

---

This discussion was created from the release ShaderGlass v1.2.1-bfi-alpha3.

[mausimus]

One more tip if you're still having capture stutter issues you can try Window capture:

• once your game is in borderless fullscreen, alt-tab to ShaderGlass
• change Input -> Window -> (your game)
• change Output -> Window -> Click-through
• click back on the game to give it focus
• Ctrl+Shift+G to make ShaderGlass fullscreen

Using Window capture is slightly more efficient because it can bypass desktop composition.

[thelastant]

@mausimus I'm trying this with a DirectX9 game, the game is locked at 60 fps. When i use Shaderglass it reads 60 on top of the 60. With other games i'm able to read the 240fps on top of the the 60. Any ideas what could it be?

[mausimus]

Hm it says 60->60 in the top bar? That's unusual, the second number should always be refresh rate (first one will vary depending on the game and how it frame-limits itself) so it'd seem ShaderGlass is being throttled somehow. What's the game?

[thelastant]

Velvet Assassin. I've tried to use SpecialK and it's able to provide me with the 240Hz. But not with Shaderglass. It may be an incompatibility issue with the DX9 API. I'll try to use DXVK and test it again.

[thelastant]

@mausimus The game itself changes the OS refresh rate to 60Hz, and if I try to force it back to 240Hz I get only a black screen. Even with DXVK; weird old-game behaviour. I'll try to understand why this is happening. I'll keep you posted.

[mausimus]

I think the game might be forcing the display mode rather than using borderless fullscreen. I don't have this one but I tried Trackmania on DX9; works fine by default (unlimited) or when frame-limited with RTSS; but when I use their built-in frame limiter it forces 60 Hz on everything including ShaderGlass (which results in massive subframes flicker). Perhaps there's a way to force your game into borderless and/or limit using RTSS.

Edit: saw your post, agreed.

[dontpokethebear3893]

With Nvidia you can force the game profile to use maximum refresh rate. Preferred Refresh Rate - Highest Available. You might want to use DXVK to force Borderless Windows mode to make it work.

[mdrejhon]

New TestUFO CRT Simulator Demo: https://testufo.com/crt

For people who want to play with CRT simulator in a web browser before trying the software out.

[SokarCodes]

Excellent as always. I can do 1400px/s speed and everything is crystal clear on 480Hz OLED. I get lots of stutter warnings though. Even when closing everything and only UFO-test tab on my Brave browser. Drops to 475fps and then syncs back to 480Hz and after few seconds stutter warning again.

9800x3D + RTX5090 + 32GB DDR5 6000MHz CL32 + Gen4 SSD.

[xCaptainTroy]

Is there anyway to get rid of these horizontal lines that happen when active the crt beam ?

[mdrejhon]

Is there anyway to get rid of these horizontal lines that happen when active the crt beam ?

1. Try adjusting based on instructions at Solutions to Known Issues [Banding, Color Ghosting, Erratic Flicker] blurbusters/crt-beam-simulator#4

2. You can also use the solid fields at TestUFO (75 IRE Solid Gray" (see links in description),
   e.g. https://testufo.com/crt#photo=crt/field-white-75ire.png

3. Try turning off scan (set scan to 0)

4. Failing that, try testing an OLED or a newer FastIPS LCD instead of TN or older LCD

[dontpokethebear3893]

a) Doesn't turning off the scan turn off the feature? Isn't the entire motion blur reduction reliant on the scan?
b) Is it safe to turn off "LCD-Anti-Retention" on an OLED display? Keeping the horizontal lines in place would cause burn-in over time, wouldn't it?

[man33li]

Using different curve screen shaders warps the text and makes it unreadable while the flat one doesn't. Also, the video in Disney's website is always black.

[mausimus]

Black screen on some streaming sites is a copy-protection feature unfortunately.

[mdrejhon]

Using different curve screen shaders warps the text and makes it unreadable while the flat one doesn't. Also, the video in Disney's website is always black.

Yeah, unfortunately DRM-protected content is not supported by any CRT simulator software. Windows is blocking access to those pixels. You need to play DRM-free software to make it work with CRT simulator.

[nigma46]

@mausimus This might help you: https://x.com/CookedNick/status/1960052790568571353

[man33li]

Thanks for the solution. Also, while importing different shaders I found that the famous Megatron shader have extreme red bloom and halation. Is it a quirk of the shader or an incompatibility with shader glass?

[mausimus]

Yes not all shaders will work exactly the same, some for example require Vulkan while ShaderGlass is DirectX-only for now; similar with HDR, it's not fully supported; if you can post a link to the shader you used I can take a look.

[man33li]

This the link for the megatron shader : https://forums.libretro.com/t/sony-megatron-colour-video-monitor/36109?u=cyber

[man33li]

Played PUBG using the CRT beam simulator felt smoother and the colors are better however there are times when the screen became too dark in glass mode. What are the differences between glass and clone?

[mausimus]

There's no difference visually between Glass and Clone modes, it's only a capture method difference. CRT Beam Simulator does make the image a bit darker (you can adjust the balance in Parameters) so it sounds like in Clone mode you might not have had ShaderGlass on top of your game (press Ctrl+Shift+G to force it fullscreen and on top).

[dontpokethebear3893]

I'm trying this out now on a 4k 240hz OLED and have a couple of issues.

I see the small black lines crawling up the screen. When playing a game, I get huge input lag when limiting the frames to 60fps (happens with both Nvidia frame limiter and RTSS). I'm also getting some stutter when the game is running despite GPU usage only being around 25%.

I made ShaderGlass real-time priority with ProcessLasso as instructed but am still seeing this lag. I will attempt to run the game as borderless windowed and change the input to just the game to see if that helps.

[dontpokethebear3893]

Solved the lag - for some reason RTSS is causing a framerate drop glitch. Was only getting 35-38 fps instead of a smooth 60. In-game limiter works fine, though. I also had to change the Nvidia Profile for the game to use fixed refresh, maximize refresh rate, and disable Vsync. Using Ultra Low Latency to make playing only at 60 a lot more tolerable.

[mausimus]

Interesting, thanks for testing and glad you found a config that works. In my testing I stopped using RTSS and either rely on in-game frame limiters or no limit at all (as long as there's GPU headroom it doesn't matter, the shaders will take input at 60 Hz anyway). I don't run that many GPU-heavy games though. As mentioned on other threads, if you'd like to reduce latency as much as possible, don't limit the game and untick "sync first sub-frame" option in ShaderGlass.

[dontpokethebear3893]

I fond out that RTSS was causing slowdowns for me because I was forcing Smooth Motion in Profile Inspector, so RTSS 60fps limit is an in-game 30fps limit.

[mdrejhon]

I see the small black lines crawling up the screen.

That's because of the LCD Saver mode. Turn that feature off, OLED's don't need it.

Adjust your OLED's brightness/contrast based on the instructions at top of https://beta.testufo.com/crt -- that will often help.

Failing that, try setting scan direction to 0, to turn it into a global phosphorescent-BFI (global CRT refresh) rather than a rolling scan.

[mdrejhon]

I fond out that RTSS was causing slowdowns for me because I was forcing Smooth Motion in Profile Inspector, so RTSS 60fps limit is an in-game 30fps limit.

It's a case-by-case usefulness: Multiply that by subframe count, e.g. For 240Hz monitors, RTSS 240fps for emulators 60fps or console 60fps ports. Some emulators need RTSS help to stop stuttering. External framerate caps can smooth a lot of software.

At least until Shaderglass has a built-in capping system (ideal).

[LionT750]

I've done extensive testing on shader, 144hz 1080p monitor and rtx 5070 ti. Shader works flawless as long as there is reasonable headroom on GPU usage. At more modern and heavy games, using window capture approach was the only way to achieve boost clock on GPU, not sure if its a bug.

[MohamedKhalil8801]

After some testing, I noticed the following:

1. The less windows open the better, even having something like WhatsApp open was causing massive issues, close all windows, and I mean all of them, even open folders, just close everything, this will improve the stability a lot.
2. The end result depends on the game, I've tried Lies of P with it's in-game fps limiter, and the experience was really good almost flawless, while a game like Ghost of Tsushima gave me a lot of trouble. Playing Lies of P even on the highest settings was flawless while playing Ghost of Tsushima even on the lowest settings was still bad.

I would suggest to add the following:

1. an integrated FPS limiter that works really well with your shader, because even small difference can cause a desync.
2. when I choose to capture the game's window (which is suppose to be slightly faster), my mouse becomes visible, which is annoying.
3. from my understanding, scanlines are not important, if that is the case then maybe you should disable them by default.
4. changing the parameters doesn't save when you exit the app, it just resets to the default settings.

[mausimus]

Thanks a lot, great points. An integrated frame limiter that can sync with ShaderGlass' processing would be a great thing to try. I have also been thinking about an injection plugin which would send info to ShaderGlass cross-process; both quite tough projects though.
I have similar experience myself that a lot depends on the game, some games like Cyberpunk run flawlessly for me even if GPU limited and rendering less than 60 fps.
BTW this is just an alpha, if you really want to save the parameters you can save a profile or set it as default (Processing menu). But please beware this will interfere with the mainline version of ShaderGlass (the one with 1,000+ other RetroArch shaders) if you're also using it.

[mo355]

I tried it on my 3k 120 hz oled laptop and it works perfectly fine no stutter or problems and it's soo amazing but I have single problem which is latency a very noticeable 200ms of latency is there any solution

[mausimus]

Wow 12 frames of latency is really unheard of, I have no idea which part of the chain would buffer this many frames (definitely not ShaderGlass, it doesn't buffer at all!). Please try a different game or experimenting with settings a bit, this is definitely not normal (are you on Win10 or Win11? the latter is unfortunately much better for ShaderGlass). In the ideal situation ShaderGlass will only add 1/60 frame (i.e. 16ms) latency on top of the input, but how much other components like Windows Capture, Desktop Window Manager or the graphics driver add is unfortunately outside of my control.

[mo355]

I think I found solution shaderglass seem to favor igpu and input<window<game helps alot with latency and output<sub-frames<internal v-sync helps with latency a bit. now it's almost unnoticeable

Also could you give us more parameter to fix very bright and very dark spots

[Citrus333]

Couple questions, is this doing 120hz BFI on 120hz panels? Or like in retroarch does the content need to be 60fps for BFI/Beam sim to work on a 120hz panel?
Also any game I tested this on always said '120 -> 120' at the top, even when I limited the game to 60fps. When running games at 120fps with BFI/Beam Sim the screen was darker like it was working. But it was hard to tell.

[mausimus]

Thanks for testing! Yes it will do BFI on 120 Hz by taking input at 60 fps and inserting black frames in-between, there are also some presets tailored to 120 Hz in there you can try. Things being darker is the best way to tell it's working (especially when it changes brighter/lighter when you toggle shader on/off with Ctrl+Shift+A).
Not to worry about seeing 120 source fps even after limiting the game, it will depend on how the game limits itself (it might display same frame twice for example); Windows Capture providing 120 input frames instead of 60 will actually help reduce latency (ShaderGlass will still always process inputs at 60 fps, as long as the "Sync first sub-frame" option is ticked, so even if you don't fps-limit a game it will be processed by BFI/BeamSim at 60 fps input). The main benefit of frame-limiting the game is to increase GPU headroom to reduce stutter/flashing.

[Citrus333]

I see! Thanks for the input! Running the games I've tested at 120fps with BFI feels like the game is running at 120fps even though ShaderGlass is only processing 60fps, which is crazy.

What happens if I disable "sync first sub-frame" and run the game at 120fps?

[mausimus]

When "Sync first sub-frame" is ticked, ShaderGlass will take 1 input frame and render all subframes using it, so on 120 Hz (2 subframes) will take 1 input frame at 60 Hz and render two shader subframes using it as input. When it's unticked, ShaderGlass will use latest input frame for every subframe.
The effect of this will depend on the shader: for simple BFI there's almost no difference since all subframes except one are pure black (you might as well untick this for lower latency), but for Beam Simulator you will start seeing artefacts like chromatic aberration on fast motion because each Beam Simulator subframe shows a portion of the screen.
TLDR if you'd like lowest possible latency you should untick this but at the cost of some visual artefacting (will depend on the game).

[LionT750]

mausimus is it possible to also allow subframes for 30 fps basis content? Like, if i want to max out a game at a 30 fps and output to 120 hz using 3 subframes for possible increase in motion clarity even at 30 fps content?

[mdrejhon]

mausimus is it possible to also allow subframes for 30 fps basis content? Like, if i want to max out a game at a 30 fps and output to 120 hz using 3 subframes for possible increase in motion clarity even at 30 fps content?

Minor nit but 120/30 = 4 subframes. You can also do 120/40 = 3 subframes.

Also, I'm creating a meta entry for my top suggestions: #209

[MohamedKhalil8801]

in the parameters, there is Brightness vs Clarity option, when I push it higher to around 0.975250 for me, it becomes totally clear and pretty much perfect, like 99% the same brightness as normal without the filter, are there downsides to doing this? why would I want to make it darker? also should I disable Scan Direction? what is the point of having it?

How do I save those changes as the default so that they don't reset everytime?

[mdrejhon]

in the parameters, there is Brightness vs Clarity option, when I push it higher to around 0.975250 for me, it becomes totally clear and pretty much perfect, like 99% the same brightness as normal without the filter, are there downsides to doing this? why would I want to make it darker? also should I disable Scan Direction? what is the point of having it?

You need a large Native:Simulated Hz ratio to see a big difference. You won't see much difference at 120Hz LCD, but you will see a big difference at 480Hz OLED for fast pans/scrolls/turns. Basically 480Hz can reduce almost 90% of 60fps motion blur, while 120Hz can only reduce 50% of 60fps motion blur.

Reward of this setting is MUCH higher at a large ratio of Hz:framerate or nativeHz:simulatedHz.

Play with the "Gain vs Blur" setting at https://beta.testufo.com/crt to see what I mean. You can even simulate a 30Hz CRT and get 75% motion blur reduction on 30fps, but it's VERY flickery. Basically you're getting sneak preview of 30fps with the motion clarity of 120fps, as a preview of what 60fps looks with 75% BFI/CRT on your future 240Hz monitor.

@mausimus you should have autocompute like I already have at TestUFO (automatically use GAIN_VS_BLUR = 1/subframe_count whenever "Auto (Best Possible Clarity)" is selected). Basically use 0.25 in Auto mode for emulating a 60Hz CRT on a 240Hz display.

[MohamedKhalil8801]

in the parameters, there is Brightness vs Clarity option, when I push it higher to around 0.975250 for me, it becomes totally clear and pretty much perfect, like 99% the same brightness as normal without the filter, are there downsides to doing this? why would I want to make it darker? also should I disable Scan Direction? what is the point of having it?

You need a large Native:Simulated Hz ratio to see a big difference. You won't see much difference at 120Hz LCD, but you will see a big difference at 480Hz OLED for fast pans/scrolls/turns. Basically 480Hz can reduce almost 90% of 60fps motion blur, while 120Hz can only reduce 50% of 60fps motion blur.

Reward of this setting is MUCH higher at a large ratio of Hz:framerate or nativeHz:simulatedHz.

Play with the "Gain vs Blur" setting at https://beta.testufo.com/crt to see what I mean. You can even simulate a 30Hz CRT and get 75% motion blur reduction on 30fps, but it's VERY flickery. Basically you're getting sneak preview of 30fps with the motion clarity of 120fps, as a preview of what 60fps looks with 75% BFI/CRT on your future 240Hz monitor.

@mausimus you should have autocompute like I already have at TestUFO (automatically use GAIN_VS_BLUR = 1/subframe_count whenever "Auto (Best Possible Clarity)" is selected). Basically use 0.25 in Auto mode for emulating a 60Hz CRT on a 240Hz display.

I have a 240hz oled monitor, so I should use 0.25 for best clarity right? it just seems very dim

[mdrejhon]

I have a 240hz oled monitor, so I should use 0.25 for best clarity right? it just seems very dim

Yes, it is pretty dim.

That's why you adjust for best compromise of "brightness vs blur". You can't max out both at the same time, so it's a continuum of adjustment.

---

@mausimus Please make sure you support turning on/off HDR in your framebuffer. My upcoming newer CRTv2 will include optional support for SDR->HDR brightness boosting. Convert SDR to HDR and then allow adjustment to make HDR brighter than SDR. On some OLEDs, it doubles brightness of BFI algorithms, as reported by Digital Foundry:

(RetroTink used HDR as a SDR BFI brightness booster)

[grendelrt]

I have a 240hz oled monitor, so I should use 0.25 for best clarity right? it just seems very dim

Yes, it is pretty dim.

That's why you adjust for best compromise of "brightness vs blur". You can't max out both at the same time, so it's a continuum of adjustment.

@mdrejhon I was playing with "brightness vs blur" yesterday, I am assuming this isn't linear when adjusting as far as losing blur reduction? I was using text on example and the Eiffel tower struts on the testufo page to watch as the brightness increased and there was still tons of blur reduction. If .25 on a 240hz monitor is 85% reduction, .75 didn't look drastically worse on the blur to me, so is it is a much smaller loss , maybe 65/75% reduction when adjusting the brightness back up to a higher value on a 240hz monitor?

[MohamedKhalil8801]

How much difference does "Max Capture Rate" option make? I have Windows 11 23h2, I don't want to upgrade unless it actually makes a meaningful difference.

[grendelrt]

I am currently applying this to ShadPS4 as test with good results, I need to play with some more settings, but its stable on my 240hz OLED.

Question for @mdrejhon based on your last blur buster article,

"The Blur Buster CRT beam simulator is currently implemented in RetroArch for emulation and in Vint for video playback. Vint provides all CRT beam simulation features including simulated phosphor decay and even VRR support so, for example, a 50FPS video can be played back perfectly on a 240Hz gsync display at 4x (200Hz output)."

Is this what retroarch does for games that are not 60hz, says 57hz or is only Vint doing this? @mausimus Based on the above would it be possible for shaderglass to support games that are not exactly 60hz by just multiplying the source refresh (57hz x 4, 228hz on a 240hz monitor) by a multiple? My highest usage of shaderglass is on retro games and retro arcade games which all rely on refreshes between 55-60hz mainly.

[mdrejhon]

Is this what retroarch does for games that are not 60hz, says 57hz or is only Vint doing this? @mausimus Based on the above would it be possible for shaderglass to support games that are not exactly 60hz by just multiplying the source refresh (57hz x 4, 228hz on a 240hz monitor) by a multiple? My highest usage of shaderglass is on retro games and retro arcade games which all rely on refreshes between 55-60hz mainly.

RetroArch doesn't support non-integer subframes, even though my TestUFO and possibly ShaderGlass can.

You have two legitimate options with separate pros/cons

1. Integer divisibility. Create a custom 228Hz refresh rate. You have multiple apps that can do it (NVCP, ToastyX, etc)
2. Non-integer divisibility. Just do 57Hz at 240Hz. You don't need integer-divisibility with https://beta.testufo.com/crt
3. ShaderGlass modifications to support custom native Hz on VRR displays

Item 1 requires hoop jumping (custom resolution) while item 2 is user friendly and creates a very smooth 57fps with just a bit of rolling flicker artifacts (not always objectionable, a user preferece). It looks much smoother than 57fps at 240Hz without the CRT simulator.

Now for @mausimus --

Suggestion: "Simulated-Fixed-Hz" via VRR

VRR via internally framerate capped VRR (shaderglass subframe cap, not game capping), to effectively emulate a 228Hz fixed-Hz display on a 240Hz+ VRR / GSYNC / FreeSync display. This eliminates the need to create a custom fixed-Hz resolution.

Alternatively, ShaderGlass can be upgraded to framepace at exactly 228fps with a busyloop-controlled ultra-high-precision Present() on a VRR display. Creating "228Hz" out of "240Hz".

Exacxting precision will be total essential. Busyloop on QueryPerformanceCounter() to do this!!!! !!!! (Burning a CPU core on busyloop is nearly completely mandatory here to prevent erratic flickers unless you have ultra-precision microsecond timer events)

The problem is that even 0.1ms frame mis-pacing violates Talbot-Plateau Theorem, since 0.1ms out of 10ms (simulating a 100Hz CRT tube on a 240Hz display using exactly 2 integer subframes per CRT refresh) is a 1% change in photons accumulation (= 1% brightness flicker because of 0.1ms mispace of CRT subframe during VRR operation). (cc @mausimus )

RTSS has microsecond-capable framerate capping (with jitter as small as under 20 microseconds) which is good enough margin, so there's already software precedent. So when you enable a "[X] Ultra Precise Frame Pacing", enable the busyloop+present+flush logic path. Only works well in High Performance Mode and you may need to "churn" the GPU under a millisecond prior (to force-wake it up) before the busyloop.

That's what I did for beam racing a GPU, see https://www.pouet.net/topic.php?which=11422&page=1

(Not to be confused with software-based GSYNC Pulsar idea)

[grendelrt]

Is this what retroarch does for games that are not 60hz, says 57hz or is only Vint doing this? @mausimus Based on the above would it be possible for shaderglass to support games that are not exactly 60hz by just multiplying the source refresh (57hz x 4, 228hz on a 240hz monitor) by a multiple? My highest usage of shaderglass is on retro games and retro arcade games which all rely on refreshes between 55-60hz mainly.

RetroArch doesn't support non-integer subframes, even though my TestUFO and possibly ShaderGlass can.

You have two legitimate options with separate pros/cons

1. Integer divisibility.  Create a custom 228Hz refresh rate.  You have multiple apps that can do it (NVCP, ToastyX, etc)

2. Non-integer divisibility.  Just do 57Hz at 240Hz.  You don't need integer-divisibility with https://beta.testufo.com/crt

3. ShaderGlass modifications to support custom native Hz on VRR displays

Item 1 requires hoop jumping (custom resolution) while item 2 is user friendly and creates a very smooth 57fps with just a bit of rolling flicker artifacts (not always objectionable, a user preferece). It looks much smoother than 57fps at 240Hz without the CRT simulator.

Now for @mausimus --

Suggestion: "Simulated-Fixed-Hz" via VRR

VRR via internally framerate capped VRR (shaderglass subframe cap, not game capping), to effectively emulate a 228Hz fixed-Hz display on a 240Hz+ VRR / GSYNC / FreeSync display. This eliminates the need to create a custom fixed-Hz resolution.

Alternatively, ShaderGlass can be upgraded to framepace at exactly 228fps with a busyloop-controlled ultra-high-precision Present() on a VRR display. Creating "228Hz" out of "240Hz".

Exacxting precision will be total essential. Busyloop on QueryPerformanceCounter() to do this!!!! !!!! (Burning a CPU core on busyloop is nearly completely mandatory here to prevent erratic flickers unless you have ultra-precision microsecond timer events)

The problem is that even 0.1ms frame mis-pacing violates Talbot-Plateau Theorem, since 0.1ms out of 10ms (simulating a 100Hz CRT tube on a 240Hz display using exactly 2 integer subframes per CRT refresh) is a 1% change in photons accumulation (= 1% brightness flicker because of 0.1ms mispace of CRT subframe during VRR operation). (cc @mausimus )

RTSS has microsecond-capable framerate capping (with jitter as small as under 20 microseconds) which is good enough margin, so there's already software precedent. So when you enable a "[X] Ultra Precise Frame Pacing", enable the busyloop+present+flush logic path. Only works well in High Performance Mode and you may need to "churn" the GPU under a millisecond prior (to force-wake it up) before the busyloop.

That's what I did for beam racing a GPU, see https://www.pouet.net/topic.php?which=11422&page=1

(Not to be confused with software-based GSYNC Pulsar idea)

Thanks for the detailed explanation and great support!

[mdrejhon]

You can already do 57Hz by creating a custom resolution in NVCP, and running RetroArch that way.

For ShaderGlass, I'm not sure if that's mandatory or optional. Theoretically you can run 57Hz CRT sim at 240Hz, since the CRT beam simulation shader uses temporal sampling and does not require integer-divisibility.

[grendelrt]

But Vint uses VRR to pick the resolution so you don't have to have separate resolutions defined right?

Interesting on the second point, I though people were having issue when it wasn't exactly 60hz, but I haven't tested yet myself. I will try that out this week. Thanks.

[mdrejhon]

Yes, VRR can be a workaround once @mausimus adds a "output-side-only subframe capping system" -- see #202 (reply in thread)

There's two caps (subframe side and game side) that can be useful.

I think mandatory should be a toggleable feature.

Mandatory is useful (perfect sync) but not mandatory. You can do any CRT simulation Hz at https://beta.testufo.com/crt -- try any custom CRT simulation refresh rate -- it works.

There are minor issues (yes), like minor flicker if native:simulated ratio is extremely tight. You will get some rolling effects, until you brute it significantly. But it looks smooth (observe how smooth 60fps at 144Hz looks), which is quite impressive considering the non-integer-divisibility, despite the rolling artifacts.

You will get some quivering artifacts and/or some flicker artifacts if the native:simulated ratio is small, but as you get to large ratios (e.g. simulated 50Hz PAL at 240Hz OLED), the flickering becomes super faint or ceases.

Kind of like spatial scaling artifacts for non-integer resolutions, but along the temporal dimension. ReShade and RetroArch can't do it, but it seems ShaderGlass can potentially be made to work (with only minor modifications). Just make sure you're presenting at framerate=Hz, regardless of the game's underlying framerate (whether or not that underlying framerate is capped or not).

P.S. VRR-CRT is possible (varying the Hz of the CRT simulation) is a planned feature of CRT simulation at some future, so you will need to (eventually) relay frametime history as shader uniforms to a future version of the CRT simulator, so it can correctly blend them together in a VRR simulator. Software based "GSYNC Pulsar" FTW. Though "useful" refresh rate range will be tight until we have high Hz, e.g. 40-240Hz "software CRT-VRR" range on a future 720Hz OLED. That's because roughly, you want at least 3:1 simulated:native Hz for non-integer Hz to keep artifacts down.

[mdrejhon]

User Friendliness CRT Hz Tweak Idea?

Maybe configurability (min Hz, target Hz, whether to round it off to integer, etc). Just a configuration workflow to think about, because you want it to automatically use 72Hz CRT for 144Hz and automatically use 60Hz CRT for 120Hz. What I propose is automatically compute nearest integer divisible subframes.

• Target Simulated CRT Hz (Recommended 60-100): [_ _ _]
  • DEFAULT: 60
• Integer Divisible Subframes To Prevent Artifacts (Recommened ON): [ON | OFF]
  • DEFAULT: ON
  • [Description Box For Users: It is not recommended to disable this checkbox unless your native:simulated ratio is at least 3. ShaderGlass will automatically round to nearest Hz based on your current display Hz]
• Actual Simulated CRT Hz Used: [display automatically calculated Hz here]
  • [Description Box For Users: "If you mandatorily require integer divisible for your target, create a custom refresh rate (e.g. 240Hz monitors should use 200Hz for 50Hz PAL emulators"]

So Actual Hz becomes "72" for 144Hz displays if you set target to 60 and turn on Integer Divisible. You can automatically go downwards if Hzroom is limited, e.g. 60 may allow 50 if you only have a 100Hz screen and you turn off integer divisible.

The formula in ShaderGlass before running CRT shader would be:

// Pseudocode for user friendly autoconfigure of CRT subframes

float nativeHz = your display refresh rate, automatically detected but overrideable (e.g. secondaries on multimonitor)
float targetSimHz = user preferred simulated Hz
bool mustIntegerDiv = user preferred integer divisibility

float subframes = nativeHz / targetSimHz;
bool integerDiv = subframes !== Math.round(subframes);

if (mustIntegerDiv) subframes = Math.floor(subframes);
if (subframes < 2) subframes = 2;
float actualSimHz = nativeHz / subframes;

if (actualSimHz < 59) {
  warn("Your simulated CRT Hz may flicker a lot. While motion can look really smooth, use a higher refresh rate display if you prefer to reduce the flicker.")
}

if (!integerDiv) {
  if (subframes < 3) {
    warn("Your non-integer-divisible simulated Hz will work and framerate may look smooth, but you may see objectionable rolling flicker.")
  } else {  
    warn("Your non-integer-divisible simulated Hz will work and framerate will look smooth. There might be minor rolling flicker that disappears during dimmer settings. Readjust gamma if necessary.")
  }
}

// Now you can relay the uniforms.

Your math formula inside ShaderGlass would automatically calculate the maximum possible subframes at a reasonably adjacent refresh rate.
"Simulated 75Hz" at 240Hz -> it will automatically use 80Hz instead.
etc.

Also for blur busting "Auto Calc - Maximum Possible" setting at https://beta.testufo.com/crt

float gainVersusBlur = (user preferred blur busting ratio, or "Maximum Blur Reduction")
bool preferMaxBlurReduce = true; (if user chooses "Maximum Blur Reduction" for gain vs blur)
if (preferMaxBlurReduce) {
  gainVersusBlur = 1.0f / subframes;
}

Now that being said, this may require editing the shader if it's better to be done over there (e.g. a checkbox uniform). Currently at TestUFO I do it at the Javascript level but you could simply relay flags instead or use magic numbers (e.g. 0=automatic calculation), and do it to a modified shader.

If you modify the shader, then I should modify my shader, because CRTv2 should still be kept be easy to port to many open source projects.

Long-Term Future

And if ShaderGlass later adds framerate capping for the underlying content framerate (ala RTSS),

mustCap = (user preferred setting whether or not to framerate cap)

The cap wouldn't need to be relayed to the CRT simulator, but would be done via separate logic to limit the game framerate to simulated Hz, a divisor thereof (above or below CRT Hz, there's pros/cons), or a preferred absolute exact number (which may or may not match Hz).

Long term, frametime history (time intervals for the last few frames) and gametime timestamp history (monotonically increasing counters) will need to be relayed as uniforms, for a future "simulated VRR CRT" (that can run to a fixed Hz display) for a defacto software-based equivalent of "GSYNC Pulsar".

Also please keep it compatible with future non-CRT shaders, https://blurbusters.com/open-source-display -- I can simulate plasma subfields on a 600Hz OLED, for example. Ditto for simulating other retro display technologies in a shader.

[mdrejhon]

Suggested Improvements (Short / Medium / Long-Term)

I just added a new github issue entry to group it in the same umbrella.

• CRT Electron Beam Simulator Improvements #209

I realize some of these are complex, but long-term, subframe shaders will benefit from this!

[grendelrt]

Suggested Improvements (Short / Medium / Long-Term)

I just added a new github issue entry to group it in the same umbrella.

* [CRT Electron Beam Simulator Improvements #209](https://github.com/mausimus/ShaderGlass/issues/209)

I realize some of these are complex, but long-term, subframe shaders will benefit from this!

This is awesome, thanks for working so closely with everyone to get this out there!

[rmboi]

Hey, Idk if you know but Lossless-Scaling let's you use a second graphics card that does it's scaling magic and that let's you play without the input latency that happens when rendering the game and LS on the same GPU. I saw that ShaderGlass has a menu for choosing the GPU, can I just pop in one and select it in the menu? How would I need it setup?

[mausimus]

Yes you should be able to use a second GPU for ShaderGlass but it's a new feature and not extensively tested yet. In theory you should plug in your monitor into the secondary GPU and play the game on primary GPU. I don't have a decent second GPU to test this myself so if you do have a chance to try please let us know how it goes.

[mdrejhon]

Yes you should be able to use a second GPU for ShaderGlass but it's a new feature and not extensively tested yet. In theory you should plug in your monitor into the secondary GPU and play the game on primary GPU. I don't have a decent second GPU to test this myself so if you do have a chance to try please let us know how it goes.

That's great news!

I am curious; Is framepacing better on a secondary GPU, when the primary gaming GPU is pegged at 100%?

[DandyConeJellos]

I'm getting insane headaches+eye strain when I turn this on. I tried 240/180/120hz (on a 240hz OLED) and each time it felt like my eyeballs were vibrating. I'm sure this isn't helpful information but I thought it was interesting. Even just looking at a static image with it on hurt.

[mdrejhon]

I'm getting insane headaches+eye strain when I turn this on. I tried 240/180/120hz (on a 240hz OLED) and each time it felt like my eyeballs were vibrating. I'm sure this isn't helpful information but I thought it was interesting. Even just looking at a static image with it on hurt.

Did you set output to be 60Hz or 80Hz output Hz (4 or 3 subframes), not 30Hz (30Hz flicker)? You don't want a low output frequency. The input frequency and output frequency is not the same.

If the output simulated CRT refresh rate is correctly configured (60Hz and 80Hz flicker), then this shader isn't for you. People still had eyestrain back in the day with CRTs too.

[DandyConeJellos]

The subframes were 4 with 240hz, 3 with 180hz and 2 with 120hz. I don't remember having much eyestrain using CRTs back in the day. The weird part is if I stare at one part of the screen it doesn't bother me as much, but as soon as I start moving my eyes around it's really bad. The worst is if I'm looking at the bottom of the screen and then I look towards the top.

So either it's something off with my monitor or my eyeballs. I'd put money on it being my eyes.

[mdrejhon]

The subframes were 4 with 240hz, 3 with 180hz and 2 with 120hz. I don't remember having much eyestrain using CRTs back in the day. The weird part is if I stare at one part of the screen it doesn't bother me as much, but as soon as I start moving my eyes around it's really bad. The worst is if I'm looking at the bottom of the screen and then I look towards the top.

So either it's something off with my monitor or my eyeballs. I'd put money on it being my eyes.

1. Yesterday's CRT monitors were never as big as today's OLEDs. (It's like momma told me to never sit that close to TV). Try a far distance or smaller size.
2. Try a higher CRT refresh rate. You could also try 3 subframes with 240Hz, for a net flicker rate of 80Hz. Like an 85Hz VGA CRT. It would preclude emulators, but be fine with PC gaming.
3. Years of not using CRTs may have desensitized you.

Not everyone gets eyestrain with this shader. However, do not continue using this shader if it continues to bother you -- do not force yourself. Discontinue using if you have discomfort, as it can lead to worse eye affilictions long-term if you're not used to it.

[DandyConeJellos]

I tried 240hz with 3 subframes and the flicker was much less noticeable. It feels like all the pixels are vibrating left and right. So weird, but kinda neat. Now it's time for me to buy a CRT and see if it feels similar.

[junakavora]

Works brilliantly on my 180Hz 1440p IPS monitor!

I use 'DisableDynamicPstate' registry entry which has helped immensely in mitigating flicker, especially when just on the desktop/browser/YouTube etc. Doing that has bumped my idle gfx wattage from 5W to 35W though. All Windows settings default, and only other Nvidia change was G-sync disabled.

The following parameters make 60fps content look perfect on my monitor:

Brightness: 0.307
Scan Direction: 0
LCD Anti-Retention: 0

The 60fps test used:
https://www.testufo.com/framerates-versus#photo=alien-invasion.png&pps=1920&framepacingerror=0&direction=ltr&framerate=60&compare=0

Also, I've found that setting my monitor overdrive/'response time' to the highest ('Faster' instead of 'Fast') brightens it up slightly and doesn't result in inverse ghosting artefacts when using bfi/crt beam sim.

[mausimus]

Fantastic, thanks for testing and for the registry tip!

[blazarevski4-png]

Hello, is there a possibility of an android release of Shaderglass?

[sachdawg]

Is it possible for this to work on 500hz monitors in the future or is this technology limited to multiples of 60?

[mdrejhon]

It is not limited to multiples of 60. You can test-drive CRT simulator online at www.testufo.com/crt at any Hz!

• You can emulate 50Hz CRT, 83.33Hz CRT, 100Hz CRT, 125Hz CRT on a 500Hz monitor
• 500 Hz monitors can do custom Hz like 234.56 Hz (via Custom Resolution Utility) so so you can create 480 Hz for NTSC emulators and 450 Hz for PAL emulators.

[watchowski]

I have a 240hz oled display, but I would like to try and limit my games at 120fps, so for this setup do I set the subframes to 2 to reach the 240hz?

[mausimus]

Yes

[teezaken]

is there any way in the future to mitigate the black crush? It appears to shift the gamma on the lower end by quite alot (especially with more subframes), I liked it alot in kingdom come deliverance 2 when I was on a field on a sunny day, but when it was nighttime I could literally not see anything even with a torch, even increasing brightness did not change it, disabling it of course made me see everything again. Same for every other game I tested with SDR and HDR, like Alice Madness Returns, It Takes Two and so on. I managed to mititage it somewhat with a ReShade Shader for SDR games, but in HDR I would need to combine shadow and exposure settings from RenoDX, and the values appear to vary alot game to game.

But I should still mention I love your work, it really is an impressive quality increase in motion and I hope it gets more attention and love in the future, so thanks alot for the work already done.

[mdrejhon]

I may add picture adjustments to my CRT simulator (black level & white level) to allow lifting the black levels / lowering the white levels). That could be helpful here. You'd slightly sacrifice blacks to get the greyscale details more visible.

You could also add it as a pre-process filter -- e.g. gamma / brightness / contrast. Then apply the CRT simulator.

Also, CRT simulator plays very wonky with a lot of HDR algorithms currently, which can make things difficult. It uses standard gamma curves instead of the HDR curves which may be part of it too.

[teezaken]

Yes, for HDR Games I had to use bfi-simple with subframe mode 2, with crt beam simulator hdr is just broken as you say.

[bobylon5]

I'm doing some wonky things and it's working? Just want to check-in with the experts and see what I can do to verify I'm actually doing and maybe learn from the feedback.

• Win 10
• B580 Render card
• BA770 framegen Card
• Shaderglass Alpha
• Lossless Scaling FG Adaptive to 120
• Viewsonic XG270 with PureXP set to Extreme (Windows Desktop setting says monitor refresh is at 240hz)

Okay now, I'm playing ARC Raiders and Darktide primarily; better results in ARC so far but curious things happening.

1. Game Launch; Windowed
2. ShaderGlass activate; I get pulsing horizontal band lines and shimmering
3. LS FG activates and eliminates all visual issues.
4. XESS Setting is Ultra Quality Plus
5. ARC Frame limit is set to 60 ( usual FG setup)
6. LS FG reporting higher frames at times than target FG.
7. Visually native rendered frames seem higher and overall quality better. Visual blur very good; not noticing any tearing; unsure at what layer any VSYNC is happening; I was using Intel Smoothsync but that's currently disabled. ShaderGlass is set to sync first sub-frame (setting 4 subframes).

I'm enjoying this abomination but yea, learning bit by bit! Love this work! Also, this may be better placed somewhere else; direct me and I shall repost. Thanks!

[mausimus]

No worries, yes you can remap the hotkey in Processing -> Global Hotkeys -> Screenshot

[bobylon5]

Doh! Didn’t dig far enough; thank you kindly!

[bobylon5]

Question; how important or what are the benefits related to upgrading to Win 11 in your opinion when it comes to this work?

[mausimus]

It's definitely recommended, not by my choice, but because Microsoft has stopped updating Capture API on Windows 10 quite a while back:

• Win 11 allows capture without the yellow border
• There are outstanding bugs in Win 10 when using flip mode (which is better for performance), I was told unlikely to be fixed
• Newer API features like Max Capture Rate are not supported on Win 10

[mdrejhon]

When using CRT simulator, it is usually recommended to turn off PureXP. Hardware-based blur reduction does not play well with software-based CRT simulator in terms of picture quality -- duplicate image effects are amplified. Also, CRT simulator doesn't bust blur as much as PureXP does, however CRT simulator flickers more softly.

Motion blur of PureXP is pulsewidth of backlight, and motionblur of CRT simulator (at max settings) can't be less than refreshtime. So you've got the attendant pros/cons of the software-based blur busting and hardware-based blur busting. Sometimes the software-based blur busting becomes superior, when you're doing low frame rate blur busting (e.g. 60fps) which is very flickery if you don't have phosphor decay nor rolling scan.

[MohamedKhalil8801]

one of the main things holding this back is hdr support, are you working on it or have an ETA?

[mausimus]

Sorry it's not high on the priority list, I don't have a decent HDR monitor at the moment.

[mdrejhon]

HDR is useful for brighter BFI/CRT. It can convert SDR to HDR, brighten it, and have improved BFI/CRT brightness.

The tricky part is the average picture level system (dimming if more pixels are bright), so you sometimes have banding with CRT simulator unless you use the global mode since different refresh cycles may be rebalanced (APL). I will add a linear2pq() mode in addition to linear2gamma() to a future version of my shader, to help with HDR, at least when outputting in rec2100-pq mode.

HDR uses floating point frame buffers use rgba-float16 (64 bit per pixel), which all modern GPUs now support, so this provides plenty of headroom. TestUFO already supports these framebuffers now, but creates some artifacts with CRT simulator in non-global mode.

Decent HDR begins at 1500+ nits, so avoid the low numbers (400 nits) where possible. Good recent MiniLED or a tandem OLED would produce the best performance.

[theboy181]

Is there a way to also have scan lines while using BFI modes?

[mausimus]

Not easily at the moment, until both versions of ShaderGlass converge. What you can do now though is export a custom shader preset from RetroArch where you can chain scanline and BFI shaders, and import that as custom shader into ShaderGlass BFI.

[mdrejhon]

@mausimus I have been reached by a major mainstream website/gaming magazine who wants to interview me about the CRT simulator. I can't disclose which yet, but I wanted to give a heads up.

My plan is to tell them about third party projects (or publish a webpage with a list) like Shaderglass Alpha. I want to give the indies credit for pushing forward CRT simulator. I am being interviewed this month and they want to do the article in early January.

If possible, release any planned alpha or beta out by January -- if you don't prefer me to link to this github alpha3 page.

I am wondering how we can make reliability more user friendly. Maybe some optional install-time automation of the DisableDynamicPState tweak (I heard there's an API or something) and automation of process priority upgrade. There's also an NVAPI call to increase GPU priority on NVIDIA products too.

[mausimus]

Thanks a lot for the heads up @mdrejhon , that's awesome! A mention of the community efforts would be most welcome. I will have some time over the holidays and I'm planning to work on ShaderGlass, so will aim to have another alpha out around New Year.

[mausimus]

Thank you everyone for testing ShaderGlass/BFI - it's now been superseded by a new app, ShaderBeam, which is a complete rewrite focusing on CRT Beam Simulator only. Feel free to check it out and leave your feedback in this thread

[mdrejhon]

This is the real breakthrough app!

It is much more reliable than ShaderGlass for CRT beam simulation!
Especially when you use two GPUs (iGPU for beam sim, dGPU for games).

Most computers have an integrated GPU, and you can run the CRT simulator on the integrated GPU while you run the game on the main GPU. That prevents the erratic flickers pretty well!

!