void element blog

Life is beautiful で興味深いエントリがあがっていたので反応してみたいと思います。

引数に数字が並ぶと何がなんだか分からなくなるのは確かにそうなのですが、開発環境によってはメソッド定義先でどういう変数名で受け取っているのか、型は何なのか、デフォルト引数は設定されているのかがコーディング時に全て分かります。
これをプロパティ渡しでやってしまうと、変数名はまだ分かるのですが型やデフォルト引数がわからなくなってしまうというデメリットが生じます。
型については識別可能なように変数名を付ければ問題ありませんが、デフォルト引数についてはコメントで補足しないとどうしようもありません。

下記みたいにプロパティ渡しでもデフォルト引数が渡せれば最強なんですが、サポートされてないのでどうしようもないですね。


function hoge({a:String="aaa",b:uint=0xffffff}:Object):void {
// ほげほげ
}


それから引数に関して前々から気になっているのが、定数とデフォルト引数について。
コーディングしている時にオートコンプリートでデフォルト引数値が表示されるのはとても便利なのですが、このデフォルト引数値に数値や文字列ではなく定数を設定していると生真面目に定数名を表示してくれるおかげでたまに面倒なことがあります。
constで宣言されている場合には値も表示してくれればどんだけー

プロパティ渡しについては実は2年前にやっていたブログで書いたことがあったので、ちょっと切ない気持ちになりましたｗ
でもあれから環境も変わり、上記のような開発環境によるメリットデメリットを改めて考察することができたのでいい機会になったと思います。

投稿者: munegon 日時: 18:00 | パーマリンク | コメント (0) | トラックバック (0)

TwitterClockをバージョンアップしました。

ダウンロード（AIRになって互換性がなくなったので一旦公開終了）

[変更点]
・読み込むデータをXMLからJSONに（アクセスがめちゃくちゃ早くなった）
・メアドを通すためにわざわざスクレイピングしてたのをやめた（API仕様書ちゃんと読んでなかった）
・タイムラインを消すタイミングを、読み込み前ではなく読み込み後に変更。

前回のエントリでソース公開するとか書きましたが、微妙に直したいところがあるのでもう少し待ってください。

ところで、airファイルを直接ダウンロードしようとすると何故か勝手にzip形式でダウンロードしてたことがあったんだけど、あれは何だったんだろう。
詳しいことは知らないけど、swcみたいに中身はただのzipなのかな。
となると、Apolloランタイム入れてない人にはちょっと不親切な気がする。

投稿者: munegon 日時: 17:30 | パーマリンク | コメント (0) | トラックバック (0)

自分の中の常識と世の中の常識にズレを感じるシリーズ第一弾（第二弾は未定）

大学の頃、プログラミングの授業で「後置演算子は一旦レジスタに退避させなきゃならないので前置演算子に比べると遅くなる」と習って以来、必要に迫られない限りはできるだけ前置で書くようにしている。
特に長大なループ文のインクリメントでは必ず前置演算子で書くことを心がけているのだが、ネットに転がっているソースコードのほとんどが後置演算子で書かれていて、何か陰謀を感じずにはいられない。

たとえば a - ++i のように演算子に続く場合は可読性の問題から後置にしてしまうのは理解できる。 ← (はてブコメントより指摘、思いっきりおかしなこと書いてました)
でもループ文のインクリメントってほとんど単独記述じゃないだろうか？

計算速度の向上から無視できるレベルになってるとはいえ、最適化のTipsなブログでも前置演算子で書かれているのは稀なのが気になってしょうがない。
本当にソースコードの可読性の問題で片付けてしまっていいのかな。

詳しい人教えてください。

投稿者: munegon 日時: 18:30 | パーマリンク | コメント (5) | トラックバック (0)

FlashPlayerでは2880pxを超えるサイズの画像を読み込んでも、2880pxのところでカットされてしまうという悲しい仕様がありますが、ActionScript3.0限定でこれを打開できる方法を見つけました。

バイナリで読み込んで、Loader.loadBytesで再生成するだけ。

要するに前回のエントリで紹介した方法と全く同じです。
このやり方だと上限がなくなるのかどうかまでは未検証ですが、誰かエロい人がやってくれるでしょう。

ちなみにバイナリ経由だと外部ドメインの画像に対するサンドボックスも無視できるため draw し放題。
ただし外部リソースの読み込み自体にセキュリティ制限があるため、crossdomain.xmlによって開放されている必要があります。

