[GEN][ZH] Fixed crash when alt-tabbing out of the game

[aliendroid1]

As noted in the original comment, the game was intended to switch to windowed mode when alt-tabbing out. However, the code mistakenly passed the current window mode instead, resulting in no actual change.

This update corrects the parameter to 1, explicitly enabling windowed mode and preventing the crash.

Closes #28

[Mauller]

Did you test this with the game set to the same resolution as the desktop?

[aliendroid1]

Did you test this with the game set to the same resolution as the desktop?

Same and different both for both full screen mode and -win shortcut. Is it still crashing for you?

[Mauller]

Same and different both for both full screen mode and -win shortcut. Is it still crashing for you?

No it didn't crash when i tested it, but i heard that the problem happens primarily when the game and desktop resolution match.

The game would pause when i alt+tab and continue again once i brought it back into focus.

It only crashed on me due to a different problem while debugging.

[aliendroid1]

Same and different both for both full screen mode and -win shortcut. Is it still crashing for you?

No it didn't crash when i tested it, but i heard that the problem happens primarily when the game and desktop resolution match.

The game would pause when i alt+tab and continue again once i brought it back into focus.

It only crashed on me due to a different problem while debugging.

Before the change, for me on window 11 it would always crash regardless of the resolution. It would sometimes be fine the first time I switched focus out of the game using alt-tab or the windows key and I'd still be focus back on to the game but it always crashed if I switched focus after this.

[Mauller]

Before the change, for me on window 11...

Ah im running 10 still, so i might not as easily see the issue occur.

[aliendroid1]

Before the change, for me on window 11...

Ah im running 10 still, so i might not as easily see the issue occur.

Did you try without the Genpatcher fixes?

[Mauller]

Before the change, for me on window 11...

Ah im running 10 still, so i might not as easily see the issue occur.

Did you try without the Genpatcher fixes?

I don't run gentool or genpatcher stuff, just our code from the repo.

[xezon]

Unclear if this fix is correct. We need to understand what exactly crashes first, then decide on fix. Start with posting crash callstack and observations in #28.

[aliendroid1]

Unclear if this fix is correct. We need to understand what exactly crashes first, then decide on fix. Start with posting crash callstack and observations in #28.

Done. I'm certain this fix is correct and I've shared the evidence. You can test for yourself

[xezon]

It would be nice to see what code paths are avoided that originally would cause crashing. And why fullscreen is meant to be treated as windowed mode. Perhaps that variable is incorrectly named? What does it do exactly?

[aliendroid1]

It would be nice to see what code paths are avoided that originally would cause crashing. And why fullscreen is meant to be treated as windowed mode. Perhaps that variable is incorrectly named? What does it do exactly?

I posted it in #28 like you had requested. Which variable are you asking about being incorrectly named?

[helmutbuhler]

I can confirm that this fixes the crash (on Windows 10).
When I set my fullscreen resolution to my native resolution, I have 100% crash rate without this PR and 0% with the PR.

Regarding the cause of the crash: This is quite likely a Windows issue. MS stopped caring about real fullscreen mode for some time now and all new games just use windowed mode for fullscreen. In my opinion we don't need to investigate it further.

I would also prefer to always set windowed to true in WW3D::Set_Render_Device. At least when the resolution matches the desktop resolution. Then we don't have to minimize the game everytime it loses focus and Alt-Tabbing will be much faster. But we can do that later in another PR.

[aliendroid1]

I can confirm that this fixes the crash (on Windows 10). When I set my fullscreen resolution to my native resolution, I have 100% crash rate without this PR and 0% with the PR.

Regarding the cause of the crash: This is quite likely a Windows issue. MS stopped caring about real fullscreen mode for some time now and all new games just use windowed mode for fullscreen. In my opinion we don't need to investigate it further.

I would also prefer to always set windowed to true in WW3D::Set_Render_Device. At least when the resolution matches the desktop resolution. Then we don't have to minimize the game everytime it loses focus and Alt-Tabbing will be much faster. But we can do that later in another PR.

Will need to check if setting it to windowed mode always would prevent edge scrolling or if it affects any other behavior. Alt tabbing seems to be pretty fast on my end when the resolution matches the screen resolution. I think the delay might have to do with the last argument to the function that determines if textures should be reloaded.

[aliendroid1]

@xezon @Mauller merging this should be a priority. Not having this fix applied causes many issues and makes proper debugging a hassle. Not only does the game crash but I have to move the game to a different desktop to be able to use task manager to exit because it won't release the ui thread. Assets The fixed version has already been tested thoroughly by many people and the logic of the fix is sound.

[Mauller]

I think there is a bigger issue here overall.

But this tweak essentially forces the game into a window when alt tabbing, this also causes the game to swap around some back buffer modes.

I don't think it was intended for it to put the game into windowed mode when alt tabbing, but this likely is helping get around the bigger problem.

I don't think this is the best long term solution but it seems to help work around the problem for now.

[aliendroid1]

So looking into this, it appears that TheDisplay->getWindowed() is always false as this value is retrieved from the game data at startup. So when in fullscreen mode this is set to false.

The problem with this is that because the false value is being passed into DX8Wrapper::Set_Render_Device when trying to change the game to a window, the game is not correctly changing to a window and setting the relevant back buffer information for when the game is minimised.

i think the issue is then that the game is attempting to perform fullscreen type video operations when minimised.

I don't think hardcoding it to pass in a value is correct either. I think a lot of the code here is a bit problematic, but hardcoding it does get around the initial alt+tab issue as it properly sets the game to windowed mode.

TheDisplay->getWindowed() is not meant to store the current state of the window but the state it is supposed to be in when active. All of the stats in TheDisplay are set based on presets. I've looked into it more and found that the reason for setting it to windowed mode when minimizing from full screen mode is because in full screen mode display settings like gamma and bit depth are modified for the entire display, not just the game. When in windowed mode it inherits the settings from the desktop instead of presets or options ini. The same is meant to be done when minimized regardless of whether it was minimizing from windowed mode or full screen mode.

This is from a small sample size but it seems like the crash occurs with Nvidia GPUs but not AMD GPUs. I wonder if that has to do with Windows showing the bit depth as 8bit even when it is set to 32bit under Nvidia control panel.

You have an amd gpu and it doesn't crash for you, can you check what number windows display properties shows for bit depth?

[Mauller]

You have an amd gpu and it doesn't crash for you, can you check what number windows display properties shows for bit depth?

10Bit

[aliendroid1]

You have an amd gpu and it doesn't crash for you, can you check what number windows display properties shows for bit depth?

10Bit

So turns out windows actually doesn't show the wrong number it's just shows the per channel information. Could you check what the full bit number for the color depth is by checking list all modes under adapter properties?