Overview
Starting from Cocos2d-x 2.0.4, Cocos2d-x proposed its own multi-resolution support solution, abandoned the previous retina-related setting interface, and proposed the concept of design resolution.
3.0 has the following related interfaces:
- Director::getInstance()->getOpenGLView()->setDesignResolutionSize() //Design resolution size and mode
- Director::getInstance()->setContentScaleFactor() //content scaling factor
- FileUtils::getInstance()->setSearchPaths() //resource search path
- Director::getInstance()->getOpenGLView()->getFrameSize() //Screen Resolution
- Director::getInstance()->getWinSize() //design resolution
- Director::getInstance()->getVisibleSize() // Design resolution visible area size
- Director::getInstance()->getVisibleOrigin() //design resolution visible area starting point
As of cocos2d-2.1beta3-x-2.1.1,
- CCFileUtils::sharedFileUtils()->setResourceDirectory()
by the new interface
- FileUtils::getInstance()->setSearchPaths(searchPath)
substitute
Starting from Cocos2d-x 2.1.3, two new ResolutionPolicy (kResolutionFixedHeight, kResolutionFixedWidth) have been added, with a total of 5 modes.
Officially introduced in
Multi_resolution_support
and
Mechanism_of_loading_resources
.
This article analyzes the multi-resolution adaptation technology of Cocos2d-x from the perspective of engine users.
From Retina to design resolution
Before Cocos2d-x 2.0.4, there was the concept of Retina, which came from cocos2d-iphone.
In order to support Retina iphone devices, cocos2d-iphone uses suffixes such as -hd to distinguish iphone and Retine iphone image resources. When designing the game, use the point coordinate system, not the real pixel coordinate system. This is consistent with the point concept proposed by iOS native application development. You can run the previous 320×480 program on a 640×960 device without modifying the code, but the picture will look blurry. Once you add @2x pictures, iOS automatically Load @2x's image to support Retna iphone.
The point coordinate system can solve the problem of multi-resolution support within a certain range. But when iphone5 and ipad 3 come out, iOS has a total of 5 resolutions that need to be supported. It is quite painful to do a universal program. The point coordinate system does not completely solve the problem, and the resolution situation on android is more complicated.
Design resolution should be a concept evolved from the point coordinate system. The purpose is to shield the device resolution, and the sprite coordinates are all laid out on the design resolution, but it is not easy to achieve this goal. Cocos2d-x provides a set of related interfaces and 5 resolution adaptation strategies, which strategy is what we need, let's explore together.
Asset Resolution, Design Resolution, Screen Resolution
Resources width is abbreviated RW below, Resources height is abbreviated RH below Design width is abbreviated as DW below, Design height is abbreviated as DH below
Screen width is abbreviated as SW below, Screen height is abbreviated as SH below
|
There is a HelloCpp project in the samples of the SDK. Shows how to use the multi-resolution scheme.
The following is basically the same configuration of AppMacros.h of HelloCpp, but the values of width and height are exchanged, taking the vertical screen game as an example.
The Cocos2d-x picture shows the following two logical processes.
The resources are laid out to the design resolution, and the design resolution is laid out to the screen.
As shown below:
The interfaces setContentScaleFactor() and setSearchPaths() control the first conversion process.
And setDesignResolutionSize() controls the second process. The two processes combine to affect the final display effect.
From Asset Resolution to Design Resolution
setSearchPaths() needs to be set appropriately according to the current screen resolution. HelloCpp shows a simple solution, but it may not be the best.
setContentScaleFactor() determines the scaling factor of the image displayed on the screen, but the parameters of this interface are not derived from the width and height of the resource image than the screen width and height. The Cocos2d-x engine design attempts to shield game developers from directly paying attention to the screen, so this factor is the width and height of the resource than the design resolution.
setContentScaleFactor() usually has two ways to set parameters.
RH/DH or RW/DW, different factor choices have different scaling negative effects.
Look at a picture first:
Using the height ratio as the content scaling factor ensures that the vertical direction of the background resource is fully displayed within the design resolution range.
Using the width ratio as the content scaling factor ensures that the horizontal direction of the background resource is fully displayed within the design resolution range.
From design resolution to screen resolution
- setDesignResolutionSize(DW, DH, resolutionPolicy)
There are three parameters, Design Resolution Wide, Design Resolution High, and Resolution Strategy.
The first two are well understood, and the complexity lies in the choice of resolution strategy.
Let's first look at the three cases of ResolutionPolicy::EXACT_FIT, ResolutionPolicy::NO_BORDER, ResolutionPolicy::SHOW_ALL, and analyze the newly added policies in 2.1.3 later.
The design resolutions of the three strategies are all incoming values, and no internal corrections are made.
Look at a picture first:
- ResolutionPolicy::SHOW_ALL
The screen width and height are calculated from the design resolution width and height, respectively, and the smaller (smaller) is used as the width and height scaling factor. It is guaranteed that the design area is fully displayed on the screen, but there may be black borders.
- ResolutionPolicy::EXACT_FIT
The ratio of the screen width to the design width is used as the scaling factor in the X direction, and the ratio of the screen height to the design height is used as the scaling factor in the Y direction. The design area is guaranteed to completely fill the screen, but image stretching may occur.
- ResolutionPolicy::NO_BORDER
The screen width and height are calculated by the design resolution width and height respectively, and the larger (larger) is used as the width and height scaling factor. It is guaranteed that the design area can always cover the screen in one direction, while the other direction generally exceeds the screen area.
ResolutionPolicy::NO_BORDER is the previously officially recommended solution. It does not stretch the image and fills the screen in one direction, but the two new strategies added in 2.1.3 will shake the status of ResolutionPolicy::NO_BORDER.
Both ResolutionPolicy::FIXED_HEIGHT and ResolutionPolicy::FIXED_WIDTH will internally correct the incoming design resolution to ensure that the screen resolution reaches the design resolution without stretching the screen.
As shown in the figure:
- ResolutionPolicy::FIXED_HEIGHT
Keep the height of the incoming design resolution unchanged, and modify the width of the design resolution according to the screen resolution.
- ResolutionPolicy::FIXED_WIDTH
保持传入的设计分辨率宽度不变，根据屏幕分辨率修正设计分辨率的高度。
结合两个过程
第一过程有两种情况，第二过程有5种情况，在一个分辨率下会有10种可能的方案组合。
如何选择自己需要的？
我们需要作出选择，是牺牲效果还是牺牲部分显示区域。
这里我们选者牺牲一个方向的显示区域为例，结果说明两个过程。
在我的游戏里面，背景图的高需要全部显示，而宽方向可以裁减。
要实现这个目的，需要保证两个过程都是在宽方向裁减。
1. 第一过程选择 setContentScaleFactor(RH/DH)
2. 第二过程有两个选择：ResolutionPolicy::NO_BORDER和ResolutionPolicy::FIXED_HEIGHT
为了说明两者的区别，需要结合VisibleOrigin和VisibleSize。
看图
ResolutionPolicy::NO_BORDER情况下，设计分辨率并不是可见区域，我们布局精灵需要根据VisibleOrigin和VisibleSize来做判断处理。
而ResolutionPolicy::FIXED_HEIGHT则不同，设计分辨率就是可见区域，VisibleOrigin总是(0,0)
getVisibleSize() = getWinSize()，ResolutionPolicy::FIXED_HEIGHT达到了同样的目的，但是却简化了代码。
ResolutionPolicy::FIXED_HEIGHT和ResolutionPolicy::FIXED_WIDTH是ResolutionPolicy::NO_BORDER的进化，新项目中建议立即开始使用这两种方式。
小结
- ResolutionPolicy::FIXED_HEIGHT
适合高方向需要撑满，宽方向可裁减的游戏，结合setContentScaleFactor(RH/DH)使用。
- ResolutionPolicy::FIXED_WIDTH
适合宽方向需要撑满，高方向可裁减的游戏，结合setContentScaleFactor(RW/DW)使用。
| tip: 正确设置AppMacros.h里面的宽高，注意横屏游戏和竖屏游戏的不同。 |