转自：https://www.2cto.com/kf/201212/175527.html
https://blog.csdn.net/u012861978/article/details/53233892
分析：
designResolutionSize是一个新的概念，它让一切与坐标，尺寸相关的数据彻底摆脱了屏幕分辨率的羁绊，或者说
由框架层来帮开发者完成转换，开发者需要的只是设置designResolutionSize。告诉框架你在什么样尺寸的场景下
做的资源，比如此例，背景图原始尺寸480x320，需求是刚好填满屏幕，那么就应该告诉框架“嗨，我设计时是以
480x320的屏幕为标准的，你帮我转转”，框架就会回答你“放心吧！” 那么框架究竟如何实现的呢？ 跟踪
pEGLView->setDesignResolutionSize(480, 320, kResolutionNoBorder);
可以发现，框架是获取了实际分辨率和开发者designResolutionSize的比例，渲染的时候把图片按照这个比例来缩放绘制。
拿本例来说，屏幕960x640，designResolutionSize为480x320，缩放比例为2，那么原始大小480x320的背景图，在绘制
时就会x2来绘制，也就是实际绘制成了960x640的大小，这样就填满窗口了！
请注意这里对不同ResolutionPolicy的处理，原理后文会分析。
ok，现在面对480x320和960x640的屏幕，你已经能写出自动适配的代码了(其实只有一句，框架的好处啊~~)
又来了新的需求，“那谁谁，你改一下代码，程序要能适应ipad2 ”，WTF！好吧，问候归问候，问题总要解决。
于是你开始想“ ipad2分辨率1024x768，就按刚才帅帅凡教我的到main.cpp里修改”，好，修改为1024x768，
ms填满了，你很满意，但是不对，右下角的按钮肿么快到屏幕外面去了？！仔细一看，不是填满是填太满，背景图都超出屏幕了。
这是肿么回事呢？ 根源在于pEGLView->setDesignResolutionSize(480, 320, kResolutionNoBorder);第三个参数，找到定义：
讲得很清楚了：
kResolutionExactFit：会靠拉伸来填满屏幕，本例来说背景图会变形来填充屏幕，因为1024:768=1.3， 480:320=1.5，宽高比不同，图片也就无法等比缩放来填满屏幕，只能变形了。
kResolutionNoBorder： 看不到黑边，实际就是宽高等比缩放，但缩放比例取宽比和高比之中大的那一个。
kResolutionShowAll：全部显示，可以理解为保证内容都显示在屏幕之内，实际也是宽高等比缩放，但缩放比例取宽比和高比之中小的那一个。
一般来说，我们希望设计时一屏的内容，用户在实际设备上也能在一屏内看到，拿本例来说，1024x768分辨率时，右下角的按钮却跑到屏幕外去了。看完上面的分析，你应该知道如何解决了： 对了，改变pEGLView->setDesignResolutionSize(480, 320, kResolutionNoBorder);第三个参数为kResolutionShowAll。 ok，看看效果：
bingo！背景图填满了屏幕(水平方向)，按钮紧贴到右下角，可以满足基本的风格统一要求。
不过纵向上出现黑边，这个是实际分辨率的宽高比和设计分辨率宽高比不同造成的，无法通过框架层来解决。
只能交给开发者自己了，比如在代码里根据分辨率计算会出现黑边时，在黑边填充相应的图片等。一些解决方法见 这里
setPosition()的变化
之前版本可能已经习惯了CCNode::setPosition(const CCPoint &position);和CCNode::setPositionInPixel(const CCPoint &position);
但在新的版本里，只有setPosition(const CCPoint &position);
这里传入的参数不是像素，也和传统的point有不同，它指的是在designResolutionSize参照下的坐标。
验证交给你自己来：比如设计分辨率为480x320，设置一个sprite的位置为240,160，在480x320分辨率下会发现它在屏幕正中，
模拟其他分辨率，960x640，1024x768，会发现它依然在屏幕中心，这就可了解240,160这个值跟实际屏幕分辨率已经无关了，
只和designResolutionSize有关，理解这一点至关重要，是后续开发正确空间感的基础！
CC_CONTENT_SCALE_FACTOR()的变化
首先enableRetinaDisplay()在新版本里取消了，将不会有什么retina设备上scalefactor为2的说法了，
因为designResolutionSize已经解决了按不同屏幕缩放的问题，所以CC_CONTENT_SCALE_FACTOR();始终返回1。
所以新版本里的定义已经过时了，无须理会。
当然，开发者可以通过CCDirector::sharedDirector()->setContentScaleFactor()来设置contentScaleFactor，这个系数可以理解为
图片原始尺寸和designResolutionSize的比值，这个比值将用来绘制图片。
如果只是一套资源按照不同屏幕分辨率缩放，可以不用理会。
getWinSize()的变化
CCDirector::sharedDirector()->getWinSize(); 获取的是designResolutionSize
CCDirector::sharedDirector()->getWinSizeInPixels(); 获取的是getWinSize*contentScaleFactor之后的值，和老版本一样。
如果contentScaleFactor为1，则这两个函数返回的值一样。
使用kResolutionNoBorder策略时要注意的
CCSize szVisible = CCDirector::sharedDirector()->getVisibleSize();
CCPoint posVisible = CCDirector::sharedDirector()->getVisibleOrigin();
使用该策略时，因为标准背景图可能会超出屏幕，所以设置位置时需要已一个可视矩形为基准。
可以这样理解，szVisible就是你在实际设备上能看到的有效区域的宽高，posVisible就是这个有效区域的起始坐标，和szVisible构成一个可视矩形，一般来说这个可视矩形是设计分辨率下可视矩形的子集。
总结一下，cocos2d-x新的版本(对于从1.0.1-x-0.11.0上来的人)的确添加了不少新的功能，代码结构也更加合理，这些都是开发者之福，希望2dxteam继续加油！
以下转自：https://blog.csdn.net/u012861978/article/details/53233892
----------------------------------------------------------------------------------
比如设计分辨率是960x640，资源是320x480。为了让这个资源铺满屏幕，可以在所有设置资源的地方设置一个scale为2，也可以直接用setContentScaleFactor（0.5），那么所有的资源都会做2倍的缩放。为什么设置0.5是2倍缩放？因为这个的算法是（资源）/（设计分辨率）。但是通常美术给的图片大小是按照我们要求的设计分辨率来的，也就是Resources Size等于Design Size
Cocos2d-x图片显示有下面两个逻辑过程。
资源布局到 到 设计分辨率，设计分辨率 布局到 屏幕。
接口setContentScaleFactor()和setSearchPaths()控制着第一个转换过程。
而setDesignResolutionSize()控制第二个过程。两个过程结合在一起，影响最终的显示效果。
setContentScaleFactor()决定了图片显示到屏幕的缩放因子，Cocos2d-x引擎设计试图屏蔽游戏开发者直接去关注屏幕，这个其实是图片投射到设计分辨率的缩放因子，下图是设置缩放因子为RH/DH和RW/DW的效果：
用高度比作为内容缩放因子，保证了背景资源的垂直方向在设计分辨率范围内的全部显示。
用宽度比作为内容缩放因子，保证了背景资源的水平方向在设计分辨率范围内的全部显示。
