Upscaling shaders (xbr) broken with output=opengl?

[pgzh]

Are you using the latest Dosbox-Staging Version?

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

Different version than latest?

Git

What Operating System are you using?

Linux x86_64

If Other OS, please describe

No response

Relevant hardware info

Ryzen 7 Pro 5750G with integrated graphics

Have you checked that no other similar issue already exists?

• I have searched and not found similar issues.

A clear and concise description of what the bug is.

Upscaling shaders (xbr) create artifacts in dosbox-staging git.
The issue was not present in 0.81.1 and I noticed only when trying the latest git.
Obviously the openglnb output was deprecated lately and the xbr shaders produce artifacts with opengl output.
If I switch to output=opengl with 0.81.1, the xbr shaders create the same artifacts.

dosbox-staging git / output = opengl

dosbox-staging 0.81.1 / output = openglnb

I understand the openglnb output was removed intentionally and there were good reasons for this.

So this is not a classic bug report, but a request for help.
Did I misconfigure something or what could I try to get the xbr shader work with output=opengl nicely?

Thanks a lot!

Steps to reproduce the behaviour.

Explain how to reproduce

1. Set output=opengl in 0.81.1 and use xbr shader
2. Use git and xbr shader

Download URL of affected game or software

No response

Your configuration

https://gist.github.com/pgzh/ca4bba5e52dbc312dc2de36892bdf722

Provide a Log

https://gist.github.com/pgzh/aed0b0b87d181d330ea38b9b7f068d44

Code of Conduct & Contributing Guidelines

• Yes, I agree.

[johnnovak]

Summary

Okay @pgzh, when migrating the Tyrell's SVN shaders into Staging, I made the following remark:

My executive summary of the xbr shaders is that they look like crap; I can't imagine anyone wanting to use these...

So yeah, I have no love for them 😆 But it's also true I did not take the time to learn how they are supposed to be used as intended. I'm not against re-instating them with the proper intended look.

If you'd like to play around with the old SVN shaders, you can get them from here:

https://github.com/tyrells/dosbox-svn-shaders/tree/master/xbr

It would be helpful if you posted screenshots showing the intended look for all 4 shaders using some sufficiently complex image (so not the DOS prompt, but maybe the static start screen of a game that features lots of pixel fonts).

Investigation

It turns out, the intended look seems to be with nearest-neighbour interpolation, as you said (filter_linear* is set to false for all):

• https://github.com/libretro/glsl-shaders/blob/master/xbr/xbr-lv2.glslp
• https://github.com/libretro/glsl-shaders/blob/master/xbr/xbr-lv2-3d.glslp
• https://github.com/libretro/glsl-shaders/blob/master/xbr/xbr-lv2-noblend.glslp
• https://github.com/libretro/glsl-shaders/blob/master/xbr/xbr-lv3.glslp

There is a README about their later Slang versions, but it's not overly helpful:
https://git.libretro.com/libretro-assets/slang-shaders/-/tree/3f49a3f1fb33ee246be0303eec7d3b72ca7b3f3c/xbr

So, I'm also quite certain these xbr shaders assume sRGB encoded pixel values as input (as they're quite old, so awareness of using correct gamma was even worse then than in current times), so these pragmas should not be enabled in our variants of these shaders:

#pragma use_srgb_texture
#pragma use_srgb_framebuffer

They also need the non-pixel doubled original input image to work correctly (see here):

#pragma force_single_scan
#pragma force_no_pixel_doubling

So it looks like I'll need to introduce a use_no_bilinear_filtering pragma or something, then we'll need the following pragmas with these shaders:

#pragma use_no_bilinear_filtering
#pragma force_single_scan
#pragma force_no_pixel_doubling

So yeah, if I don't misremember things, 0.80.1 or earlier with output = openglnb is equivalent to the above. Anyway, can you please confirm these shaders work perfectly in 0.80.1 with openglnb?

Related tickets

• Could someone please recommend an excellent upscaling shader that is much cleaner than both advmame3x and advinterp3x? #3478
• A follow-up to my two previous tickets regarding upscaling glshaders like DOSBox-X's xbr-lv3.glsl in VGA apps on 0.81 #3520
• I'm not a fan of CRT shaders in this version #3475

[pgzh]

Wow, that was a lot more feedback than I expected. Thanks a lot for that!

For some games I prefer these shaders' tendency to create a "smoother" image that has softer edges, rounder corners but without blurryness. The xbr shader does produce questionable results with text, but a lot of objects seem to have prettier shapes/outlines compared to advmame3x, which produces better results for text.
Even though it does not reproduce the original images accurately, to me it seems these shaders make a lot of games look what they may have looked if created with higher resolutions to begin with.
This is very hard to describe, I hope you get a rough idea what I mean.

Actually I prefer ScaleFX (from Retroarch) for many games, but that's a more complicated multi-pass shader that cannot work with dosbox-staging.
xbr comes close to its look, but it has its downsides...

Back to topic: I haven't found any noticable differences with how the xbr shaders look between 0.80.1 and 0.81.1.

Here's a comparison between the 'sharp' and 'xbr-lv2-noblend' shaders:

sharp:

xbr-lv2-noblend:

With the latest git, the same image looks like this:

There are differences between the variants of the xbr shaders, and the xbr-lv2-3d shader never seemed to work properly (for me).
I think I've always used the xbr-lv2-noblend variant which produces "best" (for me) results.

xbr-lv2-noblend:

xbr-lv2:

xbr-lv3:

xbr-lv2-3d:

I created the screenshots with 0.80.1.