Search Issue Tracker
By Design
Votes
0
Found in
2018.3.0b5
Issue ID
1090073
Regression
No
Game is runs in Fullscreen instead of Windowed mode when changing the build settings from Exclusive Fullscreen to Windowed mode
How to reproduce in 2018.2, 2018.3:
1. Open new empty project
2. File>Build Settings...>Player Settings
3. Set Fullscreen mode to Exclusive full screen and make sure Display resolution Dialog is Disabled
4. Build and close
5. File>Build Settings...>Player Settings
6. Set Fullscreen mode to Windowed
7. Build and run
How to reproduce in 2017.4:
1. Open new empty project
2. File>Build Settings...>Player Settings
3. Check "Default is Full Screen"
4. Set Display resolution Dialog to Disabled
5. File>Build Settings...>Player Settings
6. Uncheck "Default is Full Screen"
7. Build and run
Expected result: Built program runs in Windowed mode.
Actual result: Built program runs in Fullscreen mode.
Reproduced with:2017.4.13f1, 2018.2.13f1, 2018.3.0b6, 2019.1.0a7
Note: Only the first Player Settings are saved and built, changes afterward do not apply.
-
dradb
Jun 30, 2021 12:13
Thank you Solodevelop. So easy!
-
pengsuyu163
Dec 03, 2020 02:58
Thanks, I solved my problem by pressing Alt + Enter when I launcher the built exe. I didn't know why the exe become fullscreen when it is running, maybe because of my keyboard operation. But
it at least makes it possible to see the windows setting again by pressing Alt + Enter. -
darkAbacus247
Apr 20, 2020 03:45
Just hit this snag as well...
After some research I see that this has been an annoyance for the community for some time now...which is unfortunate.
If it's so simple to fix why do we all have to fix it rather than it just not being this way? Or at least put a note within project settings that will flag future folks with a warning. I had no idea this was a "Feature" so i've spent the better part of my day trying to rebuild projects in 1000x different ways thinking I must have messed something up. Turns out...nope not really.
...anyway, good to see that I can just correct this via code...but that's why I use unity, so I don't have to deal with silly stuff like this. I'm probably just upset but this reminded me of a "why did you put the milk in the cupboard and the cereal in the fridge?" moment (a$$ backwards).
For anyone looking for more direction, here's a helpful link:
https://docs.unity3d.com/ScriptReference/Screen-fullScreen.html?_ga=2.49926818.52793526.1586703418-2032696916.1585315865On a personal note this is frustrating because I seemingly have to include this chunk within EVERY project? And only found out by a blind mistake....so, there's my rant for the day.
-
soloDevel0p
Apr 04, 2020 15:01
If someone runs into this problem, here is the SOLUTION (not workaround) and the EXPLANATION (this is a feature, not a bug).
Solution:
1. File>Build Settings...>Player Settings
2. Resolution and Presentation>Allow Fullscreen Switch = enable
3. Launch game and press ALT + ENTER or COMMAND + ENTER (See your OS fullscreen / windowed toggle key)Explanation:
The launcher remembers the last state it had, so if it closed on fullscreen because you first builded the game with player settings specifying to launch on fullscreen (by default), it will keep opening in fullscreen even after you change the mode to windowed.
You can either set the screenmode to windowed by code or just press alt + enter. Once the game closes on widowed mode, you can disable the switch option on the player settings if for some reason yo don't want it. -
vargonian
Feb 25, 2020 07:37
If this is merely a feature, please provide a workaround. I am facing this issue in 2019.3.0b7.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
Resolution Note (2019.3.X):
This is a long standing design issue in Unity. Fixing it is more of a feature request in scope, and as such it is on our feature backlog.