Slang presets allow framebuffer outputs to be scaled at different stages using either relative or absolute scaling. However, there are many cases where specifying an absolute scale while preserving source pixel grid alignment would be beneficial.
For example, consider a source framebuffer that can be 320px, 384px, or 640px wide, with a preset configured as follows:
scale_type_x1 = absolute
scale_x1 = 640
This configuration stretches the output to 640px wide, resulting in integer scaling for 320px (2x) and no scaling for 640px (1x). However, 384px will be scaled fractionally, which presents complications depending on the shader's purpose. Depending on the situation, workarounds may include using relative scaling (wasting processing power when unnecessary), oversampling with a larger framebuffer and filtering, requiring additional user parameters, and requiring more presets.
I propose two possible solutions: introducing a new scale type or adding an additional variable.
The new scale type syntax would look like this:
scale_type_x1 = min_int
scale_x1 = 640
The additional variable syntax would look like this:
scale_type_x1 = absolute
scale_x1 = 640
min_int_scale = true
Both approaches would produce identical results: the framebuffer would be scaled by the minimum integer value that makes the framebuffer size greater than or equal to the specified scale value. In our example, 320px would scale to 640px (2x), 384px would scale to 768px (2x), and 640px would remain unscaled (1x). The actual framebuffer size can be easily retrieved from OutputSize.
This feature would greatly simplify and improve compatibility for shaders that work with absolute scale values, such as many NTSC shaders. Both proposed methods are transparent and opt-in, meaning existing shaders would remain unaffected.
Slang presets allow framebuffer outputs to be scaled at different stages using either relative or absolute scaling. However, there are many cases where specifying an absolute scale while preserving source pixel grid alignment would be beneficial.
For example, consider a source framebuffer that can be 320px, 384px, or 640px wide, with a preset configured as follows:
This configuration stretches the output to 640px wide, resulting in integer scaling for 320px (2x) and no scaling for 640px (1x). However, 384px will be scaled fractionally, which presents complications depending on the shader's purpose. Depending on the situation, workarounds may include using relative scaling (wasting processing power when unnecessary), oversampling with a larger framebuffer and filtering, requiring additional user parameters, and requiring more presets.
I propose two possible solutions: introducing a new scale type or adding an additional variable.
The new scale type syntax would look like this:
The additional variable syntax would look like this:
Both approaches would produce identical results: the framebuffer would be scaled by the minimum integer value that makes the framebuffer size greater than or equal to the specified scale value. In our example, 320px would scale to 640px (2x), 384px would scale to 768px (2x), and 640px would remain unscaled (1x). The actual framebuffer size can be easily retrieved from OutputSize.
This feature would greatly simplify and improve compatibility for shaders that work with absolute scale values, such as many NTSC shaders. Both proposed methods are transparent and opt-in, meaning existing shaders would remain unaffected.