« SSE からの整数値の取り出し | メイン | ハイブリッド データ オーダー »
2008年03月06日
吉里吉里 その他の開発日誌:: 炎を入れてあれこれ
Tweet @jin1016をフォローAthlon XP 1600 でも 256x256 程度なら余裕なんだな。
常に大きい領域で炎を出すのではなく、表示したい領域を絞り込めば普通に使える。
横幅は火種画像の幅 +32 ぐらいの大きさにして、高さは炎が上に伸びる関係上見ながらある程度調整するか、画面の一番上までとして出す領域を狭めるのが良さそう。
いきなり大きい領域ではじめから処理落ちして遅いと不自然だけど、処理落ちしない小さい領域で炎が出てその後大きく広がるような場合、大きくなった時に急にゆっくりになるが、処理落ちしているのかなとは思うけど、そんなに変ではない。
800x608 ぐらいのサイズだと、2GHzぐらいは必要になりそうだけど、みんなそれぐらいは満たしてないかな？ まあ、800x608で炎を出したいがためにそんなスペック要求するのはどうかと言う話だが。
後、倍ぐらい速くなれば、使いやすいのだけれど……
とりあえず、あれからまた 5% 程度高速化できた。
それでもまだまだ重いのだが、実際に組み込んで見た感じでは、別にプリレンダリングにしてしまうほどではないかなと言う感触。
まあ、燃やすもののパターンが結構あるので、プリレンダリングにすると容量食いそうだと言うのもある。
このエフェクトであれば、元々ある絵を火種画像として渡してやれば、その領域を元にして燃えるのでデータ量は増えない ( エフェクト用に特別に火種画像を準備すればその分増えるが ) 。
例えば、立ち絵を火種画像として 0.5 秒ぐらいの間設定しておいて、その後火種画像をクリアすると、一瞬燃え上がるようなエフェクトが出来る。
動いている絵を毎フレーム設定してやれば、それに炎も追従する ( 少し重くなると思うけど ) 。
アルファ付きムービーが使えたら、それを火種画像として設定することで、動いているものに炎を重ねられる ( アルファ付きムービーが使えるのなら、燃えてるムービーをはじめから入れておけと言う話だが )。
で、結局どうするかと言う話だが、単純にオプションでエフェクトのON/OFFを入れればいいやと言う考え。
まあ、できるだけ高速化しようと思っているが。
でも、800x608 の範囲ぐらいなら 1GHz 程度でいけても良さそうなんだけどなぁ。
根拠はないんだけど。
ポリゴン1個ずつやるのではなく、全ポリゴンの辺で一気にやる方法を再び検討する。
凹ポリゴンが少し気になるのと、前やった時に追いつきそうだったこと。
前回はデータ構造がまずかったのではないかと思ったこと。
SSE でスワップが出来るのなら、4つ同時ソートもできるのではないかと言うこと。
きっかけは、プリレンダリングするならできるだけクオリティを高くと思って、凹ポリゴンも綺麗に描画できるアルゴリズムに変えようと考えたことだけど、あれこれ考えてより高速化出来そうだとも思った。
なんとか倍ぐらい速くならないものかなぁ。
炎ではないけど、違うエフェクトを単なる連番静止画で入れてみた。
完全透明領域はカットして、オフセットと静止画像の組で出すように。
で、当然だけれど見た目は普通。
容量はほんの数秒なので、そんなでもない。
アルファムービー入れなくても、今回はこれで十分かと思いつつ、フレーム間差分ぐらい使った方がいいかな？ そうすればもっと容量削れる。さらに単純な差分じゃなくて、ある程度動き補償的なものも加えた方が…… と考えていて気付く。
普通に一般的な動画圧縮方法に近づいていることに。
それならはじめから、アルファ付きムービー入れればいいと。
でも、いろいろ工夫して圧縮率を上げるのはそれで楽しいから、惹かれてしまうのだが。
それと、元が自分の作ったスプライトアニメツールで作られているので、アニメ機能入れれば済む話とも思う。
そうすれば、可逆圧縮で最も圧縮率が優れたものになる ( ムービーの圧縮は動画像からアニメーションの元データに近付けようとしているので、アニメのデータが初めからあるのならそれが最も効率的。ただ、効率を考えずに組まれているとその限りではないが )。
先にアニメーション再生機能も入れるかな。
関連記事・続きの記事
炎エフェクトの高速化 全辺一気版
炎を入れてあれこれに書いたように、再検討した全ポリゴンの辺で一気にやる方法を試し... [続きを読む]
投稿者 Takenori : 2008年03月06日 03:06
comments powered by Disqus