Display Resolution Dialog Deprecation

It makes sense that it isn't worth maintaining the resolution dialogue when so few people use it.
This has created one problem for me though.
I'm working on a drawing app that's intended to run on screen tablets. People usually don't set their screen tablet as their main display so I've kept the resolution dialogue on to allow people to select their monitor before launching the game.
The rest of the resolution dialogue I don't need as it can be easily replicated in-game.

So I'm trying to figure out the proper way to set which monitor the app runs on. I'm aware of the command line option to set the monitor, but I need a dropdown to allow the user to select the monitor themselves. Is the only way to do this to write your own custom launcher? Is there a reasonable way to change the monitor from within the main application?

As this is a drawing app I need to create an OSX as well as an Windows version.

On Windows it's also possible to change the monitor by pressing windows key+shift+arrow (right or left)
But I would rather not have to instruct my users to do this.

 

So if we want our users to be able to choose the display the game runs on, we're expected to code an entire custom launcher? That seems excessive to me. Why can't there be a Display.SetActiveDisplay(int displayIndex) function?

 

That is extremely helpful. Thank you very much!

 

@abbapamela are there other secret PlayerPrefs settings?

 

@JimmyCushnie What I've gathered from my own experimentation (don't take this as definitive):

Screenmanager Resolution Width

Screenmanager Resolution Height

Both fairly self explanatory.

Screenmanager Fullscreen mode

is fullscreen/windowed mode, using the same integer values as FullScreenMode (0 for fullscreen exclusive, 1 for borderless, 2 for maximized, 3 for a normal window).

To the guys at Unity: This is inherently fragile, and I'd really like to see an API for setting these values directly or at least disabling the persistent behavior now that resolution setting is always our responsibility.

 

So... No way to continue using the old input system, letting the user to set up their controls there?

IMHO this was a really bad, bad decision. Since there is no ready to use replacement for all that features yet. Migrating to the new input system was not on my plans right now, due to all user interfaces that must to be created =/

I was using 2019.3 for mobile where I found better overall performance than 2018.x... But for desktops migration would take a longer time, so let's stay with 2018.x for a while.

 

I agree, I think it is a big regression to remove the old launcher without adding a new launcher. Unless the developers of a game spend many hours coding custom UI, that game will now be far far less user friendly than it was before. In particular I think game jams are going to suffer a lot from this change.

 

Hi there i'm trying to use the scripts from the screen selector project and I keep getting this error while trying to build it.
is there a certain way to use the scripts without causing this error?

 

I was able to figure it out I just built my project like normal then replaced and renamed the executable with the correct one from the screen selector LauncherExecutable folder. Still sad to see the display resolution dialog option removed, but at least we have this. Thanks

 

If you're going to start removing things people rely on, it might be nice to provide a thorough explanation of the best practices to replace that functionality. For example, from my searching around, it is unclear how to write new quality settings such that they'll be automatically picked up by the player when it is run. From my testing, QualitySettings.SetQualityLevel() seems to do it, but the documentation isn't clear that this sets a persistent setting rather than just changing the settings for that run. And the only way to learn this for yourself through testing is by building a stand-alone player, since from what I've experienced, the editor doesn't obey persistent quality settings as it uses the currently selected quality in the editor settings.

 

Very annoying I was counting on that for my Ludum Dare entry. The display resolution dialog was not the most elegant thing in the world for a finished game but when sharing a game jam prototype: it's perfect!

 

"User data and customer research" be damned, this is a big step back. I really hope Unity re-adds the old launcher, or even better, makes a new launcher.

 

Agreed, came back to Unity after a 4 year break to find not only has so little progressed in terms of features, but useful stuff has actually been removed. I only came across this thread because I couldn't find the damn setting to turn this on to quickly prototype a project only to find out the whole thing is gone with no replacement

 

Ugh, I hate to pile on, but: it's really upsetting this feature was removed because "we found out that it is one of the first things the vast majority of our developers disable when building their standalone players".

This is almost certainly true *when a game is released commercially* - but certainly not during prototyping, game jams, etc.

The resolution dialog is (was?) a useful development tool. Removing it entirely because you shouldn't _ship a game with it_ is like removing the default GUI skin and requiring everyone to design their own from day 1. You should have custom GUI art when you ship - but it's entirely appropriate to put off till late in development!

