Help removing geometry distortion from crt-mattias

Could you point me to the samples in guest please? Sorry I’m dumb, lol.

You could try changing it here:

Seems there’s more sampling in this than I remembered, so maybe it won’t be so bad.

1 Like

Sorry to ask more things but how would I do that with that sample? I’m so sorry… I thought it would be way more straightforward/I thought I kinda knew what I was doing…

My main issue is looking over crt-mattias, I don’t really understand how it’s doing what it’s doing (I don’t understand which numbers are relevant in the sampling) and how to translate that multiple entries into a single entry for guest. Am I missing something?

The way shaders work is: the fragment stage runs once for each pixel and the texture coordinate tells you where it’s currently running on a normalized (i.e., 0.0-1.0) plane. If you want to sample a texture, you use the built-in sampling function–in our case, it’s almost always just texture(tex_name, texture_coordinate)–and the current texture coordinate for the location. The texture coordinate (or ‘texCoord’ for short) is a 2-component value, one for horizontal/x and one for vertical/y.

Sometimes, you don’t want to sample from exactly from the current pixel location, so you put an offset to it. For example, texCoord - vec2(0.5, 0.5) will offset the sample by half of the image both vertically and horizontally.**

crt-mattias is creating a pseudo-random number (based on the vertical location–texcoord.y–and the FrameCount–a value provided by RetroArch that counts how many frames have elapsed; it’s used for animated effects–so it has a different value both on each frame and on each vertical pixel) and storing it in the ‘x’ variable. Then, it’s offsetting the texCoord.x (that is, the horizontal component of the current location) by that amount whenever it samples. This results in the pseudo-random wiggle as you move up/down the screen.

In the case of crt-guest-dr-venom, they’re using a preprocessor macro (the ‘#define whatever’ part, which is used to replace the defined text with some other text every time the compiler encounters it). This is fairly common in shaders (and programming in general) so you can change something once and then have the same change applied everywhere. Every time the compiler sees ‘COMPAT_TEXTURE(something, something_else)’, it’s going to replace it with the sampling function wrapped around those same values.

So, if you have your pseudo-random offset already calculated somewhere, you can plug it into the macro and it will apply that offset every time it encounters COMPAT_TEXTURE() (this should be all one line; it’s getting wrapped automatically by the forum):

#define COMPAT_TEXTURE(c,d) texture(c,d+pseudo_random_offset)

**shaders that detect pixel patterns, like xBR, ScaleFx and mdapt offset the sampling location to look at each pixel around the current pixel and then compare the color/brightness values to detect patterns

1 Like

Thanks I’m going to try to parse through this information and see what I can do. I’ll possibly message you if I get stuck, but it’ll only be if I can’t figure it out and I’ll also send you my attempt to see what isn’t working if that’s the case.

Appreciate the help Hunter.

1 Like

@hunterk

Ok sorry to bother you again, but I’ve read through everything and I’m having an issue with setup.

I don’t have a pseudo_random_offset already calculated, honestly not even sure how to do that. Or where I can even place the calculation, as I should be before this right?

#define COMPAT_TEXTURE(c,d) texture(c,d+pseudo_random_offset)

Sorry to bother you with this before I’ve even got anything done!

That’s describing this line from crt-mattias:

float x = sin(0.1*iTime+uv.y*21.0)*sin(0.23*iTime+uv.y*29.0)*sin(0.3+0.11*iTime+uv.y*31.0)*0.0017;

Since macros only replace text, it only needs to be declared above the first instance of the macro. Since all of the macro-ed instances appear inside the main fragment function, you should be able to declare the variable in there.

1 Like

So where the masks and stuff are?

Or down in the main section at the bottom of the shader?

And can I just use

float x = sin(0.1*iTime+uv.y*21.0)*sin(0.23*iTime+uv.y*29.0)*sin(0.3+0.11*iTime+uv.y*31.0)*0.0017;

From crt-mattias? (Changing the float x to float pseudo_random_offset, for this instance)

The main function is called void main(). Look for that in the fragment stage.

iTime and ‘uv’ don’t exist in crt-guest-dr-venom. You’ll have to copy those things over first.

1 Like

So here? (The only other void main I was seeing is before the #pragma stage fragment)

void main()
{
	float lum = COMPAT_TEXTURE(PassPrev5Texture, vec2(0.1,0.1)).a;

	// Calculating texel coordinates
   
	vec2 texcoord = TEX0.xy;

But I’d place it before the float lum because it uses the COMPAT_TEXTURE macro that I’m altering?

EDIT: I know I tell you this all the time but I genuinely appreciate your help and handholding (lol), with everything and I’m sincerely trying to learn from the information you give me.

1 Like

Thanks @hunterk I got it working, but it’s not really what I was going for so back to the drawing board for wiggles, lol.

1 Like

Would it be possible to modify this shader to customize a different curvature value for horizontal and vertical?

I would need first to add a new CURVATUREY parameter, but I don’t get how to treat X and Y seperately in the main() function. The only place I seem to be able to affect X and Y is in vec2 curve(vec2 uv), but if I understand the code correctly, I would need to mix uv twice (both CURVATURE and CURVATUREY parameters) in the main function for it to work properly without hardcoding anything.

Probably the easiest way to handle it would be to just replace the curvature function with one from another shader that already does what you want.

1 Like

Good idea. I’ll investigate further… Thanks!