English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 29 October 2017, 12:58   #61
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,772
Did you use updated vertex shader? (post #49). If yes, then someone needs to find fixed shader/projection calculations. I don't want to know.
Toni Wilen is offline  
AdSense AdSense  
Old 29 October 2017, 14:02   #62
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 322
Quote:
Originally Posted by Toni Wilen View Post
Did you use updated vertex shader? (post #49).
Unfortunately makes no difference.. (i've changed it in the file "_winuae.vs"). Does 1:1 mapping work for you in single line mode? I've tested this now on my LCD with NVidia GTX1070.

Quote:
Originally Posted by Toni Wilen View Post
If yes, then someone needs to find fixed shader/projection calculations. I don't want to know.
I don't think I'll be able to be of much help with that . Sadly without 1:1 mapping this is not going to work for CRT setups.
Dr.Venom is offline  
Old 29 October 2017, 19:17   #63
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,772
That was the whole point of finding Direct3D11 2D example that is usable. I knew it wasn't going to be that simple because most examples are not designed for perfect 1:1 pixel mapping and 2D examples are rare.
Toni Wilen is offline  
Old 29 October 2017, 20:05   #64
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 322
Quote:
Originally Posted by Toni Wilen View Post
That was the whole point of finding Direct3D11 2D example that is usable. I knew it wasn't going to be that simple because most examples are not designed for perfect 1:1 pixel mapping and 2D examples are rare.
Yeah I understand. Is there a reason for you to think we should be looking for the issue in the shader / projection calculation (and not something else), since double line mode seem to be fine?
Dr.Venom is offline  
Old 29 October 2017, 21:56   #65
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,609
Currently you use DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL. On Windows 10 DXGI_SWAP_EFFECT_FLIP_DISCARD could be more optimal?

That's assuming you don't want to experiment with using dirty rectangles to optimise rendering (telling DXGI which parts of the buffer have changed, which could make use over RDP better/feasible).
mark_k is offline  
Old 29 October 2017, 21:59   #66
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,772
RTG needs partial updates. Currently it flickers because it is not yet handled properly.
Toni Wilen is offline  
Old 30 October 2017, 15:22   #67
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 322
Toni, could the following be causing the "blurriness" issue in single line mode?

Half-Pixel Offset in DirectX 11


Some quotes:

Quote:
But it turns out that in Direct3D 10/11, the value of SV_Target for first pixels on the screen is not (0, 0), (1, 0), but (0.5, 0.5), (1.5, 0.5)!
Quote:
Therefore to sample texture based on pixel position, it's enought to divide it by screen resolution.
Code:
Texture2D g_Texture : register(t0);
SamplerState g_SamplerState : register(s0);

cbuffer : register(b0) {
    float2 g_ScreenResolution;
};

void PixelShader(float2 Position : SV_Position, out float4 Color : SV_Target)
{
    Color = g_Texture.Sample(g_SamplerState, Position / g_ScreenResolution);
}

Last edited by Dr.Venom; 30 October 2017 at 15:30.
Dr.Venom is offline  
Old 30 October 2017, 19:14   #68
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,772
Explanation makes sense but the shader fix does not (at least not for me). Not enough information.
Toni Wilen is offline  
Old 30 October 2017, 21:23   #69
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 322
With regards to the half pixel offset possibly being the culprit in single line mode; looking at the corsair tekst in single line mode enlarged (fourth picture in post #60 ), it seems that it may be interpolated / sampled just between the lines. I.e. the vertical white stripes of the letters seem correct, but the horizontal white pixels / lines in the "corsair" text are all grey.

Is the input to the shader by any chance an odd number of lines in single line mode, but an even number of lines in double-line-mode? Just guessing as to what is happening in single line mode, and why it seems to be correct in double line mode..
Dr.Venom is offline  
Old 30 October 2017, 23:14   #70
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 322
Quote:
Originally Posted by mark_k View Post
Just updated AMD graphics driver to 17.Q4 from here. Now in D3D11 mode CPU% reads about 650%, FPS about 9.

I'll try a clean driver install to see if that fixes it. If not it looks like AMD broke something since 17.Q3.1.
Not sure if you still have this issue, but I've just tested latest winuae beta of today with AMD RX480 card and latest driver (Crimson ReLive Edition 17.10.3, 10/27/2017, W10 64-bit) and I'm not experiencing any slowdown, it's running 50fps with CPU reading near 0%.
Dr.Venom is offline  
Old 01 November 2017, 14:16   #71
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 322
I created a simple test picture with dpaint that shows a white single pixel line square and cross on black background. (Upped to the zone as a bootable adf "testpicture.zip").

This may be helpful to more easily check whether there are display irregularities (maybe also useful when implementing integer scaling modes..)

It clearly shows the difference between double line mode and single line mode. Double line mode is showing the picture perfectly.

In single line mode all horizontal lines are grey (vertical lines are correct). This strongly suggests there's a half pixel offset in the y direction, where color is sampled as an average of white and black, resulting in the grey lines.

From what I read D3D11 already applies the half-pixel offset (that was explicitly needed in d3d9) in the background, so it's not needed for D3D10 and 11. You don't by any chance have a half-pixel offset left over somewhere (from d3d9 code) in the display code?
Attached Thumbnails
Click image for larger version

Name:	double-line-mode.png
Views:	27
Size:	11.4 KB
ID:	55252   Click image for larger version

Name:	single-line-mode.png
Views:	25
Size:	9.6 KB
ID:	55253  
Dr.Venom is offline  
Old 01 November 2017, 15:06   #72
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,772
As I already said: all the maths is from that 2d d3d11 example. I don't want to know how matrixes and shaders exactly work, I want ready made perfect example solution.

EDIT: and it is not specific to vertical, odd width or height causes it, and some other "not exactly aligned" values.

Last edited by Toni Wilen; 01 November 2017 at 20:39.
Toni Wilen is offline  
Old 02 November 2017, 21:59   #73
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,609
Is there any change if you vary window size slightly? I remember seeing extra/missing lines in D3D9 mode when window width/height is odd.

Adding an option to use the WARP renderer for D3D11 could be useful. Both to compare with how hardware drivers render, but also because it allows D3D11 mode to be used anywhere, e.g. with no graphics driver installed, in a VM which doesn't support hardware 3D acceleration, on some old PC with pre-DX9-class graphics card etc. I wonder how non-vsync/with-tearing would work with WARP...
Edit: The WARP renderer might be used by default if there's no suitable hardware/driver. But a manual option would be good for testing.

Last edited by mark_k; 02 November 2017 at 23:20.
mark_k is offline  
Old 04 November 2017, 15:01   #74
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,609
There are two ways to make WinUAE use the WARP device at the moment.

1. Install the Windows SDK then run dxcpl.exe. Click Edit List... and add the WinUAE executable to the list. Check the Force WARP box and click Apply.

2. If you don't want to install the Windows SDK, you can patch WinUAE to use the WARP device. Note that these details are for the current unofficial-beta 32-bit winuae.exe. Official betas are built with different optimisation level so they may not apply there.

This patch effectively changes the source code line
pD3D11CreateDevice(NULL, D3D_DRIVER_TYPE_HARDWARE, NULL, cdflags, levels, 2, D3D11_SDK_VERSION, &d3d->m_device, NULL, &d3d->m_deviceContext);
to
pD3D11CreateDevice(NULL, D3D_DRIVER_TYPE_WARP, NULL, cdflags, levels, 2, D3D11_SDK_VERSION, &d3d->m_device, NULL, &d3d->m_deviceContext);

Using a binary file editor, load your backup/renamed winuae.exe into it. Search for the byte sequence
6A 20 6A 00 6A 01 6A 00
Replace the 01 with 05 so it becomes
6A 20 6A 00 6A 05 6A 00


Both methods seemed to work OK for me. Windowed and full-window modes work (no tearing, sadly). Full-screen doesn't. Maybe that's because WinUAE enumerates only physical hardware adapters for full-screen mode??? Or perhaps the WARP device just doesn't support full-screen mode.


Dr.Venom: Would be interested to hear whether you see the same issues with the WARP device...
mark_k is offline  
Old 04 November 2017, 15:38   #75
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 322
Quote:
Originally Posted by mark_k View Post
Dr.Venom: Would be interested to hear whether you see the same issues with the WARP device...
I patched the winuae.exe according to your suggestion with a binary editor. Checked whether full-screen worked and it no longer does (when selecting full-screen, it reverts immediately to windowed)..

With the WARP patched exe the same issue as posted in #71 occurs for me, so no change.

I imagine you're seeing the same issue in single line mode? (You could use the testpicture.zip from the zone if you haven't done so already.)
Dr.Venom is offline  
Old 04 November 2017, 15:57   #76
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,609
Ah yes, I see the problem both with hardware and WARP renderers. So it's not driver-specific, but whether it occurs does seem to depend on the Amiga display mode. I didn't see it with HIGHGFX or SUPER72 modes, but did with PAL.
mark_k is offline  
Old 04 November 2017, 21:04   #77
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,609
In UpdateBuffers() you have:
Code:
float left, right, top, bottom;
float positionX, positionY;

positionX = (d3d->m_screenWidth - d3d->m_bitmapWidth) / 2.0 + d3d->xoffset;
positionY = (d3d->m_screenHeight - d3d->m_bitmapHeight) / 2.0 + d3d->yoffset;

// Calculate the screen coordinates of the left side of the bitmap.
left = (float)((d3d->m_screenWidth / 2) * -1) + positionX;

// Calculate the screen coordinates of the right side of the bitmap.
right = left + (float)d3d->m_bitmapWidth;

// Calculate the screen coordinates of the top of the bitmap.
top = (float)(d3d->m_screenHeight / 2) - positionY;

// Calculate the screen coordinates of the bottom of the bitmap.
bottom = top - (float)d3d->m_bitmapHeight;
Now I think left, right, top and bottom are supposed to be whole-number floats, e.g. 123.0, not 123.5.
Let's plug some numbers into the above:
screenWidth = 400, screenHeight = 300, bitmapWidth = 376, bitmapHeight = 283
(assume xoffset and yoffset are 0 here)
Then:
positionX = (400 - 376)/2.0 = 24/2.0 = 12.0
positionY = (300 - 283)/2.0 = 17/2.0 = 8.5
left = (400/2 × -1) + 12.0 = -200.0 + 12.0 = -188.0
right = -188.0 + 376.0 = 188.0
top = (float)(300/2) - 8.5 = 150.0 - 8.5 = 141.5
bottom = 141.5 - 283.0 = -141.5

Notice how top and bottom are not whole numbers.

How about reworking the calculations like this:
Code:
// positionX and positionY no longer used

// Calculate the screen coordinates of the left side of the bitmap.
left = d3d->xoffset - (float)((d3d->m_bitmapWidth + 1)/2);	// +1 to round properly, probably doesn't matter???

// Calculate the screen coordinates of the right side of the bitmap.
right = left + (float)d3d->m_bitmapWidth;

// Calculate the screen coordinates of the top of the bitmap.
top = d3d->yoffset - (float)((d3d->m_bitmapHeight + 1)/2);	// +1 to round properly, probably doesn't matter???

// Calculate the screen coordinates of the bottom of the bitmap.
bottom = top - (float)d3d->m_bitmapHeight;

Last edited by mark_k; 04 November 2017 at 21:29.
mark_k is offline  
Old 04 November 2017, 21:33   #78
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,772
I already did that few days ago. No change.
Toni Wilen is offline  
Old 04 November 2017, 22:26   #79
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,609
Hmm, OK next guess...
Code:
// Create a texture sampler state description.
samplerDesc.Filter = D3D11_FILTER_MIN_MAG_MIP_LINEAR;
samplerDesc.AddressU = D3D11_TEXTURE_ADDRESS_WRAP;
samplerDesc.AddressV = D3D11_TEXTURE_ADDRESS_WRAP;
samplerDesc.AddressW = D3D11_TEXTURE_ADDRESS_WRAP;
MSDN says: "D3D11_FILTER_MIN_MAG_MIP_LINEAR - Use linear interpolation for minification, magnification, and mip-level sampling."

Have you tried changing that to D3D11_FILTER_MIN_MAG_MIP_POINT instead? (But there's probably still an off-by-half-a-pixel error somewhere.)

Also (not related to this problem), similarly to D3D9, should probably use D3D11_TEXTURE_ADDRESS_MIRROR or D3D11_TEXTURE_ADDRESS_CLAMP for AddressU and AddressV to avoid "texture wraparound shadow".
mark_k is offline  
Old 06 November 2017, 22:26   #80
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,772
samplerDesc.Filter = filterd3d->gfx_filter_bilinear ? D3D11_FILTER_MIN_MAG_MIP_LINEAR : D3D11_FILTER_MIN_MAG_MIP_POINT;

Seems to fix it, at least it looks better now. (WRAP -> CLAMP also changed). (RTG is also fixed)
Toni Wilen is offline  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
A method for further improving latency (input lag) in FS-UAE Dr.Venom support.FS-UAE 4 12 September 2017 17:49
Photos and/or measurements of Amiga 500 bLAZER request.Other 143 29 June 2017 18:42
Optimizing DirectX apps for low latency input and longer battery life Dr.Venom support.WinUAE 2 24 April 2017 10:40
What are the measurements of Amiga 1200 case screws Tallrot support.Hardware 9 15 June 2016 11:04
A1200 and B1230 Voltage Measurements for Dummies? Jarin support.Hardware 2 23 January 2014 11:02

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 01:22.


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