あたかも最初から埋め込まれているリソースとして扱えるようになるということですね。
こうなってくると、バイナリで読み込むところにものすごい可能性が秘められているような気がしてきます。

投稿者: munegon 日時: 19:00 | パーマリンク | コメント (0) | トラックバック (1)

as1やas2では、loadMovieで読み込んだ外部swfをduplicateMovieClipで複製することができませんでしたが、as3ではバイナリを利用すれば複製することができます。

Loaderで読み込む代わりにURLLoaderでバイナリとして読み込んだ後、dataプロパティに格納されているバイナリデータからLoader.loadBytesメソッドを利用してLoaderを再構築します。
これを繰り返せば、その場で複製が可能となります。

private function loadMovie( url:String ):void {

	var loader = new URLLoader();

	loader.dataFormat = URLLoaderDataFormat.BINARY;

	loader.addEventListener( Event.COMPLETE, onCompleteLoad );

	loader.load( new URLRequest( url ) );

}


private function onCompleteLoad( e:Event ):void {

	var bytes:ByteArray = URLLoader( e.target ).data;

	

	// 複製その1

	var loader1:Loader = new Loader();

	loader1.loadBytes( bytes );

	addChild( loader1 );

	

	// 複製その2

	var loader2:Loader = new Loader();

	loader2.loadBytes( bytes  );

	loader2.x = 100;

	addChild( loader2 );

}

バイナリデータを保持しておけばいつでも複製可能になりますが、あくまで読み込んだ直後の状態すなわち外部swfの初期状態からの複製となるので注意が必要です。

もちろんswfだけではなくjpgやpngなどの画像データにも適用ができます。
今のところはBitmapDataとして保持しておいた方が使い勝手がよさそうなので、バイナリで画像データを弄るライブラリが出揃うのを待つといった感じですね。
そっち方面はまだまだ未開拓なので、@flaな人たちに期待。

で、この機能を持ったloadMovieとduplicateMovieClipをAS1MovieClipに盛り込んだら便利そうなので実装してみたいと思います。

投稿者: munegon 日時: 15:20 | パーマリンク | コメント (0) | トラックバック (1)

すごく楽しかった Flash 談義のログをまとめてみたよに引き続き、TwitterでまたひとつAS3についての話が1～2時間ほど盛り上がったのでログをまとめてみました。

話の方向別にグループ分けしつつ、それぞれの時系列は保持してあります。
全体の構成など勝手ながらてっく煮のエントリを参考にさせていただきましたが、ログの読み方などはそちらを参照してもらえればと思います。

■ AS3のメンテ性と再利用性

fladdict: AS3ウザスに追記した http://tinyurl.com/2gqfdk 微妙に釣り風味

psyark: @fladdict メンテは無くても再利用はあるよー！と、釣られてみました

beinteractive: @fladdict 俺みたいな人が差を埋める努力をしなきゃいけないと勝手に思ってます

munegon: @psyark 確実に再利用できるクラスならいいけど、絶妙な仕様変更で案件ごとに違うファイルができあがったりしてｗ

fladdict: @beinteractive そんなこと言われると超期待しちゃう

psyark: @munegon そうならない努力を俺がしたい（有言不実行ｗ）

beinteractive: @fladdict ASerとFLASHerの両方の気持ちがわかる人はなかなかいないと思うので。。

beinteractive: @fladdict FLASHerな人を応援したい！

■ フレームワークの認知度について

munegon: @fladdict フレームワークとかそういった他人が作ったものを平気で組み込んで使う人って FLASHer には少ない気がしてならない。なんとなくだけど。

fladdict: @munegon 現状そうだけど、AS3になるとそれじゃあかなり辛いんじゃないかなぁと。

trickstar_os: @munegon それは今までのAS1,2の再利用性が著しく悪かったからだよ。

fladdict: 一番大変なのは、これからFlashを憶えようとするデザイン系の人はどうなるのか？ということ

fladdict: 変数って？みたいな人にAS3を最初に教えるのは辛い

beinteractive: @munegon フレームワークとかswcとかそういう概念自体よくわからない人が多いのでは。

Saqoosha: @munegon おいらの周りのFlasherをみてるとそもそもそういうものの存在をしらにゃいかったりする。

mainyaa: @fladdict 最初はMX2004とか使って教えるほうがいいかもしれないですねぇ

fladdict: かといって、まずAS2教えたら、もうAS3は絶対やらなそう

