Display problems when using zfast-crt on Android

supersebi · 12 February 2021 17:52

Hey all,

I’ve successfully installed Retroarch on my Amazon Fire TV Stick 4K. The installed emulators for NES, SNES work perfectly.

However, there is a general display problem when using CRT shaders. The zfast-crt shader serves as an example, but the same display problem also occurs with the crt-pi shader.

As you can see on the images (the red line within of the images is used for marking only) about 40% of the screen (right side of the screen is affected) is noticeably darker than the rest.

This phenomenon also occurs when using crt-pi shader instead of zfast-crt.

Anyone who can help me to solve this problem?

Many thanks! Sebastian

Key data: Amazon Fire TV Stick 4K MediaTek MTK8695+MT7668 4x 1.70GHz, GPU: IIMG GE8300 Android Level 28 (Android 9) OpenGL ES 3.2 Retroarch 1.9.0 1920 x 1080 Both emulator cores affected (Nestopia & Snes9x)

hunterk · 12 February 2021 18:48

You could try multiplying the TexCoords by 1.0001 here:

github.com

libretro/slang-shaders/blob/master/crt/shaders/zfast_crt.slang#L74


#pragma stage vertex
layout(location = 0) in vec4 Position;
layout(location = 1) in vec2 TexCoord;
layout(location = 0) out vec2 vTexCoord;
layout(location = 1) out float maskFade;
layout(location = 2) out vec2 invDims;

void main()
{
   gl_Position = global.MVP * Position;
   vTexCoord = TexCoord;
	maskFade = 0.3333*MASK_FADE;
	invDims = 1.0/params.SourceSize.xy;
}

#pragma stage fragment
layout(location = 0) in vec2 vTexCoord;
layout(location = 1) in float maskFade;
layout(location = 2) in vec2 invDims;
layout(location = 0) out vec4 FragColor;
layout(set = 0, binding = 2) uniform sampler2D Source;

trnzaddict · 20 February 2021 01:03

I tried RA on the Firestick 4K and this same issue happened to me too. Was never able to remedy it.

A little off topic but do you have bad sound lag along with input lag on your FS4K with RA? It was such a bad experience compared to my pc I immediately deleted it because of all these hiccups.

DariusG · 3 November 2021 16:40

Same happens on many shaders on my cellphones but not on PC. Parts of the screen are darker. I will try the solution suggested by hunterk to see if it works.

DariusG · 3 November 2021 18:46

Yeah that totally fixed the issue on Android (glsl).

TEX0.xy = (TexCoord.xy*1.0001 );

DariusG · 12 November 2021 07:26

Further testing on Android. Some shaders that don’t have Curvature like CRT-Pi (default off), zfast are fixed this way, others that have Curvature don’t (assuming that Curvature is causing the problem). Hyllian-fast (glsl) is perfect by default if that matters.

hunterk · 12 November 2021 17:02

so, what that fix does is prevents rounding issues. so, if it doesn’t fix it, try looking for other areas where rounding issues could happen, such as floor().

DariusG · 11 February 2022 07:37

Did some further testing, all shaders that use a sin function (e.g sin(pos.y * pi * TextureSize.y) ) to create scanlines, have incorrect scanlines on Android. While all others that don’t e.g. CRT-Pi, Guest.r, Z-fast etc display properly. Plus they don’t scale well if integer is 5x (no matter if sin or not) while no such problem exists on Windows.

DariusG · 17 February 2022 12:19

Made some tests with various Android devices, and it seems there is an accuracy issue (no highp precision??) with some of them, example Snapdragon 650 and Adreno 510 has no issues at all and displays all shaders the same way with a PC, no rounding even at non-integer while a later Snapdragon 835 and Adreno 540 has all sorts of rounding issues if scale is not integer 4 x or 8 x

And some info i found around, probably this is what happening??

the fractional part of an FP16 number gives ~10 bits of fractional precision between 0 and 1 (the usual range for texture coordinates). A shader using mediump maths to compute texture coordinates can therefore only accurately address pixels in a texture up to 1024x1024, and even that only works for GL_NEAREST point sampling where the texel snap helps to clean-up any rounding errors. If you have larger textures than that (either physically larger, or virtually larger due to tiling repeats) or if you want good bilinear filtering (which needs at least 4 bits of sub-pixel accuracy, ideally more) then all of your shader computation for the texture coordinate must be highp.

hunterk · 17 February 2022 13:29

yep, this is a thing. mobile GPUs are a mess.