UNITY2D Multi-resolution screen adaptation scheme

Transferred from: http://www.cnblogs.com/flyFreeZn/p/4073655.html

This article will describe a simple and effective unity2d multi-resolution screen adaptation scheme, which is suitable for unity2d games based on native development, that is, without the use of third-party 2D plug-ins, such as UNI2D,2D Toolkit and other developed games, Ngui plug-ins are not affected by this scheme. Can be used perfectly with this solution.

---------------------------------------the beginning of the split line-----------------------------------------

Let's start by explaining some basic concepts:

1. Aspect ratio of the screen aspect Ratio = screen width/Screen height

The size of the camera lens in the 2.unity2d determines how much of the game we actually see, and in the editor we can adjust the camera's size by adjusting the value of the camera's Orthographicsize property. As shown in the following illustration, the camera size is exactly the same as the screen size when the camera Orthographicsize property value equals half the current screen height unit. Note that this refers to half of the screen unit height, which is measured in pixels to the unit than the pixels to units, the default value for Unity2d is 100, that is, 100 pixels equals 1 units. If our game screen is 640 pixels high, then the actual conversion to unit height is 6.4 units, and when our camera's orthographicsize value is 3.2, the camera size is exactly the same as the screen size.

(This option allows you to adjust the pixel unit ratio per picture)

When you see this, you may question that the unity editor can only directly adjust the camera's height, and how the camera's width is determined. The answer is the screen aspect ratio we mentioned earlier. Unity calculates the camera's width value based on the actual aspect ratio of the current screen and the orthographicsize value of the camera, namely:

Camera actual width = Camera orthographicsize * 2 * screen aspect ratio

That is

Camera actual width = camera height * Screen aspect ratio

Let me give an example, IPhone4 's screen pixel is 640*960, the aspect ratio is 2:3, if the pixels to units value is 100, then if the camera height is set to a size of 4.8, then the actual camera width is calculated by the formula 6.4, just the unit width of the screen.

---------------------------------------the split line------------------------------------------

Well, with all that said, we'll know why our game has a different display on devices with different screen resolutions.

Different screen resolutions, the same camera orthographicsize values will produce different camera sizes, different camera sizes cause the actual display of the game content to be different.

Next I present two concepts, in order to facilitate the following explanation:

1. Effective content of the game, refers to the game must be fully displayed on the screen content;

2. The actual content of the game, refers to the entire content of the game, including the effective content and mainly for the adaptation of multi-resolution or other unimportant purpose of the added content.

Our development is generally chosen at a fixed design resolution, such as the common iOS vertical screen game Design resolution 640*960, we use this design resolution as an example. In general, the design resolution size is the size of the effective content of our game.

With this resolution, we set the orthographicsize value of the camera to 4.8. Suppose we do not do any multi-resolution adaptation processing, so that the effective content area of our game and the actual content area of the same size, both 6.4*9.6 (has done pixel-to-unit conversion, the same below), so that the game runs on a iPhone5 device (that is, the screen is 640*1136), Let's see what happens.

To get a better explanation, let's set up a variable:

Game effective content size is Gamevalidcontentsize

The actual content size of the game is gamecontentsize

camera size is camerasize the

actual screen size is screensize

screen aspect ratio is Aspectratio

Then the calculation begins:

Orthographicsize = 4.8

aspectratio = 640/1136 = 9/16

camerasize.height = Camera orthographicsize * 2 = 4.8 * 2 = 9.6
  camerasize.width = camerasize.height * Aspectratio = 9.6 * 9/16 = 5.4

Based on the calculation, we get the actual camera width of 5.4, while the game effective content width is 6.4, the camera width is less than the game effective content width, namely Camerasize.width < Gamevalidcontentsize.width = Gamecontentsize.width, when the game content was cut by the camera.

Here's an example of a little game I've done, and we can see the problem more clearly:

The first one is the effect of running on a 640*960 device, everything is fine. The second one is the effect of running on the 640*1136 device, you can see the game content is cut very obviously, the upper right corner of the button is almost gone.

