On среда, 1 сентября 2021 г. 22:53:14 +07 you wrote:
Am 31.08.2021 um 19:26 schrieb Anton Baskanov baskanov@gmail.com:
- shader_addline(buffer, " if (fract(floor(texcoord.y * size.y) *
0.25 + 1.0 / 6.0) >= 0.5)\n"); + shader_addline(buffer, " if (fract(texcoord.y * size.y * 0.25) >= 0.5)\n");
Some archeology 2c: the code in arb_program_shader.c has this to say about the 1/6 offset:
shader_addline(buffer, "ADD texcrd2.x, texcrd2.y, yv12_coef.y;\n");/* To avoid 0.5 == 0.5 comparisons */
I don't remember why I was scared of 0.5 == 0.5 comparisons or why exactly they might happen (at the exact edge of the texture probably? But even then I'd expect the texture coordinate to be not quite 1.0), why I was scared of equality here ('SGE' is set greater equal after all. Driver bugs?). It was 13 years ago when I wrote the ARB version of this.
The ARB code does use 0.25 though, like the change your previous patch introduces.
Weirdly, the WINED3D_GL_RES_TYPE_TEX_2D branch in the ARB code does not multiply the floor result by anything at all. This means that the condition is always false. I tried to set shader_backend to arb, and I saw 4-pixel tall jaggies around the color transitions, which confirm this.
My gut feeling says that those shaders should be safe re magnifying filters, but if the blit scales the YUV image down while converting to RGB it'll probably break in interesting ways.