Haxe OpenFL Box2D 動作速度検証・他
自作 Haxe ライブラリの OpenFL への対応が完了しました。とはいえ OpenFL は Flash API 準拠という事から、ほとんど修正は必要ありませんでした。as3 の文字があるディレクトリは今後、Flash or OpenFL 用のライブラリとなります。
https://github.com/siratama/haxelib/tree/master/src
OpenFL 対応に伴い、以下のデモページを作成しました。Flash CC のステージ上に配置したシンボルを html5 canvas or flash box2d オブジェクトに変換するライブラリとなりますが、今後はあらゆるプラットフォーム(windows, mac, ios, android, etc)にて利用が可能となります。
http://www.dango-itimi.com/flash_to_box2d/
また、以下は Box2D を用いた Android アプリの動作速度比較用のものとなります。アプリの内容は Box2D の四角形のオブジェクト 100個を表示するだけのものです。
http://www.dango-itimi.com/blog/swf/195/
Androd 2.3 端末と Nexus7 とで検証した所、結果はそれぞれ以下となりました。
■ Android 2.3
Adobe AIR : fps 14~16
OpenFL : fps 25~30
■ Nexus7
Adobe AIR : fps 25~28
OpenFL : fps 55~58
Nexus7 に関しましては圧倒的な差がでています。
OpenFL が速い理由は Android NDK にて出力が行われる、という点にあります。C++ で出力が行われるため、Java で作られた Android アプリより高速に動作するとの事です。
オーサリングツール Flash で編集した素材データ(swf)を利用しつつ、あらゆるプラットフォーム向けにソースコード一つで高速に動作するアプリを生成できる、なんともすごい内容ではあります。しかし先日記事にした通り、OpenFL には懸念点はまだまだあるのも事実です。速度を必要としないアプリならば、Adobe AIR で作成したほうがよい状況もあるため、適材適所で使用していきたい所です。
クロスプラットフォーム向け記述
OpenFL で処理を記述する際の注意事項です。
cast ではなく Std.parseInt or Std.parseFloat or Std.string を利用
Flash, js ターゲットの場合 cast で済む文字列←→数値変換も、native ターゲットの場合エラー(コンパイル時のエラー)が発生するため、Std クラス経由での変換が必要となります。
Flash API 準拠に関して
OpenFL では 出力ターゲットに合わせて「openfl」「openfl native」「openfl html5」のいずれかのライブラリが自動的に選択されます。「openfl native」「openfl html5」は Flash API から機能が削られているので注意が必要です。
例えば「openfl native」 の場合 flash.display.MovieClip.currentLabel プロパティが存在しません。swf バイナリ解析で取得可能な情報のみのメソッドやプロパティが用意されていそうです。
MovieClip へのプロパティアクセス
OpenFL の Assets 機能を利用する場合、「MovieClip 内に配置した MovieClip」にアクセスするためには MovieClip.getChildByName メソッドを使用する必要があります。同様に「MovieClip 内に配置している MovieClip 数」を取得したい場合、MovieClip.numChildren を使用する必要があります。Reflect.fields メソッド経由では取得できません。
Reflect.fields(mc).length // NG mc.numChildren // OK
その他
あらたにわかった点や懸念点等です。
native extension
OpenFL では Adobe AIR と同じように、ネイティブ拡張と呼ばれる機能を利用する事でデバイス独自の機能にアクセスする模様。nme native extension といったキーワードで結構見つかります。
例えば以下の様なページが見つかります。
http://haxeflixel.com/wiki/native-extensions
スマートフォンアプリからのカメラ機能利用に関しては有力な情報が見つからず。カメラ機能実装は難しい可能性も。
nme forum: camera 検索結果
http://www.nme.io/community/forums/search/?search_paths%5B%5D=/community/forums&query=camera&submit=Search
windows ターゲット出力の場合の fps
60 fps に設定しているのに、50 fps で固定されてしまう現象が発生することがあります。発生しない事もあり、条件が不明。
http://www.nme.io/community/forums/installing-nme/windows-build-capped-at-50fps/
swf 内ベクターデータのアンチエイリアス描画
コンパイル用 xml ファイル内 windows タグでの antialiasing 指定を行うとよしとなります。
<window width="400" height="400" antialiasing="4" />
OpenFL の説明ページには書かれておらず、NME antialiasing という単語で検索すると情報が見つかります。
OpenFL 用 project.xml format
https://github.com/openfl/openfl/wiki/Project-format
今後の予定
サンプルを作ってみて大きな問題はなさそうなので、FlashToHaxeConverter に OpenFL 用 abstract クラス出力機能を実装します。
https://github.com/siratama/Flash-To-Haxe-Converter
また、こちらで指摘のあった、Flash 用 extern 無しクラス出力機能も実装します。
http://qiita.com/tail_y/items/9d7f8cf903613c1037e6
ミニゲームばかり作っていて、swf 動的ロードに関しまして検証を行なっておらず、extern クラス出力だけで問題ないものと考えてしまっていました。
後は同じく指摘のあった「リンケージ設定を行なっていないムービークリップ内部のプロパティへの IDE 補完用 内部クラス出力機能」(長い)に関しまして、余裕があれば実装したいと思います。MovieClip は Dynamic のため、内部クラスは typedef ではなく extern でも swf動的ロードで問題は発生しなさそうではありますが、コンパイルオプションで strict を利用した場合どうなるのか等、検証が必要となりそうです。
その他、内部クラス出力機能の前に、リンケージ設定が行われているムービークリップも現在は MovieClip として出力されてしまうため、まずはこちらの機能実装が先かもしれません。