dosbox-staging

dosbox-staging copied to clipboard

Are you using the latest Dosbox-Staging Version?

• [X] I have checked releases and am using the latest release.

Different version than latest?

No response

What Operating System are you using?

Windows 10

If Other OS, please describe

No response

Is your feature request related to a problem? Please describe.

(NOTE: download these images and view them in an image viewer at 1:1 magnification, otherwise the browser scaling will introduce additional aliasing)

Without having the option to oversample the raw image before applying OpenGL shaders, there are visible moire patterns with most shaders that involve scanlines, especially at lower resolutions. For example:

[sdl]
windowresolution = 960x720

[render]
glshader = crt-caligari

One always can tinker around with the resolution to find a setting that minimises or eliminates the moire/aliasing artifacts, but this greatly reduces the usefulness of the shaders, because only a few settings can produce mostly alias-free output. For example, this is one such "good" setting, but if you deviate from it even slightly, the artifacts are back:

[sdl]
windowresolution = 1060x795

[render]
glshader = crt-caligari

Describe the solution you'd like

Other emulators, such as WinUAE, provide an option to oversample the image by a factor of 2x, 3x or 4x before applying the shader, then the image is scaled back to its normal dimensions before displaying it. This greatly eliminates aliasing, but at the cost of increased GPU usage. Therefore, WinUAE provides two separate oversampling settings: one for horizontal, and another for vertical oversampling. The reason for that is that aliasing usually doesn't manifest in the horizontal, but only in the vertical direction, because of the emulated scanlines. So a horiz/vert oversampling of 1x/2x is usually sufficient to yield good results, or even 1x/3x or 2x/3x on more powerful GPUs (at 2x, 3x or 6x the GPU usage compared to non-oversampled, respectively).

Of course, existing shaders wouldn't just work out of the box; shaders would need to be adjusted to be oversampling-aware. The horizontal and vertical oversampling factors should be exposed as parameters to the shader code.

This feature would open up interesting possibilities for shader authors to come up with higher-quality shaders.

Describe alternatives you've considered

No response

Add any other context or screenshots about the feature request here.

No response

Code of Conduct & Contributing Guidelines

• [X] Yes, I agree.

I see what you mean. As a matter of fact I think the CRT emulation via shader in FS-UAE (through ".shader" files) is one of the best I've ever seen. In the meantime, the combination between "machine=vgaonly" (rendered in 640x400, recently fixed in 0.79 alpha) and the embedded "crt-fakelottes-flat" has successfully reminded me of the high quality CRT monitors I had. The result is a very subtle effect I really like. Unfortunately, CRT memories are different from user to user, so mine could never become a joint solution. :-P But Dosbox-Staging is great, because allows to mix pixel-perfect scaling with shaders. I wonder if oversampling could get in the way of pp. Great idea, though.

But Dosbox-Staging is great, because allows to mix pixel-perfect scaling with shaders. I wonder if oversampling could get in the way of pp.

It wouldn't, it would only affect the calculation of the draw area and the aspect ratio to make sure integer scaling can always be used. There's actually a few ways how the oversampling flow could work end to end, but pp would be no issue.

https://github.com/dosbox-staging/dosbox-staging/issues/1106

wonder if multi-pass shaders was done in dosbox-staging?