オデのMac Bookのリンゴマークを見て
「このリンゴ誰が食べたの?」
「パパが食べたの?」
「ママが食べたの?」
「アッキーが食べたの?」
と可愛い質問をするマイソン。
親ばか万歳。
月: 2008年11月
今コンビニに行ったらヤンジャン出てたんだけど、祝日かなんかあんのかしら?
桜の森の満開の下::夜叉ヶ池
坂口安吾ではありません・・。
桜の森の満開の下: 人間椅子
これは日本HMの名盤の一つだと思う。特に夜叉ヶ池の3:30からの展開は涙モノ。映像も松井良彦っぽくてステキング。
ちとはまったのでメモ。
swfの最小表示領域を確保したい場合にSWFForceSizeを使用するのですが、それがIEで上手く動作しなくてフガフガしてた。現象としては
・設定ウインドウサイズになってもスクロールバーが表示されない
・最初に小さいウインドウで表示させた後に、ウインドウを拡大してもFlashサイズが変わらない。
・縦サイズのみスクロールバーが表示され、横方向は表示されない。
等、上手く動作するときもあれば、上記のようなバラバラの挙動を示していた。
SWFObject2.0でSWFForceSizeを使う | FlashやWebにまつわるいろいろなことが原因かな?とも思ったのだけど、ちと違う。そもそもSWFForceSize.onResizeDivが発動していない。
Progression.jsの中を確認してみると”/contents/objects/version.swf”を用いてバージョンチェックを行って、progression.onLoadを実行。その中でswfObject,SWFForceSizeを定義するってのがデフォルトの流れ。
SWFForceSize内部では定義時に
this.addWindowEvent( 'onload', this, this.onLoadDiv );
をセットして初期化を行うようにしている。
んがprogression.onLoadの発動タイミングによって、document.onload後にSWFForceSizeが定義される可能性があり、そこが多分不具合の原因なのではないだろうか?と思う。(違ったらごめん)
単純に考えて”prog.onLoad”の一番最後にdocument.onLoad()を強制的にCALLしてやれば上手く動くかな?と思ったのだけど、横方向のスクロール制御が不能になったりしたので断念。
外部JSの読み込みのタイミング等に依存しているのか上手く動いたり動かなかったりという不安定な挙動をしめすので一度Progression.jsをはずした形で実装を進めてみることにする。
落ち着いたらも少し調べてみる。
apeirophobia: Loaderの読み込み強制終了 Loader.close編、apeirophobia: Loaderの読み込み強制終了 Loader.unload編の続き。Progression3でやるとどうなるか?の検証。
主要なコードは以下の通り。本当はもっとスマートな書き方がCastImageLoaderにはありますが、敢えてここはcontentsLoaderInfoと比較するためにこの記述の仕方で・・。
CODE:1
で、一点注意点としてはCastEventは”UNLOAD”イベントを持たないので、その部分だけはEvent.UNLOADを使用します。あ、あとcontentLoaderInfoではなく直接CastImageLoaderを監視します。
プレビュー/ダウンロードシミュレートでの実行結果は
1:読み込み中にclose実行>読み込みは中断されず、COMPLETEイベント発生。ただし_loaderは表示されない。
2:読み込み前にclose実行>特に問題なし
3:読み込み後にclose実行>_loader消去
4:読み込み中にclose実行後、再度読み込み>2回目の読み込みCOMPLETEイベントが発生するが、_loaderが表示されない。
5:読み込み完了後にclose実行後、再度読み込み>問題なく表示
6:読み込み後、再度読み込み中にclose実行>unloadが無視され、COMPLETE発生後表示されてしまう。
という感じに。読み込みは中断されずCOMPLETEイベントは発生してしまいますが、表示されることはありません。
ただし4、5、6あたりが挙動が不審なところで、読み込み中にunloadを実行する、もしくは一度unlaod無しでCOMPLETEしてしまうとcontents(DisplayObject)の制御が利かなくなるようです。(ExLoader、ExImageLoader、CastImageLoaderの中を見てみましたが、ちょっと原因良く分からなかった)
HTTP経由での実行結果は
1:読み込み中にclose実行>読み込み中断。
2:読み込み前にclose実行>特に問題なし
3:読み込み後にclose実行>_loader消去
4:読み込み中にclose実行後、再度読み込み>問題なし
5:読み込み完了後にclose実行後、再度読み込み>問題なく表示
6:読み込み後、再度読み込み中にclose実行>問題なし
という結果になりました。プレビュー環境でおかしかった4、5、6辺りはHTTP経由では問題ないようです。
で、話はちょっと横にそれますが、contentsLoaderInfoのイベントとのタイミングですが、普通にLoadingした場合
CastImageLoader::ロード開始
contentLoaderInfo::ロード開始
CastImageLoader::ロード完了
contentLoaderInfo::ロード完了
というようにCastImageLoaderのイベントのほうが先に実行されています。ステキです。
では続いて、CastImageLoaderに最適と思われる記述の仕方をしてみます。
前回(apeirophobia: Loaderの読み込み強制終了 Loader.close編)の続き。
とりあえず主要なコードは以下のような感じ。
CODE:1
これをプレビュー/ダウンロードシミュレートで実行すると
1:読み込み中にunload実行>読み込み止らず、読み込み完了して表示
2:読み込み終了後にunload実行>表示されていた_loaderが消去
3:読み込み前にunload実行>何も起きない。
といった感じ。closeの時のように例外throwは無い。ということでhttp経由で検証。
1:読み込み中にunload実行>読み込み止らず、読み込み完了して表示
2:読み込み終了後にunload実行>表示されていた_loaderが消去
3:読み込み前にunload実行>何もおきない
という感じで、どうしようもない感じに終わりましたw
つまりunloadは読み込みが完了したcontentLoaderInfoに対してのみ有効なようです。
ということでcloseと組み合わせて使うのが正解のようですが、なんにしてもプレビュー環境で動作が確認できないのでその辺が面倒です。はぃ。
じゃ次はprogression3のCastImageLoader等で同様の処理を行う場合にどするか?(多分ほとんど一緒だとは思いますが)検証することにします。
外部イメージのローディング途中で他の処理やシーンに遷移したい場合等、ローディングを任意に中止する部分で現在はまり中ということで検証を時系列的にメモ。
“Loader”クラスには”close”と”unload”という似たようなメソッドが2つほどある。
closeは
Loader インスタンスに対して現在進行中の load() メソッドの処理をキャンセルします。
一方unloadは
load() メソッドを使用してロードされた、この Loader オブジェクトの子を削除します。関連したLoaderInfo オブジェクトの property は null にリセットされます。他のオブジェクトが参照している可能性があるため、子は必ずしも破棄されるとは限りません。ただし、Loader オブジェクトの子ではなくなります。
と定義されている。
とりあえず”close”から検証してみる。
CODE:1
既にこの時点でCLOSEイベントを取得する口が見つからない(汗 EVENT.CLOSEは”Socket”,”XMLSocket”だけにしか用意されていないイベント。つまり発動したとしても結果を拾えないという謎な感じになっている。
ケートラ
HONDAさんの携帯コンテンツ。
自分の携帯に住んでいる携帯の精(モバター)が、携帯を飛び出し、他のユーザの携帯を渡り歩き日本中を旅していきます。(同時に他ユーザのモバターが自分の携帯に乗りこんできます。)
位置情報などから実際に近くにいるユーザの携帯を特定し乗り込み、下車した場所に居る他のユーザの携帯に乗り込んで・・・という感じで携帯をヒッチハイクしていくゲームです。
モバターは旅先でお土産を買って、日記を送ってきます。
通勤で家と職場を移動する間などに遊んでもらえれば・・・。
企画、仕様策定をお手伝いさせていただきました。
携帯の位置情報をベースにしてリアル空間とバーチャルを融合させたゲームとしては初めてなんじゃないかしら(知らんけど)?スケジュールの都合で制作には関与できなかったのですが、本日無事公開されたようです。
みなさま本当にお疲れ様でした。そしてゴメンナサイ。
クレジットなどはまた追って・・・。