Sonic and Sega Retro Message Board: I've ported the Sonic Mania CRT shaders to ReShade - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 2 Pages +
  • 1
  • 2
    Locked
    Locked Forum

I've ported the Sonic Mania CRT shaders to ReShade

#1 User is offline luluco 

Posted 03 September 2017 - 08:18 AM

  • Posts: 17
  • Joined: 09-August 17
  • Gender:Male
  • Location:Brazil
EDIT: Here they are: CRT-Yee64, CRT-Yeetron.

I'm a shader enthusiast, been programming shaders for a while now for fun, mostly in ReShade (a generic shader injector for almost any game).

Recently by request of a friend I translated the DirectX 9 ASM instructions of CRT-Yeetron and CRT-Yee64 (called "Sharp" and "Smooth" in the video options) to ReShade's own "FX" language, which is almost identical to CG/DX9 HLSL with a few key differences.
I was wondering about the legality of posting them here or my own GitHub repo, as the shaders have been ripped from the data file of Mania.

Here's a few screenshots:
Spoiler


The effect might not be 1x1 exactly as the original, but that's because of two factors:
  • Mania runs at a specific internal resolution, similar to an emulator. This can be partly addressed with my other Virtual Resolution effect.
  • The shaders have a set of parameters which I have no way to know how they are handled in the CPU code, so my friend has helped me achieve something similar based on RetroArch CRT shaders (which would be a nice thing to port these shaders to).


So overall I don't claim these are perfect ports, I just translated the ASM instructions into high level code, I just felt someone else might be interested.
Let me know if this isn't allowed here.
This post has been edited by luluco: 03 September 2017 - 05:10 PM

#2 User is offline Chimera 

Posted 03 September 2017 - 10:02 AM

  • I'm not a furry.
  • Posts: 1247
  • Joined: 04-October 10
  • Gender:Male
  • Project:Castlevania prettyness
  • Wiki edits:5
the only thing i can see being a problem is using the texture provided from Mania, as that's teeechnically copyrighted material. That said, we being a modding community use copyrighted content a la the sprites on the daily, so I'm assuming it's not the biggest deal if it's just the texture being used for hobbiest reasons / you're not selling anything with it.

Worst comes to worst you can try finding an alternate version of the CRT pattern online and use that, I spose, unless the shader doesn't even use a texture filter, in which case I'd say this is probably 100% fine as the code's been changed past recognition (I could be completely wrong though since digital copyright laws are legitimately awful).

#3 User is offline luluco 

Posted 03 September 2017 - 10:07 AM

  • Posts: 17
  • Joined: 09-August 17
  • Gender:Male
  • Location:Brazil

Quote

the only thing i can see being a problem is using the texture provided from Mania(...)

It doesn't use a texture, the overlay is generated by the shader.

Quote

(...)unless the shader doesn't even use a texture filter, in which case I'd say this is probably 100% fine as the code's been changed past recognition (I could be completely wrong though since digital copyright laws are legitimately awful).

That's what I'm worried about too, software copyright is a mess overall.

#4 User is offline Cooljerk 

Posted 03 September 2017 - 10:10 AM

  • NotEqual Tech, Inc - VR & Game Dev
  • Posts: 4198
  • Joined: 06-April 06
  • Gender:Male
  • Wiki edits:9

View PostChimera, on 03 September 2017 - 10:02 AM, said:

the only thing i can see being a problem is using the texture provided from Mania, as that's teeechnically copyrighted material. That said, we being a modding community use copyrighted content a la the sprites on the daily, so I'm assuming it's not the biggest deal if it's just the texture being used for hobbiest reasons / you're not selling anything with it.

Worst comes to worst you can try finding an alternate version of the CRT pattern online and use that, I spose, unless the shader doesn't even use a texture filter, in which case I'd say this is probably 100% fine as the code's been changed past recognition (I could be completely wrong though since digital copyright laws are legitimately awful).


Most CRT filters in the last several years have moved well beyond using simple texture filters. Good CRT filters these days should be simulating the actual luminosity variation per scanline depending on color value.

