Bilinear filter wraparound?

[mark_k]

I noticed a small issue with scaling & bilinear filtering. This could be due to WinUAE considering the texture (Amiga image) to be tiled when doing bilinear filtering.

The effect of that seems to be, if the top row of pixels is a different colour to the bottom row, the bottom row after bilinear filtering has a "shadow" of the top row. The same probably applies to the left and right edges.

The solution may be to consider the texture as mirrored at the edges, or (effectively) repeat the edge rows/columns.

In practice this is a very minor problem which perhaps no-one ever noticed before, since typically the top and bottom rows of an Amiga display (and the left and right) are all the same colour.

Example pics attached. HighGfx 1024×768, scaling 1.5×. One with point filtering, the other bilinear. The bilinear pic has a helpful red arrow pointing to the problem line. If I drag the screen down by a pixel that line disappears. Strangely though, the "problem line" doesn't have the dark blue border colour on its left and right edges.

[mark_k]

Never mind, looks like the problem is actually a Wine bug, since on Windows 10 the problem doesn't seem to happen!

[mark_k]

Where in the WinUAE source is the null filter defined/set up? That could help if I file a bug report for Wine.

[Toni Wilen]

Null filter in D3D mode? It has short shader file included with direct3d.cpp. (which is written to _winuae.fx in shader filter directory if it is writable)

[mark_k]

Thanks. Strangely there was a _winuae.fx file already in that dir, but an older one. (No relevant differences though.) For some reason WinUAE wasn't overwriting the old one with the new. I renamed the existing file and WinUAE wrote out the new one.

$ diff _winuae.fx_old _winuae.fx
1c1
< // 2 (version)
---
> // 3 (version)
5c5
< // by Toni Wilen 2010
---
> // by Toni Wilen 2012
10a11
> uniform extern float2 texelsize;

I also noticed this in the log:
D3D9Ex: 00000056 00000000 60020000 00000320 ALPHA DYNAMIC
D3D9Ex: PS=3.0 VS=3.0 1920*1200*0p VS=0 B=2WE 32-bit 0 (8192x8192)
D3D9Ex: D3DXCreateEffectCompilerFromResource failed: 8876086C S=1 F=0876 C=086C (2156) ()
D3D9Ex: pixelshader filter 'C:\Program Files\WinUAE\plugins\filtershaders\direct3d\_winuae.fx':-1 failed to initialize
Falling back to non-shader mode
D3D9Ex: GetMaximumFrameLatency() failed: 80004001 S=1 F=0000 C=4001 (16385) ()
D3D9Ex: 752*576 main texture, depth 32

So it seems WinUAE is using non-shader mode in this case?

[Toni Wilen]

Originally Posted by mark_k

Thanks. Strangely there was a _winuae.fx file already in that dir, but an older one. (No relevant differences though.) For some reason WinUAE wasn't overwriting the old one with the new. I renamed the existing file and WinUAE wrote out the new one.

Yes, it is by design. WinUAE does not care about the file, it is only written if someone wants to use it as a base for custom shader filter.

I also noticed this in the log:
D3D9Ex: 00000056 00000000 60020000 00000320 ALPHA DYNAMIC
D3D9Ex: PS=3.0 VS=3.0 1920*1200*0p VS=0 B=2WE 32-bit 0 (8192x8192)
D3D9Ex: D3DXCreateEffectCompilerFromResource failed: 8876086C S=1 F=0876 C=086C (2156) ()
D3D9Ex: pixelshader filter 'C:\Program Files\WinUAE\plugins\filtershaders\direct3d\_winuae.fx':-1 failed to initialize
Falling back to non-shader mode
D3D9Ex: GetMaximumFrameLatency() failed: 80004001 S=1 F=0000 C=4001 (16385) ()
D3D9Ex: 752*576 main texture, depth 32

So it seems WinUAE is using non-shader mode in this case?

Yeah, it means very basic D3D mode is in use, mainly for compatibility with pre-PS2.x hardware.

I don't know why it fails. 8876086C = D3DERR_INVALIDCALL.

