Director Lingo

あちらでは、Adobe Director11.5の販売が噂されていますね。 こちらはぼちぼちと Xtra開発を進めてます。本日は、awaOSUtil Xtraを更新。 相変わらず、日本ユーザからの反応は乏しい限りですが。。とは言っても自分が必要な限り、開発は続けていくのです。 未公開のXtraもたまってきているので、頃合いを見てまた公開しようと思います。

save Shockwave Image

Shockwaveから、画像をjpegエンコードし、ダウンロードするデモ。Shockwave単体では、ダウンロードダイアログを開くことが出来ません。特定の保護されたディレクトリにしかダウンロードできない仕様です。が、サーバサイドスクリプトを併用することで、ダウンロードダイアログを開き、任意の場所に保存することが可能になります。マルチパートでデータをサーバに送信しアップロード、アップロード先のファイルをストリームで返すことでダウンロードダイアログを開く。といった手順になります。

Post From Shockwave

Shockwaveから、画像をjpegエンコードし、CGIのフォームからアップロードするデモ。valentinの JpegEncodeとHTTPとBase64コードを組み合わせ、perlのサーバサイドで実現。xtra無しだからかなり使えるテクニックです。このサンプルは掲示板風に処理してるけど、応用すればShockaveからダウンロードダイアログを開いてローカルに保存させることもできるでしょう。

シカゴで開催された"Adobe MAX 2007"の"Director 11 Sneak Preview"で発表された「Director 11」について。主なリソースはこちら。Director11は年内に発売予定です。日本ではどうか知りません。

「Director 11」の目玉

• Unicode
• Flash Player 9 / Actionscript 3
• Mac Intel/ Vista
• DirectX9

その他の変更点

• CS3ライクなインタフェース
• 新しいスクリプトブラウザ（階層構造を表示）
• ９つの新しいビットマップフィルタ
• multiuser xtraのバグ修正

Director 12、13について

Director 11は、劇的なバージョンアップはなかった。地味ながらも必須の機能が追加されたのみ。Adobeの開発体制に変わってからの初リリース。次回も期待しよう。開発陣によると、Director 12は開発に着手、Director13についてはこれから協議するとのこと。物理エンジン Havokの新バージョンに期待が高まる。

SOLA 5.1.0.2

更新が滞るときは、業務が詰まっているか、夢中になりすぎているかのどちらかなんですが。今回は後者で、ようやく一段落ついて、SOLA 5.1を公開。小バージョンアップですが、気持ち的にはかなり上がった気分。今回はインタフェースの大幅な改良と、ようやく 3Dデータが全て編集可能になった。今まではインタフェースの作成が足枷になってなかなか進まなかった作業も、じゃんじゃん進むようになって快調。で、画像が新インタフェースのパレット。次世代ライクな仕様にした。

これ、Flashで組んだ。今まではOS標準GUIで作ってたけど、WEBで利用しづらかったし、意外と融通聞かないし、WinとMacで違うし、開発に時間掛かるしと問題が多かった。 だったら、Flash使おうかということだが、一昔前だったらやっぱり苦労するわけで。でも今は使えるツール、選択肢が増えてきたね。巷で言うWEB2.0時代の恩恵というか、Flashをフロントエンドに持ってきたWEBアプリケーションが増えたおかげ。　で、アイザワもそういう開発をしてみようと。やっぱりスゴク便利ね、Flashって。開発環境が変わっても、何でもフロントエンドに Flashもってこいみたいな勢いで、そう思う。　ま、レスポンスは下がることはあっても上がることもないが。。。。

Windows版 Shockwave Playerのバージョンが上がったよう。Shockwave 10.2.0.021となってる。ただ今のところ、何のアナウンスもなし（のようだ）。で、関係者の話によると近日中に Windows Vista対応を、とのことだったので、もしかすると Vistaのレンダラー問題が解決したのかも。だとしたら、意外と有言実行。この分だと、Intel Mac対応や新バージョンのDirectorにも期待できるかも知れない。

年齢確認なども無くなって、スマートになったよう。一時は Yahoo!ツールバーの件だったりでイヤな時期もあったけど。

