リリースノート

・モニタリングする対象 SWF をリストから選択出来るように機能を追加しました。
・不要なデータが混ざるのを防ぐため、サーバー <-> クライアント間のデータのやり取りをリモーティングからメッセージングを使ったものに変更しました。
・上記に伴い、サーバーを Jetty から自前サーバーに変更しました。
・サンプリングがおかしかった所を修正しました。

ダウンロード

SWFProfiler.zip (Ver. 0.0.3)
SWFProfiler.zip (Ver. 0.0.4)

使い方

・SWFProfiler.jar を実行します。
・監視したい対象 SWF をブラウザ上でもローカル上でもいいので開きます。
・リストから対象 SWF のファイル名を選択します。

以上の手順でプロファイリングが可能です。

使用に関して

・実行には JRE 1.6+ が必要です。
・FlashPlayer はデバックバージョンを使用する必要があります。
・SWF はデバッグリリースされている必要があります。

ソースコード

http://bitbucket.org/muta244/swfprofiler/ で bitbucket にて管理しています。

今回のアップデートでだいぶ使えるものになったんじゃないかと思います。ただ、バグやおかしな点もまだまだあるかと思いますので、これからもマイペースに更新していきます。ご意見・ご要望はコメント欄、もしくは bitbucket にチケット登録をお願いします。

先日リリースした SWFProfiler ですが、みなさん動いてなかったかと思います（ですよね？）。なので、修正版をリリースしました。ついでにモニター結果のフィルタリング機能と、定期的にガベージコレクションを自動で行う機能を追加しています。

ダウンロード

SWFProfiler.zip (Ver. 0.0.2)
＊ リンク先を間違えていたので修正しました。（’09.08.16）
SWFProfiler.zip (Ver. 0.0.4)
＊ バグ修正版。（’09.11.18）

あと、ブラウザ版にしろ、ローカル版にしろ、Flash Player はデバッグ版がインストールされている必要があります。それと、SWF 自体もデバッグモードで書き出されている必要がありますので、この点だけご注意下さい。

不明な点やバグ報告などありましたら、ぜひコメント欄へお願いします！

SWFProfiler のキャプチャ画像（nium さんの kujaku を勝手にプロファイリングw）

Flex Builder が無くてもデバッグ環境が必要だと思うので作りました。今の機能は Flex Builder プロファイラのライブオブジェクト相当のみです。Windows, Mac, Linux 全てで使用出来ますが、Swing で開発してるので JRE 1.6+ が必要です。

ダウンロード

SWFProfiler.zip (Ver. 0.0.1)

※ このバージョンは正しく動作しませんので、新しいバージョンをリリースしました。そちらをお使い下さい。

使い方

SWFProfiler.jar を起動した後、監視対象の SWF を開く（ブラウザ上でも可）と監視が始まります。現状では、複数の SWF を同時に開いているとおかしな事になるので、SWF は監視対象一つのみを開くようにして下さい。FlaProfiler とほぼ同じです。

今後の予定

・複数の SWF 対応
・モニター結果のフィルタリング機能
・コンソール機能
・メモリ使用状況のグラフ表示
・国際化

あとは Mac で文字列なカラムでソートすると、何故かちらつくんですよね。Win だと大丈夫。Swing の問題だとは思うんだけど、対処法がないか模索中。

さて、どこまで出来るかな。

前回のデモは、衝突の可能性があるオブジェクト同士の関係を確認出来るものでしたが、今回は実際に接触しているかをチェックしています。こっちの方がイメージが湧き易いかな。

四分木のデモ（※ 要 FlashPlayer 9）

通常は灰色なオブジェクトが、他のオブジェクトに接触するとオレンジ色になります。

使い方はまたまた、今度・・・。

オブジェクト同士の衝突判定を行う際、みなさんはどうしていますか？

一番最初に思い付く方法は衝突対象のオブジェクトを配列にでも入れて、総当たりで Sprite#hitTestObject() なんかで判定してしまおうという方法だと思います。この方法でも、対象のオブジェクト数が少なければ特に問題にはなりません。しかし対象のオブジェクト数が多かった場合、総当たりで計算を行うという方法では計算量が膨大になってしまい、とても現実的とは言えません。

Sprite#hitTestObject() などの衝突判定を行う前に、どうにか衝突の可能性があるオブジェクトを限定出来ないか？

そんな時には四分木を使えば計算量が減らせます。
概念的には miscellaneous さんの「四分木」エントリーが参考になります。

四分木を構築する方法で一般的（？）なものは、空間全体をルートとし、2 x 2 の空間に分割しながらノードを構築するというもの。しかしながらこの方法、必ずしも計算量が減るわけではありません。なぜなら、衝突対象のオブジェクトを探すためにルートから該当部までノードをたどる必要があり、検索にもまた、計算コストが掛かってしまうからです。

