Make engine work reliably with multiple monitor systems

[ivan-mogilko]

Problem

Existing graphics mode code assumes primary monitor in many places, whenever the desktop size is retrieved, calculated window size adjusted for the working area, window created, etc. While the game may work on any monitor in windowed mode (after player dragged it from the primary one), and even switch to "borderless desktop window" and back, some calculations are still wrong.

In addition, exclusive fullscreen mode is not working reliably in this case, depending on which graphic driver was used. From what I've read, Direct3D9 cannot make a fullscreen mode on another monitor, only one the one which IDirect3D9 object was created for. Here we need to make a decision: either we want to support it switching monitors or not.

• If we do, then it needs to be taught to recreate itself, which in turn requires to fully reset the texture cache, as all the objects tied with the IDirect3D9 interface will be invalidated.
• If we don't, then we need to resolve a situation where a player switches between a window on secondary monitor and exclusive fullscreen on a primary monitor. Judging by users reports, this causes some glitches, probably because fullscreen mode is created without moving a window to the primary monitor first (not fully certain if that's the reason).

Tasks

1. Any code that relies on display index should have display index as parameter instead of assuming "default display". We might need a function that returns "current display" from the window position. An example may be found in this temporary commit which I reverted afterwards (it was not enough, so I did not want to keep dangling changes which i'm unsure about): 4fff528 . But the code changes in that commit are not complete for this task. Note: besides general code, there's also a code in AGSWin32::ValidateWindowSize() that also assumes primary monitor.
2. DisplayMode struct, used to init a mode in graphic driver classes, should contain "DisplayIndex" value, telling the gfxdriver which monitor to init a mode on. The driver class may override that, if it's aware that it cannot perform this request (speaking primarily of Direct3D9 here). If driver creates a window (because it does not exist yet), then it creates and positions it on the requested display. If window already exists, then it moves it to requested display.
3. Optionally we might have "display" selection in winsetup, if this seems like a good idea, if not then this will be always defaulted to 0.
4. There's a code that remembers last settings for each mode (windowed, fullscreen). It should also remember resulting display index, because if window was moved to another display by a user, then old settings may not longer be applicable (resolution).
5. Then, there's a question of behavior, suppose player moved a window to the 2nd monitor and toggled fullscreen. It seems that users expect that fullscreen will also be created on that 2nd monitor, if possible. And if they switch back to windowed, then it has to be still on the 2nd monitor. On another hand, if some driver cannot create fullscreen on 2nd monitor (Direct3D9) and creates fullscreen on 1st monitor instead, then switching back to windowed mode should likely return the window to 2nd monitor?
6. There's a certain logic for mouse speed that saves desktop size prior to changing to fullscreen, because mouse speed may need to be relative to monitor size. Need to double check that it still works correctly in all situations, especially if window->fullscreen switch changes monitors in case of Direct3D9.

[ericoporto]

Optionally we might have "display" selection in winsetup, if this seems like a good idea, if not then this will be always defaulted to 0.

I made a ticket for this in #2280 . This was a request I saw from a player in a discord support channel, they were a streamer and used one monitor for playing and other for operating the stream (configs, chat, ...), and apparently had this other monitor as primary.