MAMEWorld Forums - EmuChat - Re: GLSL Shader compile errors.

> > I've really just taken the CRT-geom shader in Mame, stripped it to just the CRT
> > curvature code (which took a good hour of analysing) which can be applied to almost
> > anything, it just needs be used to multiply the final pixel colour of something
> else.
> > And then bumped that into the Halation shader after stripping out the warp code.
> >
> > Next I need to optimize that.
> >
> >
> > Iwish I knew enough about C++ and Mame to be able to just link in the HLSL2GLSL
> > library. And then add all the cool menu options that are in the Windows code.
> >
> > In the mean time, I'll continue tweaking the shaders while trying to keep them just
> > under that limit. It doesn't seem likely that we would need much more than that to
> be
> > honest.
>
> Maybe I am wrong, but you could also use the shader stacks, that MAME provides.
> I.e. glsl_shader_mame0 could be just the halation and then with glsl_shader_mame1 put
> the curvature on top of it. I like the idea of "deconstructing" shaders, with the
> stacks, people could easily build their own shaders to their like. Deconstructed
> shaders would also make it easier to create those menue sliders (like in HLSL) and
> they would be mixable . If you create sliders for a shader in the current state, you
> would need to start again from zero, if you want the same for another shader.
>
> It is really nice, that people start to convert OpenGL shaders and i would not say
> that "It doesn't seem likely that we would need much more than that to be honest."
> because there are at least two or three more shaders, that could be very interesting
> and nice... NTSC-Composite and CRT-Royale coming to my mind. Also vector-shading is a
> thing that needs more attention, but I am on it .
>
> I am at most a novice, when it comes to shaders, but it seems that Timothy Lottes
> shader can also be more optimized. This is what he wrotes me:
>
> "When creating that and posting it I was hoping that it would get integrated into
> stuff.
> Glad to see someone taking it.
>
> 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."
>
> Dunno how much of that statement went into the conversion from SoltanGris42.
>
> I hope you will sharing your results with us, it looks very promising.

Hi uman!

Did you ever see R.Belmont's conversion of the NTSC shader MooglyGuy wrote? It was posted here:

http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=94686#Post94686

It works pretty well from what I remember. The version on my PC has been edited so much that I'm not sure I remember how the default version worked. Note that for the most accurate effect, you'll need to set at least the color subcarrier frequency (just 3.579545 for NTSC), and then the ScanTime variable based on how many pixels the system outputs per period.

So you'd want to use something like 44.6984 (=640/3.579545/4) for ScanTime to get correct artifact colors out of a PC with composite CGA. OR 39.911112 (=560/3.579545/4) for an APPLE IIe. Don't know about consoles. Probably you'll "divide by 2" instead of "4". So the genesis (not always 320 width but...) should probably be 320/3.579545/2 and you'll get the same answer as for CGA. Or something like that.

Also, many systems will need an extra phase shift added for correct colors. The setting is called "OValue" in the HLSL version but missing from the GLSL I linked.

I'll take a look at separating some of the CRT shader out into separate passes. I started doing this before and ended up making things slower but maybe I'll have more luck this time.