cellfusion: @Saqoosha たしかに存在自体を知らない人って意外と多いですね。

beinteractive: @trickstar_os 確かに。再利用という風潮が超薄かった。

whitebase: @fladdict AS3だからこそコピペ＆インポートが楽になるのでは？

Saqoosha: @cellfusion フレームワークはフレームワークで学習コストがかかるしね。

■ 国内では配布物を利用する人が少ない？

nium: Flash自体を拡張できるmxpですら流行ってないので、ASパッケージとか存在を探そうとする人いなそう・・・

mainyaa: @nium ですねぇ。。。

whitebase: @nium mxpがはやんないのは日本語ドキュメントがあんまないからかね

nium: @whitebase 作るのは敷居が高いから分かるんですけど、使うだけの人も増えなかったな～と

psyark: @munegon 再利用性もそうだしそもそも配布物のクオリティがｺﾞﾆｮｺﾞﾆｮ＜今まで

munegon: @nium 国内でオープンな風潮が生まれない限りは難しそうですね（結局そこにいきつくのか）

psyark: navigateToURLを自前getURLでラップするのは簡単にできる。逆は大変。今まではキャンプファイヤーしかできなかった。今後はどちらもできる。

mnr: 8の時のスクリプトアシスト復活が全てを物語ってたような気がしてたんやけどなぁ・・・

■ Adobeの展望

trickstar_os: @fla Adobeはプログラマとデザイナの住み分けをはっきりさせて、デザイナがコーディングしなくてもいい方向に持っていこうとしてると思う

munegon: @trickstar_os デザインとプログラム兼業してる人にとっては、あまり分離しすぎるのもってのがあるかも…ボタンアクション然り。　やっぱ大規模案件向き。

trickstar_os: @munegon Adobeが見てるのは人ではなく企業ってのは間違いない。

beinteractive: デザイナー向けのはずのFlashからシンタックスシュガー的なものが減ったのは痛い。

■ ライブラリ作例集の必要性

fladdict: ようはライブラリ使えば速いしすげーって感じの作例が色々でればいいのかな

psyark: @fladdict そして粒度小さい方の恩恵も誰か分かりやすく見せられると良いですね。俺か！ｗ

nium: @fladdict 見た目から入る人は、ライブラリの説明見せるより「コレを使えばアレが簡単にできるんだ！」のが早いですね。

nium: ライブラリ×実績＆作例のリンク集は、Sparkでも色々話してたとこですね

munegon: @nium Progression も Flex2 勉強会のプレゼンで初めて知った＆興味持った人が多いでしょうしね。

nium: @munegon あれだと、ほとんどの人が3Dプレゼンツールと思われたっぽいですね（汗

fladdict: progressionは次、小～中規模のAS3仕事あったら使ってみたい

nium: @fladdict 横に座って手取り足取りレクチャーしますよっ！

munegon: @nium 確かに（汗　でも認知されないことにはどうしようもないので、いっそのことプレゼンツールとして前面に押し出すのもありですよｗ

nium: @munegon コンテンツの複雑さとProgressionの威力は反比例するので、簡単なものを作ると冗長になる・・・

nium: @munegon プレゼン資料のようなリニアな構造だと遷移制御には微妙ですねｗブラウザ連動が便利なくらいかな

munegon: @nium サイト全体を制御するものを導入すると小回りが利かなくなるんじゃないかという不安から導入をためらう人が出てくるので、そういうのをサンプルでどこまでフォローできるかですね。

fladdict: まぁパーマリンク作れるんだぜいいぇーい大量生産されれば、なにかしらのフレームワークはみんな導入せざるを得なくなってくる気が

■ まとめ

これだけ中身のある話してるのに、@flaつけて発言してる人がほとんどいなかったのが印象深かったですｗ
とにかくフレームワークにせよ単体クラスにせよ、誰かが先頭に立って作成＆テストしながら作例集をガンガン作っていかないことにはオープンな土壌が育たないのではと思います。
公開するメリットがあまりないというような意見もよく耳にしますが、まわりに人が集まるということが何よりもメリットではないでしょうか？

AS3は難しいというイメージをなんとか払拭していきたい、そう強く思った一日でした。

投稿者: munegon 日時: 03:10 | パーマリンク | コメント (0) | トラックバック (0)

公開時のエントリの追記でちょろっと書いた、ランダムジャンプ機能を付けました。
特定のタイムラインを右クリックして Random Jump 項目を選ぶと、そのユーザの友達の中からランダムに選ばれたユーザのタイムラインを表示します。
それから、アカウント入力フォームにメールアドレスも通るようにしておきました。