じゃあ、どうすればいいのか？

その計算量を減らすため、四分木の構築方法は色々な方法が考え出されているようで、その中の一つに線形四分木というものがあります。概念的なものは、マルペケつくろードットコムさんの「その８ 4分木空間分割を最適化する！（理屈編）」がとても参考になります。このエントリーで書いてあることもほぼ受け売りです。

で、本題。今回自作ライブラリに線形四分木用のクラスを追加しました。これを使えば、四分木がどうこう考えなくても計算対象のオブジェクトを限定することが出来ます。その限定したオブジェクトに対して Sprite#hitTestObject() なんかを行えば、計算量も下がります。

四分木のデモ（※ 要 FlashPlayer 9）

※ 描画部分は四分木とはまた別の部分なので最適化していません。あんまり円を増やしすぎると、総当たりに切り替えた時にかなり重くなりますので注意してください。

デモはキーボードで各種操作を行え、四分木 <-> 総当たりの計算量比較が出来ます。オブジェクト同士を繋ぐ線は、衝突判定が必要なことを表しています。計算量がどれだけ減ったかを確認してみて下さい。

ソースは Bitbucket に一式上げてますので、興味の有る方はどうぞ。
使い方は後日、時間がある時にでも…。

テキストエリアのデモ（※ 要 FlashPlayer 9）

前回の UITextField クラスのラッパークラスで、スクロールが可能な UI を作成できます。

扱い方はサンプル [ドキュメントコード | TextArea 実装コード ] や UITextArea の ASDoc をご覧下さい。

テキストフィールドのデモ（※ 要 FlashPlayer 9）

このクラスを使用して、コンポーネントでいうところの TextInput と Label が作成出来ます。標準コンポーネントでは、ダブルクリックやトリプルクリックした際のテキスト選択がおかしいですが、このクラスを使用して作成した UI では、内部で拡張したテキストフィールドを用いる事により、ダブルクリックで単語、トリプルクリックで段落を選択するように拡張されています。その他にもクリックやタブなどで最初にフォーカスが移った際にテキストを全選択する機能や、IME を制御する機能なども備えています。

詳しい扱い方はサンプル [ドキュメントコード | TextInput 実装コード | Label 実装コード ] や UITextField の ASDoc をご覧下さい。また、使ってみて変な所があれば、Issue にぜひ登録してください。

変数名の長さによる処理速度の違い

変数名の長さによる違いはありません。ですので変数名は、他の人が見やすい・自分が後で確認しても分かり易いような名前を付けておいた方が良いです。

変数を参照する際の処理速度の違い

上のコードでは _getPi <<< Math.PI <<< MyMath.PI = Main.PI < PI = _pi = ns::_pi = pi という結果で、ビルトインクラスのプロパティアクセスは若干重いので、ループ内で大量に参照する場合は変数に格納しておく方が良いです。また、getter アクセスの実態は関数ですので結構重いみたいです。MyMath.PI や Main.PI は、他の参照方法に比べると一階層下がるので若干重いですが、100 万回もループしての結果なので、あまり気にする必要はないんじゃないかと思います。ただ、注意事項が一つありますので「色々な整数化手段での処理速度の違い」も目を通しておいて下さい。

if … else と switch での処理速度の違い

if … else 文は比較回数が少ない場合は軽いですが、比較回数が増えると switch 文の方が高速です。ただ、100 万回も処理させて数ミリ秒の違いですので、臨機応変に見やすい方を記述しておけば良いんじゃないかと思います。

色々な整数化手段での処理速度の違い

Math.floor() が重いのは周知の事実。ただ、ローカル変数に格納したもので計算した場合は軽くなりそうなものの、逆に重くなるというのは以外だったと思います。これは先の「変数を参照する際の処理速度の違い」で Math.PI のようなプロパティを変数に格納しておく Tips と反して、ビルトインクラスのメソッドは逆に負担になりますので注意が必要です。そして本題の整数化では、n >> 0 などのビット演算で整数化する方が多いのですが、int(n) の方が高速だし見やすいのでお勧めです。

Array, Vector 走査時のイテレーション方法による処理速度の違い

forEach は関数を実行するコストが掛かるのでやはり重いです。ただ、for each よりも for の方が高速なのは自分的にもビックリでした。倍速近い差が出るので、大量な処理の中で走査処理が必要な場合は for の方が良いかもしれません。もちろん、Array より Vector の方が高速です。

Array, Vector 走査時に加算を行う際の処理速度の違い