EDIT: Function name is slightly wrong in the log, failing call is simply D3DXCreateEffectCompiler().

[mark_k]

I got this in Wine log output:
trace:d3dx:D3DXCreateEffectCompilerFromFileW srcfile L"C:\\Program Files\\WinUAE\\plugins\\filtershaders\\direct3d\\_winuae.fx", defines (nil), include (nil), flags 0x20000, effectcompiler 0x6a4cd68, parseerrors 0x6a4cd5c.
trace:d3dx:D3DXCreateEffectCompiler srcdata 0x3cec0000, srcdatalen 2189, defines (nil), include (nil), flags 0x20000, compiler 0x6a4cd68, parse_errors 0x6a4cd5c
trace:d3dx:d3dx9_effect_compiler_init effect 0x37550178, data 0x3cec0000, data_size 2189
trace:d3dx:d3dx9_base_effect_init base 0x37550180, data 0x3cec0000, data_size 2189, effect (nil)
trace:d3dx:d3dx9_base_effect_init Tag: 33202f2f
trace:d3dx:d3dx9_base_effect_init HLSL ASCII effect, trying to compile it.
fixme:d3dcompiler:compile_shader Compilation target "fx_2_0" not yet supported
warn:d3dx:d3dx9_base_effect_init Failed to compile ASCII effect.
fixme:d3dx:d3dx9_effect_compiler_init Failed to parse effect, hr 0x8876086c.
trace:d3dx:free_effect_compiler Free effect compiler 0x37550178
trace:d3dx:d3dx9_base_effect_cleanup base 0x37550180.
warn:d3dx:D3DXCreateEffectCompiler Failed to initialize effect compiler
trace:d3dx:D3DXCreateEffectCompiler srcdata 0xe603a8, srcdatalen 2087, defines (nil), include (nil), flags 0x20000, compiler 0x6a4cd68, parse_errors 0x6a4cd5c
trace:d3dx:d3dx9_effect_compiler_init effect 0x14a100, data 0xe603a8, data_size 2087
trace:d3dx:d3dx9_base_effect_init base 0x14a108, data 0xe603a8, data_size 2087, effect (nil)
trace:d3dx:d3dx9_base_effect_init Tag: 33202f2f
trace:d3dx:d3dx9_base_effect_init HLSL ASCII effect, trying to compile it.
fixme:d3dcompiler:compile_shader Compilation target "fx_2_0" not yet supported
warn:d3dx:d3dx9_base_effect_init Failed to compile ASCII effect.
fixme:d3dx:d3dx9_effect_compiler_init Failed to parse effect, hr 0x8876086c.
trace:d3dx:free_effect_compiler Free effect compiler 0x14a100
trace:d3dx:d3dx9_base_effect_cleanup base 0x14a108.
warn:d3dx:D3DXCreateEffectCompiler Failed to initialize effect compiler

The relevant line is probably this then:
fixme:d3dcompiler:compile_shader Compilation target "fx_2_0" not yet supported

So for the basic D3D mode, where in the WinUAE source is that handled?

[Toni Wilen]

Originally Posted by mark_k

The relevant line is probably this then:
fixme:d3dcompiler:compile_shader Compilation target "fx_2_0" not yet supported

Most likely reason.

So for the basic D3D mode, where in the WinUAE source is that handled?

Same file, different code path. Note that there is no option to force no-shader mode without recompile. (In other words: the graphics issue you see may or may not be wine bug..)

[mark_k]

Aha... so if I'm right this is the relevant code in direct3d.cpp:

// non-shader version
setupscenecoords ();
hr = d3ddev->SetTransform (D3DTS_PROJECTION, &m_matProj);
hr = d3ddev->SetTransform (D3DTS_VIEW, &m_matView);
hr = d3ddev->SetTransform (D3DTS_WORLD, &m_matWorld);
hr = d3ddev->SetTexture (0, srctex);
hr = d3ddev->DrawPrimitive (D3DPT_TRIANGLESTRIP, 0, 2);
int bl = filterd3d->gfx_filter_bilinear ? D3DTEXF_LINEAR : D3DTEXF_POINT;
hr = d3ddev->SetSamplerState (0, D3DSAMP_MINFILTER, bl);
hr = d3ddev->SetSamplerState (0, D3DSAMP_MAGFILTER, bl);

