cocos2d value vec2-x 3.2 vec2和size的区别
点击联系发帖人
时间：2014-10-23 02:03
1598人阅读
cocos2d-x(lua)学习日志（2）
区别1.去CC之前2.0的CC**,把CC都去掉，基本的元素都是保留的2.0
CCCallFunc CCNode ..
Sprite CallFunc Node ..区别2.cc***结构体改变2.0
ccpAdd(p1,p2)
ccpLength(p)
ccpDot(p1,p2);
CCPointZero
CCSizeZero
Point(x,y)
p.getLength()
p1.dot(p2)
Color3B::WHITE
Point::ZERO
Size:ZERO区别3.shared***改变(单例机制使用语法)2.0
CCSize winSize = CCDirector::sharedDirector()-&getWinSize();
SpriteFrameCache::sharedSpriteFrameCache()
AnimationCache::sharedAnimationCache()
NotificationCenter::sharedNotificationCenter()
Size size = Director::getInstance()-&getWinSize();
SpriteFrameCache::getInstance()
AnimationCache::getInstance()
NotificationCenter::getInstance()
…区别4.POD类别2.0
Rect区别5.点触事件auto dispatcher = Director::getInstance()-&getEventDispatcher();
auto touchListener = EventListenerTouchOneByOne::create();
touchListener-&onTouchBegan = CC_CALLBACK_2(FBMainScene::onTouchBegan,this);
touchListener-&onTouchMoved = CC_CALLBACK_2(FBMainScene::onTouchMoved,this);
touchListener-&onTouchEnded = CC_CALLBACK_2(FBMainScene::onTouchEnded, this);
dispatcher-&addEventListenerWithSceneGraphPriority(touchListener, this);
bool FBMainScene::onTouchBegan(Touch *touch,Event *pEvent){
CCLOG(&onTouchBegan&);
Point point = this-&convertToWorldSpace(this-&convertTouchToNodeSpace(touch));
void FBMainScene::onTouchMoved(Touch *touch,Event *pEvent){
CCLOG(&onTouchMoved&);
void FBMainScene::onTouchEnded(Touch *touch,Event *pEvent){
CCLOG(&onTouchEnded&);
//获得触点的方法也发生了改变：
Point point = this-&convertToWorldSpace(this-&convertTouchToNodeSpace(touch));
//dispatcher控制方法：
dispatcher-&addEventListener…
dispatcher-&removeEventListener(listener);
dispatcher-&removeAllListeners();区别6.回调函数CC_CALLBACK_0 CC_CALLBACK_1 CC_CALLBACK_2 CC_CALLBACK_3回调函数，分别携带不同的参数，方便2.0
CCMenuItemFont *item = CCMenuItemFont::create(&返回上个场景&, this, menu_selector(GameScene::backScene));
MenuItemFont *item = MenuItemLabel::create(&返回上个场景&, CC_CALLBACK_1(GameScene::backScene, this));
// new callbacks based on C++11
#define CC_CALLBACK_0(__selector__,__target__, ) std::bind(&__selector__,__target__, ##__VA_ARGS__)
#define CC_CALLBACK_1(__selector__,__target__, ) std::bind(&__selector__,__target__, std::placeholders::_1, ##__VA_ARGS__)
#define CC_CALLBACK_2(__selector__,__target__, ) std::bind(&__selector__,__target__, std::placeholders::_1, std::placeholders::_2, ##__VA_ARGS__)
#define CC_CALLBACK_3(__selector__,__target__, ) std::bind(&__selector__,__target__, std::placeholders::_1, std::placeholders::_2, std::placeholders::_3 ##__VA_ARGS__)区别7.CallFunc使用(使用&Function&对象)CallFunc::create([&](){
Sprite *sprite = Sprite::create(&s&);
this-&addChild(sprite);
});区别8.使用clone代替copy2.0
CCMoveBy *action = (CCMoveBy*) move-©();
action-&autorelease();
action = move-&clone();
不需要autorelease，在clone已经实现。区别9.Physics Integration 物理引擎暂无使用，box2d 在 3.0中可以延续使用
在3.0的Physics中需要定义 PhysicsWorld, PhysicsBody, PhysicsShape, PhysicsJoint 等，于box2d相仿，使用前需要定义CC_USE_PHYSICS区别10.容器2.0
cocos2d::Vector&T&
cocos2d::Map&K,V&
cocos2d::Value正在学习中……继续等待补充。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：326396次
积分：4841
积分：4841
排名：第4241名
原创：149篇
转载：15篇
评论：151条
阅读：5994
文章：19篇
阅读：28135
阅读：21551
文章：24篇
阅读：27244
(9)(1)(4)(1)(1)(3)(4)(2)(1)(5)(5)(8)(2)(15)(21)(16)(35)(10)(22)<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&20571人阅读
【Himi转载推荐系列】（3）
本站文章均为原创,转载务必在明显处注明：（作者新浪微博：)&转载自&原文链接:&&&本博客最新动态!及时将最新博文通知您！ 本文出自 [无间落叶]原文地址：为了适应移动终端的各种分辨率大小，各种屏幕宽高比，在 cocos2d-x（当前稳定版：2.0.4） 中，提供了相应的解决方案，以方便我们在设计游戏时，能够更好的适应不同的环境。而在设计游戏之初，决定着我们屏幕适配的因素有哪些，简而言之只有两点：屏幕大小 和 宽高比。这两个因素是如何影响游戏的：屏幕大小：&从小分辨率&480×320&到&&分辨率，再到全高清&1080p，从手机到平板，还有苹果设备的&Retina屏，这么多不同的分辨率，而且大小差距甚大，不可能做到一套资源走天下，资源往小了设计，在大屏幕会显示模糊，图片往大了设计，在小屏幕设备又太浪费，而且小屏幕的手机硬件资源也会相对的紧缺，所以&根据屏幕大小使用不同的资源&是有必要的，而 cocos2d-x 也帮我们解决了这一点。&宽高比：&什么是宽高比，就是你的屏幕是方的还是长的，靠近方形的分辨率如 480×320，比例为&3:2，还有 960×540 的16:9&标准宽屏，这也算是两种总极端情况了，如果能在这两种比例情况做好适配基本就可以了，如果比 3:2 “更方”如 4:3，比 16:9 “更长”，那么不论如何布局，显示效果差距甚大，最好对固定比例优化吧。当在宽高比在一定范围内，可以通过灵活编写程序去适应，而在显示效果上，cocos2d-x 为我们提供了三种模式，这些&模式更多的是帮我们解决比例不一的情况而存在&的，如果只是屏幕大小（比例一样），那通过简单的放大缩小即可完成。三种模式说是三种模式，其实还有一种&无模式，也就是 cocos2d-x 默认的适配方案，现在我们就来认识一下这些模式，并且通过这些模式去认识其中一些概念&FrameSize、WinSize、VisibleSize、VisibleOrigin，以及它们存在的意义，并且最后灵活运行这些概念&创建出一个不属于这些模式而超越这些模式的新适配解决方案，这是最终目的。kResolutionUnKnown 认识 FrameSize这是 cocos2d-x 编写的默认模式，没有做任何处理，在这种情况下，游戏画面的大小与比例都是不可控的，在程序运行之初，由各个平台入口函数定义画面大小：// proj.linux/main.cpp linux 平台手动指定画面大小CCEGLView* eglView = CCEGLView::sharedOpenGLView();eglView-&setFrameSize(720, 480);// proj.android/jni/hellocpp/main.cpp android 平台由 jni 调用传入设备分辨率参数void Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeInit(JNIEnv* env, jobject thiz, jint w, jint h){if (!CCDirector::sharedDirector()-&getOpenGLView()){CCEGLView *view = CCEGLView::sharedOpenGLView();view-&setFrameSize(w, h);AppDelegate *pAppDelegate = new AppDelegate();CCApplication::sharedApplication()-&run();}else{// other…}}在此我们首先认识了&FrameSize&参数，在游戏运行时，我们可以通过&CCEGLView::sharedOpenGLView()-&getFrameSize();获得此值。如果在手机上运行，那么不同分辨率将会得到不同的值，既然这个值不可控，那么在写游戏中也就没有参考价值了，比如我们写一个精灵的位置距离底部 320 高度，在 480×320 分辨率，能看到其在屏幕上方，如果换一台手机分辨率 960×540 那么只能显示在中间靠上的位置，如果设置精灵位置为距离屏幕上方（高度）320，反之依然，显示效果不一。此时可行的方案是使用百分比，如精灵位置在屏幕横向距离左边 1/3 宽度，在 1/2 正中间处，而类似这样的设置也不用依赖 FrameSize 的具体数值。而这样的做法，使得内部元素像弹簧一样，随着 FrameSize 的大小改变而改变，伸缩或者挤压，对于图片资源大小也是完全不可控，如果根据屏幕大小放大缩小，那我们可以考虑用下面要说的模式，在此不推荐使用 cocos2d-x 的无模式方案。kResolutionExactFit and kResolutionShowAll 认识 WinSize在 AppDelegate.cpp 处可以通过设置：&CCEGLView::sharedOpenGLView()-&setDesignResolutionSize(720, 480, kResolutionShowAll);// 或者CCEGLView::sharedOpenGLView()-&setDesignResolutionSize(720, 480, kResolutionExactFit);DesignResolutionSize！顾名思义，也就是逻辑上的游戏屏幕大小，在这里我们设置了其分辨率为 720×480 为例，那么在游戏中，我么设置精灵的位置便可以参照此值，如 左下角 ccp(0,0)，右上角 ccp(720, 480)，而不论 FrameSize 的大小为多少，是 720×480 也是，是 480×320 也罢，总能正确显示其位置，左下角和右上角。能够实现这一点的原因是，固定了设计分辨率大小，从而确定了其固定的宽高比，它的&优势&是可以使用具体的数值摆放精灵位置，不会因为实际屏幕大小宽高比而是内部元素相对位置关系出现混乱。而为了保持画面的宽高比，cocos2d-x 做了些牺牲，牺牲了什么呢？kResolutionExactFit 牺牲了画质而保持了全屏显示，对画面进行了拉伸，这意味着什么？意味着相对极端情况下，本来精灵是方形的，显示出来变成长方形，本来圆形的变成了椭圆，固此模式不推荐使用。kResolutionShowAll 为了保持设计画面比例对四周进行留黑边处理，使得不同比例下画面不能全屏。鱼和熊掌不能兼得也 ~我们可以通过如下方法获取到&setDesignResolutionSize&所设置的值：CCSize winSize = CCDirector::sharedDirector()-&getWinSize();我们可以用&&一文的方法，跟踪 WinSize 的初始化，获取过程，在这里简单提一下，如下步骤：&// 获得 winSizeCCSize winSize = CCDirector::sharedDirector()-&getWinSize();// 查看其 getWinSize(); 方法实现[cocos2dx-path]/cocos2dx/CCDirector.cppCCSize CCDirector::getWinSize(void){return m_obWinSizeInP}// 而 m_obWinSizeInPoints 是何时被赋值的[cocos2dx-path]/cocos2dx/platform/CCEGLViewProtocol.cppvoid CCEGLViewProtocol::setDesignResolutionSize(float width, float height, ResolutionPolicy resolutionPolicy){……m_obDesignResolutionSize.setSize(width, height);……CCDirector::sharedDirector()-&m_obWinSizeInPoints = getDesignResolutionSize();}const CCSize& CCEGLViewProtocol::getDesignResolutionSize() const{return m_obDesignResolutionS}具体的优势：通过设置逻辑分辨率大小，相比无模式，可以帮我们解决了屏幕自动放大缩小问题，并且保持屏幕宽高比，使得游戏更好设计，可以将设计画面大小作为默认背景图片大小等，唯一点遗憾就是那点前面所提到的一点点牺牲。kResolutionShowAll 方案可以作为我们的默认解决方案，使得游戏的设计更为简化，但为了补填拉伸或留黑边这点缺憾，进入下一个模式！kResolutionNoBorder 了解 VisibleSize 与 VisibleOrigin此模式可以解决两个问题，其一：游戏画面全屏；其二：保持设置游戏时的宽高比例，相比 kResolutionShowAll 有所区别的是，为了填补留下的黑边，将画面稍微放大，以至于能够正好补齐黑边，而这样做的后果可想而知，补齐黑边的同时，另一个方向上将会有一部分画面露出屏幕之外，如下示意图：黑色边框标示实际的屏幕分辨率，紫色区域标示游戏设计大小，而通过放大缩小，保持宽高比固定， 可以看到&Show All&之中的黑色阴影部分为留边，而&No Border&的紫色阴影部分则不能显示，而这紫色区域的大小是游戏设计之时是不可控的。那么原设计的画面大小就失去了&一定的&参考价值了，因为这可能让你的画面显示残缺。这时仅仅通过 WinSize 满足不了我们的设计需求，所以引入了&VisibleSize&与&VisibleOrigin&概念。如上所示，紫色区域是被屏幕截去的部分，不可显示的，根据实际情况，可能出现横向截取和竖向截取，这取决于实际分辨率的宽高比。而 A、B、C、D所标示的是设计分辨率，固定大小。如果我们想让一个精灵元素显示在屏幕上方靠边，那么如果使用 WinSize 的高度设置其位置，可能出现的情况就是显示到屏幕之外了。FrameSize 和 WinSize 我们已经知道其概念，而 VisibleSize 和 VisibleOrigin 所代表的是什么呢，又时如何为我们解决靠边的问题！注意上图下方的定义，&VisibleSize = H I J K 是用紫色标注的。&而在上图是&黑色&标注，标示屏幕实际分辨率，虽然 FrameSize 和 VisibleSize 都是 H I J K，但其意义不同，紫色表明它是与设计分辨率相关的。FrameSize 是实际的屏幕分辨率，而&VisibleSize 是在 WinSize 之内，保持 FrameSize 的宽高比所能占用的最大区域，实际屏幕分辨率 H I J K (黑色) 可以大于 WinSize ，但VisibleSize 一定会小于或者等于 WinSize，这两者相同的是宽高比。VisibleSize 有着 WinSize 大小（随WinSize 的大小改变而改变），还有着 FrameSize 的宽高比，它标示&在设计分辨率（WinSize）下，在屏幕中的可见区域大小。&而 VisibleOrigin 则标示在设计分辨率下被截取的区域大小，用点 K 标示，有了这些数据，我们想让游戏元素始终在屏幕显示的区域之内不成难事。下面通过几个数值带入，加深这些概念的印象。&// 组[1] :FrameSize: width = 720, height = 420WinSize: width = 720, height = 480VisibleSize: width = 720, height = 420VisibleOrigin: x = 0, y = 30// 组[2] :相比 组 [1] FrameSize 不变 VisibleSize 和 VisibleOrigin 随着 WinSize 的变小而变小FrameSize: width = 720, height = 420WinSize: width = 480, height = 320VisibleSize: width = 480, height = 280VisibleOrigin: x = 0, y = 20// 组[3] : 相比组 [1] WinSize 不变，VisibleSize 随着 FrameSize 的比例改变而改变FrameSize: width = 720, height = 540WinSize: width = 720, height = 480VisibleSize: width = 640, height = 480VisibleOrigin: x = 40, y = 0// WinSize VisibleSize VisibleOrigin 与都设计的分辨率相关，满足如下关系WinSize.width = (VisibleOrigin.x * 2) + VisibleSize.widthWinSize.height = (VisibleOrigin.y * 2) + VisibleSize.heightNoBorder 具体的使用方法可以参考 cocos2d-x 自带例程&TestCpp&，有详细的使用方法，并且封装了&VisibleRect&类，可以获取设计分辨率，不同比例屏幕之时的主要参考点，屏幕四个拐角，和边的中点等，让我们设置元素位置时，使其总能显示在屏幕之内，这里就不详细介绍了。基于这几种模式的程序使用方法，cocos2d-x 自带例程或者网上有很多教程，这里只详细解释了其中各种概念，而知道了这些概念，当然用起来就没有多大问题了。kResolutionLeafsoar！！！这是什么模式！好吧，Leafsoar 是 一叶 的 ID ，或者是本博客的一级域名而已 :P 在 cocos2d-x 中并没有这种模式。除却&UnKnown&与&ExactFit&不说，ShowAll 的优势是，只需要一个设计分辨率，然后通过 WinSize 设置相对对位即可，而且位置的最大长宽都是确定，方便了开发，但屏幕不能填满， NoBorder 模式的优势是在画面不变形的情况下，实现全屏，显示效果更好，但 WinSize 一定程度失效，需要通过运行时计算 VisibleSize 和 VisibleOrigin 来设置位置，由于是运行时计算，所以也就会出现，各种屏幕显示效果不一样的情况。ShowAll 和 NoBorder 各有所长，各有所短，而这里提出的新适配解决方案正是取两者之长，舍两者之短的&组合模式。简单说来就是用 NoBorder 去实现 ShowAll 的思想。NoBorder 可以保证全屏利用，ShowAll 可以更好的使用实际设计坐标固定位置，而且相对位置不会随宽高比的改变而改变，这在编写游戏的时候能方便不少。先上一个示意图，一目了然 （两个图，两个方向）：在原来 NoBorder 模式示意图上添加了新的概念，LsSize = X Y M N&(leafsoar 简写了，为了不跟 cocos2d-x 的一些概念混淆，什么名字不重要，只要了解其含义即可)，在 NoBorder 模式下的 LsSize 相对于 FrameSize 而言，正如 在&ShowAll&模式下的 WinSize 相对于 FrameSize，所以说这是 ShowAll NoBorder 的组合概念，而这里的 LsSize 与 WinSize 的宽高比是一致的。猛地一看，似乎把问题复杂化了，仔细一看，还不如猛地一看 ~~在 ShowAll 中，WinSize 作为最高的宽高，以此参照设置位置，因为在此范围内都能在屏幕上显示，用了 NoBorder 使得四周可能被截去一块区域，而这个区域大小不可控制，所以不能再使用 WinSize 作为参考点来设置位置，而这里的 LsSize 同样，因为 LsSzie 不论在什么情况下，总能显示在屏幕之内，我们可以方便的使用 LsSize 作为坐标系参考，并且可以全屏显示，在配合 VisibleSize ，相比纯的 NoBorder 加强了不少。它可以怎么用？可以把 LsSize 当作 ShowAll 中的 WinSize 来用，而黑边可以使用稍大的图片填充，或者使用其它图片修饰边框，修饰的边框图案可大可小，可长可短，填充屏幕，保持全屏。开始基于 LsSize 的游戏设计实现为了能够准确实现基于 LsSize 的设计，初步计划将 LsSize 设定在 480×320 的分辨率方案，为此做了些准备，首先不使用任何模式情况下，在场景内调用如下：&CCSize size = CCDirector::sharedDirector()-&getWinSize();CCPoint center = ccp(size.width/2, size.height/2);// 大小 600×500 为了 NoBorder 看到效果，使用稍大的背景图CCSprite* pb = CCSprite::create(“Back.jpg”);pb-&setPosition(center);this-&addChild(pb, 0);// 480×320 此图为使用于设计分辨率 LsSize 的图片CCSprite* pSprite = CCSprite::create(“HelloWorld.png”);pSprite-&setPosition(center);this-&addChild(pSprite, 0);// 37×37 在 480×320 画面的四个拐角处，添加参照CCSprite* p1 = CCSprite::create(“Peas.png”);p1-&setPosition(ccpAdd(center, ccp(-240, -160)));this-&addChild(p1);CCSprite* p2 = CCSprite::create(“Peas.png”);p2-&setPosition(ccpAdd(center, ccp(240, 160)));this-&addChild(p2);CCSprite* p3 = CCSprite::create(“Peas.png”);p3-&setPosition(ccpAdd(center, ccp(-240, 160)));this-&addChild(p3);CCSprite* p4 = CCSprite::create(“Peas.png”);p4-&setPosition(ccpAdd(center, ccp(240, -160)));this-&addChild(p4);显示效果：(FrameSize = 640×540)&显示效果：(ShowA FrameSize = 520×320; WinSize = 480×320)&显示效果：(NoB FrameSize = 520×320; WinSize = 480×320)&通过效果我们可以看到，在相同 FrameSize 下 NoBorder 时，画面由于填充了黑边，将画面放大，以至于上下有部分显示不全，通过拐角四个精灵可以看出。好！既然我们知道是由于放大所致，那么我们将画面缩小呢？cocos2d-x 提供了一个方法，我们调用如下代码：CCDirector *pDirector = CCDirector::sharedDirector();pDirector-&setContentScaleFactor(CCEGLView::sharedOpenGLView()-&getScaleY() );为了弥补画面因需要不填空白出现的方法，我们将画面缩小，放大系数可以通过&CCEGLView::sharedOpenGLView()-&getScaleY()&取得。其实 setContentScaleFactor 方法是为了适配不同资源而设计的，可以用此方法对不同资源适配，缩放等。效果如下：我们看到 480×320 的图片显示完全正确了，也正是我们想要的效果，但唯一的缺点是 ~~ 拐角处四个精灵的位置依然不是我们想要的，我们设计的位置是以 480×320 设置位置的，而 WinSize 也是 480×320 ，而此时基于 480×320 的设计必然会显示到屏幕之外，而要想不修改精灵位置，而让其显示正确的位置，那么为了保证 LsSize 的固定，我们需要一个方法，那就是动态设置 WinSize。什么意思？我们知道一般这些模式设计游戏时，是通过&setDesignResolutionSize&设置 WinSize 的，这个值在游戏运行其间是定植，动态改变的是 VisibleSize 等，而这里提出了 LsSize 的概念，可想而知，如果 WinSize 固定，那么 LsSize 会随着屏幕宽高比的改变而改变，那么我们反其道而行，固定&LsSize&值，那么在运行时可以通过实际的宽高比来算得 WinSize 的值，这样动态算得的 WinSize 值就能够保证我们的 LsSize 是一个定值了。相对论，WinSize 与 LsSize 的值是相对的，与其通过固定 WinSize 在运行时动态获得 LsSize （这也是 NoBorder 的默认方式，而导致的结果是 WinSize 没有参考价值），不如我们固定 LsSize 而在运行时算得 WinSize 设置来的要更妙一些。现在不使用&setContentScaleFactor&方法，而修改&setDesignResolutionSize&这里的值，我们知道 WinSize 是 480×320 时，LsSize 必然会小于此值，而 NoBorder 的放大系数我们可以通过如下方式算得（可以参考setDesignResolutionSize方法内部实现），并在 AppDelegate 里执行：&CCSize frameSize = CCEGLView::sharedOpenGLView()-&getFrameSize();// 设置 LsSize 固定值CCSize lsSize = CCSizeMake(480, 320);float scaleX = (float) frameSize.width / lsSize.float scaleY = (float) frameSize.height / lsSize.// 定义 scale 变量float scale = 0.0f; // MAX(scaleX, scaleY);if (scaleX & scaleY) {// 如果是 X 方向偏大，那么 scaleX 需要除以一个放大系数，放大系数可以由枞方向获取，// 因为此时 FrameSize 和 LsSize 的上下边是重叠的scale = scaleX / (frameSize.height / (float) lsSize.height);} else {scale = scaleY / (frameSize.width / (float) lsSize.width);}CCLog(“x: %f; y: %f; scale: %f”, scaleX, scaleY, scale);// 根据 LsSize 和屏幕宽高比动态设定 WinSizeCCEGLView::sharedOpenGLView()-&setDesignResolutionSize(lsSize.width * scale,lsSize.height * scale, kResolutionNoBorder);显示效果：（NoBorder 模式 ;FrameSize = 520×320; LsSize = 480×320; WinSize = 动态获取）&我们看到在没有修改源代码，并且在设计中使用 480×320 的参考系，也既是基于 LsSize 的设计显示效果如我们预期，那么我们换一个 FrameSize 来看看是否能够自动适应呢？如下：显示效果：（NoBorder 模式 ;FrameSize = 600×480; LsSize = 480×320; WinSize = 动态获取）&到此，基于 LsSize 参考系的游戏设计已经完成了，这样做的好处是很明显的，集 ShowAll 和 NoBorder 的优点于一处，这里的图片元素是为了好定位，实现的需要而写的，具体场景可以使用背景地图，或一张大的图片显示，而没有任何影响，也可以继续使用 VisibleSize 得到 LsSize 之外的部分区域大小，在 LsSize 之外可以使用背景图片作为装饰，即保证了游戏的全屏，又保证了游戏设计时的方便，如果使用完全基于 LsSize 的设计实现，除了显示背景装饰之外，我们不想让 LsSize 的内部元素显示到 LsSize 之外如何做呢？我们只需要设定 LsSize 层的的显示区域即可，我们可以修改场景的实现：&// 这里先简单实现思路CCScene* HelloWorld::scene() {CCScene *scene = CCScene::create();// 创建背景层CCLayer* b = CCLayer::create();scene-&addChild(b);// 添加背景图片和设置位置，可以使用其它装饰，或者小图片屏幕都行CCSize size = CCDirector::sharedDirector()-&getWinSize();CCPoint center = ccp(size.width/2, size.height/2);CCSprite* pb = CCSprite::create(“Back.jpg”);pb-&setPosition(center);b-&addChild(pb, 0);// 创建 LsLayer 层HelloWorld *lsLayer = HelloWorld::create();scene-&addChild(lsLayer);}// 在 HelloWorld 中重写 visit() 函数 设定显示区域void HelloWorld::visit() {glEnable(GL_SCISSOR_TEST); // 开启显示指定区域// 在这里只写上固定值，在特性环境下，以便快速看效果，实际的值，需要根据实际情况算得glScissor(20, 0, 480, 320); // 只显示当前窗口的区域CCLayer::visit(); // 调用下面的方法glDisable(GL_SCISSOR_TEST); // 禁用}显示效果：（NoBorder 模式 ;FrameSize = 520×320; LsSize = 480×320; WinSize = 动态获取）&屏幕适配新解看完这篇文章想必对 cocos2d-x 的屏幕适配方案及其原理有了相当的认识，从内部提供的三种模式，再到我们自定义基于 LsSize 的&Leafsoar 模式&(好把，因该叫做 ShowAllNoBorder)。这里已经给出了完全的实现原理以及实现方法，并配有效果图，当然这其中还有些细节需要注意，比如我们基于 LsSize 的大小设计，那么实际的图片肯定需要比 LsSize 的要大，大多少，太小了不够适应，太大了又浪费，如何取舍等问题，这一点取决的因素是什么，留给读者思考 ~~一叶将在 GitHub 处建立一个&项目，读者可以从这里参考实现的方案。(也许此时在 GitHub 所看到的实现并不完全，但已经有了简单的实现方法，并且能够运行，如有必要，将会新写一篇博客，去实现 ScreenSolutions 并且解说)
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2507919次
积分：22459
积分：22459
排名：第228名
原创：169篇
评论：2912条
移动开发专家,专注于移动开发领域,多年 J2me、Android、iOS 平台游戏开发经验;
CSDN、ITeye、51CTO、eoe-Android、泰然、中国移动开发者社区、微度网等多家技术论坛担任专家与版主；
? 【Unreal Engine 】
? 【React Native】
? 【Cocos Creator】
? 【Cocos2dx】
? 【C2dx-Lua】
文章：57篇
阅读：1154099
文章：31篇
阅读：720383}
cocos2d-x(lua)学习日志（2）
区别1.去CC之前2.0的CC**,把CC都去掉，基本的元素都是保留的2.0
CCCallFunc CCNode ..
Sprite CallFunc Node ..区别2.cc***结构体改变2.0
ccpAdd(p1,p2)
ccpLength(p)
ccpDot(p1,p2);
CCPointZero
CCSizeZero
Point(x,y)
p.getLength()
p1.dot(p2)
Color3B::WHITE
Point::ZERO
Size:ZERO区别3.shared***改变(单例机制使用语法)2.0
CCSize winSize = CCDirector::sharedDirector()-&getWinSize();
SpriteFrameCache::sharedSpriteFrameCache()
AnimationCache::sharedAnimationCache()
NotificationCenter::sharedNotificationCenter()
Size size = Director::getInstance()-&getWinSize();
SpriteFrameCache::getInstance()
AnimationCache::getInstance()
NotificationCenter::getInstance()
…区别4.POD类别2.0
Rect区别5.点触事件auto dispatcher = Director::getInstance()-&getEventDispatcher();
auto touchListener = EventListenerTouchOneByOne::create();
touchListener-&onTouchBegan = CC_CALLBACK_2(FBMainScene::onTouchBegan,this);
touchListener-&onTouchMoved = CC_CALLBACK_2(FBMainScene::onTouchMoved,this);
touchListener-&onTouchEnded = CC_CALLBACK_2(FBMainScene::onTouchEnded, this);
dispatcher-&addEventListenerWithSceneGraphPriority(touchListener, this);
bool FBMainScene::onTouchBegan(Touch *touch,Event *pEvent){
CCLOG(&onTouchBegan&);
Point point = this-&convertToWorldSpace(this-&convertTouchToNodeSpace(touch));
void FBMainScene::onTouchMoved(Touch *touch,Event *pEvent){
CCLOG(&onTouchMoved&);
void FBMainScene::onTouchEnded(Touch *touch,Event *pEvent){
CCLOG(&onTouchEnded&);
//获得触点的方法也发生了改变：
Point point = this-&convertToWorldSpace(this-&convertTouchToNodeSpace(touch));
//dispatcher控制方法：
dispatcher-&addEventListener…
dispatcher-&removeEventListener(listener);
dispatcher-&removeAllListeners();区别6.回调函数CC_CALLBACK_0 CC_CALLBACK_1 CC_CALLBACK_2 CC_CALLBACK_3回调函数，分别携带不同的参数，方便2.0
CCMenuItemFont *item = CCMenuItemFont::create(&返回上个场景&, this, menu_selector(GameScene::backScene));
MenuItemFont *item = MenuItemLabel::create(&返回上个场景&, CC_CALLBACK_1(GameScene::backScene, this));
// new callbacks based on C++11
#define CC_CALLBACK_0(__selector__,__target__, ) std::bind(&__selector__,__target__, ##__VA_ARGS__)
#define CC_CALLBACK_1(__selector__,__target__, ) std::bind(&__selector__,__target__, std::placeholders::_1, ##__VA_ARGS__)
#define CC_CALLBACK_2(__selector__,__target__, ) std::bind(&__selector__,__target__, std::placeholders::_1, std::placeholders::_2, ##__VA_ARGS__)
#define CC_CALLBACK_3(__selector__,__target__, ) std::bind(&__selector__,__target__, std::placeholders::_1, std::placeholders::_2, std::placeholders::_3 ##__VA_ARGS__)区别7.CallFunc使用(使用&Function&对象)CallFunc::create([&](){
Sprite *sprite = Sprite::create(&s&);
this-&addChild(sprite);
});区别8.使用clone代替copy2.0
CCMoveBy *action = (CCMoveBy*) move-©();
action-&autorelease();
action = move-&clone();
不需要autorelease，在clone已经实现。区别9.Physics Integration 物理引擎暂无使用，box2d 在 3.0中可以延续使用
在3.0的Physics中需要定义 PhysicsWorld, PhysicsBody, PhysicsShape, PhysicsJoint 等，于box2d相仿，使用前需要定义CC_USE_PHYSICS区别10.容器2.0
cocos2d::Vector&T&
cocos2d::Map&K,V&
cocos2d::Value正在学习中……继续等待补充。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：326396次
积分：4841
积分：4841
排名：第4241名
原创：149篇
转载：15篇
评论：151条
阅读：5994
文章：19篇
阅读：28135
阅读：21551
文章：24篇
阅读：27244
(9)(1)(4)(1)(1)(3)(4)(2)(1)(5)(5)(8)(2)(15)(21)(16)(35)(10)(22)<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&20571人阅读
【Himi转载推荐系列】（3）
本站文章均为原创,转载务必在明显处注明：（作者新浪微博：)&转载自&原文链接:&&&本博客最新动态!及时将最新博文通知您！ 本文出自 [无间落叶]原文地址：为了适应移动终端的各种分辨率大小，各种屏幕宽高比，在 cocos2d-x（当前稳定版：2.0.4） 中，提供了相应的解决方案，以方便我们在设计游戏时，能够更好的适应不同的环境。而在设计游戏之初，决定着我们屏幕适配的因素有哪些，简而言之只有两点：屏幕大小 和 宽高比。这两个因素是如何影响游戏的：屏幕大小：&从小分辨率&480×320&到&&分辨率，再到全高清&1080p，从手机到平板，还有苹果设备的&Retina屏，这么多不同的分辨率，而且大小差距甚大，不可能做到一套资源走天下，资源往小了设计，在大屏幕会显示模糊，图片往大了设计，在小屏幕设备又太浪费，而且小屏幕的手机硬件资源也会相对的紧缺，所以&根据屏幕大小使用不同的资源&是有必要的，而 cocos2d-x 也帮我们解决了这一点。&宽高比：&什么是宽高比，就是你的屏幕是方的还是长的，靠近方形的分辨率如 480×320，比例为&3:2，还有 960×540 的16:9&标准宽屏，这也算是两种总极端情况了，如果能在这两种比例情况做好适配基本就可以了，如果比 3:2 “更方”如 4:3，比 16:9 “更长”，那么不论如何布局，显示效果差距甚大，最好对固定比例优化吧。当在宽高比在一定范围内，可以通过灵活编写程序去适应，而在显示效果上，cocos2d-x 为我们提供了三种模式，这些&模式更多的是帮我们解决比例不一的情况而存在&的，如果只是屏幕大小（比例一样），那通过简单的放大缩小即可完成。三种模式说是三种模式，其实还有一种&无模式，也就是 cocos2d-x 默认的适配方案，现在我们就来认识一下这些模式，并且通过这些模式去认识其中一些概念&FrameSize、WinSize、VisibleSize、VisibleOrigin，以及它们存在的意义，并且最后灵活运行这些概念&创建出一个不属于这些模式而超越这些模式的新适配解决方案，这是最终目的。kResolutionUnKnown 认识 FrameSize这是 cocos2d-x 编写的默认模式，没有做任何处理，在这种情况下，游戏画面的大小与比例都是不可控的，在程序运行之初，由各个平台入口函数定义画面大小：// proj.linux/main.cpp linux 平台手动指定画面大小CCEGLView* eglView = CCEGLView::sharedOpenGLView();eglView-&setFrameSize(720, 480);// proj.android/jni/hellocpp/main.cpp android 平台由 jni 调用传入设备分辨率参数void Java_org_cocos2dx_lib_Cocos2dxRenderer_nativeInit(JNIEnv* env, jobject thiz, jint w, jint h){if (!CCDirector::sharedDirector()-&getOpenGLView()){CCEGLView *view = CCEGLView::sharedOpenGLView();view-&setFrameSize(w, h);AppDelegate *pAppDelegate = new AppDelegate();CCApplication::sharedApplication()-&run();}else{// other…}}在此我们首先认识了&FrameSize&参数，在游戏运行时，我们可以通过&CCEGLView::sharedOpenGLView()-&getFrameSize();获得此值。如果在手机上运行，那么不同分辨率将会得到不同的值，既然这个值不可控，那么在写游戏中也就没有参考价值了，比如我们写一个精灵的位置距离底部 320 高度，在 480×320 分辨率，能看到其在屏幕上方，如果换一台手机分辨率 960×540 那么只能显示在中间靠上的位置，如果设置精灵位置为距离屏幕上方（高度）320，反之依然，显示效果不一。此时可行的方案是使用百分比，如精灵位置在屏幕横向距离左边 1/3 宽度，在 1/2 正中间处，而类似这样的设置也不用依赖 FrameSize 的具体数值。而这样的做法，使得内部元素像弹簧一样，随着 FrameSize 的大小改变而改变，伸缩或者挤压，对于图片资源大小也是完全不可控，如果根据屏幕大小放大缩小，那我们可以考虑用下面要说的模式，在此不推荐使用 cocos2d-x 的无模式方案。kResolutionExactFit and kResolutionShowAll 认识 WinSize在 AppDelegate.cpp 处可以通过设置：&CCEGLView::sharedOpenGLView()-&setDesignResolutionSize(720, 480, kResolutionShowAll);// 或者CCEGLView::sharedOpenGLView()-&setDesignResolutionSize(720, 480, kResolutionExactFit);DesignResolutionSize！顾名思义，也就是逻辑上的游戏屏幕大小，在这里我们设置了其分辨率为 720×480 为例，那么在游戏中，我么设置精灵的位置便可以参照此值，如 左下角 ccp(0,0)，右上角 ccp(720, 480)，而不论 FrameSize 的大小为多少，是 720×480 也是，是 480×320 也罢，总能正确显示其位置，左下角和右上角。能够实现这一点的原因是，固定了设计分辨率大小，从而确定了其固定的宽高比，它的&优势&是可以使用具体的数值摆放精灵位置，不会因为实际屏幕大小宽高比而是内部元素相对位置关系出现混乱。而为了保持画面的宽高比，cocos2d-x 做了些牺牲，牺牲了什么呢？kResolutionExactFit 牺牲了画质而保持了全屏显示，对画面进行了拉伸，这意味着什么？意味着相对极端情况下，本来精灵是方形的，显示出来变成长方形，本来圆形的变成了椭圆，固此模式不推荐使用。kResolutionShowAll 为了保持设计画面比例对四周进行留黑边处理，使得不同比例下画面不能全屏。鱼和熊掌不能兼得也 ~我们可以通过如下方法获取到&setDesignResolutionSize&所设置的值：CCSize winSize = CCDirector::sharedDirector()-&getWinSize();我们可以用&&一文的方法，跟踪 WinSize 的初始化，获取过程，在这里简单提一下，如下步骤：&// 获得 winSizeCCSize winSize = CCDirector::sharedDirector()-&getWinSize();// 查看其 getWinSize(); 方法实现[cocos2dx-path]/cocos2dx/CCDirector.cppCCSize CCDirector::getWinSize(void){return m_obWinSizeInP}// 而 m_obWinSizeInPoints 是何时被赋值的[cocos2dx-path]/cocos2dx/platform/CCEGLViewProtocol.cppvoid CCEGLViewProtocol::setDesignResolutionSize(float width, float height, ResolutionPolicy resolutionPolicy){……m_obDesignResolutionSize.setSize(width, height);……CCDirector::sharedDirector()-&m_obWinSizeInPoints = getDesignResolutionSize();}const CCSize& CCEGLViewProtocol::getDesignResolutionSize() const{return m_obDesignResolutionS}具体的优势：通过设置逻辑分辨率大小，相比无模式，可以帮我们解决了屏幕自动放大缩小问题，并且保持屏幕宽高比，使得游戏更好设计，可以将设计画面大小作为默认背景图片大小等，唯一点遗憾就是那点前面所提到的一点点牺牲。kResolutionShowAll 方案可以作为我们的默认解决方案，使得游戏的设计更为简化，但为了补填拉伸或留黑边这点缺憾，进入下一个模式！kResolutionNoBorder 了解 VisibleSize 与 VisibleOrigin此模式可以解决两个问题，其一：游戏画面全屏；其二：保持设置游戏时的宽高比例，相比 kResolutionShowAll 有所区别的是，为了填补留下的黑边，将画面稍微放大，以至于能够正好补齐黑边，而这样做的后果可想而知，补齐黑边的同时，另一个方向上将会有一部分画面露出屏幕之外，如下示意图：黑色边框标示实际的屏幕分辨率，紫色区域标示游戏设计大小，而通过放大缩小，保持宽高比固定， 可以看到&Show All&之中的黑色阴影部分为留边，而&No Border&的紫色阴影部分则不能显示，而这紫色区域的大小是游戏设计之时是不可控的。那么原设计的画面大小就失去了&一定的&参考价值了，因为这可能让你的画面显示残缺。这时仅仅通过 WinSize 满足不了我们的设计需求，所以引入了&VisibleSize&与&VisibleOrigin&概念。如上所示，紫色区域是被屏幕截去的部分，不可显示的，根据实际情况，可能出现横向截取和竖向截取，这取决于实际分辨率的宽高比。而 A、B、C、D所标示的是设计分辨率，固定大小。如果我们想让一个精灵元素显示在屏幕上方靠边，那么如果使用 WinSize 的高度设置其位置，可能出现的情况就是显示到屏幕之外了。FrameSize 和 WinSize 我们已经知道其概念，而 VisibleSize 和 VisibleOrigin 所代表的是什么呢，又时如何为我们解决靠边的问题！注意上图下方的定义，&VisibleSize = H I J K 是用紫色标注的。&而在上图是&黑色&标注，标示屏幕实际分辨率，虽然 FrameSize 和 VisibleSize 都是 H I J K，但其意义不同，紫色表明它是与设计分辨率相关的。FrameSize 是实际的屏幕分辨率，而&VisibleSize 是在 WinSize 之内，保持 FrameSize 的宽高比所能占用的最大区域，实际屏幕分辨率 H I J K (黑色) 可以大于 WinSize ，但VisibleSize 一定会小于或者等于 WinSize，这两者相同的是宽高比。VisibleSize 有着 WinSize 大小（随WinSize 的大小改变而改变），还有着 FrameSize 的宽高比，它标示&在设计分辨率（WinSize）下，在屏幕中的可见区域大小。&而 VisibleOrigin 则标示在设计分辨率下被截取的区域大小，用点 K 标示，有了这些数据，我们想让游戏元素始终在屏幕显示的区域之内不成难事。下面通过几个数值带入，加深这些概念的印象。&// 组[1] :FrameSize: width = 720, height = 420WinSize: width = 720, height = 480VisibleSize: width = 720, height = 420VisibleOrigin: x = 0, y = 30// 组[2] :相比 组 [1] FrameSize 不变 VisibleSize 和 VisibleOrigin 随着 WinSize 的变小而变小FrameSize: width = 720, height = 420WinSize: width = 480, height = 320VisibleSize: width = 480, height = 280VisibleOrigin: x = 0, y = 20// 组[3] : 相比组 [1] WinSize 不变，VisibleSize 随着 FrameSize 的比例改变而改变FrameSize: width = 720, height = 540WinSize: width = 720, height = 480VisibleSize: width = 640, height = 480VisibleOrigin: x = 40, y = 0// WinSize VisibleSize VisibleOrigin 与都设计的分辨率相关，满足如下关系WinSize.width = (VisibleOrigin.x * 2) + VisibleSize.widthWinSize.height = (VisibleOrigin.y * 2) + VisibleSize.heightNoBorder 具体的使用方法可以参考 cocos2d-x 自带例程&TestCpp&，有详细的使用方法，并且封装了&VisibleRect&类，可以获取设计分辨率，不同比例屏幕之时的主要参考点，屏幕四个拐角，和边的中点等，让我们设置元素位置时，使其总能显示在屏幕之内，这里就不详细介绍了。基于这几种模式的程序使用方法，cocos2d-x 自带例程或者网上有很多教程，这里只详细解释了其中各种概念，而知道了这些概念，当然用起来就没有多大问题了。kResolutionLeafsoar！！！这是什么模式！好吧，Leafsoar 是 一叶 的 ID ，或者是本博客的一级域名而已 :P 在 cocos2d-x 中并没有这种模式。除却&UnKnown&与&ExactFit&不说，ShowAll 的优势是，只需要一个设计分辨率，然后通过 WinSize 设置相对对位即可，而且位置的最大长宽都是确定，方便了开发，但屏幕不能填满， NoBorder 模式的优势是在画面不变形的情况下，实现全屏，显示效果更好，但 WinSize 一定程度失效，需要通过运行时计算 VisibleSize 和 VisibleOrigin 来设置位置，由于是运行时计算，所以也就会出现，各种屏幕显示效果不一样的情况。ShowAll 和 NoBorder 各有所长，各有所短，而这里提出的新适配解决方案正是取两者之长，舍两者之短的&组合模式。简单说来就是用 NoBorder 去实现 ShowAll 的思想。NoBorder 可以保证全屏利用，ShowAll 可以更好的使用实际设计坐标固定位置，而且相对位置不会随宽高比的改变而改变，这在编写游戏的时候能方便不少。先上一个示意图，一目了然 （两个图，两个方向）：在原来 NoBorder 模式示意图上添加了新的概念，LsSize = X Y M N&(leafsoar 简写了，为了不跟 cocos2d-x 的一些概念混淆，什么名字不重要，只要了解其含义即可)，在 NoBorder 模式下的 LsSize 相对于 FrameSize 而言，正如 在&ShowAll&模式下的 WinSize 相对于 FrameSize，所以说这是 ShowAll NoBorder 的组合概念，而这里的 LsSize 与 WinSize 的宽高比是一致的。猛地一看，似乎把问题复杂化了，仔细一看，还不如猛地一看 ~~在 ShowAll 中，WinSize 作为最高的宽高，以此参照设置位置，因为在此范围内都能在屏幕上显示，用了 NoBorder 使得四周可能被截去一块区域，而这个区域大小不可控制，所以不能再使用 WinSize 作为参考点来设置位置，而这里的 LsSize 同样，因为 LsSzie 不论在什么情况下，总能显示在屏幕之内，我们可以方便的使用 LsSize 作为坐标系参考，并且可以全屏显示，在配合 VisibleSize ，相比纯的 NoBorder 加强了不少。它可以怎么用？可以把 LsSize 当作 ShowAll 中的 WinSize 来用，而黑边可以使用稍大的图片填充，或者使用其它图片修饰边框，修饰的边框图案可大可小，可长可短，填充屏幕，保持全屏。开始基于 LsSize 的游戏设计实现为了能够准确实现基于 LsSize 的设计，初步计划将 LsSize 设定在 480×320 的分辨率方案，为此做了些准备，首先不使用任何模式情况下，在场景内调用如下：&CCSize size = CCDirector::sharedDirector()-&getWinSize();CCPoint center = ccp(size.width/2, size.height/2);// 大小 600×500 为了 NoBorder 看到效果，使用稍大的背景图CCSprite* pb = CCSprite::create(“Back.jpg”);pb-&setPosition(center);this-&addChild(pb, 0);// 480×320 此图为使用于设计分辨率 LsSize 的图片CCSprite* pSprite = CCSprite::create(“HelloWorld.png”);pSprite-&setPosition(center);this-&addChild(pSprite, 0);// 37×37 在 480×320 画面的四个拐角处，添加参照CCSprite* p1 = CCSprite::create(“Peas.png”);p1-&setPosition(ccpAdd(center, ccp(-240, -160)));this-&addChild(p1);CCSprite* p2 = CCSprite::create(“Peas.png”);p2-&setPosition(ccpAdd(center, ccp(240, 160)));this-&addChild(p2);CCSprite* p3 = CCSprite::create(“Peas.png”);p3-&setPosition(ccpAdd(center, ccp(-240, 160)));this-&addChild(p3);CCSprite* p4 = CCSprite::create(“Peas.png”);p4-&setPosition(ccpAdd(center, ccp(240, -160)));this-&addChild(p4);显示效果：(FrameSize = 640×540)&显示效果：(ShowA FrameSize = 520×320; WinSize = 480×320)&显示效果：(NoB FrameSize = 520×320; WinSize = 480×320)&通过效果我们可以看到，在相同 FrameSize 下 NoBorder 时，画面由于填充了黑边，将画面放大，以至于上下有部分显示不全，通过拐角四个精灵可以看出。好！既然我们知道是由于放大所致，那么我们将画面缩小呢？cocos2d-x 提供了一个方法，我们调用如下代码：CCDirector *pDirector = CCDirector::sharedDirector();pDirector-&setContentScaleFactor(CCEGLView::sharedOpenGLView()-&getScaleY() );为了弥补画面因需要不填空白出现的方法，我们将画面缩小，放大系数可以通过&CCEGLView::sharedOpenGLView()-&getScaleY()&取得。其实 setContentScaleFactor 方法是为了适配不同资源而设计的，可以用此方法对不同资源适配，缩放等。效果如下：我们看到 480×320 的图片显示完全正确了，也正是我们想要的效果，但唯一的缺点是 ~~ 拐角处四个精灵的位置依然不是我们想要的，我们设计的位置是以 480×320 设置位置的，而 WinSize 也是 480×320 ，而此时基于 480×320 的设计必然会显示到屏幕之外，而要想不修改精灵位置，而让其显示正确的位置，那么为了保证 LsSize 的固定，我们需要一个方法，那就是动态设置 WinSize。什么意思？我们知道一般这些模式设计游戏时，是通过&setDesignResolutionSize&设置 WinSize 的，这个值在游戏运行其间是定植，动态改变的是 VisibleSize 等，而这里提出了 LsSize 的概念，可想而知，如果 WinSize 固定，那么 LsSize 会随着屏幕宽高比的改变而改变，那么我们反其道而行，固定&LsSize&值，那么在运行时可以通过实际的宽高比来算得 WinSize 的值，这样动态算得的 WinSize 值就能够保证我们的 LsSize 是一个定值了。相对论，WinSize 与 LsSize 的值是相对的，与其通过固定 WinSize 在运行时动态获得 LsSize （这也是 NoBorder 的默认方式，而导致的结果是 WinSize 没有参考价值），不如我们固定 LsSize 而在运行时算得 WinSize 设置来的要更妙一些。现在不使用&setContentScaleFactor&方法，而修改&setDesignResolutionSize&这里的值，我们知道 WinSize 是 480×320 时，LsSize 必然会小于此值，而 NoBorder 的放大系数我们可以通过如下方式算得（可以参考setDesignResolutionSize方法内部实现），并在 AppDelegate 里执行：&CCSize frameSize = CCEGLView::sharedOpenGLView()-&getFrameSize();// 设置 LsSize 固定值CCSize lsSize = CCSizeMake(480, 320);float scaleX = (float) frameSize.width / lsSize.float scaleY = (float) frameSize.height / lsSize.// 定义 scale 变量float scale = 0.0f; // MAX(scaleX, scaleY);if (scaleX & scaleY) {// 如果是 X 方向偏大，那么 scaleX 需要除以一个放大系数，放大系数可以由枞方向获取，// 因为此时 FrameSize 和 LsSize 的上下边是重叠的scale = scaleX / (frameSize.height / (float) lsSize.height);} else {scale = scaleY / (frameSize.width / (float) lsSize.width);}CCLog(“x: %f; y: %f; scale: %f”, scaleX, scaleY, scale);// 根据 LsSize 和屏幕宽高比动态设定 WinSizeCCEGLView::sharedOpenGLView()-&setDesignResolutionSize(lsSize.width * scale,lsSize.height * scale, kResolutionNoBorder);显示效果：（NoBorder 模式 ;FrameSize = 520×320; LsSize = 480×320; WinSize = 动态获取）&我们看到在没有修改源代码，并且在设计中使用 480×320 的参考系，也既是基于 LsSize 的设计显示效果如我们预期，那么我们换一个 FrameSize 来看看是否能够自动适应呢？如下：显示效果：（NoBorder 模式 ;FrameSize = 600×480; LsSize = 480×320; WinSize = 动态获取）&到此，基于 LsSize 参考系的游戏设计已经完成了，这样做的好处是很明显的，集 ShowAll 和 NoBorder 的优点于一处，这里的图片元素是为了好定位，实现的需要而写的，具体场景可以使用背景地图，或一张大的图片显示，而没有任何影响，也可以继续使用 VisibleSize 得到 LsSize 之外的部分区域大小，在 LsSize 之外可以使用背景图片作为装饰，即保证了游戏的全屏，又保证了游戏设计时的方便，如果使用完全基于 LsSize 的设计实现，除了显示背景装饰之外，我们不想让 LsSize 的内部元素显示到 LsSize 之外如何做呢？我们只需要设定 LsSize 层的的显示区域即可，我们可以修改场景的实现：&// 这里先简单实现思路CCScene* HelloWorld::scene() {CCScene *scene = CCScene::create();// 创建背景层CCLayer* b = CCLayer::create();scene-&addChild(b);// 添加背景图片和设置位置，可以使用其它装饰，或者小图片屏幕都行CCSize size = CCDirector::sharedDirector()-&getWinSize();CCPoint center = ccp(size.width/2, size.height/2);CCSprite* pb = CCSprite::create(“Back.jpg”);pb-&setPosition(center);b-&addChild(pb, 0);// 创建 LsLayer 层HelloWorld *lsLayer = HelloWorld::create();scene-&addChild(lsLayer);}// 在 HelloWorld 中重写 visit() 函数 设定显示区域void HelloWorld::visit() {glEnable(GL_SCISSOR_TEST); // 开启显示指定区域// 在这里只写上固定值，在特性环境下，以便快速看效果，实际的值，需要根据实际情况算得glScissor(20, 0, 480, 320); // 只显示当前窗口的区域CCLayer::visit(); // 调用下面的方法glDisable(GL_SCISSOR_TEST); // 禁用}显示效果：（NoBorder 模式 ;FrameSize = 520×320; LsSize = 480×320; WinSize = 动态获取）&屏幕适配新解看完这篇文章想必对 cocos2d-x 的屏幕适配方案及其原理有了相当的认识，从内部提供的三种模式，再到我们自定义基于 LsSize 的&Leafsoar 模式&(好把，因该叫做 ShowAllNoBorder)。这里已经给出了完全的实现原理以及实现方法，并配有效果图，当然这其中还有些细节需要注意，比如我们基于 LsSize 的大小设计，那么实际的图片肯定需要比 LsSize 的要大，大多少，太小了不够适应，太大了又浪费，如何取舍等问题，这一点取决的因素是什么，留给读者思考 ~~一叶将在 GitHub 处建立一个&项目，读者可以从这里参考实现的方案。(也许此时在 GitHub 所看到的实现并不完全，但已经有了简单的实现方法，并且能够运行，如有必要，将会新写一篇博客，去实现 ScreenSolutions 并且解说)
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2507919次
积分：22459
积分：22459
排名：第228名
原创：169篇
评论：2912条
移动开发专家,专注于移动开发领域,多年 J2me、Android、iOS 平台游戏开发经验;
CSDN、ITeye、51CTO、eoe-Android、泰然、中国移动开发者社区、微度网等多家技术论坛担任专家与版主；
? 【Unreal Engine 】
? 【React Native】
? 【Cocos Creator】
? 【Cocos2dx】
? 【C2dx-Lua】
文章：57篇
阅读：1154099
文章：31篇
阅读：720383}
我要回帖
更多推荐
- ·淘宝黑号检测最新方法被盾了怎么解除啊？
- ·群主宣布群解散的句子群,这些话句句戳心窝
- ·的学西餐到哪个西餐学校好培训学校？
- ·这是什么呀 有没有人知道 小腿上面长的 查了百度说是血小板减少性紫癜能根治吗 有点害怕？
- ·广州火蝠电商怎么样代运营可靠吗？
- ·behringer百灵达耳机fbq1000反馈抑制器调试
- ·欧冠赛程事要怎么玩？？网上可以玩吗？
- ·92分贝音箱覆盖面是人正常说话多少分贝
- ·求大神。。大整数运算器 要求： （1）用顺序数据结构线性表表存储整数，每个单元存储4位。 （2）实现大整数
- ·2k15怎么编辑球员手机版如何提升自建球员能力
- ·微信转账到兴业微信银行卡转账多久到账
- ·匡威在天猫的天猫旗舰店是真的吗吗?
- ·1.93G的win108g内存虚拟内存存怎么设置
- ·欧洲杯赛制冠军联赛的赛制是怎么样的?要怎么玩
- ·天津新浪家居大连新浪工长俱乐部部的地址在哪？？
- ·尼基塔怎么看不了在哪看播放器可以看
- ·美国福特汽车金融公司著名导购员是谁
- ·关于欧冠足球2联赛奖励联赛的常识?要怎么玩
- ·苹果5s解id锁软件i0s 8.1装什么软件可以下载东西
- ·cocos2d value vec2-x 3.2 vec2和size的区别
- ·微信收藏的信息如qq空间主人寄语删除删除了我收藏里面还会有吗?
- ·一个小船救一大船人限坐4人大船限坐6人我们一共28人.如果每条船都坐满,可以怎样租船? - 百度
- ·欧冠打一场比赛收入怎样啊，一起玩
- ·我用农行还平安的信用卡,可是农行已经扣款了,平安银行没有收到我的还款记录，要怎么办
- ·红色瑙景泰蓝手镯有什么功效效
- ·reid.condor闪电公路车价格表
- ·你好，能允许我激战2加入团队你的知道团队吗？
- ·怎么查出qq匿名悄悄话群匿名是谁
- ·笔记本添加笔记本固态硬盘装系统，系统要重装吗？
- ·CCTV欧冠 直播 cctv直播表有吗
- ·离中泰最近的公共自行车租赁系统点
- ·奔驰宝马老虎机规则游戏需要注意什么规则吗？
- ·如何在vb中添加file1vb 控件数组