ダウンロード（AIRになって互換性がなくなったので一旦公開終了）

以下、駄文＆補足。
Twitter検索やTwitterPodなど、便利なツール群はほぼ出揃っている感じでそんなところで勝負をかけるのはあまり意味がありません。

TwitterでのFlash談義でも「Flashらしさを心がけておけばなんとかなると思う。同じ土壌で勝負は避けるってことで。」と発言したのですが、ばりばりのFlasherはサーバサイド技術をはじめとしてコアな技術周りは不得手であったりすることが多いです。
その分、インタラクティブで刺激的な表現には普段から着目していることが多いので、そういったアイデアやノウハウを前面に押し出してやっていくのがFlasherとしての使命なのではと考えています。

ということで、ちょっと言い訳くさいですが利便性には劣っているのは作った本人が一番自覚しています。
アナログ時計ライクにタイムラインを配置する時点で重なって読めないなんてのは自明なので、ひとりひとりのタイムライン配置パターンから何か読み取れたら面白いかな、程度のアプリってことでひとつよろしくお願いします。
ちなみに60秒ごとにオートリロードに設定してありますが、ランダムジャンプで飛んでいた場合はオートランダムジャンプが発動するので、一度ジャンプした後は放置しておくとどんどん渡り歩いていきます。

--今後の予定--
・ソース公開する
・午前と午後の区別くらいは色か何かで識別できるようにしたい
・友達を登録していないユーザに飛んだらそこで終わってしまうのをどうにかする

投稿者: munegon 日時: 00:30 | パーマリンク | コメント (0) | トラックバック (1)

結論から先に述べるとクリエイターはモノ作ってなんぼなので、作りたいモノのカテゴリごとに Tips を集積・共有する仕組みを用意してはどうかなという提案。

きっかけは、にとよんさんがまとめてくれた すごく楽しかった Flash 談義のログをまとめてみたよ のFlash談義です。
ちなみに一番盛り上がってる時にちょうど帰宅中で携帯からの参加だったため、あまり突っ込んだ発言ができずにすごく悔しい思いをしましたｗ

あれからいくらか動きがあったようで、Flashな国内ブログへのリンク集積だとか @fla の RSS な Pipes だとか、早速ノウハウ共有の第一歩といったところですが、ひとつ危惧しているのが集めたきりになってしまうこと。

ノウハウや知識はあくまでモノ作りのためということですね。
実際のモノ作りの現場を顧みると、Webに散らばっているノウハウは見たその場で使い物になったためしがほとんどなく、なんとなく必要に迫られた時には何処に書かれていたか思い出せずに慌ててググって探したりタグから参照するということがよくありました。
また、配布されているクラスライブラリについてもいきなり案件に組み込むものではなく、本当に使えるものなのか検討に検討を重ねた上で使ったり、一部だけが使えるのであればその部分だけ自作してしまうことが多々あります。

ということで最初に戻りますが、たとえば Flash でシューティングゲームを制作する際にはあのエントリの知識が必須であのエントリは見て置いて損はない、YouTubeクライアントを制作する際にはあのエントリとあのエントリが役に立つ、といった各製作過程における Tips を共有していけばビギナーからマニアまで幅広く役に立つと思うのですがどうでしょう？

やれることが多くなった分、必要な時に必要な知識だけを確実に取り出せないとひたすら時間に追われてしまいます。
みんな同じところで詰まったなんていう状況もよくあり、困って検索したらずっと前に同じところで詰まって書いた自分のブログが引っかかったなんていう笑い話も見たことがありましたｗ
タグで管理しようと思えばできることですが、必要な知識をブクマしてるとは限らない上にジャンルが多岐に渡るので、wikiなり使って一元管理したほうがよさそうです。

後で使えるかもしれないというより、後で使いたいという精神で。

投稿者: munegon 日時: 23:00 | パーマリンク | コメント (2) | トラックバック (0)

お互いトラバ合戦になりかねないですが

で、結局 FLASHer 的に AS3.0 って・・・
AS3 は FLASHer には使いにくい？

などで言われているように、ActionScript3.0になって煩わしくなったのがやはり何をするにもコード量が増えてしまったことです。
getURLのようなほんとに些細な処理でも手続きが煩雑になってしまいました。

ですが、逆に考えてみます。

