(16) Cocos2d-x Multi-resolution adaptation full resolution

Overview

Starting with Cocos2d-x 2.0.4, Cocos2d-x proposed a multi-resolution support scheme, discarding the previous Retina-related setup interface, and proposed the design resolution concept.

The following related interfaces are available in 3.0:

Director::getInstance()->getOpenGLView()->setDesignResolutionSize() //设计分辨率大小及模式Director::getInstance()->setContentScaleFactor() //内容缩放因子FileUtils::getInstance()->setSearchPaths() //资源搜索路径Director::getInstance()->getOpenGLView()->getFrameSize() //屏幕分辨率Director::getInstance()->getWinSize() //设计分辨率Director::getInstance()->getVisibleSize() //设计分辨率可视区域大小Director::getInstance()->getVisibleOrigin() //设计分辨率可视区域起点

Starting from cocos2d-2.1beta3-x-2.1.1,

CCFileUtils::sharedFileUtils()->setResourceDirectory()

By the new interface

FileUtils::getInstance()->setSearchPaths(searchPath)

Alternative

Starting with Cocos2d-x 2.1.3, two new Resolutionpolicy (Kresolutionfixedheight, kresolutionfixedwidth) were added, with a total of 5 modes.

Officials are introduced in Multi_resolution_support and Mechanism_of_loading_resources respectively.

In this paper, the multi-resolution adaptation technology of Cocos2d-x is analyzed from the perspective of engine users.

From retina to design resolution

Before Cocos2d-x 2.0.4, there was the concept of retina, a concept that came from Cocos2d-iphone.

To support the Retina iphone device, Cocos2d-iphone uses suffixes such as-HD to differentiate the image resources of the iphone and Retine iphone. When designing a game, use the point coordinate system rather than the true pixel coordinate system. This and iOS native application development proposed point concept one to, without modifying the code, can run on 640x960 device before 320x480 program, but the picture will look blurred, once added @2x pictures, iOS automatically load @2x pictures, implementation of Retna iphone support.

Point coordinate system that solves the problem of multi-resolution support within a certain range. But when Iphone5,ipad 3 comes out, iOS has a total of 5 resolutions to support, and it's pretty painful to do a universal program. The point coordinate system does not solve the problem completely, and the resolution on Android is more complex.

Design resolution should be a concept evolved from the point coordinate system, with the aim of shielding the device resolution, and the sprite coordinates being 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 is what we need, and we'll explore together.

Resource resolution, design resolution, screen resolution

Resources width hereinafter abbreviated to rw,resources height below abbreviated to RH

Design width below abbreviated to dw,design height below abbreviated to DH

Screen width below abbreviated to sw,screen height below shorthand for SH

There is a hellocpp project in the samples of the SDK. Shows how to use a multi-resolution scenario.

The following is basically the same as the AppMacros.h configuration of hellocpp, but the value of wide-height is exchanged, and the vertical screen game is the example.

The Cocos2d-x picture shows the following two logical processes. Resource layout to design resolution, design resolution layout to screen.

As shown in the following:

Interface Setcontentscalefactor () and setsearchpaths () control the first conversion process.

and Setdesignresolutionsize () controls the second process. Two processes are combined to affect the final display effect.

From resource resolution to design resolution

Setsearchpaths () needs to be properly set according to the current screen resolution, Hellocpp shows a simple solution, but may not be optimal.

Setcontentscalefactor () determines the zoom factor of the image display to the screen, but the parameters of this interface are not through the width and height of the resource picture, but the width and height of the screen. Cocos2d-x engine design tries to block the game developers to focus on the screen directly, so this factor is the resource width, high ratio design resolution is wide and high.

Setcontentscalefactor () usually has two ways to set parameters. Rh/dh or RW/DW, different factor choices have different scaling negative effects. First look at a picture:

With the height ratio as the content scaling factor, the vertical direction of the background resources is guaranteed to display all within the design resolution range.

By using the width ratio as the content scaling factor, the horizontal orientation of the background resource is guaranteed to be displayed in the design resolution range.

From design resolution to screen resolution

Setdesignresolutionsize (DW, DH, Resolutionpolicy)

There are three parameters, design resolution is wide, design resolution is high, resolution strategy.

The first two are well understood and complex points are selected on the resolution strategy.

First of all, look at Resolutionpolicy::exact_fit,resolutionpolicy::no_border,resolutionpolicy::show_all These three cases, 2.1.3 newly added strategy later analysis.

The design resolution of three strategies is the incoming value, not the internal correction.

First look at a picture:

Resolutionpolicy::show_all

Screen width, height difference and design resolution wide, high computational scaling factor, take (small) as a wide, high scaling factor. Ensure that the design area is all displayed on the screen, but there may be black edges.

Resolutionpolicy::exact_fit

The screen width and design aspect ratio are the scaling factor in the x direction, and the screen height is the zoom factor in the y direction as the design height ratio. The design area is guaranteed to fully fill the screen, but image stretching may occur.

Resolutionpolicy::no_border

Screen width, height difference and design resolution wide, high computational scaling factor, take the (large) as a wide, high scaling factor. Ensures that the design area is always covered in one direction, while the other is generally outside the screen area.

Resolutionpolicy::no_border, which was previously recommended by the authorities, did not stretch the image and fill the screen in one Direction, but 2.1.3 's two new strategies will shake Resolutionpolicy::no_border's position.

Both the Resolutionpolicy::fixed_height and Resolutionpolicy::fixed_width are internally corrected for incoming design resolution to ensure screen resolution to the design resolution without stretching the full screen.

Resolutionpolicy::fixed_height

Keeps the incoming design resolution height constant, correcting the width of the design resolution based on the screen resolution.

Resolutionpolicy::fixed_width

Keeps the passed-in design resolution width unchanged, correcting the height of the design resolution based on the screen resolution.

Combined with two of processes

There are two scenarios for the first process, with 5 cases in the second process and 10 possible combinations of scenarios at a certain resolution. How do you choose what you need?

We need to make a choice between sacrificing the effect or sacrificing some of the display area.

Here we elect to sacrifice One direction of the display area as an example, the results illustrate two processes.

In my game, the background image of the high need to show all, and the wide direction can be cut.

To achieve this, it is necessary to ensure that two processes are cut in a wide direction.

• First process selection Setcontentscalefactor (RH/DH)
• The second process has two options: Resolutionpolicy::no_border and Resolutionpolicy::fixed_height

To illustrate the difference between the two, it is necessary to combine visibleorigin and visiblesize. Look at the picture

Resolutionpolicy::no_border case, the design resolution is not the visible area, our Layout wizard needs to be based on Visibleorigin and visiblesize to do judgment processing.

And Resolutionpolicy::fixed_height is different, the design resolution is the visible area, Visibleorigin always (0,0)

Getvisiblesize () = Getwinsize (), Resolutionpolicy::fixed_height achieves the same goal, but simplifies the code.

Resolutionpolicy::fixed_height and Resolutionpolicy::fixed_width are the evolution of resolutionpolicy::no_border, and it is recommended that these two approaches be used immediately in new projects.

Summary Resolutionpolicy::fixed_height

Suitable for high-direction need to be full, wide-direction can be cut in the game, combined with Setcontentscalefactor (RH/DH) use.

Resolutionpolicy::fixed_width

Suitable for wide-direction needs to be full, high-direction can be cut in the game, combined with Setcontentscalefactor (RW/DW) use.

Tip: Correctly set the width of the AppMacros.h inside, pay attention to horizontal screen game and vertical screen game different.

(16) Cocos2d-x Multi-resolution adaptation full resolution