SDL2: Graphic issues with bilinear filtering enabled (Win, direct3d)

[rootfather]

Note: This bug seems to be related with #9592.

OS: Windows 10
ScummVM: currently at f7381c2, but happens with all versions that include SDL2+filtering
GPU: AMD Radeon HD 6320 [integrated solution]

I noticed that when I enable the linear filtering feature in fullscreen mode, on my Windows system, it seems that the image is about 1px too small on each side and the image starts to 'wrap around'. See the attached screenshot from 'Myst', it should be much clearer than my explanation.

Basically, it seems that the linear filter uses image data from the last pixel column on the right side to draw/fill/interpolate the image data of the first pixel column on the left side (and the same going on with the top and the bottom). This does *not* happen when you turn off the linear filtering.

criezy couldn't reproduce the issue on his system. After some poking around in the source code from my side, criezy suggested to insert the lines

SDL_SetHint(SDL_HINT_RENDER_DRIVER, "direct3d11")

or

SDL_SetHint(SDL_HINT_RENDER_DRIVER, "opengl")

right before the call of SDL_CreateRenderer in line 2622 of surfacesdl-graphics.cpp.

First, I tried direct3d11. It really works like a charm, it fixes this bug and even resolves #9592. The downside of this is that direct3d11 support in SDL is pretty new (from 2015), and we don't know how it behaves on older SDL2 versions or unsupported Windows versions (although I think DirectX 11 is supported in Windows XP SP3 and higher). Will it just ignore the setting and do a fallback to the first supported driver? Will it segfault? Will it kill your hamster? We have to investigate this.

Next, I tried opengl. Using OpenGL solved this issue, but #9592 is persisting, although the rendering artefacts in the launcher changed the location. While both direct3d11 and opengl have a good ingame-performance, it is interesting to see that opengl has a better performance when switching between scalers (like 2x->3x and vice versa).

Because using direct3d11 solves both issues for me, I would opt for using this if there are no unwanted side-effects with older versions of SDL2 or Windows or even with other operating systems. In case we can't use direct3d11 due to non-existing fallback mechanisms, opengl seems to be a good solution too (but then, we have to care about #9592 again).

[rootfather]

"Myst" with linear filtering enabled. Notice the artifacts on the pixel colums at the sides.

[rootfather]

windowed mode when using opengl as hinting

[rootfather]

opengl breaks windowed mode, see the attached screenshot.

No issue with direct3d11.

To do a quick test what might happen if an older version of SDL hits the "direct3d11" string, I tried with "3headedmonkey" as SDL_HINT_DRIVER. It compiles and runs fine, seems to fallback to the default driver.

[rootfather]

SDL 2.0.5: Works as expected.
SDL 2.0.4: no direct3d11, fallback to default renderer.
SDL 2.0.3: no direct3d11, fallback to default renderer.
SDL 2.0.2 and earlier: same borked windowed mode as with opengl, probably fallback to this?

Conclusion: We could add a SDL_VERSION_ATLEAST(2,0,5) check and only add direct3d11 if this is true? Then, we would have less problems with other OSs, and because we bundle the SDL2.dll with our Windows builds, the official versions have direct3d11 enabled in future releases.

Update: Seems that my system has issues with SDL 2.0.2 and earlier in general, the windowed mode is even broken if I remove the direct3d11 stuff entirely and use the stock ScummVM code with SDL 2.0.2. So maybe using direct3d11 is safe to use in general.

For me, it seems that SDL 2.0.2 uses opengl as renderer anyway, because even if I remove the stuff we changed here, I cannot replicate this issue.

[csnover]

Could you please verify whether this is still a problem with latest ScummVM & SDL? Thanks!

[rootfather]

This problem still persists. I'm on the latest ScummVM codebase and just re-compiled everything from scratch with SDL 2.0.7. The bug still only appears when linear filtering is enabled *and* the default SDL2 renderer is used. No issues with either bilinear filtering enabled or disabled when I use the OpenGL renderer.

What changed though is that the artefacts are still visible in-game, but are *not* captured anymore when using the screenshot function in ScummVM or using the Windows screenshot function using PrntScr and pasting the output to MS Paint.

OS: Windows 10, build 17025 (yes, pre-release, but I ran a non-insider version when I opened this report)
ScummVM version: current master branch
Graphics hardware: ATI Mobility Radeon HD 4200 Series (driver from Windows 10 itself, legacy hardware...)

Clearly we need more testers for this one... I don't know if this is just a driver issue with the AMD driver or if all graphics vendors are affected on Windows.

[rootfather]

Reproducible on the following system:

OS: Windows 10, build 17035
ScummVM: current master
Graphics hardware: Intel HD Graphics 620

[rootfather]

Also reproducible on the following system:

OS: Windows 10, build 16299.15 (latest non-insider version)
ScummVM: current master
Graphics hardware: Mobile Intel 4 Series (very legacy from 2009)

It seems that the image is wrapping around (or shifted) exactly 1px to the top and exactly 1px to the right and then wrapping around to the opposite side. Therefore it is less noticeable on the 2nd system because it has a FullHD screen whereas the other systems have a lower resolution.

What to do next?

[rootfather]

I could reproduce it in a VM.

OS: Windows 7, no Updates, fresh installation
Graphics hardware: Standard VMWare SVGA driver without any passthrough to rule out driver issues.

[rootfather]

Lowering priority back to normal since this seems to be an upstream bug in the SDL2 library: ​https://bugzilla.libsdl.org/show_bug.cgi?id=1878

I'll report this to the SDL team.

[blam666]

I can confirm this problem with bilinear filtering turned on on a INTEL HD 4000 WIN10 machine, using Scumm Daily Builds 1.10.0git3185 (Apr 25 2017) and 1.10.0git5368 (Nov 13 2017). The last fine line of pixels gets depicted on the opposite side of the picture. It's the same for last line of the upper edge, gets depicted as line at the bottom of the picture and vice versa. Only happens with default graph. setting and bilnear filtering on.

But it doesn't happen in stable version 1.9.0.2 in the same system. Bilnear filtering is enabled by default there (without a checkbox to turn it off).

[rootfather]

Fixed by upstream commit ​http://hg.libsdl.org/SDL/rev/0c134b939fd9.