GLSL Shaders in .vsh format?

RetroArch Additions Shaders
#28

It all hangs only on this “rubyOutputSize.x” thingy… code works now (but with no difference) , even with mod_factor and dotmask, as long as I keep out “rubyOutputSize.x” .

so i need a replacement for this:

uniform vec2 rubyOutputSize;

and this:

mod_factor = texCoord.x * color_texture_pow2_sz.x * rubyOutputSize.x / color_texture_sz.x;

these are the only places, where “rubyOutputSize.x” stuff is placed and both lines are in the vertex part (or vsh file)

PS: Just tried, with leaving those “rubyOutputSize” as is… no error prompt, but no slotmask either :frowning:

#29

Ok, if I get rid of the mod_factor stuff (and, thus, all of the OutputSize, etc. stuff, too) entirely and replace it with gl_FragCoord.x, it works fine here (not in MAME, but in a GLSL shader IDE).

#30

Ok, shall I delete everything mod_factor related ??? Because I have two lines in the vertex part, where mod_factor is included:

varying float mod_factor;

and

mod_factor = texCoord.x * color_texture_pow2_sz.x * rubyOutputSize.x / color_texture_sz.x;

And in the fragment part, there are also two lines:

varying float mod_factor;

and

vec3 dotMaskWeights = mix( vec3(1.0, 0.7, 1.0), vec3(0.7, 1.0, 0.7), floor(mod(mod_factor, 2.0)) );

So i replace the whole lines with gl_FragCoord.x or only the term mod_factor ???

#31

Dude, you are awesome… it worked. So I only kept the line:

vec3 dotMaskWeights = mix( vec3(1.0, 0.7, 1.0), vec3(0.7, 1.0, 0.7), floor(mod(gl_FragCoord.x, 2.0)) );

It works now, but the dotmask is barely visible… how I can make the mask more visible?

And it doesnt work on vertical games, so I guess it needs to be rotated for them. How would I do this?

Anyway, first a very BIIIIIGGG THANNNKS … You made one person in the world really happy now :slight_smile:

PS: I got that solved with the vertical alignment… and I am ashamed that I even asked… off course it is “gl_FragCoord.y”

#32

There are a couple of options. You can change the 1.0s and 0.7s to a bigger difference, such as 1.3 and 0.4 (just make sure they add up to 2.0 so it all balances out), and/or you can try making it larger by multiplying gl_FragCoord by something <1.0, like 0.5. Tbh, rather than sticking with gl_FragCoord, you might be better off just playing around with something that ties it to the resolution, like texCoord.x * color_texture_pow2_sz.x or whatever works, as I believe gl_FragCoord is going to stay the same size whether you have it fullscreen on a 4K TV or windowed at 640x480…

#33

Thanks for your advices, they really helped me. Multiplying gl_FragCoord by something <1.0, worked only good with 0.5, as there was ugly color shifting with other values. Tried to replace gl_FragCoord, with something like texCoord.x * color_texture_pow2_sz.x, but same here… it didnt looked so well. Today, I will not have much time to prove if gl_FragCoord dont tie with resolution… with my first tests, it was hard to tell… I will need a deep screenshot photoshop comparison to be safe.

Also trying to achieve some bilinear filtering or blur, prior the crt-geom processing. I allready have a shader, but it blurs way, way too much and I dont know how to reduce it properly. Everything I tried, didnt reduced it equally on X,Y cord. So I guess, it is not the right way :wink: . Maybe you have some hint for me? :slight_smile: I attached you my Bilinear-shader.

What is this .LUT stuff? I have those in the linux part, but they dont do anything, if i use them with windows… at least I think so. It makes no difference for me, if its there or not.

I would like to credit you for helping me, if we put this shader into the next release of UIFX, is this ok for you? any special wishes?

cheers u-man

#34

LUT stands for “lookup texture,” so if it’s referencing one, there should be an external image file that it’s pulling from. That bilinear shader looks pretty crazy to me insfoar as regular bilinear scaling should be essentially “free” on any hardware. Doing it manually like this is likely to be super-slow, particularly with the branching if statements.

Generally for blurs, you want to break them into 2 passes: one for vertical and one for horizontal. Gaussian blurs look nice and are super-simple to code. You can look at my bigblur-horiz and bigblur-vert shaders in common-shaders/borders/resources for examples. They can be very resource-intensive at large sizes, though, so you would want to run them at, say, 1x scale and then let your crt shader do the scaling from there.

Don’t worry about crediting me. I’m happy to help :slight_smile:

#35

Long time, no hear… :slight_smile: … I tried to seperate the four main parts of the shader: Curvature, Corner, Scanlines and Dotmask. Something like the cgwg-CRT-deconstructed.shader, but I fail at the scanlines. The four parts are bounded or sticked together in a way, that i cant remove the scanlines part. It would be nice to have the parts seperated, so users could try them on different shaders and maybe “construct” new versions.