Quote

The shaders have a set of parameters which I have no way to know how they are handled in the CPU code, so my friend has helped me achieve something similar based on RetroArch CRT shaders (which would be a nice thing to port these shaders to).


Dunno what type of uniform or vertex buffer object variables you're needing, but simple things like fragment counting can be achieved using atomic operations. You can discern the width of the texture being operated on this way by iterating atomic counters until you detect a change in Y position of the incoming fragment.

I have no idea how to work with atomic counters in HLSL, though, only GLSL.

EDIT: Beaten

EDIT AGAIN: Also, you can find lots of freely-licensed CRT shaders online if you look around, if anybody is really worried about legality.
This post has been edited by Cooljerk: 03 September 2017 - 10:16 AM

#5 User is offline luluco 

Posted 03 September 2017 - 10:21 AM

  • Posts: 17
  • Joined: 09-August 17
  • Gender:Male
  • Location:Brazil
Here's an example taken from the original code, and how I translated it:
ASM:
Spoiler

FX/HLSL:
Spoiler


It's not even a particularly hard task, just tedious, but it's pretty much the same code, hence it could be considered "stolen" by law.

Quote

Dunno what type of uniform or vertex buffer object variables you're needing, but simple things like fragment counting can be achieved using atomic operations. You can discern the width of the texture being operated on this way by iterating atomic counters until you detect a change in Y position of the incoming fragment.


These are the parameters it uses:
Spoiler


In my current implementation I've added a source resolution parameter and a "downscale" paramater, then I set textureSize to source_resolution / downscale

I set the pixelSize to the screen resolution but with the x component multiplied by the screen aspect ratio and it gave me close results to the original.
viewSize is just set to the screen resolution, as I believe it should be.
texDiffuse is obviously the fullscreen texture the game renders to.

#6 User is offline Cooljerk 

Posted 03 September 2017 - 10:21 AM

  • NotEqual Tech, Inc - VR & Game Dev
  • Posts: 4198
  • Joined: 06-April 06
  • Gender:Male
  • Wiki edits:9

View Postluluco, on 03 September 2017 - 10:17 AM, said:

Here's an example taken from the original code, and how I translated it:
ASM:
Spoiler

FX/HLSL:
Spoiler


It's not even a particularly hard task, just tedious, but it's pretty much the same code, hence it could be considered "stolen" by law.

Quote

Dunno what type of uniform or vertex buffer object variables you're needing, but simple things like fragment counting can be achieved using atomic operations. You can discern the width of the texture being operated on this way by iterating atomic counters until you detect a change in Y position of the incoming fragment.


These are the parameters it uses:
Spoiler



Ha, they actually do use a diffuse texture, I guess for the pattern. Or wait, is that texture supposed to be the input texture (i.e. the framebuffer) that the CRT filter is being applied to? EDIT: haha, we're playing post tag it seems :P. PixelSize and viewSize I guess are related to the scaling the engine does to convert from the internal resolution to screen resolution. This makes sense, you wouldn't want to do the CRT filter on the original texture size, then blow it up, or else the CRT artifacts would look scaled and weird.

I'm about go work at my parents place (they got hit by the hurricane) but I'll come back later tonight and see if we can figure out a way to discern the total output resolution using atomic counters.
This post has been edited by Cooljerk: 03 September 2017 - 10:22 AM

#7 User is offline luluco 

Posted 03 September 2017 - 10:28 AM

  • Posts: 17
  • Joined: 09-August 17
  • Gender:Male
  • Location:Brazil

Quote

Ha, they actually do use a diffuse texture, I guess for the pattern. Or wait, is that texture supposed to be the input texture (i.e. the framebuffer) that the CRT filter is being applied to? EDIT: haha, we're playing post tag it seems :P. PixelSize and viewSize I guess are related to the scaling the engine does to convert from the internal resolution to screen resolution. This makes sense, you wouldn't want to do the CRT filter on the original texture size, then blow it up, or else the CRT artifacts would look scaled and weird.