How to solve this problem. The immediate idea is that if our game is on a 640*1136 screen device, the camera width remains 6.4, and that's definitely not cut. To do this, we have to adjust the orthographicsize value of the camera at run time. The method is simple, or apply the formula mentioned above:

Aspectratio = 9/16

in order to make Camerasize.width = 6.4, we calculate

camerasize.height = Camerasize.width/aspectratio = 6.4 * 16/9

Camera orthographicsize = camerasize.height/2 approx. =5.69 (because it is not endless)

Once again we run the game, dynamically modifying the camera's orthographicsize value to 5.69, you can see:

The wide aspect is completely displayed, but the top and bottom appear the "Black Edge" (here is blue side, hehe). This is because the height of the camera is already greater than the height of the game content, so there will naturally be no content area, that is, "Black edge." To solve this problem, we need to add the upper and lower sides of the game, directly on the black edge of the same size diagram is a method, but there is a more simple way to directly enlarge the game background to cover the black edge. This game is relatively simple, we use this simple method, we will enlarge the game background to 1.3 times times, as shown below:

Ok. Now that our game seems to be normal, we have completed the adaptation of IPhone5.

Notice that this time the effective content area of our game is not equal to the actual content area, we enlarge the background image, actually equal to the game added a layer of outer edge. In the picture, inside the white box is the valid content area, outside the white box is the invalid content area. The overall actual game content area is already larger than the active content area.

-----------------------------------------the dividing line of the final conclusion------------------------------------------

Based on the resolution process above, we can conclude that the actual resolution adaptation problem is related to three dimensions, namely: Camera size, game content size (including valid content size and invalid content size) and actual screen size. To be able to display the valid content we need and not show the black edge, we must ensure that:

The size of the camera must be less than or equal to the actual content size of the game, and must be greater than or equal to the game's active content size. As shown in the following figure, the blue wireframe indicates the size of the camera, so we can guarantee that the contents of the game will be displayed correctly as long as the blue box is in the white box.

As long as you can ensure this, our game can handle almost any screen resolution.

In the final analysis, the solution to screen resolution adaptation is to solve the problem of how to limit the size of the game camera to a given range.

To summarize, the steps are: first, you need to determine the effective content area and the actual content area of the game, and then, when the game starts, adjust the size of your camera to fit your game according to the actual screen aspect ratio.

-----------------------------------------the last split line------------------------------------------

Recently wrote a lot of small games, with this solution once and for all to solve the multi-resolution adaptation, especially Android device adaptation problems. The advantage of this approach is that as long as the understanding, the operation is very simple, on the other hand is different from the scaling game content of the scheme, this method to ensure the original game content. Of course, the disadvantage may also be some, temporarily can think of some need to rely on the camera to do the effect or operation of the game, change the size of the camera may have some impact. At present, the experience of this area is relatively small, I hope we can continue to improve the program.

Finally, I wrote a simple script to adjust the Orthographicsize value, to ensure that the width value of the camera is not less than the effective content of the game, the effective content size is 6.4*9.6. This script can take effect as long as it is attached to the camera on the game.

 1 using Unityengine;
 2 using System.Collections;
 3 4 public class Gamecamera:monobehaviour {5 6 float devheight = 9.6f;
 7 float devwidth = 6.4f; 
8 9//Use this for initialization () {One-to-one float screenheight = screen.height; 13
Debug.Log ("screenheight =" + screenheight); //this.
Getcomponent<camera> (). orthographicsize = screenheight/200.0f; orthographicsize float = this.
Getcomponent<camera> (). orthographicsize;
float Aspectratio = screen.width * 1.0f/screen.height;
float camerawidth = orthographicsize * 2 * aspectratio;
Debug.Log ("camerawidth =" + camerawidth); 
if (Camerawidth < devwidth), {orthographicsize = Devwidth/(2 * aspectratio);
Debug.Log ("New orthographicsize =" + orthographicsize); this. Getcomponent<camera> (). orthographicsize = OrtHographicsize; +/Update is called once per frame + void