On the fly full screen <-> full window switching

[NewDeli]

Hi,


Sorry for posting two requests in a row. This is more or less a continuation of my better pausing thread.
As you may know, I usually play games in full screen and direct the signal onto another monitor. My problem is that I sometimes need to pause the game to do stuff on the main monitor. Inherently to DirectX, and according to Toni, it's not possible to maintain full screen when focus is lost.
Probably not many people care, but I think it's nice to keep an eye on the exact frame at which the game was paused.

There is a known workaround : Hit F12, switch to full-window, then pausing the game then alt+tabbing won't minimize the screen.
Then I thought :
What about being able to do on the fly full screen <-> full window switching ?
Reading further explanations would be tedious for most of you at this point, but I need to say a few words about "on the fly" mode switching :
Via assigning a button through the input panel, I successfully manage to switch to window mode when playing full screen and pause nicely (0x20C), but then the screen "jumps" to the TFT.
Apparently, the option to do this with full-window (on the fly, I'll repeat) is not yet implemented (I tried to do it using the custom events).

[TCD]

Originally Posted by NewDeli

Hi,

can there be an input event to switch between fullscreen and fullwindow like 'Toogle fullscreen/windowed'? Thanks

Fixed

[NewDeli]

Nice fix TCD, but it doesn't mention that I tried to do the switching using the custom events. Should it have worked this way, request would have been dismissed with an "insufficient testing" comment !

You may try it if you want to, set an unused button to the following to custom event :

"gfx_fullscreen_amiga=fullwindow"

[Toni Wilen]

This needs to support all 3 possible mode switch combinations:

windowed <> fullscreen
windowed <> fullwindow
fullwindow <> fullscreen

and preferably without any new GUI elements.. Not so simple.

[NewDeli]

Is it necessary to support window <> fullwindow too ? I mean : Do you think some people would be interested or do you consider it should be implemented too to make the switching options from the input panel more complete.
In either case, since it's possible to use the drop-down list from the Display tab for any combination, I don't think a GUI modification should be necessary.

[Toni Wilen]

Originally Posted by NewDeli

Is it necessary to support window <> fullwindow too ?

Yes, it is either all or nothing

[NewDeli]

I think I've Deli'd WinUAE with my unusual input combinations . Well, sort of.

Here's what I did :

• Used the above mentioned custom event
• Used "gfx_fullscreen_amiga=fullwindow" in slot 3 (that's just the way custom event are assigned via the input panel)
• Assigned pause emulation to another of my gamepad button
• Started my custom Workbench in full window mode as usual
• Started Menace preinstalled in full screen mode as usual
• pulled the right trigger to pause emulation (7th and 8th buttons are right & left triggers)
• pulled the left trigger to attempt again to toggle full screen <-> full window

... it works both ways, Toni (back and forth) ! Native screen turns black, but I just need to unpause with right trigger (emulation is not broken), eventually pause again, then I may safely untrap the mouse... well, almost, read on, plz.

Now, for the really weird part :
In my config, I disable the sound when emulation is inactive. Well, if I leave the tick on, once I pull the mouse cursor away from the native screen (once it appears on the TFT, in other words), the (unpaused) emulation speed increases like if it was on acid.

I won't have to deal with a bloody minimized screen each time I need to check GUI settings / use the screen capture program / read an online walktrough on the TFT ! Hurray !

I have attached my A1200 config and winuaelog in case you can do smth useful with it.

[Toni Wilen]

Originally Posted by NewDeli

In my config, I disable the sound when emulation is inactive. Well, if I leave the tick on, once I pull the mouse cursor away from the native screen (once it appears on the TFT, in other words), the (unpaused) emulation speed increases like if it was on acid.

This does not really explain the situation. Windowed? Fullwindow? You press ALT-TAB and/or middle mousebutton to uncapture the mouse and speed changes?

Exact steps to duplicate it please.

[NewDeli]

It's rather simple actually, but first things first : Thread's title is slightly misleading, as it's not on the fly switching anymore.
I am not sure this could be duplicated in single display mode.
OK, fortunately I didn't use Alt+tab to restore a minimized screen, nor did I have to bring the GUI upfront (that's what I really mean by on the fly).

If one pauses emulation, it becomes possible to switch from full screen (I use full screen + autoVsync) to full window as I described, with a temporary black screen as a minor side effect.
From full window (with the game unpaused and Disable sound When Inactive ticked), press middle mouse button, then drag the mouse cursor outside the screen (sound should be disabled at this point) -> the speed changes dramatically. Speed gets back to normal when the screen regains focus.

[Toni Wilen]

Originally Posted by NewDeli

From full window (with the game unpaused and Disable sound When Inactive ticked), press middle mouse button, then drag the mouse cursor outside the screen (sound should be disabled at this point) -> the speed changes dramatically. Speed gets back to normal when the screen regains focus.

Can you duplicate it without switching to fullscreen first?

[NewDeli]

Originally Posted by NewDeli

I am not sure this could be duplicated in single display mode.

To duplicate in single display mode, you just need to have another program or explorer window in the background, then alt+tab to give it focus.

I was able to reproduce with alt+tab instead of middle button clicking and with the game started in full window, then full screen, then full window again (Trying with full screen wouldn't make sense as I would not be able to see the screen behavior with lost focus, I hope we agree on that).
Of course, full window
+ lost focus
+ disable sound when inactive ticked
+ none of my special input triggering
works as intended .

That would be nice if you fixed the bug of course (wild guess : may have something to do with audio brutally unsync'ed to screen refresh rate); but it would be even nicer if you managed to cook something to process my initial request out of it.

[Toni Wilen]

Sorry but your explanation is still too confusing. Just exact steps, nothing else, nothing more, please.

[NewDeli]

Version of WinUAE used : 2.1

Here's what I did :
a. Concerning custom input events

• Assigned button 6 of my gamepad with

  "gfx_fullscreen_amiga=fullwindow"

  in slot 1
• Used

  "gfx_fullscreen_amiga=true"

  in slot 3

b. Concerning normal input events

• Assigned pause emulation to button 7

c. Concerning the pri. & Extensions tab

• All 3 run at priority drop-down boxes set to normal
• disable sound when Inactive ticked

then

• Started custom Workbench in full window mode as usual (RTG mode set to full window)
• Started Menace preinstalled in full screen mode +AutoVsync as usual (Native mode set to Fullscreen + AutoVsync)
• Paused emulation after the game had entered demo mode
• Managed to toggle full screen <-> full window by using the aforementioned assigned control (button 6)

State of the emulation at this point :
Paused, Full window mode, Black screen

To reproduce the bug :

• Press button 7 again (resumes emulation)
• Make the emulation lost its focus (middle mouse click + dragging the mouse cursor to another monitor if you can or alt+tab to give focus to some other program)

State of the emulation at this point :
Full window mode, no sound, crazy speed

[Toni Wilen]

It is still too complex and surely it can be duplicated without that many steps. Finding the shortest way to duplicate bugs is an art

Sorry but I am too lazy to attempt above steps.

[NewDeli]

It looks complex, but it isn't. It's just a matter of starting the emulation in Vsync full screen mode, pausing it before switching to full window with the assigned custom event, then finally alt+tabbing.

The reason why I choose to assign pause emulation to a gamepad button is because I like to do all of the above from the comfort of my gamepad. You may pause emulation the way you usually do, of course.
Just make sure you've ticked Disable sound when Inactive in the first place, alt+tab to something and there you go.

# of discarded steps this time :
2 (custom event to restore full screen & input event for pausing emulation). Can't do much shorter I am afraid.

AFAIK, there's nothing in WinUAE to attempt to force full window without showing up the GUI, so I had to come with something imperfect to mimicking it.

If an input event corresponding to switching to full window (even if it did nothing more than 1. pause emulation and 2. send the equivalent of 0x20c for switching to full window 3. resume emulation) was implemented in one of the next betas, then I guess booting the workbench to test it could be the 3rd discarded step (in other words, reproducing would become possible without uae-configuration program).

Needless to say : Easier said than done.

[NewDeli]

As expected, the speed bug doesn't occur when switching from "normal" full screen (not Vsync'd) to full window.

I thought of recording a few seconds of the output to show it to you "live", but the internal recorder manages to adjust its framerate to the emulation's, resulting in the speed boost being negated in the footage I made initially !

Here is it, grabbed with my digital camera :
http://.com/files/39017606...CrazySpeed.AVI
(crank up the volume a little)

I attached a snapshot of the main settings, so hopefully you or someone else can shed some light.

[Toni Wilen]

Vsync should have been first thing to say..

Does http://www.winuae.net/files/b/winuae.zip fix it?

[NewDeli]

I suppose the new input panel and the way it is tied to game ports panel is work-in-progress :
I found a few problems with it. To activate Configuration #1, I had to untick, then tick again Configuration #1... (probably better to continue this in beta thread)

Other than that, yep, new beta fixes the speed issue, thanx.

Now I mean to ask, do you think my experimentation results could be used to implement missing switching options via input panel or is it simply too dirty a hack ?

[Toni Wilen]

Originally Posted by NewDeli

I suppose the new input panel and the way it is tied to game ports panel is work-in-progress :
I found a few problems with it. To activate Configuration #1, I had to untick, then tick again Configuration #1... (probably better to continue this in beta thread)

Other than that, yep, new beta fixes the speed issue, thanx.

Now I mean to ask, do you think my experimentation results could be used to implement missing switching options via input panel or is it simply too dirty a hack ?

Keyboard can stop working (gets disabled or there is no mappings at all) in next beta if you have saved new configuration using 2.2 betas 1-3 and configuration #1-#3 is enabled.

[NewDeli]

I'll watch for that (but would rather use betas for "production" when the next stable completion is getting near).

That leaves some of this thread's questions unanswered, but it's all right, I know you know what you're doing or not, and why, most of the times.