What's the resolution dialog replacement?

In 2019.3b07 the resolution dialog setting is gone. What is the replacement setting?

 

Thanks, I'll try the command line options. It's tough without a dialog when you want to find out which resolutions you can use so that DXR still performs

 

No, not at all. Because it should be the user's choice to select something from a proper dialog and not have to mess around with scripts

But I see your point. Everyone should make their own resolution dialog in-game.

Does Unity provide an example for that?

 

Yeah, that's my use case. Testing and prototyping. Currently finding out which resolutions perform eg for HDRP and DXR. I guess I'll have to create my own external app for that now.

It would be really nice if Unity Learn could provide an example settings in-game menu.

 

This makes no sense. You removed an OPTIONAL feature because most but not all people didn't use it? What about the people that did use it for things like game jams? This just seems like an unjustified punishment to users of a feature that most people opted out of. I either have to code in-game options UI or rollback to an older version of Unity, neither of which seem like a great options for a 48 hour jam. Decisions like this are driving me to start looking at other engines after so many years with Unity.

 

I'd like to see that too...

 

https://learn.unity.com/tutorial/live-sessions-on-ui#5c7f8528edbc2a002053b4b9

 

Ok Unity, you really messed things up. Players often want to play the game on their 2nd monitor, so could you at least put the option back so players can choose the monitor to play on?!

 

So Unity, can you provide an example please.

 

What about https://docs.unity3d.com/ScriptReference/Camera-targetDisplay.html?

 

How will be multi monitor setup with this, to let player select another screen?

I hope there will be a good option for that...

It's bad activating the other monitor after the game launches since the first one gets locked too (at least in older versions).

 

My problem with the removal of this is, sure, few developers used it in the final builds of their games that they shipped. But now ask how many developers used that menu during development? I think you'll find 99% of them did.

The lack of the menu option means we have to manually build our own menu while still in the early stages of development. Or in my specific situation, we are using Unity to make internal applications where we just need something simple and solid that we know works, and now we have to spend resources and money making our own menu, to replace a good one Unity already had (and as you said, "support cost for this thing wasn't insignificant." - now that cost falls on all us users). And in our case, being able to choose the primary display from the start is important, and I don't want to make non-developers use commandline parameters.

It sounds like you had problems with the input system, just remove that section and leave the rest.

 

My suggestion... (I do rely a lot on that due to use of multi monitor setup)

At least please provide an open source launcher with the same functionalities: selecting the monitor screen, windowed mode and resolution in a list! That would be great. Turn open source that multiplatform launcher as a separate file and depreciate/remove it, keeping the command line params sent to the executable. So it will be a win-win situation.

 

I agree completely with @Dreamback. Unity will save the effort to maintain it, but now all developers have to do the work themselves.

We use the resolution dialog in almost all unreleased projects. I find it very useful for prototyping. Of course, in a commercial release it's less "professional" to have it enabled, but that doesn't mean there's no use for it in another context. A command line option will not replace it. I regularly send standalone builds (prototypes) to people who don't know how to use a command line parameter.

Why not just clean it up a bit, remove the input tab, and disable the resolution dialog by default, so devs only use it when needed?

 

The last time I looked into it was for Unity 2018.3, I believe. I wanted to implement a "Select target Monitor" option in my in-game options menu. At this time, it wasn't supported by Unity.

If the resolution dialog is being removed, it would be helpful if you can provide an API that allows us to replicate it an in-game options menu what the resolution dialog was supposed to do. I believe the only thing that is missing is an API to select the target monitor.

 

I am all for getting rid of this dialog and putting it in-game, but you are still not exposing the needed multi-platform APIs at runtime! I am not sure how you expect devs to utilize command line args on a shipped title. Are you expecting the devs to write a custom launcher app for all three platforms (Windows/Mac/Linux)? No one wants to spend dev time writing a launcher app instead of working on a game.

We need runtime access to the command-line args at runtime inside the player that we currently don’t have. This includes:

• Display index (with appropriate APIs to query display names/IDs)
• Fullscreen/Window modes (windowed, popup, borderless, exclusive)
• PlayerPref serialization of these fields so we can serialize them properly for the next player launch. Having the window jump around on the first script is awful UX.

It has been years since I have looked at the standalone experience and these features are still not available. I am very disappointed. I am not sure why Unity treats their standalone player like dirt with it being a major platform. Look at DOTA2, Battlefield, or any Blizzard title to see examples of display settings that our users expect. Please expose them at runtime for us like a multi-platform engine should!

 