(I'm particularly salty about this because we have an internal prototype build to ship to a publisher, and I didn't realize this feature was removed. The publisher *does not care*, at this early early stage of development, whether we've made a nice looking settings screen. But: *we do care* that they're able to select the right resolution and quality settings for their machine, so that the game runs smoothly and looks nice.)

 

I have to echo what @tconkling said. One of the chief advantages and attractive aspects of Unity, particularly for indie devs, is the ease of prototyping. And that doesn't just mean in-editor, but being able to make a fully-functional built player without having to do all the boilerplate stuff yourself. Yes, we will all eventually do the boilerplate stuff further down the production pipeline, but that doesn't mean it isn't HUGELY valuable to have adequate placeholders ready for use in the early phases. A lot of game concepts never even make it into full production, but the ability to rapidly iterate on them, make them fail, and discard them so we can move on to the next concept, is critically important. Raising the level of difficulty and effort required to get that early out-of-the-box functionality lowers the value proposition of the engine itself.

 

I agree that this window was very useful for prototype, game jam, and just test build situations. The dialog certainly wasn't professional but it worked. However, when getting the game up and running in a prototype fashion it was perfect until a fully fleshed out options screen could be made.

I'm not too concerned with the loss of the quality/input mapper, but the resolution/monitor picking is sorely missing and there isn't a multi-platform runtime API yet to query/pick a monitor such that we can't provide that functionality in the game options screen even if we wanted to? Command line arguments and player prefs are not a solution for end users when distributing builds. Bad Unity, BAD!

 

I am genuinely amazed to see that Unity Technologies went through with this without a simple and elegant replacement. Who was involved in the decision making progress and why didn't anyone go "okay, but we should have a way to pick the resolution, window mode, and display in place before deprecating this?"

It's a genuine headscratcher as to why anyone would do this and go "just make a custom launcher or use these command line args."

 

My biggest problem with Unity is that they're out of touch with what actual developers need and want. This is a perfect example.

 

Look no further. Here's the replacement:
https://forum.unity.com/threads/dis...nt-for-those-who-cant-live-without-it.896618/

 

Thank you very much for making this. Obviously it's not a full replacement, but it's a heck of a lot better than nothing.

 

This is a reckless move!

If you're going to re-place a tool with another you replace it when the new version is ready.

I hope Unity do the right thing and bring it back!

 

This is bullshit. I regularly use that feature because I often make new empty projects so I can experiment and code a particular feature in complete isolation and when I make a test build I've often NOT implemented a UI for doing resolution, input rebinding, etc.
Even in actual game, like my own BHB: BioHazard Bot on steam, I kept that feature hidden but still enabled so that if player holds shift or alt it shows up. The reason for this is that if the player sets the graphics/resolution higher than what their system can handle in the game's settings menu by mistake, they have an option for changing the settings outside of the game. This was useful when I was testing the game on lower end machines and wasn't sure how it would run.

Bring this feature back you idiots or provide an alternative. Seriously, what the hell are you guys smoking?

EDIT: Also, if this is the 2019.1 blog post you're talking about, it said nothing about the feature being removed, only that it would be disabled by default.

 

To be fair, I have never been a fan of the old resolution selector. I never thought it felt production ready for commercial use, and I usually disabled it immediately and replaced it with my own menus in game. But I definitely do see the point about game jams and quick prototypes, though.

 

I imagine that a supermajority of projects made in Unity are game jams and quick prototypes.

 

Not to mention projects explicitly not made for public distribution, in our case that would be trade fairs and company internal apps for marketing / demonstration purposes that need to run both on the big screen on high-end computers with dedicated graphics but also on low-end business notebooks with integrated graphics - and to support that the resolution dialog was just ... available at no additional development cost. It did its job just fine being able to choose the two main balancing factors when it comes to pick either quality or performance: setting resolution and quality level and that's it.

 

Make Display Resolution Dialog optional. As it was.
Just another expense and a slowdown for business developers.
It feels bad when Unity decides to waste our money & time.
Remove the optional dialog only when you have a replacement ready. I see there are problems with your current replacement in the command line. This is just very unprofessional.

 

What a blunder!
Today I upgraded my project from 2018 LTS to 2019 LTS and found the feature i use every day is gone.
The point of deprecation is to discourage use of one method in favor of another.
The feature is now completely gone and it's "replacement" is not ready and far more difficult to use.
If this is the way Unity moves now I worry about it's future.

 