Although I found out, that the tilt feature, doesnt work on every vertical game.

i.e., if you use this values with Donkey Kong, then the screen will be tilted into the correct direction:

// tilt angle in radians // (behavior might be a bit wrong if both components are nonzero) const vec2 angle = vec2(-0.15,0.0);

but if you try the same values with lets say Time Pilot, then the screen will tilt into the wrong direction (just the opposite). If you correct the line with a positive value like: const vec2 angle = vec2(0.15,0.0); then it will not work with Donkey Kong anymore. I really wonder, why is this tilt option behaving like this and if there is a solution for this? I didnt find errors, if I use the tilt option on horizontal games. My guess is, that it has to do, with the axis where the tilt is happening.

Thats all for now… maybe you have a clue :slight_smile: , cheers u-man

#36

PS: http://mame32fx.altervista.org/home.htm

:smiley: :wink:

#37

Hello Hunter K., i need to bump this thread again.

While the CRT-geom shader is working well on my setup, i have frequent postings of users, where the CRT-geom shader just delivers a black screen with audio. To have a picture again, the #define CURVATURE parameter needs to be out-commented with two //. I would really like to have some debugger-tool for opengl, because its hard to find the cause of the problem here, especially with a setup, that dont have to deal with that “bug”. I guess it is a “transform” problem, but “transform” is related to so many operations, nearly impossible for me to find the cause of this “bug”.

All things mentioned in my #35 post, are still actual :frowning: . It would be very useful to have a “deconstructed” version. I hope you can help me out Hunter K. :wink:

Greets, u-man

#38

You could try putting a simple curvature shader into a separate pass and just always commenting out the curvature function:

It’s simple enough that you could pretty easily merge it into crt-geom if you want it to stay single-pass.

#39

First, a big thanks to you … Hunter K. , my dude who solves the problems :smiley: . I just want to confirm, that it worked. I managed to include your “new” curvature to replace the “old” one. It has some downsides, i.e. you cant use the Tilt function anymore. I can live with this, at least there is a solution for the very view people that had a problem with our old CRT-geom shader. We can distribute this version as a fix now :wink: , thanks to you :slight_smile: .

I still have some questions, for my next steps. I guess this is the halation part from the CRT-geom shader:

uniform sampler2D mpass_texture; uniform vec2 color_texture_pow2_sz; uniform vec2 color_texture_sz; uniform vec2 rubyOutputSize;

#define CRTgamma 2.5 #define display_gamma 2.2 #define TEX2D© pow(texture2D(mpass_texture, ©), vec4(CRTgamma))

void main() { vec2 xy = gl_TexCoord[0].st; float oney = 1.0/color_texture_pow2_sz.y;

            float wid = 2.0;

            float c1 = exp(-1.0/wid/wid);
            float c2 = exp(-4.0/wid/wid);
            float c3 = exp(-9.0/wid/wid);
            float c4 = exp(-16.0/wid/wid);
            float norm = 1.0 / (1.0 + 2.0*(c1+c2+c3+c4));

            vec4 sum = vec4(0.0);

            sum += TEX2D(xy + vec2(0.0, -4.0 * oney)) * vec4(c4);
            sum += TEX2D(xy + vec2(0.0, -3.0 * oney)) * vec4(c3);
            sum += TEX2D(xy + vec2(0.0, -2.0 * oney)) * vec4(c2);
            sum += TEX2D(xy + vec2(0.0, -1.0 * oney)) * vec4(c1);
            sum += TEX2D(xy);
            sum += TEX2D(xy + vec2(0.0, +1.0 * oney)) * vec4(c1);
            sum += TEX2D(xy + vec2(0.0, +2.0 * oney)) * vec4(c2);
            sum += TEX2D(xy + vec2(0.0, +3.0 * oney)) * vec4(c3);
            sum += TEX2D(xy + vec2(0.0, +4.0 * oney)) * vec4(c4);

            gl_FragColor = pow(sum*vec4(norm),vec4(1.0/display_gamma));
    }

I managed to run this code in a seperate shader, but i am not able to include it into the CRT-geom shader. The seperate shader creates some kind of a blurry image, thats all, but I guess this is the part of a halation process, which blends this result with the final image to create the halation. How I can do this properly?

… and thank you so much for your help so far, I would not come so far without it :slight_smile:

#40

You’re not going to want to do halation in a single pass, if that’s what you’re after. Those blurs look terrible and are very slow unless you bust them out into separate passes. You’ll also need the ability to reference output from previous specific passes for it to work, which I don’t know if your MAME variant has. Also, those passes are just simple gaussian blurs, which is fine, but most people doing proper bloom/HDR include a brightness-threshold (commonly called a bright pass) first to isolate just the really bright stuff ([url=]this shader from maister’s “glow” does this step), which then gets blurred and added to the final image.

