Fix monitors going to sleep during cutscenes on systems with low display turn off timeouts

[ShizCalev]

Folks who use OLED screens tend to set their display sleep timers pretty low to prevent burn-in.

On top of not only being inconvenient during cutscenes, this can also cause the game to crash outright since lots of stuff gets shifted by Windows when a display turns off.

This fix simply sets the main process to flag itself as ES_DISPLAY_REQUIRED (and the necessary prerequisite flags), meaning the game now tells powercfg that the screen must remain on at all times while it's running.

[xezon]

Nice detail :) We will hold off merging these code edits for now until build pipeline and other things are setup.

[Igoorx]

I think this is too broad, it would be better if ES_DISPLAY_REQUIRED is only set when the game is actually in progress (i.e. not paused, not in the main menu)

[ayumi-chizuru189]

I disagree personally.
Most people I know AFK at the main menu or while the game is paused, and the game has a high tendency to freeze when the device go to sleep in my experience, and I'm sure no one want to get back and see that their game has froze.

So unless we managed to fix the core issue, I think it's better if the game doesn't allow the device to sleep at all if it's running.

[xezon]

We should fix that freeze then.

[ShizCalev]

Set! Implemented exactly as Igoorx requested.

I'll elaborate a little on the chain is since the codebase is still new!

GameMessage::MSG_NEW_GAME (signal sent at the start of a new singleplayer game, multiplayer match, rest below) & doLoadGame() call prepareNewGame(), which both call setGameMode( GAMEMODE )

Gamemode Defs

	GAME_SINGLE_PLAYER
	GAME_LAN
	GAME_SKIRMISH
	GAME_REPLAY
	GAME_SHELL
	GAME_INTERNET //multiplayer match
	GAME_NONE  //main menu

clearGameData(), which is called at the end of a match, calls setGameMode(GAME_NONE) as you're sent back to the main menu.

SetThreadExecutionState() also updates w/ setGamePaused()

---

Lastly I realized I should've put this in _WIN32 def flags for proper linux support. :>

[DevGeniusCode]

I think we should give users of OLED screens a warning about the existence of this feature and the option to disable it (with clarification of the consequences) because there may be cases where there may be burn-in on the screen.

[tintinhamans]

We can add it to the patchnotes, but I don't know if making much more noise about it is really needed as this is already an improvement on the existing situation.

[Generalcamo]

From the windows API documentation:

Applications such as [...] games do not need to call SetThreadExecutionState.

I'm not convinced on violating a recommendation by Microsoft themselves on this.

EDIT: It might be reasonable to do this when playing videos, or entering a cutscene state:

Multimedia applications, such as video players and presentation applications, must use ES_DISPLAY_REQUIRED when they display video for long periods of time without user input.

[ShizCalev]

From the windows API documentation:

Applications such as [...] games do not need to call SetThreadExecutionState.

I'm not convinced on violating a recommendation by Microsoft themselves on this.

EDIT: It might be reasonable to do this when playing videos, or entering a cutscene state:

Multimedia applications, such as video players and presentation applications, must use ES_DISPLAY_REQUIRED when they display video for long periods of time without user input.

Hello fellow spessman! (Noticed aurora in your profile haha.)

That advice is there because games typically have constant user input which prevent the monitor from going to sleep in the first place, however that article hasn't been updated in four years and the usage of OLED screens for monitors (which folks typically utilize ultra-low display sleep timers with to minimize the risk of burn-in) has only really become prevalent in the last two years. As such, it's becoming increasingly more common for games to set ES_DISPLAY_REQUIRED nowadays specifically because of low idle timeouts.

There is no overhead associated with, nor any downsides to enabling the flag while the game is in an active (meaning unpaused) match/cutscene/loading screen, which is how this has already been coded. (The flag is not active while the game is paused, while in the main menu, ect.) On the other hand, as previously mentioned, not having the flag enabled can result in the game to crash if the user's screen turns off if, for example, they don't immediately move their mouse the moment a cutscene finishes after a loading screen, which can easily happen with levels like GLA3, which has a loading screen that feeds into an almost 3 minute long cutscene.

As someone who uses an OLED screen, having the flag ONLY enabled during the cutscene & not during the match immediately afterward would make this PR essentially worthless. As for the risk of someone going AFK during an active match, this flag is already coded to immediately deactivate when the defeat screen is shown - which is pretty much going to occur anyway if someone randomly goes AFK for 5+ minutes with an opponent on the map without first investing heavily into base defenses. xP

Will let others weigh in on actual formatting in code, argument for violating API documentation is sound.