GLSL Shaders in .vsh format?

RetroArch Additions Shaders
#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.

#48

Hey hello SoltanGris42 :slight_smile: ,

nice to see you here. Yeah about bannister.org, i didnt realize or read the “important” note :smiley: , i thought it was the usual yala yala, bla bla forum-stuff :wink: . 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 :smiley: . 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 :frowning: . I know it is a learning process, but this is really the hard way :slight_smile: . 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 :smiley: . I like how helpful Hunter K. is here and i really appreciate the forum.

#49

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 :slight_smile: ,

nice to see you here. Yeah about bannister.org, i didnt realize or read the “important” note :smiley: , i thought it was the usual yala yala, bla bla forum-stuff :wink: . 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 :smiley: . 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 :frowning: . I know it is a learning process, but this is really the hard way :slight_smile: . 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 :smiley: . I like how helpful Hunter K. is here and i really appreciate the forum.[/QUOTE]

#50

Hey Soltan42,

Glad to hear, that those links where useful for you :slight_smile: . 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 :wink: . 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 :wink: .

Greetz u-man

#51

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.