Matthew Craig, on 04 November 2013 - 10:15 AM, said:
Thanks for the feedback on the current value that allowing windowed to full-screen transition is providing it's good to hear that it is helpful much of the time. We'll look at it and see if we can retain an option to continue to use that mode, but I can't promise anything.
To better explain the issues that arise during the transition with the current system; during the transition into game we currently have to call functions to re-size the screen buffers. This can contribute to edge cases, the game needs code to handle failure cases, if you Alt-tab during load it can change behavior which can be different for DX9 and 11. Given there has been much complaint about users not making it into game (showing as a disconnected player) anything we can do to help reduce the likelihood for that seems to be a win.
Ultimately this is not that hard to maintain in the new system as an option, but anything we retain as an official option needs to be dealt with by QA which means we have to consistently test these edge cases that may be low user path.
Another factor in this decision is that not many games make use of a windowed to full-screen transition so the engine code to handle these transitions, ends up being largely custom code we have to craft into any future engine updates in a way that doesn't break functionality.
Also as you're all aware the mouse capturing in the current engine is 'frustrating' to say the least and another reason to simplify this flow is to help allow us to quickly clean up that behavior. All this said though I'm not trying to dictate the flow and I'm open to facilitating the community, perhaps you could explain in more detail what the current flow allows you to do and there may be better ways to get that same functionality. e.g. if it's for rapidly switching to VoIP 3rd party apps, there are apps that work in full-screen overlay mode we can ensure we work with?
I understand the mode jumping issues that come with screen resizing, and that minimizing changes within the video card driver setup is a strong developer goal (it's a black box from your perspective, so you need to keep interaction with it very strictly controlled), however I think all this boils down to what people expect from the game experience.
Right now, the game only has two play modes and a mechlab. The other experiences either aren't present or are minimal (social). In order for players to gather up friends, experiment with mech builds, experience the battletech universe and otherwise fully enjoy themselves, they rely on third party products to fill the gap. Until in game features are as compelling as the out of game experience, the back and forth jump will always be present.
If people can alt-enter, and if it is reliable, then for those of us with dual screens, we might find that works well enough. Not everyone falls into this category, however, and it becomes another trade off against the number of people who use it vs the cost to support it.
Please consider other options here. You might consider splitting the main game engine away from the launcher. This solves a few problems (memory leaks, for instance) and lets your rapidly iterate one without co-dependence on the other. It does mean you lose some things (fancy mech models in the mechlab probably wouldn't be as easily accomplished), but I don't think people would mind much, honestly. The current and UI 2.0 mechlabs aren't actually very good for building mechs, I'm afraid.
I don't use overlays (second monitor handles that) so others can speak to applications they use. I know mumble supports it and is in common use, and I can guess teamspeak is the same.
Edited by EoRaptor, 04 November 2013 - 02:55 PM.