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…
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 
. Maybe you have some hint for me? 
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
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
Long time, no hear… … 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 , cheers u-man
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 
. It would be very useful to have a “deconstructed” version.
I hope you can help me out Hunter K.
Greets, u-man
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.
First, a big thanks to you … Hunter K. , my dude who solves the problems 
.
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 , thanks to you .
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
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.
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.
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.
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 . 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 . 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.
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
Yeah, i tried to register at bannister.org, but there is no one who approves my account . I guess I will PM R.Belmont to do this. I will check the other repo-link too.
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.
Hey man, welcome
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.
Hey hello SoltanGris42 ,
nice to see you here. Yeah about bannister.org, i didnt realize or read the “important” note , i thought it was the usual yala yala, bla bla forum-stuff . Now, everything is fine and i got registered.
I am after modular concepts too, but guess what, the only chain-shader i got, is the NTSC one . Thats what I like the most with Retroarch… that you can mix shaders, how you like.
Funny thing about the NTSC shader is, it runs only in a chain-version pretty good, as a standalone shader i get a huge performance-drop, dont know what is wrong, but thats what i experienced with the standalone version.
I still hope that we have overseen some things, regarding the multiple passes. Sadly docs on this are very rare. Like i said, the only thing i found useful was this: http://git.redump.net/mess/plain/src/osd/sdl/shader/docs/PluggableShader.txt
If i understand that correctly, the SCREEN-BMP Shader, would pass the results in a correct size, but i am not sure. Or better said, the MAME-BMP Shader would be the internal game resolution and the SCREEN-BMP Shader would be the user screen resolution.
I really would like to know more, as i am a noob, but have enough interest to find out more. The thing i mostly hate, is the .vsh and .fsh stuff with MAME. In a conversion process, I often dont know what belongs where.
Looking at this for example: https://gitlab.com/higan/xml-shaders/blob/master/shaders/OpenGL/v1.2/CRT-interlaced-halation.shader … you see that the whole thing is just one file and if you try to convert this, i often end with the problem, that i dont know, what goes to .vsh and what goes to .fsh . I know it is a learning process, but this is really the hard way .
This link: https://bugs.freedesktop.org/attachment.cgi?id=41595 shows me at least, how some OpenGL stuff is converted into MAME shader language.
MAME’s “rgb effect” overlay thingies can be nice, but I prefer procedural textures too. They often look better and comparing to HLSL (current state) that use .png files too for shadowmasks, they are superior and gives less headaches. Usually you need high prescale factors (at least 6), to achieve similar, but somehow still weaker results. They where the biggest problems for Jezze as he wrote the big overhaul for HLSL. Beta-testing was a pain and we also had a problem, that results could differ from different setups, because alignment was not always the same on every machine.
However I am really very happy to see you here and maybe we will bring more light into MAME GLSL mysteries . I like how helpful Hunter K. is here and i really appreciate the forum.
You know, I’ve been playing with MAME’s glsl stuff for a few years now and I never knew that: (a) There was a document that actually described how it was supposed to work. (b) That SCREEN-BMP shaders existed.
So I feel pretty dumb!
But now I managed to split the Lottes shader into two passes. I haven’t added/fixed the linear/srgb stuff yet. And I’m probably calculating texture coordinates improperly. But at least the horizontal scaling pass and vertical scaling/scanline pass are working. I don’t know about speed, but I’ll test that once I fix it up a little more.
Then I can write a shadow mask pass, and a curvature/rounded corner pass. At which point I’ll be able to modularly swap out any part I don’t like without messing up the rest! If it doesn’t slow everything to a crawl to have several more passes it should be pretty cool.
So thanks for those links.
BTW, I couldn’t really get the SCREEN-BMP passes working right until I scrapped what I had and started with the ones from the MAME docs (the ones below). I’m not sure what I was doing wrong, but once I had these working (I downloaded them from here: https://github.com/villavic/mamethings/find/master) I was able to make progress.
sdlmame -gl_glsl \
-glsl_shader_mame0 /shader/glsl_plain \
-glsl_shader_mame1 /shader/custom/glsl_add_mamebm_bilinear \
-glsl_shader_screen0 /shader/custom/glsl_add_screenbm_hscanlines \
-glsl_shader_screen1 /shader/custom/glsl_add_screenbm_vscanlines \
puckman
[QUOTE=u-man;25310]Hey hello SoltanGris42 ,
nice to see you here. Yeah about bannister.org, i didnt realize or read the “important” note , i thought it was the usual yala yala, bla bla forum-stuff . Now, everything is fine and i got registered.
I am after modular concepts too, but guess what, the only chain-shader i got, is the NTSC one . Thats what I like the most with Retroarch… that you can mix shaders, how you like.
Funny thing about the NTSC shader is, it runs only in a chain-version pretty good, as a standalone shader i get a huge performance-drop, dont know what is wrong, but thats what i experienced with the standalone version.
I still hope that we have overseen some things, regarding the multiple passes. Sadly docs on this are very rare. Like i said, the only thing i found useful was this: http://git.redump.net/mess/plain/src/osd/sdl/shader/docs/PluggableShader.txt
If i understand that correctly, the SCREEN-BMP Shader, would pass the results in a correct size, but i am not sure. Or better said, the MAME-BMP Shader would be the internal game resolution and the SCREEN-BMP Shader would be the user screen resolution.
I really would like to know more, as i am a noob, but have enough interest to find out more. The thing i mostly hate, is the .vsh and .fsh stuff with MAME. In a conversion process, I often dont know what belongs where.
Looking at this for example: https://gitlab.com/higan/xml-shaders/blob/master/shaders/OpenGL/v1.2/CRT-interlaced-halation.shader … you see that the whole thing is just one file and if you try to convert this, i often end with the problem, that i dont know, what goes to .vsh and what goes to .fsh . I know it is a learning process, but this is really the hard way .
This link: https://bugs.freedesktop.org/attachment.cgi?id=41595 shows me at least, how some OpenGL stuff is converted into MAME shader language.
MAME’s “rgb effect” overlay thingies can be nice, but I prefer procedural textures too. They often look better and comparing to HLSL (current state) that use .png files too for shadowmasks, they are superior and gives less headaches. Usually you need high prescale factors (at least 6), to achieve similar, but somehow still weaker results. They where the biggest problems for Jezze as he wrote the big overhaul for HLSL. Beta-testing was a pain and we also had a problem, that results could differ from different setups, because alignment was not always the same on every machine.
However I am really very happy to see you here and maybe we will bring more light into MAME GLSL mysteries . I like how helpful Hunter K. is here and i really appreciate the forum.[/QUOTE]
Hey Soltan42,
Glad to hear, that those links where useful for you . I also did not know exactly, what those SCREEN BITMAP Shader where for, but with the help of Hunter K. and this thread, i digged very deep .
I hope you will succeed with the seperate passes and you may remember what Timothy Lotte wrote me about his shadertoy:
[i]
"There are a bunch of optimizations possible. For instance I usually separate it into 2 passes.
First pass to do the horizontal blur and enlargement, then the second pass to do the vertical blur and enlargement.
Much faster that way." [/i]
So I think, even with the fact of more passes, everything should be faster. I can only offer to help you with shader-speed testing, once everything is working. From my understanding modular/deconstructed shaders have only benefits. I.e. it will be easier to make sliders for GLSL shaders, like the HLSL variant allready have. Smaller parts are easier done, than one large part and you dont have to start from scratch, if you make changes or create new shaders.
[i]
“BTW, I couldn’t really get the SCREEN-BMP passes working right until I scrapped what I had and started with the ones from the MAME docs (the ones below). I’m not sure what I was doing wrong, but once I had these working (I downloaded them from here: https://github.com/villavic/mamethings/find/master) I was able to make progress.” [/i]
I think it has to do, with the subtle syntax changes of “color_texture_sz” vs. “screen_texture_sz” and “color_texture_pow2_sz” vs. “screen_texture_pow2_sz”. Also very important is the line “Using SCREEN-BMP shader requires the usage of at least one MAME-BMP shader, which is applied before the SCREEN-BMP shader.” So maybe this was the cause for your trouble.
In my case with the CRT-geom shader, I want it fully working like the original one. With the help of Hunter K. i got at least the shadowmask working. If you compare the CRT-geom shader from your link (https://github.com/villavic/mamethings/find/master) with our version or the original one, you will see that the shadowmask, interlace-fix and halation/bloom/glow part is missing. I am now struggling only with the halation part, to finish the “real” CRT-geom shader.
These codes are making headaches for me:
uniform sampler2D rubyOrigTexture; uniform vec2 rubyOrigInputSize; uniform vec2 rubyOrigTextureSize;
uniform sampler2D rubyTexture; uniform vec2 rubyInputSize; uniform vec2 rubyTextureSize; uniform int rubyFrameCount;
and this is what i found out:
uniform sampler2D mpass_texture; // = rubyTexture uniform vec2 color_texture_sz; // = rubyInputSize uniform vec2 color_texture_pow2_sz; // = rubyTextureSize
I am pretty sure now, that the remaining “ruby” stuff belongs to the “screen_texture” stuff, with the exception of “rubyFrameCount”, where i dont know the equivalent syntax for MAME GLSL. It belongs to the interlace-fix…so.
I PMed mamesick (author of MAMEUIFX) to implement SCREEN-BMP in his GUI, as it seems it will be important .
Greetz u-man
rubyOrigTexture refers to the original, unfiltered input image, which doesn’t seem to be exposed to later passes in MAME. Likewise, rubyOrigInputSize and *TextureSize refer to the dimensions of that raw image. rubyFrameCount is the frame counter / timer. For interlacing, it only needs 2 ticks (i.e., 0 and 1) to alternate which fields are shown.