今までは面倒なことを全部 FlashPlayer がやってくれてただけだと。
本来は複数のクラスを組み合わせてやらなければいけなかったことを、単一メソッドで済むように便宜を図ってくれていただけだと。
そのせいで選択の余地がなく、自由度が低かったのだと。
あるべき形に戻っただけなのだと。

ここにきて継承か委譲か、なんていう多言語ではよく目にする話題も出始めました。
ああでもないこうでもないと思考を巡らせ、自作ライブラリを公開してメリット・デメリットについて意見交換をする。
その中で蓄積されたノウハウを元にケースバイケースでクラスを取捨選択するという形に昇華していくのでしょう。

以前からFlash業界ではノウハウを共有しようという動きが幾つもありましたが、特に国内ではそういった動きが活性化することなく自然消滅していました。
共有するまでもなく、各自のとれる手法が限られていたというのもあります。
しかし、ActionScript3.0ではその膨大（というほどでもないがそれなりに大量）なクラスの数に圧倒されるため、知識を共有する流れに乗っていかないと勉強が追いつきません。

手前味噌ではありますが AS1MovieClip のような、似非ではあるけれど従来の手法に近い形でコーディングするためのクラスを作ることは比較的簡単にできます。
これからもどんどん便利なクラスライブラリが多くの人によって生み出されていくと思いますが、それはひとえに AS3 が煩雑になったからだと言えそうです。

少しでも楽ができるように工夫するのが人間ですからｗ
今までぬるま湯に浸かっていた FLASHer に対する挑戦なんだと受け止めて、みんなで工夫しようぜ！といったところですね。

投稿者: munegon 日時: 13:30 | パーマリンク | コメント (0) | トラックバック (1)

Apolloの習作がてら、Twitterのタイムライン一覧をグラフィカルに表示するためのクライアントアプリ TwitterClock を作ってみました。（AIRになって互換性がなくなったので一旦公開終了）

友達のタイムラインをアナログ時計ライクに並べて表示します。

表示エリアのリサイズ・移動には Tweener を使いました。
最新20件という仕様上、友達が多いとほとんど一箇所に固まって表示されてしまいますが、拡大表示したいエリアをマウスで範囲選択することができます。
あまり拡大しすぎるとレイアウトが崩れるのでご注意をば。
また、シフトキー押しながらドラッグすることで画面全体をスクロールすることができます。

その他の機能として、各ユーザのタイムライン上で右クリックメニューからそのユーザのタイムライン一覧またはそのユーザの友達のタイムライン一覧に飛ぶことができます。
ユーザタイムラインを眺めていると、出社時間とか更新頻度とかその人の一日が見えてきて楽しいですが、負荷対策とはいえ20件しか拾えないのが惜しい。

最初に友達リストだけ拾ってきて、全員のユーザタイムライン拾ってくれば賑やかになるんだけどさすがにやばそうだから自粛中。

[関連エントリ]
TwitterClock其の弐
TwitterClockバージョンアップ

--追記--
自分も含めほとんどのユーザは友達のタイムラインがほとんど一箇所に固まってしまうため、いっそ思い切ってユーザ単位のタイムラインに絞った方がいいかも。
そして、そのユーザの友達からランダムに飛んでいくボタンをつける、と。
むしろ一定時間でランダムにユーザを渡り歩いていく機能をつければ、スクリーンセーバーっぽくなるし悪くないですね。

投稿者: munegon 日時: 15:12 | パーマリンク | コメント (0) | トラックバック (1)

前回のエントリに引き続いて、AS1MovieClipクラスについて。

as1な手軽さで書けるようにと onEnterFrame などのイベントハンドラを setter で処理したのはいいものの、イベントハンドラを解除する時の以下の記述

delete mc.onEnterFrame;

を setter で自動検出できないのが痛い！
とTwitterでぼやいていたら、BeInteractiveの人に「setterがある時点で、dynamicなプロパティとしては扱われていない（と思う）ので、deleteは出来ない気がします。」と言われた。
そりゃそーだ。
でも、deleteできるできないに関わらず、Proxyクラスを継承しない限りは自動検出する術がなさそう。

もちろん、以下の方法だとちゃんと解除できる。

mc.onEnterFrame = null;

多重継承ができれば解決するんだけどな。
ENTER_FRAME でチェックするにしてもタイミングのズレで思わぬバグが発生しかねないので、とりあえず delete は禁止の方向で。