PlayerPrefs - What I mean is that there needs to be similar (and documented) fields that remembers the display index and fullscreen/windowed mode in addition to the resolution/fullscreen bool toggle so there isn't startup jank that occurs.

Pop-up Window Styling (AKA no border, titlebar window) - There is a usefulness to having a borderless fullscreen windowed view in Windows. It allows you to have a fullscreen window and alt-tab out of the window without minimizing the application. This is useful for streamers, bringing up a chat window, or skype or something. We'd only ever do it on products when the user selected the display's max resolution from the resolution drop list and didn't have fullscreen checkbox selected. However, it was a requirement for our products. So we had to hack windows-specific styling which I would like to avoid. It should be exposed if you allow it in a command line (popup command). We couldn't ship a command line launcher with our games so we had to do some Win32 Window styling nonsense on first update, but that again created the aforementioned startup jank.

I hope that helps!

 

You are correct. I just tested it with 19.3 instead of assuming nothing had changed. The version was in the 5.x lifecycle when I was last testing it. I think 5.3 or so. The FullScreenWindow does indeed look pretty close to what we ended up with. Thanks for your patience to educate me.

I do still hope that display adapter enumerators and pickers can be added ASAP (which was the last big thing the resolution dialog provided).

 

That's actually part of the jankiness - if we want to create our own startup config screen similar to the old Unity one, that shows up every time the app is run (because resolution and display are important parts of our business app), we can't. Let's say our app is run the first time, we can create a small popup-style window with the config settings, similar to before. The user chooses full screen/4k, great! But next time the app runs, instead of bringing up our small popup config screen, it starts in full screen/4k. If to counter this we then switch the resolution to small/windowed like before, it really looks bad to be switching resolutions like that. So instead we have to try and make our config screen look professional at every possible resolution / mode, just for a simple screen config picker for our business apps, something Unity used to do for us.

What we need then to truly create our own config screen similar to the old one, is to either make the config a separate app entirely (ie, a launcher), or we need Unity to add options to force our resolution/presentation settings in the Player Settings configuration in Unity, ignoring the previously chosen settings.

 

This should have been a consideration much earlier, especially considering the display target issues mentioned before. I leave the alt-startup so that people can do their display targeting on their own because this has been a pain point in Unity for years now.

 

The problem ends up being that the resolution dialogue is a real chicken and egg situation. Part of the reason nobody used it ended up being the following:

1. It was ugly
2. The total lack of customization aside from a header made it so there was no way to make it not ugly
3. Its functionality radically decreased as assets like InControl and Rewired came out to deal with the input system shortcomings
   
4. These problems existed for years without any of them being addressed at all

The situation with Unity feels increasingly "these things are bad, but rather than address them we'll just deprecate them with little notice" and that's not great. It makes sense in situations like UnityScript and Boo being deprecated because there were alternatives to those built into the engine. There was no alternative to the launcher system and the runtime support for some of its features were completely non-existent.

 

I think just bringing back the graphics-related settings (like resolution, fullscreen and such) would already be enough. Especially with the new input system, I can imagine that a remapping system would complicate things quite a bit.

 

This question belongs in the Input System forum, not a thread about the resolution dialogue. Not only that, but it's in the documentation:

https://docs.unity3d.com/Packages/c.../manual/ActionBindings.html#runtime-rebinding

 

Hi. Please re-add an monitor selector and
an api to start on which monitor (0,1,2) too.

We use Unity heavily in simulation with multi display setups and multiple unity instances.
E.g.
- main car scene runs on big screen monitor 1.
- UI scene 01 runs on touch screen (must be monitor 0 because of touch input) and is streamed to main scene
- UI scene 02 runs on transparent screen as HUD simulation and is streamed to main scene too

in 2019.3 we are not able to start up our systems on the right displays/touch screens anymore.

 

there are also several other forum posts...

https://forum.unity.com/threads/the...d-will-be-removed-in-a-future-version.670798/

https://forum.unity.com/threads/whats-the-resolution-dialog-replacement.762551/


Rewieving and building in Unity 2019.3

- Fontainebleau, (no chance to select resolution or monitor anymore)
- SpaceshipDemo, (nice approach but you must switch through all resolution to get to the target one, no monitor selector anymore)
- SmallOfficeRayTracing (crashes when resolution is to high, e.g. 3840x2060 is set on display, set lower res or start on display with lower res is not possible anymore)
and
- DOTSSample

shows nicely that a common solution would save a lot of redundant work and would deliever a more consistent experiene.

 

