Originally Posted By u-man
AFAIK, in the "old" GLSL version of the shader, only one option should be enabled at once and the other needs to be commented out. In my documentation it is stated like this:

No, there's never been a reason not to enable both. Over time I've come to prefer the Gaussian profile, and the oversampling will improve image quality with some reduction in speed.

Same is true, for the LINEAR_PROCESSING, commenting it out, makes the shader faster, but AFAIK produce lower quality.

The "LINEAR_PROCESSING" feature will indeed be a bit slower, but whether the quality is higher is debatable. (I believe this feature was actually added by one of the other authors, and I've never been in favour of it.) The image on a CRT is blurred horizontally in (at least) two different steps:
  • In the video amplifier, which has limited bandwidth
  • In the electron beam, which has nonzero width.

To first approximation, the gamma ramp occurs between these two steps. In the default setup, my shader does four-tap Lanczos interpolation before applying the gamma ramp. This provides some simulation of the first step but not the second. If "LINEAR_PROCESSING" is turned on, the gamma ramp is applied before the Lanczos interpolation; this means that there is no simulation of the nonlinear effects that occur in the first step.

Would not we need only one "Tilt" parameter, with the correct use of the "u_swap_xy function"? .
If we use this function, the "Tilt" should be always correctly oriented and if the rotation info (90 or 270) from a game could be retrieved, only positive values would matter. In my thoughts, this would lead to a single "Tilt" parameter, that would always tilt in the desired direction and would work for every game.

Yes, that's a good idea. I actually tried using "u_rotation_type" for this (the code is still present in my shader but commented out) but that uniform only carries the user-specified rotation and not any automatic rotation of the game screen. I don't know if this was the intended behaviour.