The Display Resolution Dialogue has been deprecated and will be removed in a future version

Its pretty bad as an artist that I have to code my own menu now for something that used to work just fine for quick build testing.

Please just bring it back. Thank you

And yes I work on a Mac, and unity made my life more difficult not easier.

 

When feature such as this got "removed" we should be ale to see and understand the reason behind its removal.
Was there such statement anywhere? Where was the supposed "More information about the evolution of the Display Resolution Dialog will be shared in the near future." ?? Have I missed anything? The launcher sample mentioned above.. is that the "official" way to do the launcher dialog now? If so, I don't mind. I just don't like the fact that it seems like it was removed completely without official proper explanation or future plan from Uniy.

 

Is it harmful to keep this dialog in? It's going to be so much harder for me to let users configure controls on different controllers now

 

I'm not sure if removing it is really helping anybody, I just don't see any reason why it was on top of the priority list. there are so many other things that need improving before actually taking things out that worked just fine.

sorry for the rant but the removal of this is costing me dev time I could spend on prototyping. I won't mention it again in the future but at least know that not every user was taking out the dialog box.

 

Just want to add to the group that found this option useful.

Sometimes I will create a prototype of something simple, like character controls, and send a build to a friend for feedback. No menus or game progression. Having to implement a resolution menu as the first task in every prototype seems like a huge hassle.

 

It was a great debugging tool. you could set a bunch of quality settings and not have to roll any kinda settings UI. Cant we have it in development build and not release?

 

They would only remove it if it was in the way of some future development work. When Unity just doesn't want to support something they typically deprecate it but leave it in until they have some reason it must be removed. There would be no point in leaving it in for one kind of build but arbitrarily disable it for another.

 

I made i little bit simpler solution https://github.com/newnon/UnityScreenSelector it is also only for windows but you can only copy ScreenSelectorExaple/Assets/ScreenSelector folder on any place inside assets folder and it will create file named ScreenSelector.exe near you game exe file

[Mod edit: removed link to executable.]

 

Add me to the list of people that think this is silly. With no replacement, I now have to spend time creating an alternative for my, until now, relatively simple game.

 

Removing the built-in Configuration Dialog a.k.a. Display Resolution Dialog a.k.a. Screen Selector FEATURE is one of the dumbest things Unity has done recently. Who wants to spend time in early development to find or implement that FEATURE yourself instead of just using the built-in timesaver?

Here I was happy that Unity finally added the most basic thing into their editor (being able to lock GameObjects so you don't accidentally move them in the scene view) and then you remove the super useful FEATURE because... why exactly?

"Based on user data and customer research, we found out that it is one of the first things the vast majority of our developers disable when building their standalone players, and it frequently goes unused". So basically some people simply didn't like to see that dialog on indie games? Who cares. Add the FEATURE back please.

Notice how I emphasize FEATURE several times because that's what you've removed. For nothing. I don't get it. Why does it even matter if it goes unused in the final product, it's a fantastic tool to have during development. As a built-in!

Also my gut feeling tells me those "vast majority of our developers" doesn't include the thousands of people that pump out games during weekend game jams every year. I certainly wasn't interviewed. It was not uncommon to see the built-in resolution selector shipped with the final product in those games. A feature we are now deprived.

TL;DR I can't see how removing the dialog in any way, shape or form is a net positive. Leaving it built-in but being disabled by default wouldn't have hurt anybody. Rather than removing it the more sensible thing would have been to improve the launcher and make it fully customizable. Lots of AAA titles have launchers, they just don't all look the same.

 

So pissed off I have to dick around creating something that used to exist. Thanks Unity :}

 

wow yeah this is pretty crappy...

 

This is a strange deprecation. Yeah it wasn't elegant but it was a handy accessibility feature for folks who needed to configure custom controllers. I guess it was someone's pet peeve over at Unity and they finally found a chance to nix it.

 

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

 

@abbapamela please look at above LINK.

@SteffenItterheim This is amazing!! Thanks so much! And I don't even need to use GIT to clone. There's a download link!! Thank you~~~~