MUI Xtraを使用する際の注意点。Macで使用する場合、コンポーネントはOSX仕様で見栄えは良いのですが、表示に関する問題が多いのが残念です。Windowsの場合は、目立つ問題はありませんが、#editTextコンポーネントを #itemchangedイベント内で ItemUpdateした際、無限ループする可能性があります。（実際には 15回目程度で Xtraが停止させるようですが。）

Mac OSX

• window.modeが #pixel以外の場合、ItemUpdateを行うと致命的な表示バグ。
• #editTextコンポーネントの表示サイズが、3ピクセルオフセットされる。
• モーダルウインドウの場合、closeBoxは表示されない。
• closeBoxボタンを押しても、機能しない。
• #editTextコンポーネントを ItemUpdateした際、フォーカスイベントが発生。
• TABで #editTextコンポーネント間を移動可能。
• #editText以外のコンポーネントではフォーカスイベントが発生しない。
• #editTextでは日本語入力ができない。

Windows

• 非モーダルウインドウの場合、ウインドウを閉じても #windowclosedが発生しない。
• 非モーダルウインドウの場合、ウインドウがアクティブになった際に #itementeringfocusが発生。
• #editTextコンポーネントを ItemUpdateした際、#itemchangedイベントが発生。

MUIダイアログを作成する際に便利なツールに、muiguiやMUIComposerなどがあります。しかし、アイザワが一番お奨めするのは Xcodeに付属する Interface Builder、Visual C++などの Windowsフォームなどです。各OSのデザインガイドラインに沿ったダイアログがキレイ、簡単に作成できます。（直接 Lingoコードを書き出すわけではないですが）

Director MX 2004以降、ウインドウクラスのオブジェクトからアクセス(_player.window[1].movie...)できるようになりました。これにより、他のムービー自体のメソッドやプロパティにも、現在のムービーからアクセスできます。従来、ムービー内部のアクセスは、そのムービー自身からしか行えませんでした。そのため、tellコマンドというやや特殊な仕様がありました。しかし、ウインドウオブジェクトやムービーオブジェクトにより、より簡単にムービーを扱えるようになりました。ですが、簡単なことには落とし穴があります。

FPS with Light

ライトがフレームレートにどれほど影響するかというFPSテスト。想像以上にライトが足枷になるのが体感できるかも。『シーンにライトがあると、リアルタイムに頂点ひとつひとつにライトの色が加算される』。この単純な理屈を理解すれば、負荷が高くなるための単純な結論が出る。（じゃないのかな。。）

• ライトの数が多ければ多いほど。
• 頂点が多ければ多いほど。
• #ambient < #directional < #point < #spot

極論は、ライトが無くても 3Dシーンは成立する。現実世界では光源があって、モノに反射して色が見えるわけだけど、（だから光源がないと真っ暗）、CGの世界では違う。マテリアル自体に明るさを持たせたり、頂点自体に色を持たせたり、テクスチャに焼き付けたり。光源が無くても、色を出す（表示させる）方法は幾つかある。ということで、リアルタイム系CGでは負荷の掛かるライトはそれほど使わない。あらかじめ照明効果を何らかの方法で持たせておいて、リアルタイムではライトの計算をなるべくさせないのが一般的。とはいえ、陰付けのための手っ取り早い方法としてライトはとてもラク。現実世界の光源のあるところにライトを配置する感覚ではなく、どのように陰を付けるのかを意識すると、必要最小限のライトで済みます。

今回の FPSテストでも、ログをとってあります。

Flashコンポーネントのメタタグで InspectableListが働かない。調べたけど日本語の情報を見つけられなかったのでメモ。

拡張したコンポーネントで継承したパラメータをプロパティインスペクタに表示するには [InspectableList()]タグを使うのだけど、どうも表示されない。自身のプロパティは InspectableListにあるなしに関わらず表示される。どうやら、InspectableListが機能していないよう。で、検索すると「“import” is required for component meta-data」に情報があり。古い内容みたいなので、もしかすると最新版の Flashだと問題ないのかも。。

スーパークラスを importで読み込んでおく必要があるよう。さらに付け加えると、拡張する際に完全修飾名（mx.controls...）を使うと駄目なのね。単純にクラス名にする必要があるっぽい。