WinUAE 3.6.0 beta series

[Toni Wilen]

Originally Posted by Toni Wilen

Hmm.. It looks like emulation is still running normally or it hung inside DXGI Present() method.

If you boot some a game or demo that plays music and then press alt-tab, does music continue? (make sure pause when inactive and minimized is not ticked)

Does task manager also show about same CPU usage after and before alt-tab?

A game like Hyris running has 11-13% CPU usage. After pressing Alt-Tab the music stops and the task manager shows 4-7% CPU usage.

Does today's winuae.7z work better? (I removed threaded Present() calls, it is just quick test, performance may be worse in some vsync modes temporarily)

[Zilog]

Originally Posted by Toni Wilen

I can't see anything wrong happening in the video? Did you record it using built-in recorder? It may not see the difference depending on where it happens. (at least make sure record before capturing is not ticked)

Does anything appear in the log when the flickering line appears? (run with -log command line parameter to see it in real time)

Does it move with the image when using Filter panel adjustments?

A) I Have use a built in recorder present in winuae (no external program)
B) I have try with no filter active, and i register the video, where there is a problem appears and not appears the line.
C) I have register another video with the winaue 3.5 where all is perfect.
D) I have put a log file of winaue 3.6

My Idea is that the problem is in the "Remove interlace artifacts" don't function correctly...the last bottom line stay in interlace mode....but is my idea.

I Dream that you now see the problem with this videos.
You see alway a last line blue bottom in the screen of video
You see beeter the problem if not use video in full screen mode.

Thanks a lot tony.

[Retro-Nerd]

Does today's winuae.7z work better? (I removed threaded Present() calls, it is just quick test, performance may be worse in some vsync modes temporarily)

It works indeed better but not 100%. I can finally use Alt-Tab to switch through the open tasks. But if i switch back to the WinUAE task the screen is black. Pressing F12 then shows the GUI again and selecting "OK" switches properly back to WinUAE fullscreen. Nearly fixed i would say.

edit: Ah, the last black screen is caused by a custom shader. Seems like all the CRT guest shaders are the issue.

[hexaae]

Originally Posted by Toni Wilen

Was JIT enabled? This crash dump seems like it was which makes it mostly useless.

Yep, JIT is on in my cfg... Seems quite unstable with JIT on

EDIT:
but the strange thing is that emu didn't even started. Only ran WinUAE b16 with GUI open and left on the Windows desktop...

[Toni Wilen]

Originally Posted by Retro-Nerd

It works indeed better but not 100%. I can finally use Alt-Tab to switch through the open tasks. But if i switch back to the WinUAE task the screen is black. Pressing F12 then shows the GUI again and selecting "OK" switches properly back to WinUAE fullscreen. Nearly fixed i would say.

edit: Ah, the last black screen is caused by a custom shader. Seems like all the CRT guest shaders are the issue.

Do you mean shader worked initially but after alt-tab if showed only black screen?

Check logs for error messages.

Originally Posted by Zilog

My Idea is that the problem is in the "Remove interlace artifacts" don't function correctly...the last bottom line stay in interlace mode....but is my idea.

It is! I think there was two problems, first was d3d11-only, second was interlace artifacts related. But you said you didn't last line flickering when using d3d9 mode?

[Retro-Nerd]

Originally Posted by Toni Wilen

Do you mean shader worked initially but after alt-tab if showed only black screen?

Check logs for error messages.

Yes, exactly. Logs attached.

[Zilog]

Originally Posted by Toni Wilen

....

It is! I think there was two problems, first was d3d11-only, second was interlace artifacts related. But you said you didn't last line flickering when using d3d9 mode?

The Problem ARE NOT PRESENT with "Diretct Draw" or "Direct 3d 9" with WINAUE 3.5

The Problem ARE ALWAYS PRESENT with "Direct Draw" or "Direct 3d 9" or "Direct 3d 10" with WINAUE 3.6

[Toni Wilen]

Originally Posted by Retro-Nerd

Yes, exactly. Logs attached.

ResizeBuffers 887a0001

There was D3D11 object leak that may explain this (or not, I can't duplicate it but it probably depends on GPU model/manufacturer). Does winuae.7z now work?

Originally Posted by Zilog

The Problem ARE NOT PRESENT with "Diretct Draw" or "Direct 3d 9" with WINAUE 3.5

The Problem ARE ALWAYS PRESENT with "Direct Draw" or "Direct 3d 9" or "Direct 3d 10" with WINAUE 3.6

Should be fixed now.

[Retro-Nerd]

There was D3D11 object leak that may explain this (or not, I can't duplicate it but it probably depends on GPU model/manufacturer). Does winuae.7z now work?

No, still the same.

[Toni Wilen]

Originally Posted by Retro-Nerd

No, still the same.

Does all shaders cause it or only some? Does it also happen if you don't have any shaders but enable only mask and/or d3d scanlines?

[Zilog]

Originally Posted by Toni Wilen

Should be fixed now.

YES!!!
Now Function corretly with all directx: draw, d3d 9 and d3d 10!!!

Very Very Thanks for your patience.

Thanks a lot!

[Retro-Nerd]

Originally Posted by Toni Wilen

Does all shaders cause it or only some? Does it also happen if you don't have any shaders but enable only mask and/or d3d scanlines?

Masks are fine, D3D scanlines and the normal filters too (PAL, SuperEagle...). Seems only Guests CRT shaders are affected, haven't tried his xBRZ stuff yet.

[Toni Wilen]

Originally Posted by Retro-Nerd

Masks are fine, D3D scanlines and the normal filters too (PAL, SuperEagle...). Seems only Guests CRT shaders are affected, haven't tried his xBRZ stuff yet.

Does it also happen in windowed mode after resizing the window with mouse? (It also uses same ResizeBuffers() call)

[Retro-Nerd]

The windowed mode shows a bit of a black flickering during the resize, but i get no black screen when the resize in finally done.

[Toni Wilen]

Originally Posted by Retro-Nerd

The windowed mode shows a bit of a black flickering during the resize, but i get no black screen when the resize in finally done.

Yeah, flickering/slow resize is normal. Fullscreen only problems are annoying..

Could you redownload winuae.7z, then do following (use -logflush again): enter fullscreen, wait few seconds, enter gui, exit gui, wait few seconds, alt-tab, try to restore from alt-tab (=blank screen). Quit. winuaelog.txt only needed.

[Retro-Nerd]

[Toni Wilen]

What about now? (include log again, even if it works now)

[Retro-Nerd]

Looks like you've fixed it.

[Toni Wilen]

Originally Posted by Retro-Nerd

Looks like you've fixed it.

Great but it isn't really fixed, it just reinitializes display if ResizeBuffers() returns an error. Which seems to succeed just fine so it is good enough workaround for this problem (which sounds like some weird driver issue if it only happens with some shaders).

[Retro-Nerd]

Must be D3D11 specific then, since in D3D9 there are no issues with custom shaders and alt+tab. Anyway, it works for now as expected and i will tell you if something break in further updates.