But still need to ask. Why Unity? Why?

 

Well I just updated from 2018.4 to 2019.3 and now I can't bind any control inputs, since I'm still on legacy input manager. Is there an alternative way to bind inputs until I'm able to make the switch to the new input system?

 

So in 2019.4, the Display Resolution Dialog is no longer visible under the Project Settings->Player->Resolution and presentation->Standalone Player Options...

This was a great tool during development, any way to get it back?

 

Yes, there is. Implement your own config menu and use Input.GetKey seriesof API instead of the default ones.
For gamepads just use Xinput dot net as unity's gamepad support was never existing.

 

Input.GetKey doesn't work for Joystick inputs as you know. Switching to using XInput would be just as much work as switching to the new Input System. I was more along the lines wondering if there was a temporary way to get the Input binding dialog back. I guess I'll just stay on 2018 in the meantime until I can work out a solution.

 

Note that there are PlayerSettings that can help you now, especially during development for quick testing:
"Allow Fullcreen Switch" (=toggle with Alt-Return from within the app) and "Resizable Window".
You can even use this to change the display the app uses for fullscreen (=Alt-Return to enter windowed mode, drag window to different display, Alt-Return to re-enter fullscreen mode...)

Be aware that Unity stores many launch settings hidden away in the registry, so if you use the command line parameters to modify the launch defaults, Unity will store this and from now on ALWAYS use these, meaning even without the parameters your app may now no longer launch in the way you built it.

 

for mac there is still no good solution, and unity does not see this as a priority anymore, and just thinks we all program a resolution dialog first when we start to make a game. that's just not realistic for a solo dev

 

you could have left the one that was working in there, now we have nothing.

 

Alright, bad decision timing again. You should have removed a 12 years lasting feature only with a replacement ...
I'm typically in a spot where I need a video of my game in 16/9 for yesterday but my monitor is 21/9 and I can't find the CMD argument anywhere, and I'm tired, as a paying Game Dev customer should be.

SO :
1. Fix this, you already took 1 hour of my time to understand what happened.
2. Could someone tell me what and where to find the cmd args ? Thanks.

 

Unity always striving to make our lives better ...

 

Anyway, today no one need to set screen size, it don't exist in sucking windows 10, frame per second is nothing, if the game is running slow, just buy a better computer, or a worse screen. Done...

 

Just going to make note: not everyone here has the same career, even though we may all use Unity.

Broad assumptions about what makes sense for other people and their given fields really is at best disrespectful, if not harmful. Not to mention, its really annoying to wade through when searching for a solution to something that's taking up someone's time .

 

What a surprise that they just removed something that pretty much everyone needed. What's next? Remove textures? Meshes? You guys are total clowns. I'm moving to UE after my next title releases. It's pretty easy to see the writing on the wall here. Unity's days are numbered.

 

This was a terrible decision. That dialogue was INSTRUMENTAL for testing a bunch of resolutions on a build, quickly changing a keybind without having to do a new build or code a keybind menu, switching monitor...

It seems Unity are focusing more and more on AAA firms, who can throw dozens of people at building custom engine parts that are suddenly broken or missing, but are dropping the ball on getting the rest of their customers on the train, as well. With these new render pipelines, everything has become a convoluted chore. Every little thing has to be studied for hours or days to figure out what's the correct way to do things, and we indies just have to eat that burden. I didn't have to worry about half of this stuff before, and I could wait until I was done prototyping to set it all up right, but with the new pipelines everything is much more difficult to set up for the basics, and you're much more likely to have to completely rebuild a prototype to make it work properly, where it might have been a few simple import changes before. I get that most of these things come from switching to deferred rendering (and HDRP has even more quirks to learn about before you can even begin to use it), but the amount of documentation one has to read in order to have an inkling of what they're supposed to do with a new HDRP project and the implications all around the engine, is staggering.

