やばい。書くことが無い罠。
ゲームとかしてません。 本もあんま読んでません。 アニメは作業しながら横目でみてます（ぉ
ハルヒすげぇ。なにがすごいって、これだけ「つまらない」ものを
１話まるまる、しかも初回にもってくるのがすごい ^^;
わりと爆笑しながらみてたわけですがー。
アニメの主題歌の CD ってなんでこんなに発売が遅いんだろう。 欲しい時ってのはわりと１話みた直後なんだが……。 放映当日からネットで売っていただきたいデス。
具体的にはハルヒのED なのですが
アニメ版ハルヒ１話、原作（２巻・涼宮ハルヒの溜息）は「映画をつくる話」で、映画の内容の断片（撮影の様子） は語られつつも、完成形については、ラストでキョン君が語るだけなわけで。 それを視聴者に「まるごと追体験させる」という、「『アニメ化』でしかなしえない」 ことをなにげにやってるのはすごいよなぁと。誰からでてきたアイディアなんだろう？
周囲の前評判としては、いくら京アニとはいえ、あの「キョン君の語り」がコアに なって成立してる作品の素晴らしいアニメ化は無理でね？ ってのが主流だったのですが、 良い方向に裏切られたのでした。今一番先が楽しみかもしれない ^^;
追記。ああ、６巻にそのまま収録されてたや^^; ＞「朝比奈ミクルの冒険 Episode00」
完全に忘れてた（ぉ
なんかスレでほしがってる人がいたので、 だいぶ前につくって放置してたやつだけどなげとく。 吉里吉里透視変形コピー拡張
agg での記述なので、がちな性能あるわけじゃないけど勘弁な。 あとテストはほとんどしてないので動かなくても知らない（ぇー
ソースはツリーにコミットしてあるので適当に。
ライセンスは本体準拠でよろ。
_ 高橋直樹氏の日記の記述を見て知った TVML がいろいろとすばらしい件について。 そっかー、NHK でよく見る、なんかキャラつかった番組系ってのはこれの成果なのかー。すごいや。
_ オブジェクト指向な「ADVゲームスタイル」の演出スクリプトで、 十分実用ラインにのっかったものが、もう何年も前から世にでていたとは……。 無知を恥じます（苦笑）
_ ML とかついてるから最初 XML スタイルのマークアップを一瞬想像したんだけど、 シンプルな行指向MLなあたり、つくった人はよくわかってます。 XML スタイルは人が手打ちするもんじゃない。
_ スクリプティングの考え方は、うちのシステムと同じですね。 キャラクタがあって、スタジオセット（うちのシステムでは「舞台」） があって、 それぞれに名前をふってオブジェクトをわりあてて、コマンドやパラメータを随時変更していく体系。 テキストの表示は「キャラクタのtalk コマンド」の結果としてあらわれてくる辺りまで同じ。 やっぱそこにおちつくよね。
_ この言語の惜しいところ。この文法構造と概念体系なら「イベント」に対して 名前をわりあててしまえば一気に記述量が減ります。 character:casting(name=Hoge) とかして登録された Hoge という name に対して、 Hoge:コマンド(...) の記述を行なうと、character:コマンド(name=Hoge ...) と みなして動作するようにすれば OK。キャラクタに限らずカメラとか他のもろもろに応用可能
_ 記法が冗長なのと、あとは、3D キャラが前提の体系ではあるので、 これをこのまま参考にすることはないですが、体系の概念は一部 まねさせてもらおうっと。
_ 例えばカメラに名前をつけて複数もつ発想はもってませんでした （環境機能の一部にしてた）。そっか、１カメ、２カメと名前を つけてスイッチできると演出記述が楽なんだな。
_ ライティングは前から足したいなーとは思ってたところ。 あー、誰か、2D なライティングのレイヤデータを作成してくれる いいライブラリの存在しりませんか（考えたくないらしい） IE の DHTML がもってる light ぐらいのでいいんだよなー。
_ もう一つは。ビデオスイッチャー。 これにあわせてタイトルとかは別概念としてもたせるのがよさそうなかんじ。 あとは複数の「環境」もきりかえの対象にしてしまえば……
_ ぐあ、ここで一つ気づいてしまった。 そうすると、現状の「表画面・裏画面」な概念がいろいろと良くないことになる。
_ そもそも旧コードだと「キャラクタ」が「環境」と同格のインスタンス だったので「複数環境」に原理的に対応できてませんでした。 新しいコードでは「キャラクタ」は「環境」に内包されるインスタンスとして 考え直したので、それごとに状態を維持しているので、複数環境にすること 自体は特に問題ありません。
_ ただ、今、環境用の表示系は、その内部でのトランジション用の 「表画面」と「裏画面」という構造になっていて、キャラクターはそれの どちらかに自力でレイヤを維持しています。画面切り替えのときは レイヤをクローンして、裏側に残し、キャラクタとは切り放してその表示状態のまま を維持させ、新たに設定されたキャラクタのと表のレイヤーとの間でトランジション をおこなわせてます。
_ まず、複数環境があるなら、そもそも状態が分離しているため、 表示状態を切り放して維持するための「表・裏」の概念は必要ないことになります。 それぞれの環境の間で普通に切り替えてしまえば良い。 １つしか環境が無い状態でトランジションする場合は、やや冗長な 処理ですが、環境をクローンして、クローン後の環境の状態を変更し、 その前後でトランジションして、その後旧環境をすててしまえばいい。 スクリプト体系としては「カレントの操作対象としての環境」と「画面に表示している環境」の ２種類の操作対象を切り替えつつ作業する。ことになります。
例: 画面のフルトランジション ---------------------------------------------------------------------------------------- // 標準の環境は最初から存在する。名前は "default" .... スクリプト [envclone] // 表示環境とカレント環境が同一の場合のみ機能する。 // 古い環境は無名化して表示環境として残る。カレント環境はクローンされた環境になる。 .... 新しい画面を初期化するスクリプト [videoswitch name=default trans=crossfade] // （新しい）環境を表示する。無名環境は表示からはずれるときに抹殺される ---------------------------------------------------------------------------------------- 例２: 過去回送処理 ---------------------------------------------------------------------------------------- // 標準の環境は最初から存在する。名前は "default" あかり: そういえばあんんなことが…… [envswitch name=回想] // カレント環境を「回想」に切り替える。無いときは自動生成 ... 回想シーン用初期化処理 [videoswitch name=回想 trans=...] // 表示も「回想」に切り替え ... 回想シーンのスクリプト [envswitch name=default withvideo] // カレント環境を「default」に切り替える。同時に画面も切り替え あかり：あのあともおもしろかったよね [envswitch name=回想 withvideo] // カレント環境を 「回想」に切り替える。同時に画面も切り替え ..... [envdelete 回想] // 回想の破棄。画面に表示する環境がなくなったら自動的に default に戻す ----------------------------------------------------------------------------------------
_ では、レイヤ構造は環境に１つでいいか、となると、そうでもなくて、 むしろ、任意個数のレイヤセットを「カメラ」として維持させます。
_ ちなみに、3D だとこんなややこしいことはしなくていいです……。 カメラは位置情報だけもって、毎回全部再レンダリングしてしまえばOK。 いわゆる 2D系の ADV だと、ファイル読み出しが多い関係で、なるべく 画面状態はキャッシュして保持しないといけない罠。
_ 実は、カメラ移動による視点移動だけなら、単純にカメラ１つでことたります。 「カメラ位置」の概念をもたせて、あるカメラに対してその位置を 瞬間適用してしまえば、はたから見る分にはカメラの変更とかわりません。
_
ではなぜあえてわけるのか、というと、物理的に２つ環境の画面を再構成する
カメラの概念があると、同一環境に対する別カメラからの「split screen」ができるんですな。
画面を縦でも横でもいいから分割して、同じシーンの画像を２個所から表示。
吉里吉里だと、Layer.piledCopy を駆使するのが勝利の鍵の予感（まだためしてない）
メールはこちらへ...[わたなべごう (go @(at) denpa .(dot) org)]
この日記は、GNSを使用して作成されています。