Introducing crt-royale for ReShade

github.com/akgunter/crt-royale-reshade
This is a port of RetroArch's crt-royale shader by TroggleMonkey to ReShade, with a handful of additions to account for technical differences.

Whether you've used crt-royale before or not, I strongly recommend reading the setup instructions first - it has a ton of moving parts. Be aware that it will never be a pixel-perfect port, but it should be pretty darn close at this point.

Thank you, Matsilagi, for helping test and debug. Thank you, Crosire, for implementing support for rectangular matrices.
 
UPDATE 2021-01-30
I've finally gone ahead and merged the new scanline logic into the master branch. Aside from fixing a lot of the math to work corretly in reshade, this includes a brand new setting "Scanline Blend Strength". This new setting lets you choose between accurate screenshots and smooth animations, theoretically with only a minimal change in colors. Set it to 0 to replicate the original crt-royale behavior or to 1 to remove vsync artifacts.

UPDATE 2021-01-07
Crosire has released ReShade 4.9, so now this shader does not require compiling anything. Install 4.9 as usual and follow the instructions in my readme file.

I've just pushed a big ol' update that finalizes support for DX9 and cleans out a ton of extraneous preprocessor definitions. I've also added a sharpness setting for Mask Sample Mode 0 and added some more setup instructions.

This is very good news, I already look forward to using the shader with old PC games.

Is there a way to change the opacity/strength of the mask? I don't seem to find it.

Can you add settings from crt royale kurozumi or do you need to completely rewrite the shader for this? Specifically, the sharpness setting is not enough or does it just depend on the opacity / strength of the mask?

Tojkar wrote: Is there a way to change the opacity/strength of the mask? I don't seem to find it.

 

There wasn't such a setting in the RetroArch version of crt-royale because the mask is only one of several effects it applies. I might be able to add such a setting, but I can't promise anything because the phosphor mask also interacts with other pieces of math. There's a good chance an opacity setting would throw other stuff way out of whack.

gottenspell wrote: Can you add settings from crt royale kurozumi or do you need to completely rewrite the shader for this? Specifically, the sharpness setting is not enough or does it just depend on the opacity / strength of the mask?

 

It should be possible to recreate that configuration by using a LUT shader and then tuning the crt-royale shader.

You should place the LUT shader above crt-royale and use one of the kurozumi LUT files from github.com/Themaister/slang-shaders/tree.../reshade/shaders/LUT . Bear in mind, I've never actually used a LUT before; so I can't really help much with that. They're really popular, though; so there are a ton of guides for them.

Then use crt-royale's config options to duplicate the relevant parameters at the bottom of github.com/Themaister/slang-shaders/blob...yale-kurozumi.slangp .

Hi akgunter, that is incredible! Thanks for this.

I hope you are open to and have time to improve on the current build. I find that it does not really feel right yet. I'll attached a few screenshots to illustrate my point.

Screenshot 1 (Reshade):



Screenshot 1 (RetroArch):



Comparing these two screenshots, you can see that it seems that there seems to be more blur in your reshade code. It also seems like your code seems to form more emphasised vertical lines, where the RetroArch version of the shade seems to have equal emphasis of vertical and horizontal spaces between the dots (please excuse my uneducated terminalogy).

I'll show another screenshot.

Screenshot 2 (Reshade):



Screenshot 2 (RetroArch):



On these screenshots one can again see the heavy emphasis on vertical lines especially in the darker green of the grass.

So in summary in my limited knowledge what isn't looking right:

1. Heavy emphasis of vertical lines - or too little on horizontal
2. Too much blurring between dots.

OneArchetype wrote: Hi akgunter, that is incredible! Thanks for this.

I hope you are open to and have time to improve on the current build. I find that it does not really feel right yet. I'll attached a few screenshots to illustrate my point.
...
 

That's actually the third item on my list right now, after a pair of breaking issues. The problem you're seeing is caused by crt-royale's auto-detection for scanlines. It doesn't recognize your scaled up resolution as one that warrants interlacing, so it doesn't draw them. I'm probably going to replace that detection logic with a toggle switch and let users decide whether the scanlines should be there.

github.com/akgunter/crt-royale-reshade/issues/2

This incredible and want to say thank you, I never played around too much with this in retroarch besides enabling it and always felt the other CRT shaders I've tried in reshade couldn't quite replicate whatever branch/version of crt-royale I was trying. Was doing the once in a blue moon "crt-royale" reshade shader web search and I am floored. You've done magic my friend.

I guess I should also mention I noticed as well that there is an uneven number of horizontal lines in comparison to verticals. I happen to be playing on a 5120x1440 monitor though with the game I'm currently running at 3440x1440. Also as someone mentioned on GitHub mask 0 gives me only vertical lines and no horizontal but mask 1 at least gives me the above result with the uneven amount of lines but still gives off an interesting effect in its own right. 

