In rP22314#34004, @Stan wrote:

This breaks sounds for me. I believe that maybe g_SoundManager->IdleTask(); gets called too often ?

Does it break sound always? Or only if you minimised?
Can you try:

• Putting SwapBuffers()s in the main loop after Render();
• Putting the same if for the sound manager as for Render();

It has to be one of these two.

In rP22314#34010, @wraitii wrote:

In rP22314#34004, @Stan wrote:

This breaks sounds for me. I believe that maybe g_SoundManager->IdleTask(); gets called too often ?

Does it break sound always? Or only if you minimised?
Can you try:

• Putting SwapBuffers()s in the main loop after Render();
• Putting the same if for the sound manager as for Render();

It has to be one of these two.

I think it is moved sound manager. just move sound manager inside renderer after if check as it was before should solve the problem. I do not think we want duplication for the if condition, one is enough :)

In rP22314#34011, @Angen wrote:

In rP22314#34010, @wraitii wrote:

In rP22314#34004, @Stan wrote:

This breaks sounds for me. I believe that maybe g_SoundManager->IdleTask(); gets called too often ?

Does it break sound always? Or only if you minimised?
Can you try:

• Putting SwapBuffers()s in the main loop after Render();
• Putting the same if for the sound manager as for Render();

It has to be one of these two.

I think it is moved sound manager. just move sound manager inside renderer after if check as it was before should solve the problem. I do not think we want duplication for the if condition, one is enough :)

I would disagree, this function is called "Render" and putting sound management there is unexpected. If the lack of If condition is what breaks sound, then we should rather:

• Move the sound call in a GameSetup.cpp function called "SoundTask()" or something.
• Wrap the if condition in a standalone function in GameSetup.cpp
• Use the same if condition in both functions

@Stan what does "break sound for me" mean, no sound at all (on windows?)? Is this reproduced by others (on windows)?

@Angen: What were the original steps to reproduce other than alt+tab just after the loading screen?
Perhaps one can reproduce it with some code modification (triggering the unfocused window code after the loading screen programmatically)
You say "it is kind of rare but not impossible", which sounds like it could not be reproduced reliably, which means the absence of the bug could also not be confirmed, is that right?

Sorry, should have been more specific.

After this commit (after running dichotomia on all other commits) when I run the simulation in Atlas (Doesn't seem to happen in game) and make a 4v4 archer fight, they will stop making sounds after a short time, maybe 3-4 arrows, then the game units go completely silent.

I believe @Angen reproduced the bug as well.

Bug n 1.
Run game with postprocessing on in fullscreen, alt tab and go back (solved by D1212)
Bug n 2.
Postprocessing on in fullscreen, alt tab while loading match, return back after match started ( original solution https://code.wildfiregames.com/D1495?id=7570) commited version (this)

Was anybody else able to reproduce ?

@wraitii @Stan
g_Soundmanager->IdleTask has to be inside Render()
Events changing g_app_minimised, g_app_has_focus, isinfullscreen can ( and looks like they do mainly in atlas ) come after g_SoundIdleTask and before Render so Idle task is called but Render not

@Stan can you please check if it works for you?