これももちろん、Array より Vector の方が高速という結果に。ただ、Vector の長さを固定している方が高速になるかと思いきや、固定していなくても参照速度に差はないようです。

オブジェクト生成による処理速度の違い

new Object() より {}、new Array() より [] が高速というのは周知だと思います。あと、Vector の長さを指定すると最初に要素の初期化処理が入るようで、生成コストが高くなります。あとは Sprite の生成コストは当たり前のように高いです。独自クラスの生成は、処理が少なければ Object を生成するのとあまり変わりません。

サイン・コサインの取得方法による処理速度の違い

予めサインテーブルを生成した後、ラジアンをテーブルのインデックスに変換して近似値を参照するというもの。かなりの高速化が期待できますが、取得できる値は近似値だという点に注意が必要です。3D での頂点処理などで大量のループ処理を行う際などに効果が期待できるかと思います。

今のところ試したコードはこんな感じです。これからも、他の最適化を思い付いたら wonderfl に投稿した後、ブログにエントリーしていきます。

ゲーム会社の人間でもないのにデベロッパー登録していたので、お叱りのメールかな？とビクビクしながらメールを開いてみたのですが内容は全然違ったもので、Scaleform GFx をゲーム業界だけでなく、Flash クリエイターと言われる人たちにも、ぜひ使ってみてほしいといったものでした。

Scaleform GFx について簡単に説明すると、Flash IDE と ActionScript 2.0 を用いて、ゲーム（PS3, XBox360, Wii, PC, PSP, PS2）用の UI などを制作出来るというものです。fladdict.net さんのエントリーもご参考ください。

他の Flash を生業とされている方々の参考になればと思い、メールの内容を箇条掲載します。ブログへの掲載については快諾頂いてます。

GFx についての内容

• GFx の一般的なアプリケーションは 3D ゲーム内の 2D 表示部分。
• 主に、メニュー、テキスト表示、HUD などに使われている。
• 導入事例は国内では 20 ほど、海外に至っては 300 タイトル以上。
• フルフラッシュのゲーム（あるいはゲームではないコンテンツ）をブラウザ以外のプラットフォームでプレイバックまたはプレイすることも可能。
• 現行の GFx3.0 で搭載された CLIK では、海外の著名な Flasher である Grant Skinner 氏がゲーム用 UI のコンポーネントセットを作っている。
• 現在は AS2.0 のみの対応だが、将来的には AS3.0 への対応も視野に入っている（一年後くらいには？）。
• 海外ではゲーム業界とウェブ業界の垣根がなく人材の行き来が盛ん。
• 国内でも業界間での Flasher との垣根が取り払われて、相互の行き来が生じることでよりクリエイティブなものを産み出せれば。

国内での GFx 導入事例

• 「あいうえ・おーちゃん (Home Media)」WiiWare – 幼児用教育ゲームのフルフラッシュのコンテンツ。GFx2.2 で開発。
• 「NINJA BLADE (FromSoftware)」XBox360 – シネマティックアクションゲーム（映画を見ているようなアクションゲーム）。
• 「ガンダム無双2 (Bandai Namco/Developer Koei)」PS3/XBox360 – アクションゲーム。
• 「King of Fighters 12 (SNK Playmore)」アーケード – 格闘アクションゲーム。

海外での GFx 導入事例

• 「Crysis (Crytek)」PC – 一人称視点シューティングゲーム (FPS)。
• 「Crysis Warhead (Crytek)」PC – 一人称視点シューティングゲーム (FPS)。
• 「シヴィライゼーション レボリューション (Firaxis/2K games)」PS3/XBox360 – ターン制のシミュレーションゲーム。

といった内容でした。

個人的には早く AS3.0 への対応が進めば嬉しい限りです。会社名義であれば試用目的でのデベロッパー登録も大丈夫との事でしたので、興味のある方はぜひ！

今回のスクロールペインのデモ（※ 要 FlashPlayer 9）

Firefox や Opera だと前回のものは、バーやコーナーをドラッグしたまま swf の領域外に持っていった状態でマウスボタンをリリースすると、領域内に戻っても引っ付いたままになってしまっていましたが、これも JSModifier クラスによって改善されています。前回のものも掲載しておきますので、両方を試してみて下さい。

前回のスクロールペインのデモ（※ 要 FlashPlayer 9）

ちなみに JSModifier というクラスは何かというと、Mac のホイールを認識しない問題や、wmode を使用した際の不具合、その他ブラウザに起因する問題を JavaScript を用いて改善するクラスで、使い方は JSModifier.initialize(stage) するだけです。

ASDoc をアップロードしてますので、どういった問題が改善されるかなどの詳しい情報は JSModifier の項を参照して下さい。