T00Sp00kyFoU wrote: This incredible and want to say thank you, I never played around too much with this in retroarch besides enabling it and always felt the other CRT shaders I've tried in reshade couldn't quite replicate whatever branch/version of crt-royale I was trying. Was doing the once in a blue moon "crt-royale" reshade shader web search and I am floored. You've done magic my friend.

I guess I should also mention I noticed as well that there is an uneven number of horizontal lines in comparison to verticals. I happen to be playing on a 5120x1440 monitor though with the game I'm currently running at 3440x1440. Also as someone mentioned on GitHub mask 0 gives me only vertical lines and no horizontal but mask 1 at least gives me the above result with the uneven amount of lines but still gives off an interesting effect in its own right. 
 

Try giving the feature/scanline-fixes branch a try and make sure Enable Interlacing is set to 1. That should put the horizontal lines back into Mask 0, and it'll be excellent to have some feedback based on a 2k monitor. Bear in mind, you might have to poke at vsync settings on your end.

Also, Mask 1's horizonal lines come from the slot mask itself, with some inconsistencies being a side effect of the resizing algorithm. There isn't a whole lot I can do about that in Sample Mode 0 to be honest, but you can mitigate it by increasing the Triad Size and/or increasing the Downsampling Sharpness.

akgunter wrote: Try giving the feature/scanline-fixes branch a try and make sure Enable Interlacing is set to 1. That should put the horizontal lines back into Mask 0, and it'll be excellent to have some feedback based on a 2k monitor. Bear in mind, you might have to poke at vsync settings on your end.

Also, Mask 1's horizonal lines come from the slot mask itself, with some inconsistencies being a side effect of the resizing algorithm. There isn't a whole lot I can do about that in Sample Mode 0 to be honest, but you can mitigate it by increasing the Triad Size and/or increasing the Downsampling Sharpness.Lo

Looks like this branch fixed the issue. Tried it on only two games so far, but will update if i find anything else and have yet to adjust many parameters for this version besides enabling and comparing the pixel grid. Looks to be good to me? Apparently im challenged and having trouble embeding the image here but heres what Fallout 4 and Hades look like zoomed in at 200% and 400%. 
 

T00Sp00kyFoU wrote:

akgunter wrote: Try giving the feature/scanline-fixes branch a try and make sure Enable Interlacing is set to 1. That should put the horizontal lines back into Mask 0, and it'll be excellent to have some feedback based on a 2k monitor. Bear in mind, you might have to poke at vsync settings on your end.

Also, Mask 1's horizonal lines come from the slot mask itself, with some inconsistencies being a side effect of the resizing algorithm. There isn't a whole lot I can do about that in Sample Mode 0 to be honest, but you can mitigate it by increasing the Triad Size and/or increasing the Downsampling Sharpness.Lo

Looks like this branch fixed the issue. Tried it on only two games so far, but will update if i find anything else and have yet to adjust many parameters for this version besides enabling and comparing the pixel grid. Looks to be good to me? Apparently im challenged and having trouble embeding the image here but heres what Fallout 4 and Hades look like zoomed in at 200% and 400%.
 

Glad to hear it! And you're getting the same pattern as I do. Now I just have to figure out how to fix those extra red pixels between the lines.

akgunter wrote: Glad to hear it! And you're getting the same pattern as I do. Now I just have to figure out how to fix those extra red pixels between the lines.

Huh, honestly couldn't tell until you mentioned it. Do you mean how the grid seems to do a dim blue, dim green, bright red, then alternates to bright blue, bright green, dim red? Sorry if these are odd questions, honestly this shader fascinates me due to all the parameters and how related they are to the phyics principles of actual CRTs. 

T00Sp00kyFoU wrote: Huh, honestly couldn't tell until you mentioned it. Do you mean how the grid seems to do a dim blue, dim green, bright red, then alternates to bright blue, bright green, dim red? Sorry if these are odd questions, honestly this shader fascinates me due to all the parameters and how related they are to the phyics principles of actual CRTs. 
 

Yup, the issue ended up being a combination of some scanline math still being wonky; and the in-code default convergence offsets were not the same the ones in the RetroArch version's .slangp/.glsp files. The master branch has both of those fixed now, so it's pretty friggin close to the original shader. Up to and including the image retention problems my monitor has with it lol.

Can we get rid of the v-sync dependency in the future? In some games it is impossible to do anything, for example, in diablo 2, turning v-sync on and off does nothing. Tried in D3D / 3DFX the image still jitters, as if v-sync is not enabled.

gottenspell wrote: Can we get rid of the v-sync dependency in the future? In some games it is impossible to do anything, for example, in diablo 2, turning v-sync on and off does nothing. Tried in D3D / 3DFX the image still jitters, as if v-sync is not enabled.
 

