FrameSize、WinSize、VisibleSize、VisibleOrigin概念理解
转载地址:http://blog.csdn.net/monzart7an/article/details/19357893 FrameSize就是屏幕的实际分辨率,这是不变的,比如我用的盖世三的手机分辨率为1280x720,这就是盖世三的FrameSize。 注意这个FrameSize很容易理解成屏幕的长宽多少,其实不是,分辨率和实际的长宽没有必然联系。 比如: 盖世3的尺寸(长宽)为4.8寸,分辨率为1280x720 盖世4的尺寸(长宽)为4.99寸,分辨率为1920x1080 所以在设计游戏时,只考虑屏幕的分辨率即可,不用考虑屏幕的实际长宽。 WinSize就是设计分辨率,相当于游戏设计的逻辑大小,可以这样理解,上面的FrameSize就是画框,这里的WinSize就是画布。 VisibleSize就是画布显示在画框中的部分,注意:它的大小是用WinSize来表示的。 VisibleOrigin就是VisibleSize在画框中的左下角坐标点,注意也是用WinSize来表示的。 比如: FrameSize:假设为width = 720,height = 420 WinSize:假设为width = 360,height = 240 在kResolutionNoBorder模式下,实例图像如下: 此时的VisibleSize就是HIKJ,此时的VisibleSize为Width = 360,height = 210。 因为FrameSize的长宽比为 720 :420 = 360 :210,而我们的设计分辨率为 360 :240,所以在kResolutionNoBorder模式下,被画框截下来的设计分辨率 就为360:210 此时的VisibleOrigin就是在VisibleSize中的K,坐标为(0,15),右图中可以看出 15 = (240-210)/2 自我总结: 其实设计分辨率(WinSize)就是程序里面的逻辑画布大小,是我们需要去关注的东西,我们所有的绘图元素都是放在逻辑大小的画布上的。 至于设计分辨率显示到屏幕分辨率(FrameSize),是通过程序给我们的几种模式(kResolutionExactFit,kResolutionNoBorder,kResolutionShowAll,kResolutionFixedHeight,kResolutionFixedWidth)让我们去适配的,去决定画布的那些部分需要显示在画框中(手机屏幕)上。 下面的文章属于转载: http://www.himigame.com/iphone-cocos2dx/1404.html 为了适应移动终端的各种分辨率大小,各种屏幕宽高比,在 cocos2d-x(当前稳定版:2.0.4) 中,提供了相应的解决方案,以方便我们在设计游戏时,能够更好的适应不同的环境。 而在设计游戏之初,决定着我们屏幕适配的因素有哪些,简而言之只有两点:屏幕大小 和 宽高比。这两个因素是如何影响游戏的:
三种模式说是三种模式,其实还有一种无模式,也就是 cocos2d-x 默认的适配方案,现在我们就来认识一下这些模式,并且通过这些模式去认识其中一些概念FrameSize、WinSize、VisibleSize、VisibleOrigin,以及它们存在的意义,并且最后灵活运行这些概念创建出一个不属于这些模式而超越这些模式的新适配解决方案,这是最终目的。 kResolutionUnKnown 认识 FrameSize这是 cocos2d-x 编写的默认模式,没有做任何处理,在这种情况下,游戏画面的大小与比例都是不可控的,在程序运行之初,由各个平台入口函数定义画面大小:
在此我们首先认识了FrameSize参数,在游戏运行时,我们可以通过 此时可行的方案是使用百分比,如精灵位置在屏幕横向距离左边 1/3 宽度,在 1/2 正中间处,而类似这样的设置也不用依赖 FrameSize 的具体数值。而这样的做法,使得内部元素像弹簧一样,随着 FrameSize 的大小改变而改变,伸缩或者挤压,对于图片资源大小也是完全不可控,如果根据屏幕大小放大缩小,那我们可以考虑用下面要说的模式,在此不推荐使用 cocos2d-x 的无模式方案。 kResolutionExactFit and kResolutionShowAll 认识 WinSize在 AppDelegate.cpp 处可以通过设置:
而为了保持画面的宽高比,cocos2d-x 做了些牺牲,牺牲了什么呢?kResolutionExactFit 牺牲了画质而保持了全屏显示,对画面进行了拉伸,这意味着什么?意味着相对极端情况下,本来精灵是方形的,显示出来变成长方形,本来圆形的变成了椭圆,固此模式不推荐使用。kResolutionShowAll 为了保持设计画面比例对四周进行留黑边处理,使得不同比例下画面不能全屏。鱼和熊掌不能兼得也 ~ 我们可以通过如下方法获取到setDesignResolutionSize所设置的值: 我们可以用Cocos2d-x 程序是如何开始运行与结束的一文的方法,跟踪 WinSize 的初始化,获取过程,在这里简单提一下,如下步骤:
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 标示,有了这些数据,我们想让游戏元素始终在屏幕显示的区域之内不成难事。下面通过几个数值带入,加深这些概念的印象。
基于这几种模式的程序使用方法,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 的分辨率方案,为此做了些准备,首先不使用任何模式情况下,在场景内调用如下:
显示效果:(ShowAll; FrameSize = 520×320; WinSize = 480×320) 显示效果:(NoBorder; FrameSize = 520×320; WinSize = 480×320) 通过效果我们可以看到,在相同 FrameSize 下 NoBorder 时,画面由于填充了黑边,将画面放大,以至于上下有部分显示不全,通过拐角四个精灵可以看出。 好!既然我们知道是由于放大所致,那么我们将画面缩小呢?cocos2d-x 提供了一个方法,我们调用如下代码: 为了弥补画面因需要不填空白出现的方法,我们将画面缩小,放大系数可以通过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 里执行:
我们看到在没有修改源代码,并且在设计中使用 480×320 的参考系,也既是基于 LsSize 的设计显示效果如我们预期,那么我们换一个 FrameSize 来看看是否能够自动适应呢?如下: 显示效果:(NoBorder 模式 ;FrameSize = 600×480; LsSize = 480×320; WinSize = 动态获取) 到此,基于 LsSize 参考系的游戏设计已经完成了,这样做的好处是很明显的,集 ShowAll 和 NoBorder 的优点于一处,这里的图片元素是为了好定位,实现的需要而写的,具体场景可以使用背景地图,或一张大的图片显示,而没有任何影响,也可以继续使用 VisibleSize 得到 LsSize 之外的部分区域大小,在 LsSize 之外可以使用背景图片作为装饰,即保证了游戏的全屏,又保证了游戏设计时的方便,如果使用完全基于 LsSize 的设计实现,除了显示背景装饰之外,我们不想让 LsSize 的内部元素显示到 LsSize 之外如何做呢?我们只需要设定 LsSize 层的的显示区域即可,我们可以修改场景的实现:
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |