Search Issue Tracker
Duplicate
Votes
64
Found in
5.0.2f1
Issue ID
704405
Regression
No
Button position is wrong on fullscreen player which aspect ratio is different then monitor's
Steps to reproduce:
1. Open attached project's scene "BrokenButton".
2. Check how button is highlighted.
3. Build and run project.
4. Choose 1024x768 resolution on 16x9 monitor. (fullscreen)
5. Hit Play! and observe how button gets highlighted.
-
lexx2real
Aug 12, 2015 09:19
This problem plays and I and friends.
And in the last fifth version, and 4.6.7f1 -
movra
Aug 10, 2015 21:12
So I pushed a bit for an answer and got this:
Alex Lian: "Not a 5.2 specific feature and pushing for ETAs/schedules isn't assisting us in any way.
In checking on things for 704405:
1. It's been noted as a input issue internally, and being marked duplicate of another bug
2. This input issue is marked fixed, though not clear in landing in which build/release.
May not make 5.2 final build, but possibly a patch-release."According to the roadmap, 5.2 final is scheduled for Sept 8th. And then a patch release after that, so that could be over a month from now.
In the meantime you'll have to work around the issue by e.g.:
- offering only exclusive mode
- disabling the resolution dialog and adapting to the user's aspect ratio through code
- or just forcing it to 16:9 and ignoring the problems with the other aspect ratios -
jimmikaelkael
Aug 10, 2015 12:59
Just noticed that it doesn't happen when using Exclusive fullscreen mode.
-
jimmikaelkael
Aug 10, 2015 10:49
Any news about this issue ? Is it going to be fixed soon ?
-
melkior
Aug 08, 2015 20:29
Having same problem. Interestingly on my Win 10 system it does not repro, but on my Win7 box it does?
-
hoopsnake
Jul 27, 2015 16:45
I am experiencing this issue as well in full-screen modes where the resolutions do not match the native resolution.
After setting a software cursor, I realized that the software and hardware cursors did not line up. Their (0,0) was identical, but as a panned from the left to the right with the mouse, they grew increasingly distant. The hardware mouse thought it was at native resolution, while the software mouse traveled the equivalent distance based on the reduced resolution.
-
movra
Jul 23, 2015 20:17
So there are 2 problems at play here:
1) D3D11 doesn't render the chosen resolution / aspect ratio.
In Unity 5.1.2 non-native resolution on borderless fullscreen windowed results in a screen stretched to fit the desktop resolution. For example if you chose 640x480 (4:3) it will be stretched to 770x480 (16:10) on a 1920x1200 (16:10) screen.
In Unity 5.2.0b3 non-native resolution is just completely broken. 800x600 has pillars on the side and the bottom half is black.
2) The UI interaction is confused by problem 1).
-
thisisashan
Jul 17, 2015 21:30
I just spent a solid 24 hours looking for a fix, finally stumbled on this here.
As there is no workaround posted, well pretty much anywhere, this is a huge roadblock for people who are new to unity, and are trying to learn the GUI. I was making sure GUI scaling was working and ran into this.
Windowed is fine, but fullscreen the mouseover etc breaks.
Any news on a fix? -
Tim-C
Jul 17, 2015 08:34
HI, this is with the graphics team / input team. They will be looking into it.
-
Arachin
Jul 13, 2015 15:38
Same issue here... I'm sure I could hack around it, but I'd prefer not to.
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
- GPU utilization increases by 20% on Meta Quest headsets when Render Graph is enabled on 6000.0.16f1 and higher
- Value on Slider (Int) control in UI Builder displays as default when saving UI Document
- Color mismatch in UI Builders Library panel when the Editors theme is set to Light Mode
- [Android ] "AndroidJNI.ToBooleanArray" returns a random non-zero value instead of "IntPtr.Zero" when the method argument is null
- Non-HDR color picker opens when selecting material color with HDR enabled
This is a duplicate of issue #715666