The vsync dependency is inherent to the effect - it's coded specifically to simulate scanlines by only drawing the odd rows and on the next frame only drawing the even rows (turning off the pixels it didn't draw at all). That frame-by-frame relationship combined with it being an on/off toggle makes it inherently hypersensitive to your framerate.

The workaround would be an entirely new scanline effect, but that'll take me a while to design, build, and calibrate - assuming I can make it work. In the meantime, my best suggestion is to try using the NVidia control panel (or AMD/Intel equivalent) to force vsync on for uncooperative games.

If it's any consolation, I actually can't use the scanline effect for long periods on my monitor because the rapid on/off toggling causes awful image retention after only a few minutes. I need the scanline rewrite too lol.

Strange, I have no afterimage. But in any case, thank you very much, I have been waiting for this shader for a very long time and am very pleased with the port.
There is one question, would it be possible to make phosphor a standalone shader? Or does it make no sense because it looks like bloom?

So for some odd reason, fallout new vegas runs into the same issue from the old version where their is an uneven amount/alternating grid of pixels instead of the uniform grid. When I take a screenshot to try and capture it though,  the grid lines up for probably just a frame then back to the alternated grid. Thought I was going crazy being 2inches from the screen but the screenshots come out fine. This is a directx 9 game btw, haven't tried any other directx9 games to see if that happens. It's the only game I've had trouble with so far. Tried it at both 5120x1440, and 3440x1440. Have my vsync locked to 60 FPS.

Edit: Nevermind don't listen to me, just read through the github a second time and saw that dx9 don't respond to the slider, but need to bet set lower down. Setting it from 1, to 0 returns the grid to uniformity. 

I've still got to update the readme and make sure I don't run into any obvious problems before merging into master, but the new branch feature/scanline-rewrite is ready for use. It includes fixes for DX9, rewritten vertical sampling logic for scanlines, corrections to the convergence offsets, and a new Scanline Blend Strength setting that can smooth out frame-by-frame jitters.

Setting the blend strength to 1 basically makes it take an average of the current frame and the previous frame, so the video should look nearly identical to you during gameplay regardless of how well-behaved the framerate is. The tradeoff is that the dark lines won't show up in screenshots because they've been blended away.

If you find that the color looks notably different between strength 0 and 1, try nudging the Blend Gamma a little. The default should be close, but it might not be quite right for some monitors.

akgunter wrote: I've still got to update the readme and make sure I don't run into any obvious problems before merging into master, but the new branch feature/scanline-rewrite is ready for use. It includes fixes for DX9, rewritten vertical sampling logic for scanlines, corrections to the convergence offsets, and a new Scanline Blend Strength setting that can smooth out frame-by-frame jitters.

Setting the blend strength to 1 basically makes it take an average of the current frame and the previous frame, so the video should look nearly identical to you during gameplay regardless of how well-behaved the framerate is. The tradeoff is that the dark lines won't show up in screenshots because they've been blended away.

If you find that the color looks notably different between strength 0 and 1, try nudging the Blend Gamma a little. The default should be close, but it might not be quite right for some monitors.

Crazy timing, just checked on here 8 minutes after your post. Seem to have some funny business when i have scanlines set to size 1 in Fallout 3, DX9 as seen here:  imgur.com/a/CLa5t9C

Tried it out in Fallout 4 and works good though, the blending features for sure works as intended. Not sure why Fallout 3 has those scan lines in the middle that wont go away. They seem to when I set the size of them to 2: (This ones zoomed up to 600%)  imgur.com/a/fI6sgwV

T00Sp00kyFoU wrote: Crazy timing, just checked on here 8 minutes after your post. Seem to have some funny business when i have scanlines set to size 1 in Fallout 3, DX9 as seen here:  imgur.com/a/CLa5t9C

Tried it out in Fallout 4 and works good though, the blending features for sure works as intended. Not sure why Fallout 3 has those scan lines in the middle that wont go away. They seem to when I set the size of them to 2: (This ones zoomed up to 600%)  imgur.com/a/fI6sgwV

The black lines with the scanline size set to 1 look like yet another friggin' rounding error in DX9. I can't for the life of me manage to weed them out apparently. The lines you see with the size set to 2 are probably those artifacts getting caught in the blending logic and passed along as a feedback loop. If you set the blend strength to 0 for a moment and back up to 1, it'll break the feedback loop and clear them out. I've not found a good way to automatically do that because it requires programmatically seeing whether a config setting has changed since the previous frame, which isn't typically something shaders do.

Edit: I think I've got that rounding error fixed now. Ironically, the rounding correction I added to the old shader code introduced the rounding error into the new shader code. Who'da'thunk

Edit2: Now the original DX9 rounding issue is back.

Edit3: There we go! I think I managed to magic away a slew of issues. Fingers crossed I didn't screw something else up.