I read the doc for D3DSAMPLERSTATETYPE enumeration, and that says:
"D3DSAMP_ADDRESSU
Texture-address mode for the u coordinate. The default is D3DTADDRESS_WRAP. For more information, see D3DTEXTUREADDRESS."

It looks like you should use D3DTADDRESS_CLAMP for D3DSAMP_ADDRESSU and D3DSAMP_ADDRESSV. So add something like
hr = d3ddev->SetSamplerState (0, D3DSAMP_ADDRESSU, D3DTADDRESS_CLAMP);
hr = d3ddev->SetSamplerState (0, D3DSAMP_ADDRESSV, D3DTADDRESS_CLAMP);

[mark_k]

Also (but not related to this issue), should you do something like
hr = d3ddev->SetSamplerState (0, D3DSAMP_SRGBTEXTURE, 1);
because the Amiga image data should be considered to be in sRGB space.

[mark_k]

Wine bug 37676 is about the lack of fx_2_0. A suggested workaround is to do "winetricks -q d3dcompiler_43" but after that WinUAE/Wine crashes in d3dx9_43... sigh.

[Toni Wilen]

Originally Posted by mark_k

It looks like you should use D3DTADDRESS_CLAMP for D3DSAMP_ADDRESSU and D3DSAMP_ADDRESSV. So add something like
hr = d3ddev->SetSamplerState (0, D3DSAMP_ADDRESSU, D3DTADDRESS_CLAMP);
hr = d3ddev->SetSamplerState (0, D3DSAMP_ADDRESSV, D3DTADDRESS_CLAMP);

Added. Shaders also use clamping when accessing source texture.

Originally Posted by mark_k

Also (but not related to this issue), should you do something like
hr = d3ddev->SetSamplerState (0, D3DSAMP_SRGBTEXTURE, 1);
because the Amiga image data should be considered to be in sRGB space.

Not going to make any changes that can modify how whole display looks.

[mark_k]

Originally Posted by Toni Wilen

Added. Shaders also use clamping when accessing source texture.

Thanks, the line is gone.

Originally Posted by Toni Wilen

Not going to make any changes that can modify how whole display looks.

I think D3DSAMP_SRGBTEXTURE should only make any difference when blending textures (which could/should be "more correct" then), e.g. when using an overlay texture. In theory, with no overlay the Amiga image should look exactly the same as before.

[mark_k]

Originally Posted by Toni Wilen

Note that there is no option to force no-shader mode without recompile. (In other words: the graphics issue you see may or may not be wine bug..)

Could you add an option to force no-shader mode? That could be useful on lower-end/older GPUs and when running in a VM.

For instance, in a VirtualBox VM here (Lubuntu host, XP guest) DirectDraw gives smooth(ish) graphics but D3D is jerky. Maybe the jerkiness could be reduced if no shader was used?

[Tomislav]

Originally Posted by mark_k

For instance, in a VirtualBox VM here (Lubuntu host, XP guest) DirectDraw gives smooth(ish) graphics but D3D is jerky. Maybe the jerkiness could be reduced if no shader was used?

You didn't tried in wine? Use newest wine in which are improved many things.

[Toni Wilen]

Originally Posted by mark_k

Could you add an option to force no-shader mode?

Added -nod3d9shader command line parameter.

[mark_k]

Thanks for that. It didn't seem to make a huge difference to my XP VirtualBox VM, but perhaps on some low-end real hardware it could be more noticeable.

-nod3d9shader disables all shaders. Would it be possible to instead just disable the final _winuae.fx shader? Then the user could disable or enable other shaders which get run before that independently.

[Toni Wilen]

Originally Posted by mark_k

-nod3d9shader disables all shaders. Would it be possible to instead just disable the final _winuae.fx shader? Then the user could disable or enable other shaders which get run before that independently.

No. Totally different incompatible code paths.