English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 24 September 2016, 20:04   #1
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
Bilinear filter wraparound?

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.
Attached Thumbnails
Click image for larger version

Name:	Point_1.5x.png
Views:	98
Size:	10.4 KB
ID:	50096   Click image for larger version

Name:	Bilinear_1.5x.png
Views:	83
Size:	165.7 KB
ID:	50097  
mark_k is offline  
AdSense AdSense  
Old 24 September 2016, 20:19   #2
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
Never mind, looks like the problem is actually a Wine bug, since on Windows 10 the problem doesn't seem to happen!
mark_k is offline  
Old 25 September 2016, 17:47   #3
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
Where in the WinUAE source is the null filter defined/set up? That could help if I file a bug report for Wine.
mark_k is offline  
Old 25 September 2016, 18:05   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
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)
Toni Wilen is offline  
Old 25 September 2016, 18:59   #5
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
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.

Code:
$ 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?
mark_k is offline  
Old 25 September 2016, 19:12   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
Quote:
Originally Posted by mark_k View Post
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.

Quote:
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().
Toni Wilen is offline  
Old 25 September 2016, 21:03   #7
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
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?
mark_k is offline  
Old 25 September 2016, 21:27   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
Quote:
Originally Posted by mark_k View Post
The relevant line is probably this then:
fixme:d3dcompiler:compile_shader Compilation target "fx_2_0" not yet supported
Most likely reason.

Quote:
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..)
Toni Wilen is offline  
Old 25 September 2016, 21:41   #9
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
Aha... so if I'm right this is the relevant code in direct3d.cpp:
Code:
// 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);

Last edited by mark_k; 25 September 2016 at 22:10.
mark_k is offline  
Old 25 September 2016, 22:30   #10
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
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 is offline  
Old 25 September 2016, 23:28   #11
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
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.
mark_k is offline  
Old 26 September 2016, 18:07   #12
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
Quote:
Originally Posted by mark_k View Post
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.

Quote:
Originally Posted by mark_k View Post
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.
Toni Wilen is offline  
Old 26 September 2016, 20:08   #13
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
Quote:
Originally Posted by Toni Wilen View Post
Added. Shaders also use clamping when accessing source texture.
Thanks, the line is gone.
Quote:
Originally Posted by Toni Wilen View Post
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 is offline  
Old 16 October 2016, 18:09   #14
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
Quote:
Originally Posted by Toni Wilen View Post
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?
mark_k is offline  
Old 17 October 2016, 12:52   #15
Tomislav
Registered User

 
Join Date: Aug 2014
Location: Zagreb / Croatia
Posts: 74
Quote:
Originally Posted by mark_k View Post
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.
Tomislav is offline  
Old 17 October 2016, 15:59   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
Quote:
Originally Posted by mark_k View Post
Could you add an option to force no-shader mode?
Added -nod3d9shader command line parameter.
Toni Wilen is offline  
Old 23 October 2016, 18:21   #17
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,482
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.
mark_k is offline  
Old 23 October 2016, 20:18   #18
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,561
Quote:
Originally Posted by mark_k View Post
-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.
Toni Wilen is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Pre-scaling before bilinear filtering for less-blurry image mark_k support.WinUAE 10 03 October 2016 22:01
Pre-Scaling before Bilinear Scaling? rsn8887 request.UAE Wishlist 6 05 September 2015 19:13
D3D point/bilinear setting trouble Ami_GFX support.WinUAE 4 10 December 2014 20:23
i need pal filter jim78b support.WinUAE 0 25 July 2013 14:54
New filter? Ian support.WinUAE 51 27 May 2013 14:10

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 07:51.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.34735 seconds with 12 queries