FairyGUI provides a UI adaptation strategy that automatically adapts to the resolution of various devices for game development, which means that developers only need to create a set of UIs to adapt to all resolution devices.
Usually we choose a fixed resolution for UI design and production. This resolution is called design resolution. For example, 1136×640 and 1280×720 are relatively common design resolutions. When a design resolution is selected, the size of the largest UI interface (usually the full screen interface) is limited to this resolution.
The resolution of the running device is called the device resolution. This resolution is not necessarily the same as the design resolution. You need to project the UI interface to the screen with a certain zoom.
When the design resolution and device resolution are inconsistent, the first thing to do is global scaling. This global zoom is transparent to the inside of the UI, which means that all UI interfaces don’t need to worry about the existence of this zoom. For example, if the overall size is doubled and the size of a window is 400×400 pixels, the window size that will eventually be displayed to the screen will be 800×800 pixels, but if you read the width and height of this window, it will still return 400×400. , all internal coordinates will not change.
The screen size after global scaling is the logical screen size. In the above example, the device resolution is 1280×720, and the global scaling factor is 1.125, then the logical screen size is (1280/1.125=1138, 720/1.125=640)= 1138x640 . The size of the GRoot UI root component always fills the logical screen, that is, the size of the logical screen can be obtained by GRoot.inst.width and GRoot.inst.height.
After global scaling, most UIs don’t need to be adjusted. With one exception, they are designed to be full-screen. In the above example, at the design resolution, the size of the full-screen interface is 960x640, and we also design full-screen components by this size. After global scaling, the size of the logical screen becomes 1138x640, and the size is inconsistent. At this point we need to resize the component to make it full.
In general, the screen size will not change after entering the game. But if you are developing a desktop game, or a game that supports horizontal and vertical screen switching, that is, the screen size will change, then the full screen interface also needs to add constraints on the screen size.
Of course, this is just one way to handle a full screen interface. In some cases, such as the “MatchHeight” mode, which is a high-priority adaptation method, this method ensures that the vertical direction of the UI interface is always full, and the horizontal direction may exceed the screen. This kind of adaptation requires the designer to have a “safe area” design thinking, and can’t arrange content beyond the screen. For example, center the full screen interface and sacrifice content on both sides.
In this way, the left and right edges will be cropped off by the edge of the screen, which requires the designer to take this into account when designing.
The full-screen component needs to be reset to full screen during the adaptation process, and the component size will change. In this case, the associated system needs to be used to automatically lay out the elements in the component in the correct position.
I hope that my strategies can help you.
