July 23, 2007.

アニメーション設計について

昨日立てたデータモデルで軽くアニメーションアプリを組んでみました。うん、一応動作します(当たり前)。日ごろ我々が目にする動画は30fps(frames per second)から60fpsの間で、滑らかな動画の実現のためにはfpsは高い方がよい。最初は携帯だし10fpsぐらいで良いかなと思ったのですが、高速で動くものがスムースに見えないため20fpsに変更。まだ滑らかさに不満が残るけれどこれぐらいかな。30fpsにするとsleep時間が33msとか34msとかへんな数字になるのがネックだし(笑)。と書いていて、液晶やゲームの話で出てくる29.4fpsって中途半端な値の意味が初めて理解できました。34msごとに再描画をかけると29.4fpsになるのね。

昨日の設計には問題点も多数。１つはメモリ管理。昨日のモデルで組んだ場合、動作はintの２次元配列で保持する。static finalな物の集合で実現すればシンプル。しかしstatic finalで持たせると言うことは、即値を全部同時に持つわけで、それってクラスを読み込んだ瞬間に膨大なメモリ初期化処理が走って、遅い、あるいはヒープが一杯になるのでは？と心配。かといって、プログラムからあるタイムライン変数に代入するシステムだとint配列のnewが何度も発生してフラグメント化が進みそうな...。今のMIDP&CLDCはgcやヒープ整理機能を実装しているらしいからそこまでセンシティブでなくても良いのかなぁ。

それから昨日書いたとおり、タイムライン配列が固定のため蟻の大群のようなものが表現できない。10本準備して１キャラならそれも無駄。さらにいうなら、昨日のモデルだと、左から右へ1dotずつ240dot動くキャラを書くのに240フレーム準備する羽目になる。プログラムで組めばfor文でx++;するだけで済むのに。

とまぁそんなわけで「わーい実機でアニメが動く。可愛いな」と遊びつつ、設計に頭をひねっています。パフォーマンスを一旦無視して思い切りオブジェクト指向で組んでみようかなぁ。それならActionクラスを作成し、各アニメーション動作をActionのサブクラスにして、アニメを変更する際は動作スロットにActionインスタンスを格納。関数doActionを呼び出すとオーバーライドされた動作がキャラの種類や、位置を描画オブジェクトリストに配置し、paintは描画オブジェクトを描画。うん、それっぽい。

欠点は新規の動作をリソース化して読み込みがたいため、プラグイン化が難しいこと。RMIやinvokeで解決可能かもしれませんが、携帯でできるのかな？？あとは処理とアニメーションが分離されないため、デザイナに優しくない。「一人プロジェクトだからいいじゃん」という無かれ。デザイナが自分って事だからより一層大問題なのです(その発想は性格悪いぞ)。

画像は取り合えずPNGフォーマットでよいかな。というのもbyte配列型からのCreateImageはヘッダを含んだ状態のbyte配列で無いといけないらしく、精製が面倒。4色PNG画像を試しに作ったところ、32x32で200バイト未満とまぁ許容範囲ですし。byte配列はSpriteの時に。ゲーム作成まで温存かな。

Copyright 2007 barista. All rights reserved.