Related to that, right now I have no way to render Text reliably in HDRP (EDIT: Unity 2019.4 LTS), because TextMeshPro renders underneath the UI layer (we've been waiting on new HDRP TMP shaders for over a year now, and it seems to finally be coming along, and it's apparently not the Stephan_B's fault, but some Shader Graph development that has delayed it...but over a year?), and the regular Text components need a dumb workaround to disable Bilinear Filtering on them for pixelated fonts, along with generally looking bad and scaling in weird size-steps when using the default "Character" setting of "Dynamic" which is default and required for font styles, so they're not viable replacements for TMP which has none of those problems.

Most infuriating is that all the newer systems, like the new particle and physics systems, require you to use DOTS and ECS to take advantage of them, requiring a completely different workflow for just about every part of the development cycle. The way you have to structure things hurts my brain. I was looking forward to a new physics system, where I can handle each collision during the physics step, but alas, just for that feature, I have to completely rewrite my existing games. Not a fan.

It's not that I'm opposed to having to solve some of these problems. It's that there are SO MANY of these problems, even with a relatively simple game, that I'm finding it hard to find the parts of Unity that I don't want to replace with an asset that just works, and that makes me really sad because I've liked working in Unity so far. And also I've learned that assets are suddenly discontinued, and then because of that, sometimes you are then blocked from upgrading to the next Unity version, so I'd rather stick with Unity's best, as far as I can. There's just not enough guidance and help for people who don't have 400 people on staff to throw at making custom solutions for everything, because there are no official answers to a lot of the basic issues of game development. It has been especially bad with HDRP. The answer to every problem I pose is to write another custom shader. The default particle shader doesn't support transparency. How useful is that thing, then? And no lighting information available in shaders in HDRP, so how do we get that light info? No answers, except "roll your own lighting shader". Really? How many months is that going to take me? I don't understand how HDRP is labelled "production ready". I guess it kind of is, if what you want is to write half your own game engine, which I guess most AAA developers end up doing. Maybe I should just drop it and try URP, but from what I'm hearing it's not much easier with that.

Where are the official guides/tutorials for making these basic things properly, like UI that looks good (which rules for sprites to consider, how to make them scale properly down from the reference resolution without artifacts), or how to make custom UI shaders for each pipeline (since it's apparently very different), and if you're confident in your UI system, a guide on how to make an auto-sizing textbox? There's a bunch of documentation, but it would be nice with some good general guidelines. And not just how to make them in their simplest form, but making them properly. How am I supposed to know exactly which format of PNG Unity likes for UI and which import settings to use for different types of UI images? How to make UI not look crappy in other resolutions than my reference resolution, because mipmapping and pixel perfect canvases don't seem to solve the terrible sprite scaling. Heeelp! Help me use your fantastic engine.

 

Currently using HDRP 10.2 + TMP 3.0.1 without any issues whatsoever. Make sure you're using correct package version.

Other than that, implementing resolution switch in game for debugging is trivial. Just use a key to iterate through available resolutions, or an invible button for the mobile.

Implementing in game key rebind menu is trivial, but rather time consuming. Fortunately, it doesn't have to be done for each project. And if you're aiming for PC / Console targets - it should be implemented anyways (following Steam / other guidelines). I've used this as a base: https://github.com/daemon3000/InputManager for easy remapping and in-game button display.

Regarding UI / Sprites - it all boils down to the chosen reference resolution and canvas scaling.
And the only way to make UI look good everywhere is to prevent any (or drastic) size changes.

That is not because of engine, but rather because that's how rasterized formats work.
Another way of doing UI is pure vector sprites. But its another can of worms.

DOTS / ECS concepts are rather simplistic once it "clicks" that you don't need classes, inheritance, and other OOP stuff. Its just plain data management. Nothing else.

And no, you don't need to use ECS / DOTS right away.
There's ways to do everything using classic MonoBehaviour approach.

Regarding shaders and HDRP - official statement is to use Shader Graph. Or use any other shader editor. Personally I'm using Amplify Shader Editor.
There's a lot of stuff that is black boxed, undeniably. Shaders on their own are absurdly complex topic. That includes proper knowledge of how pipeline works.

HDRP is aimed for middle / high-end teams and devices. Rather AA than AAA.
But nothing stops indies like me from using it. Because there's things that are plain impossible to implement in built-in pipeline.

Just be aware that it took about 10 years to polish builtin pipeline. And HDRP is rather "young".


TL;DR:
There's no universal "Make game button" overall. And no engine will allow that in any near or distant future.


I understand that learning might be quite a difficult process and post above is just venting out rage. But in future, please consider splitting issues separately, and asking around.
People on this forum tend to help other people most of the times.

Or you know, google things. There's a solution for nearly every problem.

 

First of all, I really appreciate you actually writing something for all the things in my rant, as you perfectly describe it. Thanks for taking the time.

We're stuck in 2019 LTS for now, so HDRP 7.3.1 and TMP 2.0.1. It's those shaders we're waiting for. Sorry, I should have specified. Added specification to my other post.

It might be trivial, but they are both time consuming to do right, and until they removed the launcher I didn't have to worry about it until late in development, meaning I never had to do it for most of my games up until now. And I don't find their reasoning valid in the least. At least do a poll or something. Its removal is obviously annoying a lot of people.

I understand that, but part of the reason you use a game engine is to have it help you to get a good result, and I can't find any source that tells me how to prepare sprites for UI, which filtering mode to use for which sprites, and pitfalls to avoid when drawing them. That's a lot to ask about in a forum post, but I guess I'll have to. I think we'll go the vector graphics route, but as you say, another can of worms, and one I haven't opened before.

For a guy who has spent the last 20 years doing OOP, figuring out how to translate what I'm used to doing into whatever it is DOTS/ECS wants me to do, just doesn't click for me. But it'll have to, eventually.

I was under the impression that running hybrid would essentially make the benefits of ECS/DOTS simply not apply to Monobehaviours, but let them run "alongside" ECS/DOTS. Are you telling me I can still use OOP etc. and still take advantage of the new systems? Not fully, I imagine?

We use Amplify, as well, but are finding it hard to do certain things without light info. All the posts I've made and found on that subject go unanswered (along with how to make a particle that receives light), except that I should make my own lighting shader. Another thing I have to master somehow. Or am I missing something?

I wouldn't want that button. You have to know that's not what I'm asking for here. I wouldn't have a job, then. I have no problem with having to learn things or make forum posts. It's that after working with this engine for 7 years, the basic UI is still buggy and a mystery, I still don't know what exactly is the right way to draw sprites that will look good on a canvas and how to set it up properly for multiple resolutions, and this is the 5th time I've tried diving into Unity UI to really understand how to make it work and look properly, and what I'm finding is a whole lot of people who have given up and bought a UI asset that works properly. THAT annoys me. And the devs keep saying it's working as tended, but it is exceedingly hard to make it look good and not have gaps and such in certain resolutions. I'd just like some more information about how to use their engine optimally than is currently in their docs, especially their confusing UI (about which several blogposts have been written to point out its weirdness).

But in summation, this is all a rant after fighting Unity UI for the past 3 weeks, ending back where we started after hitting walls every step of the way. It is highly likely that I am simply an idiot, though I did make it through an MSc. I just hoped I would have a better grasp of how to make a game after all this time, but it just keeps getting more complicated to do the same things; even things you'd think were simple to create in a game engine, like dynamically sizing textboxes that don't require expensive hacks. I mean, all games have these. Why is there no help for making them and no way to do it without dumb hacks? It's weird to me. If I was making a game engine, I'd try to make it easy to do the most common things, like some other parts of the engine does. UGUI doesn't seem to want to help me. It just wants to give me more work. I want a box with Text in it, using a 9-sliced sprite as background. Should be maybe 8-10 clicks. Instead, it's a wasted weekend.

TMP will work soon enough, though. The standard Text component is one of the worst parts, so having TMP back will make me happy again. But I'm trying to decide whether to do a 6th dive into Unity UI or to find a UI asset that works better for doing layouts. Flexbox 4 looks neat, as it professes to be a drop-in replacement for Unity's layout components, but working ones. But as I said, I'd rather just know how to use Unity's UI properly...it's just so weird, inconsistent and buggy that it's hard to figure out what the problem is, which I need to do in order to Google how to fix it. Huge sigh. I'm usually able to solve anything, but particularly the UI is frustrating me to no end.

Anyway, thanks Your calm response has given me renewed hope, that it might be possible to fix some of these seemingly impossible things. I'd still like the launcher back for debugging purposes. I guess I'll try that replacement posted above.

 

Have you tried preview versions higher than 2.0.1? (Enable experimental in package manager)
I'm pretty sure I was running 2019 with HDRP + TMP ~2.3.0 just fine before updating to 2020.

Actual reason for this dialog removal is native platform support complexity, constant bugfixes and updates.
Some OS are trivial to maintain, others (looking at MacOS) are nightmare when new versions come out.

This is my speculation, but probably close enough to the truth.

Its really a vast topic, there's plenty of info in the net on both raster vs vector.

Yes, you can have benefits from ECS and have MonoBehaviours running in the same project. No need to force everything to ECS. This is how I use it currently in projects.

Moreover, with .AddComponentObject its possible to attach MonoBehaviours directly to entities, query them from systems, and perform operations directly on MonoBehaviours. This will not have performance benefits of burst, memory alignment and other data optimizations, but there's way less boilerplate code than it was before. (from 2019.4x+ onwards)

You should ask on Amplify discord server. Folks there really helpful.

Also, particle shaders are pretty simple to recreate in even Shader Graph (which I did for my project). All you have to do is download builtin shader sources and see what data particle system is using. Then recreate it with nodes. Default particle system shader is unlit for designer tweaking purposes, but I'm pretty sure its possible to make a lit one. And I pretty much sure I saw one from UT member on a forum somewhere.

There's always a https://docs.unity3d.com/2020.1/Documentation/Manual/script-ContentSizeFitter.html
Although it can be tricky to use sometimes, in the end it does what it suppose to do - resizing RectTransforms.

 

The dialog window on Mac was working for 10 years, I don't think it required nightmare upgrading issues between OS releases, even the older builds are working with the dialog window on Catalina.

Its true that this did not have any use on mobile and consoles, but during development when making test builds it had a great benefit.

 

I have not, in fear of even more weirdness I'll be attempting a move to 2020 soon, just to see how much the project breaks. If it doesn't break too badly, I'll update it, but right now we're at the end of a vertical slice, so it's not really feasible to do right now. Thanks for the tip, though! It just might end up being the solution for this whole TMP-thing, without having to wait.

That's what I would think, and it would be perfectly fine with me, but that's not the reason they gave. Instead, they say they based their decision on data mining results? That's weird.

True, and I've read a lot of it. But it still doesn't sit right with me, that it's extremely difficult to put an image on a canvas and have it look good, in a program that's made to make you able to do exactly that. It's like a game with no tutorial, relying on people to start a wiki for it.

You, sir or madam, have made me very happy, even if it's mostly as I thought about the optimization part. I thought I had read up on DOTS/ECS, but I guess it was about a year ago now. A lot more information is available now.

Thanks, I will! I always forget Discord as a source. I'm a forum rat

The one he posted was in a unitypackage of shaders slated for being added into Unity later (I don't know if they have been yet), but people were having some trouble with that shader. I couldn't make it work properly, but I'm not much of a shader-guy. I'm used to just having the basic shaders I need. I've actually had those on-hand in Unity until I went to HDRP, except in the projects where we had a technical artist. But I guess I have to get into shaders some more, as well. I've only ever coded a few of my own, never used a shader creator.

I've tried. When using it with a Layout Group, it doesn't correctly account for the scale of its children on both axes, despite ticking "Use Child Scale" on the Layout Group for both axes. I made a post here about it.

Thanks again! You remind of how I act on the Don't Starve modding forums. Calm and exceedingly helpful

 

The input manager was ugly. Uglier than the splash screen! It was user unfriendly. I'm glad its gotten rid of.

We are better off without it. Its a not a good UX to rely on the user editing settings through this window.

If a user has multiple screens, they are a power user. Just rely on them to use their preferred screen as their main screen.

I have a successful commercial PC release without this input screen, and users cannot change their window (they would have to restart the game and change their Windows main screen setting). I have received *zero* complaints.

Not having the input screen makes your title look a lot more professional.

 

The point for many people was not about released games, it was about quickly trying different settings during development

 

If you want to 'quickly trying different settings', you can launch from command line. Important settings are there.

Unity sent out a survey a couple of weeks ago that they want to revive the dialog. I'm afraid, they will. Instead of what they should do: help us to build a proper launcher app inside our projects.

 

Command line is not the same thing, you use the unity editor right? you can also use command line to code your whole game and yet thats is not a solution suitable for everyone. I for one like a GUI editor for these things. And I also appreciate that there is a command line option for users who prefer that.

 

No one said it is the same. I said it is fast.

 

This seems to me like a gap that a Unity Store asset should fill....

I'd also note that the interaction between the input launcher and the ingame Options were a source of bugs for me. When I got rid of the launcher and just relied on good ingame Options functionality as well as some auto-settings, these bugs disappeared.

It would be a backwards step for Unity to reintroduce the launcher, unless its integrated into some kind of fancy patching or DRM system.

 

Among a ton of other things, this is the reason I'm saying they shouldn't reanimate that zombie, they should give us a framework/tool to build a proper launcher. They can help us writing performance tester to auto-setup, writing proper settings, sharing the settings between the launcher and the in-game settings, etc. At the very least.

 

The question is... will this ever happen? Very little probability, imo. While it's true this would definitely be the best outcome, I'm not into the whole logic of "Don't do X because Y could happen even though it's nearly guaranteed it will not"

 

Silence from unity right now... would love to see an official replacement/framework

 

It appears to be still in the "planned" section.

https://portal.productboard.com/gupat5mdsl4luvs35fqy5vlq/c/408-display-resolution-dialog

 

Such things are why i tend to use UE over Unity ^^
So if you find out that most (BUT NOT ALL) people disable it, why not making it deisabled by default then instead of removing it?

 

UE has a Display Resolution Dialog? Where can I find it?

 

Resolution dialog was the only way to enable Stereo Display.

Moving forward with the new dialog-less setup, is there a way to get the same display detection for 3d projectors and lightfield displays that Resolution Dialog offered?

 

well, i just encountered this because i recently got a 50" inch TV, so at 4K in fullscreen it seems certain builds in Unity 2021 that were fine in 1080p now run like molasses. i'm a teacher that develops simple 2D and 3D games for students, and was hoping i could turn on the old reliable display resolution dialog to fix the issue, only to find in this thread that it's been deprecated in favor of - nothing (nothing internal to Unity Editor at least). yippee.

i do find that dialog useful in testing, and it really seems inexplicable to just take it out entirely (i can see not making it the default option of course). it's obvious that pro devs making a high quality game would set resolution with an in-game section but things like Itch.io game jam games should just have an easy way to set custom resolutions. i suppose i'll just set things at 1080p and hope things work consistently.

 

Absolutely bloody annoying actually..

Build & Run.. asically launches your game in fullscreen.. .unless you goto extra lengths to do something else about it... gone was the launcher that gave you some resolution options to pick before the game is launched.

This was on the roadmap as a new thing they were doing, where is it gone?

 

I just found this was totally removed and yeah it's a stupid move by Unity. I get they intended it for only developers or whatever. I get there are 3rd party options out there. However without having to spend any effort we really need this as an option.

What they should have done was simply change the default so it didn't include it but leave it as an option. Developers could choose to go into the player options and enable if it they need it. I don't care what reasoning someone has to remove it (I read the other threads, I actually don't see the reason why they removed it).

Hopefully it comes back in some form, but please don't make it a 3rd party solution. A package would be fine as there are some core packages I always include (post processing, TMP, etc.) so having it as a package would be okay as long as I don't have to write code to invoke/configure it (in some cases I have quick tests that have no code and I don't want to crack open C# to turn this on).