{"id":102,"date":"2013-11-04T10:49:51","date_gmt":"2013-11-04T09:49:51","guid":{"rendered":"http:\/\/mczerwonka.pl\/dev\/?p=102"},"modified":"2022-05-07T19:07:17","modified_gmt":"2022-05-07T17:07:17","slug":"unity-gui-resolution-independence","status":"publish","type":"post","link":"http:\/\/mczerwonka.pl\/dev\/unity-gui-resolution-independence\/","title":{"rendered":"Unity GUI: resolution independence"},"content":{"rendered":"

When using Unity GUI, you usually want your UI to be resolution independent. And you never know what resolution the user will run your game with,\u00a0when building for desktop (or floating canvas webplayer).<\/p>\n

Unity GUI works on absolute screen pixel coordinates, where (0,0) is top left corner of the screen, and (Screen.width, Screen.height) is bottom right corner.<\/p>\n

First thing I do when working with Unity GUI is picking neutral resolution. I design my UI to be ideal for this resolution.\u00a0Let’s say my neutral resolution is 1024 x 768 and I have three GUI elements:<\/p>\n

\n
GUI.Box ( new Rect (0, 0, 1024, 768 ), \"full screen box\" ); \nGUI.Box ( new Rect ( 10, 10, 400, 400 ), \"top left box\" ); \nGUI.Box ( new Rect ( 1024 - 410, 768 - 410, 400, 400 ), \"bottom right box\");<\/code><\/pre>\n<\/div>\n
\"Screen<\/a><\/p>\n
It looks as I expected, as soon as my game runs in 1024 x 768, which was picked as neutral resolution.<\/p>\n
<\/p>\n
When I \u00a0run this code in the editor, and won’t allow game window to maximize – my UI will not scale itself to fit the window. It will rather extend beyond the viewport, as you can see on the screen below.<\/p>\n
\"Screen<\/a><\/p>\n
There are two (well maybe more, but I will focus on two) ways to make this code resolution independent: docking and scaling. Each of them has its advantages, and disadvantages which depend mostly on the effect you try to achieve. Main differences between them is: do we fix positions, or do we fix sizes?<\/p>\n
I will use game window as test environment for these two methods.<\/p>\n
<\/h2>\n
Docking<\/h2>\n
What would happen, if I changed hardcoded constants 1024 and 764 to Screen.width, and Screen.height accordingly? Let’s see:<\/p>\n
\n
float width = Screen.width; \nfloat height = Screen.height;\nGUI.Box ( new Rect (0, 0, width, height ), \"full screen box\" ); \nGUI.Box ( new Rect ( 10, 10, 400, 400 ), \"top left box\" ); \nGUI.Box ( new Rect ( width - 410, height - 410, 400, 400 ), \"bottom right box\");<\/code><\/pre>\n<\/div>\n
\"Screen<\/a><\/p>\n
The positions of elements are not absolute anymore, but relative to screen edges and this relation is fixed. In other words – positions are always relative to screen edgesa and this relation does not change with resolution change. I call this method docking, because it “docks” x and y coordinates of each control with one of screen edges (x with left or right, y with top or bottom).<\/p>\n
\n
\/\/ docked to left and top edge of the screen \nGUI.Box ( new Rect ( 10, 10, 400, 400 ), \"top left box\" ); \n\/\/ docked to right and bottom edge of the screen \nGUI.Box ( new Rect ( width - 410, height - 410, 400, 400 ), \"bottom right box\");<\/code><\/pre>\n<\/div>\n
Other thing we can see is, that the boxes now occupy most of the screen and top-left box overlap the text of the background box.<\/p>\n
This drawback results from the fact, that box areas did not change, when we changed resolution. This is great advantage if you want your UI to be pixel perfect, but becomes problematic when you have big controls and need to switch to lower resolution (like in our scenario).<\/p>\n
Scaling<\/h2>\n
When using scaling, boxes positions change when changing resolution, but relative area of boxes\u00a0remain the same (they occupy the same percentage of area they did before resolution change). Example of scaling code:<\/p>\n
\n
float xFactor = Screen.width \/ 1024f; \nfloat yFactor = Screen.height \/ 768f; \nGUIUtility.ScaleAroundPivot( new Vector2 (xFactor, yFactor), Vector2.zero); \nGUI.Box ( new Rect (0, 0, 1024, 768 ), \"full screen box\" ); \nGUI.Box ( new Rect ( 10, 10, 400, 400 ), \"top left box\" ); \nGUI.Box ( new Rect ( 1024 - 410, 768 - 410, 400, 400 ), \"bottom right box\");<\/code><\/pre>\n<\/div>\n
Function GUIUtility.ScaleAroundPivot changes GUI transformation matrix, so that each GUI control drawn below it will be scaled by the values of Vector2 we passed to it.<\/p>\n
\"Screen<\/a><\/p>\n
As you can see, I didn’t have to change UI drawing code at all – which is a big plus of scaling, when you have lots of controls which positions depend on each other. But also, there is a drawback. You can forget about pixel perfect when scaling the UI, as absolutely everything will be scaled up\/down to maintain the relative size of neutral resolution.<\/p>\n
Each of these methods can be expanded for actual needs (ie. docking with size modifications, scaling with UI centered etc.), but this is out of the scope of this post.\u00a0To sup up – I use docking whenever I need my UI to be pixel perfect. But whenever I do not, or I want to have scaleable UI in the editor – I pick scaling.<\/p>\n","protected":false},"excerpt":{"rendered":"
When using Unity GUI, you usually want your UI to be resolution independent. And you never know what resolution the user will run your game with,\u00a0when building for desktop (or floating canvas webplayer). Unity GUI works on absolute screen pixel coordinates, where (0,0) is top left corner of the screen, and (Screen.width, Screen.height) is bottom right corner. First thing I do when working with Unity GUI is picking neutral resolution. I design my UI to be ideal for this resolution.\u00a0Let’s say my neutral resolution is 1024 x 768 and I have three GUI elements: GUI.Box ( new Rect (0, 0,\u2026<\/p>\n","protected":false},"author":1,"featured_media":106,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[2],"tags":[4,9,10,11,12],"blocksy_meta":{"styles_descriptor":{"styles":{"desktop":"","tablet":"","mobile":""},"google_fonts":[],"version":5}},"_links":{"self":[{"href":"http:\/\/mczerwonka.pl\/dev\/wp-json\/wp\/v2\/posts\/102"}],"collection":[{"href":"http:\/\/mczerwonka.pl\/dev\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/mczerwonka.pl\/dev\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/mczerwonka.pl\/dev\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/mczerwonka.pl\/dev\/wp-json\/wp\/v2\/comments?post=102"}],"version-history":[{"count":13,"href":"http:\/\/mczerwonka.pl\/dev\/wp-json\/wp\/v2\/posts\/102\/revisions"}],"predecessor-version":[{"id":141,"href":"http:\/\/mczerwonka.pl\/dev\/wp-json\/wp\/v2\/posts\/102\/revisions\/141"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/mczerwonka.pl\/dev\/wp-json\/wp\/v2\/media\/106"}],"wp:attachment":[{"href":"http:\/\/mczerwonka.pl\/dev\/wp-json\/wp\/v2\/media?parent=102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/mczerwonka.pl\/dev\/wp-json\/wp\/v2\/categories?post=102"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/mczerwonka.pl\/dev\/wp-json\/wp\/v2\/tags?post=102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}