Has there ever been any resolution to this? I do a lot of trade/auto show experiences and it was handy to use so I could set my app to open on a different display and still utilize my main monitor to remote in and make content updates and what not. As it is not I cannot choose which monitor it opens on becuase it will always open on the main display. Which if there are any notification or anything they will pop up with the App where everyone can see it all.

How is it possible in 2019.3.0 f5 to even programmatically set the start monitor to display 2?
And even then sometimes I have 3 screen. 2 showing content at different resolutions and 1 as a the primary display where I can do all my moving around in the background.

 

What parameters can I use with -monitor? I am on https://docs.unity3d.com/Manual/CommandLineArguments.html but I do not see monitor anywhere

 

My bad didn't realize I was on 2019.2..Working now thanks!

 

I'm not sure I'm at all in love with the idea of having to make an entire launcher for my game to replace something that used to come standard with Unity.

 

Seems there is an new deprecation process installed.
Simply click to remove and find min 10 people who never used it.)

* Realtime GI
* Dispay Resolution Dialog
* Camera Stacking
* MSAA and TAA together

 

So everything works fine if I am using multiple displays and only content on one screen and just the desktop on display 1. I use -monitor 2 to start the app on display 2 and desktop is available on display 1. Works!

But... What if I have mulitple displays and have different content on each display. Example Camera 1 on display 1 and Camera 2 on display 2. If I set it to -monitor 2 it won't start on display 2 and 3. Displays 1 and 2 always show the content and not 2 & 3. If that makes sense.

And Display 1 never displays fullscreen even with -screen-fullscreen 1
Seems to always be in windowed mode.

 

Wrote over 100 bat files this week to test different projects in 2019.3. All have multi monitor, gpu and resolution setups. with different resolutions.

The command line parameters work. But; if you have a little error in one of the command line parameters. the following ones are not executed.)

My hitlist...

1. forgor a - somewhere
2. gpu starts with 0, gpu 2 is 1
3. monitor starts with 1, monitor 2 is 2

What a waste of time that every Unity User must create a own console,screens dialog or bat. files now.
Not so nice.

 

I have to agree. The Launcher was ugly but helped more then trying to figure out multi monitors with command line arguments that I have to remember to add each build or its displayed wrong.

 

That and I can't figure out on a 3 monitor system how to get a 2 display app to show up on monitors 2 and 3 where 1 is the primary where I can do work behind the scenes if needed. Everything I've tried it always wants to show on the primary monitor. Works fine with 2 monitors and 1 screen showing content with my primary monitor to work on but not with 2 like i was able to get going in 2018

 

MoveWindow works fine if I only have 1 camera and its set to display 1. (From what I've been able to do unless I am missing something)

but..
In my case I have 2 cameras. One is set to Display 1 and the other is set to Display 2. Both show different content. Both have displays activated.

My Monitor Set up
[display 1 (primary)] [display 2] [display 3]

How I want it to work
[display 1 - used for doing things behind the scenes] [display 2 - Camera 1 Display] [display 3 - Camera 2 display]

When ever I use Move Window Unitys display Camera for Display 1 shows on display 2and Unitys Display Camera for Display 2 shows up behind Camera for Display 1 when I need it on display 3.

How would I move multiple camera with multiple camera displays? Is this even possible?

 

I couldn't figure out if it was pssoble to move any disaplys other then display 1 to monitor 2 with the Windows API MoveMWindow but I ended up writing into my script if there was more then 1 screen to change the cameras target display to 2 and 3. This left my primary monitor white since it was activated initally so I added the MoveWindow to what is below to hide it and now it's atleast working the way I need it to.

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4. using System.Runtime.InteropServices;
5.  
6. public class MoveWindowUtility : MonoBehaviour
7. {
8.     [DllImport("user32.dll")]
9.     static extern System.IntPtr GetActiveWindow();
10.  
11.     [DllImport("User32.dll")]
12.     private static extern bool MoveWindow(IntPtr handle, int x, int y, int width, int height, bool redraw);
13.    
14.     System.IntPtr ptr=System.IntPtr.Zero;
15.    
16.     void Update()
17.     {
18.            if(ptr==System.IntPtr.Zero)
19.            {
20.              ptr=GetActiveWindow();
21.            }
22.            else
23.            {
24.                MoveWindow(ptr, 0, 0, 0, 0, true);
25.           }
26.     }
27. }

 

Any chance to get a mac version of this? And are there any plans to publish the old screen/resolution selector as a (cross-platform) package?