おとといはあにそん三昧とマシン構築で日がくれました（挨拶）

とはいっても新しいマシンにしたわけではなくて、今メインでつかってる ノートの HDD だけの更新。別マシンで OS だけ再構築して新マシンと HDD 入れ替えてから各種必要なアプリケーションを全部再インストール、 あとはデータだけかきもどして完了。やっぱ丸一日作業かかりますな。

そしてネット系の再構築でえあえじや無線でつなげなくてはまる^^; パスワードとか書いた紙はどこにはさんだっけ……

えー、今回の更新から、いまさらながら「制限つきユーザ」環境を メインにしてみました。たいていのソフトは特に問題はない模様。 Visual Studio 2005 も特にいじることなく問題なし。 必要なときだけ runas で、それでどうしようもないところは ユーザの切り替えで対応。

「制限つきユーザ」で使うと、Application Data にデータを 書き込まないアプリがちょっと困りますな。もちろんえろげも含む。 Vista 対応以前に、「XP で制限つきユーザ対応」をしていたならば、 特に Vista ですることは無い（実行ファイルにマニフェストつけるぐらい） ということですね。本来。

Sleipnir は管理者ユーザでのインストール時に選べるように なってました。Limechat2 がダメで、実行ファイルフォルダに ユーザのプロファイルを保存しようとするので、Program Files 以下に インストールできません。別の Users 権限で問題ないところに いれて暫定対応。要望だすべきかなぁ。

_ すたじお緑茶の「片恋いの月」の体験版。

おー、ワイドだ。今後増えてくるのかな。 とりあえず最初のジングルの声に反応^^; キャラクタがうごきまくってておもしろいですね。 画面内にいない人はフェイス枠で表現しててこれも動く動く。 背景も大きめにつくってあってスクロールに耐えるようになってます。

立ち絵が常に画面外にスライドしていくのはちょっと違和感あり。 中途でフェードして消したほうがそれっぽい気がする思う。 あと気になったのは、ムチャなポーズのままのジャンプと 「歩いてる」表現かな ^^; 縦にゆらせばもう少しそれっぽいかも。

テキストが各キャラの位置に表示されるのは、前はうざい かなとおもってたんだけど、画面が（物理的に）広くなってる昨今、 映画の字幕ぐらい短いならともかく、一定以上の長さの文章と キャラの両方を視野の中におさめるのがむずかしくというのも あって、むしろわかりやすいのかな？というのが最近の結論。 他の方法論としてはメッセージ窓に表情だけ反映された顔窓を配置、 というのがあるわけですが、ポーズにも動きがある場合は結局 立ち絵が見えなくてだめなんですね。このスタイルの場合、 できれば縦書きのが見やすいような気はします。FFD のように。

旧作の体験版もためしてみたのですが、本作のほうが動きが 洗練されてるのと、あとエンジンの性能もあがってますね。 ちょっとつっかかってた感があったのがさくさくスムーズになってます。 回転するとジャギるのがちょっと気になったくらいかな。

内容的にもキャラがたっててなかなか期待させる雰囲気。 ここのブランドの作品は一度も買ったことはなかったの ですが絶賛興味アップ中。

_ めろめろキュートの「吸血奇譚 ドラクリウス」の体験版。 制限つきユーザではエラーが出て起動しない罠。しくしく。 ぐほ、コンフィグが無い……。つらいぜ、ということで全然話を見ることなく中断。

エンジンは「椎名里緒」……って、どっかでみかけたよーな記憶が……ってことで ぐぐってみる。ふむ、フォレスト系由来のエンジンのようで、現在は Will 系の ブランドのいくつかでつかわれてるようですね。propeller の「あやかしびと」、 ruf の「つくとり」などで確認。それらではちゃんとコンフィグありますから、 システムの問題でなくて使う側の問題だな（汗）

めろめろキュートや関連ブランドは以前は吉里吉里を使ってた模様。 どういう経緯でののりかえなのかしら^^;

_ とりあえずえろげ向けゲームエンジンリスト更新。 あー、それぞれのシステムの典型例へのリンクとかつくったほうがいいんだろうなぁ

MS の Flash 対抗技術の Silvelight。 うは、まだ 1.0 がリリースされてないのに 1.1 の発表で かすんでしまうってどうなんだろう^^;; MS らしいといえばらしいのか。

1.1 で CLR-mini がはいって C# やら Ruby やら使えるようになるそうです。 限定的ながら .NET によるプログラミングが OS X でも行なえるという インパクトはけっこうありそう。問題はツールがどの程度つかえるかだなぁ。 ここは Orcas の環境をくんでみるべきか？

Orcas Beta1でけぇ。 700M ぐらいの分割 で 8ファイルもある。DVD イメージなんかな。

それはさておき、 Getting Started with SilverLight 1.1がやばすぎる件。 ぐほっ、ソースコードベースの Visual Studio と、 タイムラインベースの Expression Blend が完全連携してやがる……。 こいつぁ強力だぜ。まだ Flex と Flash の連携ツールがだせてない Adobeちん、ぴんち。

Blend はこっちのBlend2 (preview) でないとダメかな？

あと Dynamic Languages with Silverlightの動的っぷりと節操のなさにしびれる。 しれっと OS X 上だし。Ruby もうさくさく動いてるのね。

