Right now unfortunately there isn’t. I have a plan to add a feature to specify a list of parameters to hide in the UI for this sort of thing, but that isn’t there yet.
So right now if you don’t want it to show up in the UI the best thing is using a #define or variable in the shader.
At a certain point it might be a good idea to stop analyzing and start playing. Even taking a break from creating can help reset your eyes and mind.
Sometimes after a break, when you come back, you realize how good things really were or by relaxing and playing, you might start to notice things you didn’t while you were in analysis mode.
This may not be an ideal thing to do because different phosphor masks might be required to get the simulation to work as best as possible on different displays. If you take away the option and leave just one mask in, then people who have a setup that behaves differently from yours might be left completely in the dark.
What masks are in there right now?
Other than RGBX (and possibly RYCB), it might be a good idea to add a BGRX mask for displays with BGR subpixels. A lot of TVs are like this for some reason.
I think you’re right that it’s better for the shader to retain its focus. Not every shader has to be all things to all people (we already have guest-dr-venom for that).
Tbf, we already had swiss-army CRT shaders before, its just guests rendition of it, is more accessible to normal people without needing some crazy documentation (+ a masters degree of some kind 
) to get it in the ballpark of the look you’re going for. (It could really do with some new documentation tho)
Back on topic tho, I do agree with you that maintaining scope and focus is the better play.
How were you planning on implementing those hidden parameters?
Something like ‘#pragma hidden_parameter’ or ‘#pragma property’ or some other name or done in some entirely different way?
For a couple of reasons I was thinking the best way was to add it as a list of parameter names in the preset. This way you can control which parameters appear per preset.
If you have a shader with lots of variations and reused code like the Mega Bezel it’s important to be able to control this from the preset.
The core reason for this is because during loading/compilation the pragma stage comes before the #defines, so you can’t #ifdef a #pragma parameter.
So this would allow you to set values and hide the parameters in the preset for things the user is never supposed to access, either because the parameters aren’t used for the particular variation of the shader, or they define basic operation of the shader for this preset which shouldn’t be changed by the user.
As an example, imagine that your base shader was a multifunctional crt shader. The multifunctional nature of it means that some parameters are only used by one use case of the shader, E.G. Aperture grille vs Slot mask. You would make 2 presets which use the base shader, and hide the parameters that are not used for the use case, so no slot mask parameters in the aperture grille preset and vice versa.
Yes this makes sense as it’s more flexible than having it in the core slang file as you say. Ok so how would you implement it in .slangp? Would you have a tag after/before the parameter name/value pair or a separate keyword with the names of parameters to hide? What name would you call this?
I’m thinking just one entry that has a semicolon separated list of the parameters to be hidden, so in the preset file it would look like:
hiddenparameters = "MyApetureGlow;MyApetureScanlineSharpness"
Then when loading the shader and creating the parameter structs under the shader struct we would add an item on the struct to say if the param is to be visible.
Then when the ui code gets the shader struct and is populating the parameters in the UI it can skip the ones which have their visibility set to off
Edit: Also I think to start we should only save the hiddenparameters if we are saving a full preset
We could also do it with a simple preset too, but requires doing a diff of the currently hidden params and the hidden params coming from the referenced preset
If I can muster up the enthusiam to fight github I may try to add this as you’ve described.
The other thing I want to do is provide instructions to the user on how to use the shader preset properly i.e what minimum requirements are and thats its for 4K etc. I think the best place for this is under the shader parameters at the top (before the parameters).
Do you know a better place or have ideas yourself on this type of thing - I noticed people have been using dummy paramters to achieve menu section titles.
Do you think something like ‘#define text MyText’ and then defining a string for it or does something like this already exist?
anything that’s not actually shader code should probably go behind a pragma so it’s ignored by compilers and other programs that don’t know anything about them. #pragma print_text or something would be good, I think, off the top of my head.
Yeah, let me know if you want to do this and I can point you to where to start, I know the shader loading code relatively well because I re-wrote a bunch of it a year or so ago to do the simple presets.
In terms of Github my workflow is when you are going to submit or get the latest changes, you want to squash all your changes into one commit, then rebase onto the tip of master. You want to make sure that you are not pulling and merging changes into your branch.
GitKraken is a nice UI for Git that can help you see visually where you are as well. You can also use Git Graph extension in VS Code which works well, but not quite as nice as GitKraken.
Yeah if there is something short enough that you want to put in a section title that can be very helpful because the user definitely sees it. Each parameter has a name that is max 63 characters.
Yeah I think this would be good for some sort of help page accessible from the shaders menu. Or as I think what you were suggesting, just printing a line of text in the parameter list for a title. This would be much more elegant than the parameter hack.
Yes this is absolutely true - taking a break is when I do all my work! The thing I’d say though is that it’s a balance between that and enthusiasm and momentum both of which I’ve got at the moment.
I’ll keep on plugging away for the immediate future as I’ve still got to submit my latest changes at the very least!
I think I’m going to drastically reduce the number of patterns I have though as I’m only interested in aperture grilles at 4K and above resolutions. But I’ll still keep a few.
I’ve a load - I can’t quite remember what they all are - there’s about 10. I think I’m going to keep RGBX and add BGRX as you say and then have a think about what would be best for 8K.
RYCB I’m on the fence about as it really ruins the look at least close up. It is a lot brighter though so swings and roundabouts.
When in doubt do without. If you miss it (or if there’s enough demand) you can always put it back in later.
8K:
RRGGBBX
RxxRxxxGxxGxxxBxxBxxxRxxRxxxGxxGxxxBxxBxxx…
Would probably look even better than RGBX. TVL is ~617 at 8K, still PVM territory.
Yup makes sense RRGGBBX - I was going to go for RRGGBBXX but this is more accurate. I’m wondering if there are any versions that give 800 and 1000TVL.
RGBX is 1080 TVL @ 8K
edit: RGBXX is 864 TVL but probably won’t look good, way too much space between triads.
Possibly RYCBX is solution for 800TVL at 8K
I think it would look strange:
RYCBX
RxxRGxxGBxxBxxxRxxRGxxGBxxBxxx
The emulated phosphors wouldn’t be a consistent width but would vary in width per color; red and blue would be fatter.
RYGCB is also weird, in this case the greens would be fatter.
RxxRGxxGxxGBxxB
I think if we want to stick to the goal of accuracy we’re limited to RRGGBBX and RGBX (and the BGR equivalents)
I maybe am not seeing what you mean with RYCBX but red, green and blue are all the same width in your pattern as in each quad of sub pixels have colours on the outside and two off in the middle. I’m not seeing different widths.
I do think it may lead to fatter phosphors though.
EDIT: I think I see what you are saying in that the phosphors wouldn’t be evenly spaced as the triad you have a gap beside it - in-between blue and red.