Yeah before scaling the pixelSize to the aspect ratio the CRT artifacts looked too stretched (specially on my 21:9 screen).
I'm not much of a CRT effects guy so most of this is still magic to me.

Quote

I'm about go work at my parents place (they got hit by the hurricane) but I'll come back later tonight and see if we can figure out a way to discern the total output resolution using atomic counters.

Good luck there!

#8 User is online Black Squirrel 

Posted 03 September 2017 - 03:03 PM

  • maybe she's born with it
  • Posts: 4151
  • Joined: 27-December 03
  • Gender:Male
  • Location:Northumberland, England
  • Project:maybe it's maybelline
  • Wiki edits:20,569
CRT filters are weird.

I mean sure, they do sort-of emulate a slightly wonky CRT television, and if that's your bag, more power to you. But every CRT is different and every filter, including the one in Mania, gets it wrong in unique and interesting ways. You'd have more luck emulating a CRT by playing a 15,734Hz tone over the top of everything - at least that bit was consistent across models.


The way I'd do it, and is what I tend to recommend when using Kega Fusion (or one of its derivatives) as a Mega Drive emulator, is to go for the CBVS filter. That doesn't emulate a CRT display per se, it emulates a composite signal, which is naturally a bit blurry and usually crap. Faced with limited colours, Mega Drive artists drew their pixels in a certain way to take advantage of this - it's how the Mega Drive (and Saturn) does semi-transparency. It doesn't actually do semi-transparency, but if your screen isn't ultra-sharp, it totally does.


This was something pulled up in the Sonic 1/2/CD remakes - Taxman uses real alpha transparency for the shields, but half the graphics use these tricks in subtle little ways and Sonic 3 is loaded with them (although not to the same extent as say, Earthworm Jim).


to get out the old example again:

Posted Image

As far as I could see, Mania doesn't really do this. Although it's a difficult one to judge because it actually has colours to spare so doesn't need to.



As an aside, this is exactly the same for audio. If you turn on the "filter" in Kega Fusion, you can hear the tune in the Sonic Spinball options music. They never expected absolute clarity.

#9 User is offline Blue Spikeball 

Posted 03 September 2017 - 04:28 PM

  • Posts: 327
  • Joined: 29-October 16
  • Gender:Male

View PostBlack Squirrel, on 03 September 2017 - 03:03 PM, said:

This was something pulled up in the Sonic 1/2/CD remakes - Taxman uses real alpha transparency for the shields, but half the graphics use these tricks in subtle little ways and Sonic 3 is loaded with them (although not to the same extent as say, Earthworm Jim).

The half-assed transparencies were one of the things that annoyed me the most about the remakes. They had the opportunity to finally fix stuff such as the waterfalls and give them real transparency, but no, they opted to keep the original dithered effect that doesn't work on anything other than CRT screens for some reason. Sonic 1 was the worst in that aspect. They left the waterfalls untouched, made the shields truly transparent but kept the flickering for seemingly no reason, and I still don't get why they replaced the spring sprites with the extra dithered ones from CD. And it was just as baffling how Sonic 2 alternated between transparent waterfalls (EHZ) and dithered waterfalls (ARZ).

Sorry for the rant. Anyways, what's the filter used by the bottom pic?
This post has been edited by Blue Spikeball: 04 September 2017 - 05:49 AM

#10 User is offline luluco 

Posted 03 September 2017 - 05:07 PM

  • Posts: 17
  • Joined: 09-August 17
  • Gender:Male
  • Location:Brazil
I'm aware the effect isn't really realistic compared to a real CRT TV.
I did port a shader called "Artifact Colors" before for the same friend that does a more realistic approach: https://github.com/M...tifactColors.fx
Original: https://www.shadertoy.com/view/llyGzR

Also here are the CRT effects from Mania I ported:
CRT-Yee64
CRT-Yeetron

It's ported to ReShade but can be easily ported over to CG, HLSL or GLSL, like to RetroArch.
This post has been edited by luluco: 03 September 2017 - 05:08 PM

#11 User is offline Matsilagi 

Posted 03 September 2017 - 05:07 PM

  • Posts: 3
  • Joined: 30-August 17

