WinUAE 4.0.0 strange issue with Fullwindow mode and Yo Joe
 

Repro steps:

set Display mode: Fullwindow (I have g-sync and select nothing else)
run Yo Joe WHDLoad
while playing hit F12 or switch Windows screen with LALT+TAB
return to the game: bottom display with energy won't be updated anymore

Unreproducible if you run the game in Fullscreen mode

Do I really need to say what is missing? (in case of full window, not even config file is enough)

https://nofile.io/f/mxcsBbubq9y/winuaelog.7z

There is no strange crash or whatsoever, but for some reason game gets corrupt and energy won't move anymore just switching screen with ALT+TAB or calling WinUAE UI (F12), and going back to the game...

I didn't mean to not include config file. Filter settings are also very important.

I assume it is D3D11 only? It is usually good idea to try some obvious settings to narrow it down a bit, makes it much easier for me. It also always good idea to assume that no one else can duplicate it easily. It is very very common.

EDIT: Photo of the screen would also help. If you take a screenshot (using winuae's screenshot function), does it include missing parts?

No, it happens also in DX9 rendering mode and there is no graphical corruption. Something in the game code gets corrupt, and only if Fullwindow is used and you switch screen or press F12 while in-game...

Can't you reproduce it starting "Yo Joe" WHDLoad from one of your testing WB env? It looks like a generic bug... I'll have to do a mini-boot in this case…

Checked old WinUAE versions and this bug starts with 3.3.0, no issue with 3.2.0 and before pressing F12 in game and going back to play in Fullwindow… and yes it's the first time I see this kind of bug thanks to Yo Joe WHDLoad (i.e. other games seem unaffected).

Oh god, please don't mention that all was ok in v2.5.x again; I can't take it anymore :rolleyes

Anyway, doesn't happen here...

I'm using WinUAE v4.0.0 but not a crazy / unstable NG OS like you... all from floppy disk and perfect :agree

Instead of blaming WinUAE, possible that it's your OS setup or as a last resort, WHDLoad?

It being game weirdness can be confirmed easily: use built-in screenshot with "capture before filtering" ticked. This takes screenshot directly from internal buffer that chipset emulation fills, before it goes to d3d texture etc..

https://image.ibb.co/hWnUaT/image.png
Like this? Never used before these… And what is the key combo to take the screenshot?

What's strange in this bug?
- rare memory corruption due to simple pause/unpause emulation ONLY in Fullwindow mode (just with Yo Joe WHDLoad???)
- versions <=3.2.0 of WinUAE were not affected

There's nothing unstable here :P All my reported issues have been proven bugs in the end, fixed by Toni :bowdown… weird and under rare conditions but yet true bugs ;)

I think the real problem is that there are very few WinUAE users with advanced cfg and fully fledged emulated WB ;) Most users run it like MAME just for gaming with ADFs/IPFs or have very minimal WB3.1 AGA installation just as a front-end to launch games/demos… In the end, most users simply don't care (=reboot et voilà) or don't even notice the bugs ;P

@Toni
After many settings tested and activated one by one, I've found how to reproduce it!

Requirements:
Fullwindow native + Z3 RTG + DEVS:Monitors\uaegfx & Misc settings: Shared clipboard

At this point you can launch Yo Joe WHDLoad and while in game press F12, then Cancel to return to game, get hit by enemies and see the energy bar stuck. If I disable Z3 RTG or Shared clipboard before I launch the game from WB, it's ok.
If you need I can PM a mini-boot test partition + cfg to quickly reproduce it...

It's "Print Screen"/"SysRq" key by default and you can remap to other key(s) in "Input" part of configuration if needed.

Does winuae.7z fix it? (That was nicely narrowed down to few options!)

It does! You're the n°1! :great

Great.

Technically this wasn't a bug. Clipboard emulation pushed Windows clipboard data to Amiga side each time window focus changes but if whdload (or any other program) has taken over the system, memory may be moved around and if clipboard buffer was used for other purposes..

Now clipboard data is only copied if uae boot rom "heartbeat" signal (uae boot rom vblank interrupt is running = AmigaOS is alive) is detected.

Unfortunately today I've reproduced this again (!).
Repro steps:
as above, but… press F12 (will open on Fullwindow screen), press ALT-TAB to switch to win-desktop (at this point emulation will continue in bg even though the frontmost screen is Win desktop, just like if I've pressed Cancel from GUI), and click on the WinUAE icon in the bottom Windows taskbar to return to WinUAE Fullwindow screen. Same bug with Yo Joe: stuck bottom panel (energy, weapons selection)…

This is the Pri & Ext. settings I use:
https://image.ibb.co/hDbkKo/image.png

EDIT:
Just additional information: Misc.: Main Window always on top, GUI window always on top, Minimize when focus is lost. And of course Clipboard sharing.

… and I've found also another iconification/window issue: repeating repro-steps above while playing Yo Joe WHDLoad + Misc.: Don't show taskbar button, Don't show notification icon, this is the result:
https://preview.ibb.co/bRz85T/image.png
Can't switch back to WinUAE and I have a mini-window in the bottom left...

It probably has nothing to do with the game. Always attempt to duplicate these kind of problems with basic A500 config without no disks.

About clipboard: download winuae.7z and trigger the bug and then attach winuaelog.txt. (Make sure some text is in windows clipboard before starting winuae)

Yep, it seems an issue with internal clipboard handling and Windows VS WinUAE on windows focus swap… funny it shows up this way with this game.
https://nofile.io/f/pFhPOeROQkD/winuaebootlog.7z here is it, following steps in #15

What about today's winuae.7z? If it still happens, I probably have to leave it for later because I plan to do quick 4.0.1 fix release soonish that fixes few stupid bugs.

You never stop Toni ;)