まとめ: SliverLight 1.0 だと、それFlashでいいんじゃ？ と、わりとお話になってなかったのが SliverLight 1.1 （てかこれは事実上の Ver2 だろう）ではMS様が本気をみせて やるぜ状態ですごいかも。

でもボタンとかのパーツは相変わらず存在しないのな ＾＾； やっぱ矩形とテキストでつくれってことだよね……。 基本的なのは一式シンプルなのでいいのでそろえておいてほしいところです。はい。

_ 昨日体験版をプレイした（正確にはしそこねた）、 「吸血奇譚 ドラクリウス」のブランド、めろめろキュートの 前身ブランドの XANADU の「ひめしょ！」について Darios 氏の日記でふれられてるのを発見（2007/4/27の記述）。「正体が良く分からないエンジン」 とのことですが、その作品のシステムは（体験版から判断すると） 「吉里吉里２」ですね。 実行ファイルのプロパティや CTRL-F12 押下で確認可能。あと拡張子 xp3でばればれ。 完全CPU描画で、ダブルバッファ描画を有効にすると全画面の転送に DirectX を使う場合がありますがデフォルトではこの機能は off です。

特殊な演出機構は素のフレームワークでは、レイヤのスプラインベースの 移動とかぐらいです。レイヤシステムの構造はシンプルで制御は直感的 なので自前で組み合わせて拡張して作るのは容易で、レイヤを多数つかった 雨とかのサンプルはついてます。

エンジンの描画系は比較的純粋なレイヤ合成システムで、合成モード処理と レイヤ間のトランジション処理以外のリアルタイムなエフェクト処理は提供されていません。 ただ、レイヤの内容の操作は、アフィンコピーや色補正処理などのメソッドが 標準で提供されている他、DLLで記述するプラグインからの直接操作も 可能なので、隠れレイヤから表示レイヤに毎回再描画する形で処理を書けば、 ラスター処理は回転・拡縮などのリアルタイムエフェクトは実現できます。 コピー回数が処理時と合成時で倍になるのでパフォーマンス的には あんま良くないはずですが、素の合成性能が良いのでそれなりに動きます^^; 一応アフィンコピーを使った回転・拡縮はサンプルがフレームワークに付属。

5/5の話。とある方面で業界のプログラマばかりがあつまる宴会が あるということで、某氏にくっついて参加。いやー、えらい濃かった^^;

業界的にも重要なエンジンをつくってる方とかと面識が得られたのは僥倖。 あと、この業界からは足を洗ったと聞いていた旧知に再会^^ ; なんか 結局足をあらいきれず、裏仕事としてつづけてるらしい（苦笑） 会話の断片からブランドを特定。なるほど、確かに氏のシステムだ。 設定パネルとかから気付くべきだったぜ

そして、どこの会社もやっぱり手作業でスクリプトしてる事実が。 AE で作成された指示ムービーに従ってそれを手動で再現！とか、 えらい大変だったりするらしい。出力がそのまま使えるツール つくったほうがいいんだけどねぇ、という点で合意は得られるも、 そんな余裕はなかなかないという現実。うーむ^^;

とりあえず実装してみたもの。 AE 使いや Flash 使いがいるなら、αムービーは、ぱっと見インパクト がある画面効果を比較的低コストで作成できるのでとても便利だと思います。

吉里吉里の VideoOverlay クラス はレイヤに対するムービー再生機能ももってるわけですが、それとは別に LayerExMovieプラグインを実装してみました。 レイヤ個別で処理できるので、こっちのが概念的にはわかりやすいでしょう。 ただ、吉里吉里標準の krmovie.dll は、かなりまじめに腐ったコーデック対策をしてるのですが、 これは Multimedia Streaming API まかせなのでそのへんのリスクには注意。しかしこの API の利用例、ぐぐってもさっぱりでてこないんだよな……。 あ、だれか IStream を IMoniker にするいい方法しってたら教えてください。自前実装しかないのかしら（汗）

さてさて、どうやってαを実現してるかはデータをみれば一目瞭然（あははー）。 うーん、おいらに軽量な独自CODECを開発するような腕があればねぇ…… αつきのムービーの CODEC って案外物がありません。無圧縮 AVI、Indeo の一部、あと、QuickTime と Adobe が Flash で 使ってる VP6 ぐらいでしょうか。編集中データとしては、とりまわしが楽な連番静止画が一番良く使われてる模様。 あと、本来的にはムービー合成なんて「重い」処理は CPUでなく GPUにやらせるべき ことなので、Irrlicht driver 側にムービー機能が入ればいらなくなるものですが、 とりあえず現行アーキテクチャ内でも出来るってことで。

ついでに fpslimit という負荷調整用プラグインも作成。指定した fps を越えないように制限がかかります。 吉里吉里は標準ではトランジションや Continuous ハンドラが駆動するときに全力で動くので CPU 利用率100% に なってしまうのですが、それが制限されます。この挙動自体は起動時オプションで制限はできるのですが、 指定が荒いので、微調整できるようなものを組んでみました。やってることは単純で、規定時間より早く処理が まわってきたら時間まで Sleep してるだけです。↑のレイヤムービーは Continuous ハンドラで更新かけてるので、 これに追従して余分な描画はしなくなります。関連して KAGEX のアクション用モジュールからも Timer を排除して Continuous ハンドラベースに更新。