WinUAE 4.0.0 beta series

[mark_k]

With Windows desktop set to portrait orientation, start emulation in full-screen D3D9 mode. Press F12 to open the settings window. The Amiga display behind is messed up: rotated 90 degrees anti-clockwise and squashed horizontally (= vertically if monitor isn't physically in portrait orientation). Doesn't happen with 3.6.1.

[Toni Wilen]

Originally Posted by mark_k

It does actually seem to work as long as DWM is disabled (so realistically, only on Windows XP/Vista/7). Probably works best when the window occupies most of the screen height.

Why would anyone need lagless vsync in windowed mode? I don't like special cases ("you need to have this windows version and do this and that to support feature x")

Originally Posted by mark_k

With Windows desktop set to portrait orientation, start emulation in full-screen D3D9 mode. Press F12 to open the settings window. The Amiga display behind is messed up: rotated 90 degrees anti-clockwise and squashed horizontally (= vertically if monitor isn't physically in portrait orientation). Doesn't happen with 3.6.1.

Did you use exact same resolution and other settings? AFAIK thats how it works (driver needs to change some internal bitmap format to make it GDI compatible, causing fullscreen graphics to become temporarily corrupted. D3D fullscreen and GDI never mixed well). When I had multimonitor portrait config, it always did that.

[mark_k]

This config should show the problem:

http://www.media!fire.com/file/eudds5tzd1j2liu/A500_1.2_test_D3D9_FS.uae.zip

Fine with 3.6.1, problem with 4.0.0b5.

Something which may be related: line mode is "double, fields+", no vsync. With emulation running, on WinUAE 3.6.1 the display "shimmers" due to the different refresh rates of emulated PAL Amiga vs 60Hz PC. That's normal, to be expected. However with 4.0.0b5, the shimmering is different in vertical regions across the screen.

[Toni Wilen]

Problem is that there is no functional D3D9 changes so you need to have more proof and guarantee it isn't something weird going on your system. And which beta was first?

[mark_k]

I think that was a false alarm and the issue isn't beta-specific. The problem seems to happen (on Windows 10 1709) when "Disable full-screen optimisations" is checked in the program/shortcut properties. When not checked (which is the default), the Amiga display looks correct on pressing F12. Strange that the issue only happened in portrait orientation though.

[Dr.Venom]

@mark_k

Just curious, are you doing your tests with "disable fullscreen optimizations" set for the winuae.exe or not?

Apparently since the Fall Creators update fullscreen optimizations are forced on for all applications by default. When I did some testing very recently with winuae in d3d9 mode and fullscreen without vsync on a 60hz display I noticed there's no longer tearing. Apparently some sort of vsync is forced.

Ticking the "disable fullscreen optimizations" on the compatability tab for the WinUAE exe solved it (non-vsync mode in d3d9 showed tearing again).

Google search show a lot of hits for this feature. Apparently it has a benefit that the compositor is skipped in certain cases. But evidently it also forces vsync in situations where it shouldn't.

Fullscreen optimizations might be hurting your game performance in Windows 10

Why you should disable Fullscreen Optimizations on Windows 10


Here's a way apparently to disable it system wide instead of going through every exe (haven't tried it myself yet):

Disable Fullscreen Optimizations in Windows 10

@Toni

I'm not sure how (or whether) this may be affecting lagless vsync for certain users, but it seems the feature is aggressive enough that it may interfere in some way / situations at least.

Probably best thing to do for now is to make sure this "fullscreen optimizations" feature is disabled for the winuae.exe when doing lagless vsync testing in Windows 10. Just to be on the safe side...

[Toni Wilen]

Use D3D11, it should not affect DXGI fullscreen.

I haven't disabled it and both D3D9 and D3D11 works just fine. (It is also possible next soon officially released Windows 10 update improved it)

Note that as usual, I don't support any Windows hacks. Don't do it just because some web site says so.

[vagrant]

I checked the latest beta and lagless vsync looks to be working very nice under d3d11.. no more tearing & lower cpu usage

One new problem introduced. I use startup/cleanup args to change cpu settings on the fly when launching & exiting whd games. WinUAE will now crash & exit whenever I quit a game and attempt to switch from CE mode back to JIT & fastest possible.

[Toni Wilen]

Originally Posted by ED-209

I checked the latest beta and lagless vsync looks to be working very nice under d3d11.. no more tearing & lower cpu usage

One new problem introduced. I use startup/cleanup args to change cpu settings on the fly when launching & exiting whd games. WinUAE will now crash & exit whenever I quit a game and attempt to switch from CE mode back to JIT & fastest possible.

Attach your config + whdload.prefs
Does same happen in windowed mode? (without vsync)

[Dr.Venom]

Originally Posted by Toni Wilen

Use D3D11, it should not affect DXGI fullscreen.

Yes, preferably I would use D3D11 solely. There's an exception though for me to use D3D9 when using the CRT shader by guest.r (this one) on my Atom portable, as the shader

- looks better in d3d9 when used with the modified winuae.fx (mask applied in gamma space, see here). The modified winuae.fx doesn't seem to have an effect with d3d11.
- and more importantly the crt-guest-low-res.fx shader is much slower when used in d3d11 mode on the Atom compared to d3d9 mode, to the point where audio will start to crackle periodically in d3d11 mode, where in d3d9 mode it runs flawless. And I need to use this CRT shader when I'm away from my real CRT

Note that as usual, I don't support any Windows hacks. Don't do it just because some web site says so.

Preferably I would leave it on as you say. I do think MS goes one step to far by forcing some weird non-tearing / "vsynced" - latency inducing - swapping behaviour when using winuae d3d9 mode with vsync off.

I think my main gripe as a "power user" is that this is all done silently in the background and leave us guessing and spending hours to find out why an application is showing unexpected behaviour.

[vagrant]

Originally Posted by Toni Wilen

Attach your config + whdload.prefs
Does same happen in windowed mode? (without vsync)

Nope, windowed & no vsync works fine.
whdload.prefs is default, tooltypes used are;
executestartup=uae-configuration cpu_speed real cachesize 0 cycle_exact true
executecleanup=uae-configuration cpu_speed max cacheszie 8192 cycle_exact false

[Toni Wilen]

Don't enable RTG lagless vsync, it isn't implemented yet.

[vagrant]

Ok I tried with RTG completely disabled and still the same problem.
(I havn't been launching games via RTG screen anyway, it is early startup menu launcher via native output).

[Toni Wilen]

Originally Posted by ED-209

Ok I tried with RTG completely disabled and still the same problem.
(I havn't been launching games via RTG screen anyway, it is early startup menu launcher via native output).

Fixed. Lagless vsync timing method now changes depending on CPU mode (approx/ce or fastest possible) and it had missing check..

[vagrant]

Excellent, thanks Toni

[thomas]

Originally Posted by Toni Wilen

- Directory harddrives now use uaehf.device as a fake device driver (instead of non-existing uae.device)

The capacity returned by READ CAPACITY is doubled. For example a 32 GB harddrive appears as 64 GB.

TD_GETGEOMETRY does not fill the dg_TotalSectors and dg_Cylinders fields.

CMD_READ and SCSI READ(10) commands seem to always succeed although they cannot return any meaningful values. READ(10) even succeeds if the requested block is far beyond the disk size, for example it can read block 4294967295.

The sector size in the DosList entry does not match that returned by READ CAPACITY and TD_GETGEOMETRY. It's always 512.

[Toni Wilen]

Do you have test program? (This is how it works, final fixes only when good test case is available )

[thomas]

Originally Posted by Toni Wilen

Do you have test program? (This is how it works, final fixes only when good test case is available )

http://thomas-rapp.homepage.t-online.../hddreport.lha

It probably gives too much information for your needs, but that's how I found out about it. I can make a smaller program tomorrow.

[Toni Wilen]

Should be fixed now. (I didn't get wrong capacity but wrong blocksize probably could have caused it depending on size of drive)

[thomas]

Originally Posted by Toni Wilen

Should be fixed now.

Confirmed.