What would you deprecate next? Legacy animations, skyboxes maybe? Don't support it. Leave it as a freaking option, no one's harmed because of it.

 

I have a question is why these are used.
(I have to change and delete the registry)

It will cause troubles, so I would like you to give priority to the item of Unity project setting.

・Screenmanager Resolution Width
・Screenmanager Resolution Height
・Screenmanager Fullscreen mode

 

Question: I last started a build of my game with some debug sized window for testing. Since then I updated to 2019.4 and since I have no dialog anymore, how do I change back to fullscreen? My game keeps starting with the settings I once set?

 

This is very bad. It's good when there was a choice whether to launch a dialog box or not. I am already tired of constant changes. You install a new version and instead of working, you're looking for solutions to make things work that used to work.

 

This is horrible. As stated before, I currently have 10 projects that I revisit, to test assets and experimenting. And I help friends with their games.

A huge thanks to Steffen Itterheim! A package makes it a lot easier than the github repo. Still. Not looking forward to installing the package 10 times a year.

A reasonable approach for "the vast majority of our developers disable when building their standalone players" would have been to disable it. Not to remove it completely.

 

I swear who ever is in charge rarely uses smart thinking, if at all.

Unity is driving itself into the ground by constantly removing aspects that many users rely on for prototyping. Yes, we can just make our own, but for networking and other uses that little box was a must.

Unity is destroying itself in a feeble attempt to become unreal engine 2.0 instead of focusing on the main reason people started using Unity in the first place.
(Don't even get me started on D.O.T.S, the new networking solution that *cough* never came out *cough*, or what ever the hell is going on with the different graphic pipelines.)

 

Yeah, supremely stupid move Unity. I routinely use the dialogue resolution selector to export game videos at various resolutions. Even if I did not explicitly utilize the dialogue in a game build, the fact that I could force activate it on launch gave me the flexibility to use different resolutions without having to engineer an in game resolution selection in early builds. At the very least you should take the temperature of the community before completely removing engine features that have existed since day one of your engine.

 

I'll take you one further: projects explicity made for public distribution, but that have the same exact issues as you just mentioned. IE: educational software in schools.

 

Please remember that there are paying customers who may not use Unity the same way the "vast majority of developers" do. I work in the educational software field, which doesn't always have the same expectations as commercial games, etc! Just throwing that out there so we're not swept under the rug because we're different!

 

And also remember that just because something isn't used in final, production builds doesn't mean it isn't used by the vast majority of developers. I mean, I don't see the profiler in ANY production builds, but I sure hope Unity doesn't conclude from that that it should be removed!

 

It would be interested to know, what kind of user research you have done for doing something so horrible. How can I now change between displays at runtime?

 

Please put this back......

Testing multiple clients it is extremely easy to set a custom resolution via the launcher.
The code was also already there......

 

Hey SteffenItterheim, the plugin works mostly.. except changing the monitor! I am on Linux though. The only way to change the monitor is by windowing it, moving it manually, and full screening it again! I wonder if anyone has any work arounds..

 

One of the biggest mistakes in Unity's history.
Proof? People keep talking about it.

This was one of the reasons why so many people relied on Unity.
You are slowly but steadily killing every single reason large or small that made Unity the first choice for small developers and creative people.

People who were not programmers and were able to make an application that also had a simple yet useful settings menu and the performance could be adapted to the machine the application was used on without anyone having to lift a finger.

Perfect for designers, architects, etc etc. Now people have an app, which is stuck in one performance mode, and there is no way to do anything about it without learning how to code As if you have nothing else to do.

Who is this "majority"?
How did you come up with that decision?

Why couldn't you let those experts who always disable it with a single line of code, keep doing that, instead of leaving thousands of people who do not know how to code without an easy useful and free solution?

 

On the other hand many others always used it and all the people who were using the applications were using it and could easily adapt performance and presentation to match their hardware from a simple and obvious menu. It was perfectly fine and quite a few games used it too, without having to waste their time creating a basic settings menu.

If your game doesn't use many exotic features (which is the case with oh so many indie Unity developers) that was all the settings you needed. And that is why it is still surprising that Unity came up with the idea that most people do not use it...

 

Bad move, unity. Really, really bad. Killing off features that ease the hurdles for new game devs is never a good idea.

 

Well it's been two weeks since someone complained about this being removed. We need this for quick prototyping.