Using SWF animation in Haxe/OpenFL applications
Asked Answered
U

2

5

As great as Haxe got with NME/OpenFL the big problem transitioning from AS3 development are assets. As much as Haxe is similar to as3 and OpenFL tries to provide a familiar API the lack of SWF support scares away many developers. My research on this topic led me to understand that current SWF is rather weak and buggy with many edits necessary to SWF file in order to run it in Haxe.

The question is how do you use SWF animation in OpenFL apps, or if you don't - whats the best solution you've found regarding rendering time, processor time and file size.

Unsure answered 14/8, 2013 at 1:55 Comment(0)
U
11

Having spent more time on the research and asking other developers I put together a small list of possible alternatives to using SWF assets for animation. Hopefully it will help other developers, who has a similar problem while the SWF animation support is weak.

NOTE: all methods were selected considering three factors important for me: availability on all platforms, performance and file-size of assets. Therefor not all possible methods were included.

Tested on: HTML5, Android, iOS

  • SWF animation is possible with Haxe/OpenFL, but there are few rules: no tweens - all animations are frame-by-frame. Vector art should be cached as bitmap, saved as bitmap or pre-rendered as bitmap sequence as on some platforms (e.g. neko) vector art is being transformed to raster with ugly bitten edges. Some bugs were reported if representing MovieClip's as graphics or vice versa, but I didn't notice any bugs on HTML5, Flash, iOS, Android releases. Nested animations sometimes might skip frames if looped (didn't see that either, maybe older release of NME/OpenFL did that). I'd say this is a fairly good way to animate content from the concern of file size and platform availability, but it's a headache to edit all the assets to meet requirements of Haxe support. And it's not fun to reuse these assets later, since they're all frame-by-frame animations and it's a mess.

  • Sprite sheet animations. Primary used for HTML5 targets due to higher rendering performance. This is directly from a openGL standard, so this method should apply for all openGL targets. The idea is to rather have one big file and save time on opening/loading multiple smaller files. The performance is good, works on all tested platforms, but the file size get's quickly out of hand and can be hardly used for animations where object size is changing in size - makes unnecessary large transparent space, rotating the image to best fit the space reduces rendering performance with editing the transformation matrix on run-time.

  • Frame sequence aka PNG sequence animation. Personal favorite. It works well and fast on all platforms, it's possible to pre-render the the animation (just like any other method above), transform to BitmapData array, stream-load etc. It does take a lot of disk space for the animations, but can be softened by loading the assets before using them (HTML5, SWF) and it doesn't really matter for mobile devices - as even 1-2GB apps are ok for the market. Large advantage that I found for myself is that this type of asset can be used for any other developing standard (C++, Java, cocos2d) and saved as Sprite sheet if needed (e.g. cocos2d, like HTML5 prefers Sprite sheets over anything else as written in the official book COCOS2DX by Roger Engelbert).
    With this flexibility, good performance is tolerable file size I prefer this method over any other method listed above.

  • Bone animation - PNG array + property list. Another approach is having separate images of an animated object and every image matrix data for every frame. That way with minimum disk space use it's possible to make thousands of animations. The downsides are: it's harder (not impossible) to have nested animations for more complex animations, constant matrix transformations limit number of active animations on the display list (horrible method for HTML5, other platforms held on well) and little reusability of assets. Usually it's the same good old SWF assets that were exported to this type, so it makes sense to edit the FLA rather then the bone animation itself.

Surely I've missed some great points, there are many ways to animate graphics and some might work for you better than others so feel free to leave comments and criticize, but I still hope this topic was helpful.

Unsure answered 20/8, 2013 at 5:18 Comment(0)
A
5

This question might be obsolete. I compiled a C++ app in Haxe/OpenFL just 5 minutes ago and had no trouble getting SWF animations (with tweens) to work.

Here's a gif recording: https://imgflip.com/gif/7l02f

I had an asset called "library.swf" containing that animation, exported as class "Oluv"

This requires the "swf" library which is now free, and can be installed with "haxelib install swf"

In my example, I added this to my application.xml file:

<haxelib name="swf" />
<library id="oluvLib" path="assets/library.swf" type="swf"/>

Then put this in a standard OpenFL template project:

Assets.loadLibrary("oluvLib", swfAssetsLoaded);

private function swfAssetsLoaded(library:AssetLibrary):Void {
    var oluv = Assets.getMovieClip("oluvLib:Oluv");
    addChild(oluv);
    oluv.x = (stage.stageWidth - oluv.width) / 2;
    oluv.y = (stage.stageHeight - oluv.height) / 2;
}

Tweens do not seem to work on neko target, but they work fine in C++, and flash (of course).

Alexine answered 17/3, 2014 at 18:33 Comment(2)
Thank you for your response, it will definitely help new developers. Please do note that one of the reasons to create this topic was to find an approach that works reliably on all platforms with most performance and least disk space.Unsure
@Alexine Hi, I tried what you have given in your answer but I get the following errors during compilation (Would you know what's wrong?): Called from openfl/_v2/media/SoundChannel.hx line 323 Called from openfl/_v2/Lib.hx line 207 Called from /usr/lib/haxe/std/neko/Lib.hx line 30 Uncaught exception - load.c(357) : Primitive not found : ./lime@lime_sound_channel_set_pitch(2) Build halted with errors.Clamorous

© 2022 - 2024 — McMap. All rights reserved.