About

<#TEMPLATE_INCLUDE_NINEPAGE_ABOUTME#>
  • Dec

    18

    starling 库 Sprite3D 翻转动画

    • 0 Comments
    • Flash Platform

    用starling做 3D 翻转/旋转效果就是这么简单:

    //样例主代码,以Y轴旋转为例(其它代码都省了)
    var sprite3d: Sprite3D = new Sprite3D();
    sprite3d.addChild(frontImage)//frontImage是一个starling Image对象
    sprite3d.addChild(backImage)//backImage是一个starling Image对象

    sprite3d.x = 300;
    sprite3d.y = 300;
    sprite3d.pivotY = sprite3d.height / 2//让它沿着容器的中间旋转
    sprite3d.pivotX = sprite3d.width / 2;

    addChild(sprite3d);

    //为了偷懒直接用了TweenLite类,否则要添加侦听器,再加Juggler神马神马的很烦人
    TweenLite.to(sprite3d, 2
    {
        rotationY: Math.PI,
        onUpdate: onUpdateHandler,
        onUpdateParams: [sprite3d]
    });

    var vector3D: Vector3D = new Vector3D();

    function onUpdateHandler(_sprite3d: Sprite3D): void 
    {
        vector3D = stage.getCameraPosition(_sprite3d);
        //设置平面图片在旋转时的可见性
        frontImage.visible = vector3D.z > 0;
        backImage.visible = !frontImage.visible;
    }

    Jun

    11

    Starling 的稳定版本为了兼容 iPad1 代产品,将纹理限制在 2048x2048,可以通过修改源码的方式将纹理大小扩展至和 AIR 支持的 4096x4096。但除了 iPad1 之外,还有其它的一些安卓低端产品也依然不支持大的纹理集,所以为了保持更好的兼容性,对于静态的资源集可以限制采用 2048x2048 纹理集。

    但 Starling 的滤镜比如 BlurFilter.createGlow 创建时,它是动态的纹理,如果滤镜应用到一个较大的显示对象上,那么依然有可能产生运行时异常,会报以下错误:

    Error #3683: Texture too big (max is 2048x2048).

    另一方面,滤镜因为是运行时产生,所以会占用 CPU 资源和较多的内存,而且还会增加 DRW 。所以最好避免大面积的使用滤镜(突然对滤镜没啥好感了),尤其对一个包含多个子对象的容器使用大面积滤镜,还是优先考虑静态的资源吧。

    May

    29

    Apr

    1

    最近做了一款场景游戏,每个场景中都有数十个物品需要“排版”——每个物品都涉及到坐标定位、缩放、旋转、叠加,甚至个别物体需要镜像反转,算上叠加的物品,背景其它元素等,所有关卡加起来有近200个这样的物品,如果每个物品都使用纯代码的方式去编写坐标、缩放、旋转之类的属性值,我觉的我一定是会疯掉的——因为一开始的时候我真的这么做了:我花了一上午将近 3个小时,只写了 5 个物品的“排版”,写第 6 个时我已经要晕了。

    然后就去 Google 上寻找 Starling 可视化编辑的工具,比较了之后,最终选择了 lang 神开发的 StarlingSWF ,主要原因有二个:

    一、StarlingSWF 生成的资源是静态的,它比其它运行时动态生成或转换出来的效率要高。StarlingSWF 提供的类库都继承自原始的 Starling 的类,从加载资源到管理资源,和我以往使用 AssetManager 类基本都一样。反正对象和 API 都基本兼容,没有发现不兼容的对象或 API。

    二、:资料比较全,有提供完整资料的官方博客,而且它是中文的,可以省下大量去翻译其它类库资料的时间(人生最痛苦的事,就是等你花了大量的时间翻译完了之后,测试时发现性能完全不行;人生最最痛苦的事,就是等你花了大量的时间翻译完了之后,测试时性能也可以,应用到项目中去了,项目要接近尾声了,发现性能不行 - - !!

    StarlingSWF 试用感觉就像它自己的广告语那样“像传统Flash AS3开发一样在Starling上开发”。StarlingSWF 给我的感觉就是一个字:爽。再配合 zero 大神提供的 BatchPane,两个字,超爽。然后就没有然后了。

    可能和这两位大牛都使用中文写帮助资料有关系,所以这两个工具仅仅只是花了一下午不到的时间就基本上摸透了(如果是英文的话我估计又得花上个好几天 - -!)。在第二天的时候花了一天的时间就“排版”完成了,事实上是只花了一上午的时间就“排版”完成了,但第一次使用,难免出个幺蛾子:

    以往在手动命名某个实例时,因为懒的多打字母,所以一般都是用 mc、sp、obj 等作为前缀或后缀,一般从来不会超过 3 个字母作为后缀或前缀。因为用了 BatchPane 批量操作,在命名实例时特意很“贱”的加了一个很长的字符串“_instance”作为后缀,和 starling 或 starlingSWF 类库中使用的 “instance” 作为关键字产生了冲突,结果导致了在生成对象后,无法操作对象...然后折腾了一下午之后, lang 神终于看到了我的咨讯信息,告诉实例名中不能包含 instance 字符串让我更换实例名...所以懒人有懒福,以后千万别写那么全的后缀名 - -!!

    Feb

    27

    管理 Feathers 资源的两种主要方式:一种是静态嵌入,另一种运行时动态加载。

    静态嵌入

    在 Feathers 中只需如下类似代码即可完成对主题资源的使用(现在新版的 Feathers 已经不需要一个类对象或对象的属性去保存对一个主题的引用了,直接 new 就可以):

    new MetalWorksMobileTheme()

    这种方式比较简单,适合初学者或资源文件不大的情况下。但这种方式要求更多的内存(基本上就是翻倍的内存要求),所以不适合资源文件非常大的情况:Flash 运行时环境在运行 SWF 文件时会存储整个 SWF 文件,当一个嵌入的资源文件被实例化的时候,它又会被复制一份到内存中,所以这种静态嵌入资源对内存的使用基本上会让内存翻一倍。

    在 MetalWorksMobileTheme 默认的这个主题中因为资源文件较小,所以影响不大,但一个自定义的主题资源文件可能会有非常大的内存需求,特别是在开发游戏时的那些大型资源,建义都使用运行时动态加载。

    运行时动态加载

    通过 Starling 的 AssetManager 类在运行时可以动态的加载资源文件,资源文件可以通过 URL 加载(网络服务器上的资源),在 AIR 环境里也可以直接加载本地文件系统中的资源文件。这种方式相对于静态嵌入资源的方式优点是使用内存较少,因为它只会在内存中出现一次,缺点是使用资源管理对象时会相对来说稍复杂一些。

    首先需要指定资源的位置,在一个 AIR 程序中,需要同时打包被引用的资源文件,比如,MetalWorksMobileThemeWithAssetManager 需要以下两个资源文件(MetalWorksMobileTheme 继承自 MetalWorksMobileThemeWithAssetManager ) 

    images/metalworks.xml
    images/metalworks.png

    然后通过下面的代码来告诉主题 images 目录(包含了上面两个文件)的位置在 File.applicationDirectory 下(当然这个资源文件的位置也可以放在其它子目录中):

    var theme:MetalWorksMobileThemeWithAssetManager =
        new MetalWorksMobileThemeWithAssetManager( File.applicationDirectory );

    然后侦听 theme 对象的 Event.COMPLETE 事件:

    theme.addEventListener( Event.COMPLETE, theme_completeHandler );

    当资源文件被加载完成后,并且可用于组件时,资源管理对象调度这个事件,换句话说,开发者必须等待这个事件调度后才能使用资源文件中的东西,否则就不会有任何纹理或其它东西可以提供给组件的皮肤,事件的侦听器可能是如下类似代码:

    private function theme_completeHandler( event:Event ):void
    {
        // the theme is ready!
        this.button = new Button();
        this.button.label = "Click Me";
        this.addChild( button );
    }

     PS:春节前我才刚升级到 Starling 1.6.0 与 Feathers 2.0.1 版本,过完春节后发现它们又分别升级到了 1.6.1 与 2.1.0 版本(并且 Feathers 已经开始出了 2.2 的测试版本),看来还是有不少人在用的样子 

    Feb

    15

    1、starling 对象的 enableErrorChecking 属性值如果设为 true,内部的 clear() 与 drawTriangles() 方法将会同步的调用,如果是false,这两个方法将会异步调用。所以最好只在测试时使用 true,正式发布时使用 false 以提高性能。

    2、显示对象的 rotation 属性使用的是弧度,不是角度。可以使用 starling.utils.deg2rad 进行转换。

    注:如 deg2rad(Math.random() * 360);

    3、starling 显示对象只有 hitTest() 方法的(它没有 hitTestPoint 或 hitTestObject 方法,至少现在是没有),它返回的是一个显示对象。

    4、简单的显示对象碰撞检测可以使用 getBounds () 方法返回两个对象相对于同一个坐标系后,通过 Rectangle 原生方法“相交 / 交集” intersects() 测试。

    5、PDParticleSystem 虽然也是 starling 显示对象,但它的大小为 0,所以最好不要动态的修改它的大小,而是要通过修改粒子系统本身的配置数据来改变粒子的大小;同样也不要动态修改它的注点 pivotX 与 pivotY,而应改修改它的发射点 emitterX 与 emitterY。

    6、starling 的事件机制是没有捕获阶段的,只有冒泡阶段的。

    注:starling 的 触摸事件 TouchEvent 在 iOS 与 Android 设备中是有差别的。参考 http://blog.zinewow.com/post/397.html

    8、starling 的影片剪辑对象(MC)与传统的 MC 对象虽然 API 语法类似,但本质有很大区别。

    注1、starling 的 MC 通过一定的时间间隔切换纹理图像摸似传统 MC 的时间轴上帧画面连续播放。

    注2、starling 中的 MC 索引是从 0 开始的,不是从 1 开始的。

    注3、stop() 方法更像是 gotoAndStop(0),而 pause() 方法更像是传统 MC 的 stop()。

    注4、只要不是同时添加的显示对象,它们的播放头并不会像传统的 MC 那样同步。既便两个 MC具有相同的帧速率,只要不是同时添加的,那么它们的播放头就不是同步的(这一点可是与传统 MC 有很大区别哦,一不小心可能会引起大 Bug)。

    9、starling 与时间相关的属性值都是以秒为单位的(不是以毫秒为单位的)

    注:API 参考 http://doc.starling-framework.org/core/)。

    10、starling 对象的 nativeOverlay 引用的只是原生舞台上某个显示对象,与主类为兄弟关系(引用的不是主类,也不是主类的子对象)。

    Feb

    4

    Starling 粒子系统

    • 0 Comments
    • Flash Platform

    Nov

    4

    Starling 截屏功能测试

    • 0 Comments
    • Flash Platform
    var _w:Number = Starling.current.stage.stageWidth;
    var _h:Number = Starling.current.stage.stageHeight;

    var t:Number = getTimer();

    var r:RenderSupport=new RenderSupport();

    RenderSupport.clear();

    r.setOrthographicProjection(00, _w, _h);

    Starling.current.stage.render(r,1);

    r.finishQuadBatch();

    var bitmapData:BitmapData=new BitmapData(_w, _h, true);

    Starling.current.context.drawToBitmapData(bitmapData);

    trace(getTimer() - t);//iPhone4 调试模式平均值输出也在267ms左右

    以上代码测试 Starling 版本为 1.5.1 版,既便是在 iPhone4 这么老的机器中使用调试模式,截分辨率为 960x460 全屏图平均值输出也只有 0.267 秒左右,感觉速度很可以了吧。

    Oct

    5

    从 iOS 升级到 7 以后的版本时,AIR 最常见的问题是由状态栏引起的。在 iOS 7 以前的版本中,如果是在全屏状态下,APP 的状态栏是真正的不可见的,但在 iOS7 以后的版本中,会发现它的状态栏是一个透明状态栏并且浮动在 APP 界面上,并且舞台的分辫率尺寸发生变化(由原先的不包含状态栏区域,变成包含状态栏的区域部份),如果没有做自适应处理,那么界面元素将有可能被拉伸,或界面元素与状态栏的文字重叠等,但这些还都只是小问题。

    最严重的问题还在于状态栏还可能引起 Starling 丢失 Context,比如:在全屏状态的 APP 中,调用 CameraRoll 浏览照片,此时 CameraRoll 本身会包含状态栏,当从 CameraRoll 界面返回到 APP 界面时,APP 实际上包含了状态栏的显示和消失的过程,而这个过程又其实包含了 AIR 生成一个新的 Stage3D context 的过程(Starling 基于 Stage3D),并且这个过程导致了原先 Starling context 的丢失。

    虽然官方的 API 手册中只是建义在安卓和 Windows 系统中设置 handleLostContext 为 true 防止纹理意外丢失(比如睡眠状态返回,旋转屏幕等等),而事实上在 iOS 中如果像上面这种 CameraRoll 调用的情况下,使用 Starling 最新版本同样也要设置 handleLostContext 为 true(尽管这可能会造成较大的内存使用来缓存纹理)。这并不是一个最好的建义,如果开发者足够仔细,会发现从 CameraRoll 界面返回时,因为重新创建纹理的原因,所以会导致整界面刷新,在视觉上有“瑕疵”(丢了 Context 的舞台什么都没有一闪而过)。

    不知道 Adobe 未来的 AIR SDK 中是否会修改这个问题,或不知道要多久才能修正这个问题。所以除了 handleLostContext 设置为 true 防止意外的丢失 Context 外,推荐将 -app.xml 中的 fullScreen 设为 false,防止由于状态栏的原因造成 Context 丢失的问题(除非你正在开发的 APP 不是基于 Starling 的,或始终与状态栏的显示与消失无关如果状态栏文字需要在 APP 运行期间动态的修改颜色,推荐一个能动态修改状态栏文字颜色的 ANE 文件:IOSStatusBarAne-master.zip

    Jan

    7

    在《Introducing Starling》一书中在介绍 Flash Player 中的显示层次结构时,我们会看到 StageVideo 处于 Stage3D 和 传统的 Display List 层之下,但书中也非常明确的写明了 StageVideo 显示的内容总是会重叠在 Stage3D 层的内容上面。初一看,也许会觉的这个是原作者写错了,或写反了;连《Introducing Starling》中文译版(《Starling 框架帮助手册中文版》)的作者 S_eVent ,也在翻译的中文版里注明了这一点让他感到困惑。

    其实要解释这个问题很简单,StageVideo 层中的内容是会被单独渲染成一个独立的 StageVideo 对象,但这个对象并不是直接显示的,而是通过 GPU 在渲染的步骤中被合成进去的,所以它总是会在 Stage3D 层上面。

    智能电视机、数字机顶盒,以及其它移动设备,虽然没有像台机那样强大的 CPU,但它们却有非常强大的视频解码功能,只需要少量的 CPU 使用率就可以渲染高品质视频(前提是视频编码的支持,比如 H.264视频编解码器,能使视频从解码开始到渲染,都能充份利用 GPU 加速)。为了确保 StageVideo 可用,须设置 wmode 属性为 direct 模式, 这种模式在 Windows 上会使用 Direct3D;在 Mac OS 和 Linux 系统中使用 OpenGL,这样就可以通过GPU进行视频帧的合成处理。

    当然,GPU 加速同样适用于桌面设备上,所以一些视频网站同样利用 StageVideo 开发桌面 WEB 版的视频播放器,但这其实会产生一个问题:利用 GPU 硬件加速的时候会造成显卡的温度过高,而普通的笔记本用户大多只有一个 CPU 的风扇,所以看起来 CPU 使用率很低的情况下,笔记本用户仍然会因为显卡温度过高而自动关机。而开发公司的开发者们往往使用的散热良好的台机(台机显卡大多会有独立的风扇),一般情况下他们不容易发现这个问题。

    注:如果需要 《Starling 框架帮助手册中文版》,可以加入 QQ 群:15965780,群共享内有下载。

    More...