View PostBlue Spikeball, on 03 September 2017 - 04:28 PM, said:

View PostBlack Squirrel, on 03 September 2017 - 03:03 PM, said:

This was something pulled up in the Sonic 1/2/CD remakes - Taxman uses real alpha transparency for the shields, but half the graphics use these tricks in subtle little ways and Sonic 3 is loaded with them (although not to the same extent as say, Earthworm Jim).

The half-assed transparencies were one of the things that annoyed me the most about the remakes. They had the opportunity to finally fix stuff such as the waterfalls and give them real transparency, but no, they opted to keep the original dithered effect that doesn't work on anything other than CRT screens for some reason. Sonic 1 was the worst in that aspect. They made the shields truly transparent but kept the blinking effect for no reason, and I still don't get why they gave extra dithering to the springs.

Sorry for the rant. Anyways, what's the filter used by the bottom pic?


It may be one of those RetroArch NTSC blurring filters.
I've some ported on my github for ReShade aswell, funny enough, the OP from this thread helped me with lots of them.
If you guys want, i can edit this post and place the link here.
EDIT: ninja'd.
This post has been edited by Matsilagi: 03 September 2017 - 05:08 PM

#12 User is offline Zenor 

Posted 03 September 2017 - 05:40 PM

  • flip the chessboard over
  • Posts: 270
  • Joined: 09-April 07
  • Gender:Male

View PostBlue Spikeball, on 03 September 2017 - 04:28 PM, said:

Sorry for the rant. Anyways, what's the filter used by the bottom pic?


It's a simple filter that just averages each pixel with the one directly to its left, like so.
This post has been edited by Zenor: 03 September 2017 - 06:19 PM

#13 User is offline luluco 

Posted 03 September 2017 - 11:38 PM

  • Posts: 17
  • Joined: 09-August 17
  • Gender:Male
  • Location:Brazil

Quote

It's a simple filter that just averages each pixel with the one directly to its left, like so.

So just good ol' box blur?
This post has been edited by luluco: 03 September 2017 - 11:38 PM

#14 User is offline Blue Spikeball 

Posted 04 September 2017 - 05:35 AM

  • Posts: 327
  • Joined: 29-October 16
  • Gender:Male

View PostZenor, on 03 September 2017 - 05:40 PM, said:

View PostBlue Spikeball, on 03 September 2017 - 04:28 PM, said:

Sorry for the rant. Anyways, what's the filter used by the bottom pic?


It's a simple filter that just averages each pixel with the one directly to its left, like so.

I don't suppose anyone knows if a filter like that exists for Kega Fusion? I know it has TV Mode, but it makes everything look too blurry.

Edit: Derp, it seems that the excessive blurriness in Kega was due to the upscaling. Running it on the native MD resolution with TV mode (CVBS) on makes it look like the screenshots posted here.

I wonder if there would be a way around that, hypothetically speaking? Maybe if one rendered the graphics on 320x240 with the blending filter and then upscaled them using 2xSaI or a similar filter?
This post has been edited by Blue Spikeball: 04 September 2017 - 08:09 AM

#15 User is offline luluco 

Posted 04 September 2017 - 08:33 AM

  • Posts: 17
  • Joined: 09-August 17
  • Gender:Male
  • Location:Brazil

Quote

I don't suppose anyone knows if a filter like that exists for Kega Fusion? I know it has TV Mode, but it makes everything look too blurry.

Edit: Derp, it seems that the excessive blurriness in Kega was due to the upscaling. Running it on the native MD resolution with TV mode (CVBS) on makes it look like the screenshots posted here.

I wonder if there would be a way around that, hypothetically speaking? Maybe if one rendered the graphics on 320x240 with the blending filter and then upscaled them using 2xSaI or a similar filter?

You can get Blargg's excellent "MD NTSC" filter for Kega Fusion together with various plugins here, I use that with 25% scanlines:
Spoiler


I also use the "Brighten" option, to compensate for the general darkness brought by scanlines and MD NTSC.

  • 2 Pages +
  • 1
  • 2
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users