So, you would have the bright pass, followed by a horizontal blur pass and a vertical blur pass that run in order referencing the one before, followed by the crt effect pass that references the original frame, and then a final frame that adds the output of the crt effect pass with the output of the last blurring pass. If you want it to look exactly like cgwg’s version, just leave out the bright pass bit.

#41

I dont know what you mean with single pass, i also dont know how to reference output from previous passes, but i guess it goes with “sampler2D mpass_texture”. I dont use a MAME variant. I use the original from he MAME devs. The only docs i found are this: http://git.redump.net/mess/plain/src/osd/sdl/shader/docs/PluggableShader.txt

Sadly your provided link (if it is one) doesnt work.

"So, you would have the bright pass, followed by a horizontal blur pass and a vertical blur pass that run in order referencing the one before, followed by the crt effect pass that references the original frame, and then a final frame that adds the output of the crt effect pass with the output of the last blurring pass. "… sounds plausible for me, just hard to “translate” or to perform, as i dont know how to “pass” my results to the next pocess step. This is the tricky part for me.

#42

Ha, whoops. BBCode fail. It was supposed to be this link:

That shader needs to run in linear gamma, though, so if you just try to run it on its own, it won’t look correct. Anyway… Judging by that document, you won’t be able to refer back to arbitrary passes, so you’re stuck with the same limitations that affect this version: Which is fine, since it still looks nice, you just can’t do the bright pass.

Yes, mpass_texture is the previous pass’ output, so you’ll do a horizontal blur pass, then a vertical blur pass and your crt pass, replacing the rubyTexture stuff with mpass_texture in both.

#43

Ok… I understand what i have to do, but i am not able to do it properly. Problem is the mpass_texture syntax… replacing the rubyTexture stuff with mpass_texture in both blur-passes doesnt work or i am doing it wrong :frowning: . It only works with color_texture_pow2_sz . If you look at my previous code-posting, you will see also rubyOutputSize is left “untranslated”. I dont know what the equivalent would be in MAME language for this.

I am also not able to include the blur-passes into my CRT-geom shader. The only thing I got working is, if the blur-passes run as a seperate shader (two shaders for each direction), but then i have the problem that the last shader (my CRT-geom) doesnt treat the previous blur-passes right and i got a blurred final image, with curvature, dotmask etc. … but blurred game-screen :frowning: . I dont know, how to tell the CRT-geom shader, to use the blur-passes to calculate the bloom/halation.

I am sorry going on your nerves and its not that i am not trying, but without knowledge of the whole syntax or no debugger, it is really a pain.

#44

Yeah, I’m pretty much in the same boat. Btw, have you seen this thread where cgwg posts some of his own shaders for MAME? http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=96032&page=1 EDIT: this repo looks pertinent, as well: https://github.com/douglaslassance/mame/tree/master/glsl

#45

Yeah, i tried to register at bannister.org, but there is no one who approves my account :frowning: . I guess I will PM R.Belmont to do this. I will check the other repo-link too.

#46

I was going to separate Timothy Lottes’s shader out into two passes to make it faster a while back.

I wanted to use one pass for horizontal scaling, one that would do vertical scaling and scanlines. Then maybe one that would handle the aperture mask, one for screen curvature, etc.

Then everything would be modular so that you could take, for example, a simple bicubic horizontal scaling, with the CRT-geom scanlines, and with Lottes’s aperture mask.

I ran into trouble immediatley getting multiple passes to work they way I though they should. I guess (I could be wrong) that only the final pass gets a screen sized texture to write into. And any previous passes just get a texture the size of the original input. So I could write shaders that work as long as they are the only/last pass. But if they are earlier than that, they won’t work properly because the intermediate texture is just too small for proper scanlines (or aperture effect, or anything really except for NTSC processing and basic color transformations).

If I’m wrong though, I’d love to hear it!

Also, see below about bannister

When you registered on bannister you must have checked a box just to verify that you read this:

IMPORTANT NOTICE

Due to a large quantity of spam posts to this forum, newly registered users need to contact the board administrator in order to have their accounts made live. To do this, use the email form located on the main www.bannister.org site, quoting your username, real name, and a list of emulators that you are interested in (this is solely to prove that you are human rather than a spam bot!). Messages without this information will be ignored. Accounts registered without this information present will be deleted a fortnight after their creation.

#47

Hey man, welcome :slight_smile:

I think you’re right about the scaling only happening on the last pass. I do think that blur passes are okay at 1x, though, for the halation stuff (based on Hyllian’s Cg port of cgwg’s crt-halation shader, which runs those passes at 1x), but yeah, not much else.

It seems the masks can be reproduced well enough with MAME’s “rgb effect” overlay thingies, as you demonstrated in that bannister thread I linked.