すごすぎてイミフ

Rewriteの発売も近いということで、久しぶりにKeyのスタッフブログを確認しているとある記事が気になりました。

プログラムの話です。この記事
プログラマのとなぴょんさんが、Rewriteのベンチマークソフトである「ちはやローリング」を少し性能の低いパソコンでも動くように改善してくださいました。
都乃川さんが、となぴょんさんに「どうやったの？」と聞いたときの回答が載っています。
俺は、諸事情によりプログラムを書くことがありますが、さっぱり分かりませんでした。
DirectXに直接関係のある部分をいじったことがないせいだと思いますが、さっぱりです。

「ムービーは動的テクスチャ上に展開してるんですが、どこがネックになってるかを調べると環境ごとに全く違うわけです。テクスチャのロック処理に時間がかかってる環境もあれば、ムービーの展開に時間がかかってる環境もあるわけで。展開はアルゴリズム考えればどうにかなるかもだけどロック処理はどうしようもないよ！　ところで、ムービーは差分展開されます。つまりあるフレームのデータは、キーとなっているフレームからの差分方式で格納されてるわけです。なのでフレーム更新には前フレームのデータが必要です。ビデオメモリから前フレームのデータを取得するわけにもいかないので、システムメモリ上に保存しておく必要があるわけです。ファイル→システムメモリ→ビデオメモリとコピーする必要があります。無駄です。ビデオメモリ上に直接展開したいがために D3DLOCKED_DISCARD をはずしてみると…。ネットブックとかでひどいことになりました。展開よりロックの方が時間かかるっておいおい。システムメモリとビデオメモリ共有のノートとかだと時間差がなかったので気付かなかったです。ごめんなさい。さらに、遅いマシンで再生が間に合わずにフレームをスキップしつつ再生しなければいけない場合、スキップしても結局キーフレームまで戻らないといけないんですね。ひどいことになります。…じゃあ全フレームをキーフレームにしちゃえばいいんじゃね？　Ｏｈ！速くなったよ！でもいいのかこんなことして…。これブログに乗せるんですか？　載せちゃっていいのか内心ビクビクしてます。後はねぇメモリ確保ルーチンを部分的に特殊化してうまく使いまわせるようにして汎用性なんてユーザは求めてないんだよと自分に言い聞かせてみたり安全のために無駄に通ってた処理をちまちま削って DirectX のデバッガにリークしてんぞこらって怒られてみたりアセンブラチューニングしてた箇所をやめてコンパイラの最適化に任せて見たら何か速くなって最近のコンパイラはほんと賢いなぁすごいなぁ Visual Studio 2010 にとっとと移行したいぞと感動してみたり急に速くなったぞ！何でだ！！！って調べてたらマシンの構成変えたことすっかり忘れてたりスクリプタさんに仕様ですごめんなさいごめんなさいと無理を押し付けてしまったり（ご協力本当にありがとうございますm(_ _)m）大丈夫僕にはこまりんがついてるんだああ今日は十六茶買いに行かないと…と逃亡したり、 まあそんな感じです」

(引用元)
となぴょんさんすごすぎる…。いや、ゲーム業界これが普通なのか？！
俺はVisualArt'sさんが無償公開しているエンジンRealLiveMaxをちょこちょこといじっています。
このエンジン非常に優秀で、リトバスのミニゲームもこれで作成されたらしいのです。
そんなエンジンに携わっているのが、こんなにすごい方ならあのエンジンのクオリティも納得がいきます。
エロゲ業界もあなどってはいけないよね。すごいなぁ。