もうひとつ、as1では親がボタン化すると子のボタンが無効化するという仕様があるのですが、これをas3で再現するのがめちゃくちゃ難しい！
イベントはデフォルトではバブリング段階で処理されるので、stopPropagationで親に伝播するのを止めることはできても、子に伝播するのを親が止めることはできない。
それならキャプチャ段階で監視すればいいかというと、そうは問屋が卸さない。
キャプチャを有効にしてリスナ登録すると、キャプチャフェーズだけでイベント伝播が終了してしまうためターゲットにまでイベントがこない。

さて、どうしたものか…親がボタン化しているのかどうかわざわざ問い合わせるメソッド用意しなきゃいけないのかなあ。
処理的に美しくないので避けたいところだけど、他に方法がなければそうするしかないかな。

投稿者: munegon 日時: 00:20 | パーマリンク | コメント (0) | トラックバック (0)

fladdict.net blog : processingライクにくめるAS3が欲しいに触発されて、as1記法でMovieClipのメソッドを扱える AS1MovieClip クラスを作ってみました。

ソース

まだ全メソッドを登録していませんが、MovieClipクラスを継承しているので特に不自由なく使えると思います。

以下、使用例。

インポート文はこれ

import com.voidelement.display.AS1MovieClip;

んで、as1ライクな記述がこれ

class Hoge extends AS1MovieClip {

  public function Hoge() {

    var mc1:AS1MovieClip = createEmptyMovieClip("mc1", 1 );

    mc1.a = 0;

    mc1.b = 0;

    mc1.onEnterFrame = function():void {

      this.a += 1;

      this.b += this.a;

    }

    mc1.onMouseUp = function():void {

      this.onEnterFrame = null;

      trace( this.a, this.b );

    }

    

    var mc2:AS1MovieClip = mc1.createEmptyMovieClip("mc2", 1 );

    mc2.moveTo( 100, 100 );

    mc2.lineTo( 200, 200 );

  }

}

深度管理についてはas1を踏襲しているため、すでにインスタンスが配置されている深度に createEmptyMovieClip などで配置しようとすると上書きにより消えてしまいます。
これを実現するにあたって、深度概念が交錯しないように addChildAt メソッドを使用禁止にしました。
あくまでas1の深度ベースでサンプルを組み上げるためのクラスなので、その他のas3クラスとの親和性は多少犠牲にしています。
また、深度管理の都合上 removeMovieClip や swapDepths などの自身を対象とするメソッドについては親が AS1MovieClip かその派生クラスでないと機能しないように制限してあります。

ちなみに _xscale や _yscale などのアンダースコアなプロパティも定義してみました。
as1では0～100ベースだったのに、as3で0～1になったのでよく間違えるorz

それと深度管理するにあたって、Dictionaryクラスがやたらと役に立ちました。
インスタンスと深度値を相互参照することで、インスタンスに直接深度プロパティを持たせずに済んでいます。
他にも便利な使い方があると思うのでそのうちまとめてみる予定。

果たして需要があるのか否や。
突貫で作ったのでコメントぶっ飛ばし状態…後から追加しますが、そもそもこんなクラスをわざわざ使うような人は、as1のメソッドなんてほとんど暗記してるんじゃないかと勝手に予想。
なんだか無駄に張り切りすぎた感があるので、深度関係のところだけ抽出して DepthManager クラスとして作り直した方がいい気もしてきたけど、まだまだ作りかけだしツッコミ大歓迎。

投稿者: munegon 日時: 04:25 | パーマリンク | コメント (0) | トラックバック (0)

さっき悩まされた見つけたバグについて、情報共有のために紹介。
MovieClip.setMaskによってマスクされたシンボルをBitmapData.drawすると、マスクの位置がなぜかグローバル座標基準になった状態でマスクされたビットマップができあがり。

以下、図解（青:マスク、赤:シンボル、100x100のビットマップにシンボルをdraw）





左から順に、配置・理想・現実です。
シンボルは全て左上を原点合わせで、配置では円形マスクの相対座標を(0,0)、絶対座標を(20,20)としています。
理想ではくりぬかれた100x100のビットマップになるはずですが、実際には円形マスクが絶対座標にあるかのごとく振る舞います。

こんなの予想外。
最初as3のバグかと思っていたら、as1でもしっかり起こるし。
drawする場合はシンボル内部でマスクした方がよさそう。

投稿者: munegon 日時: 18:20 | パーマリンク | コメント (0) | トラックバック (0)