[WitchTech 00648] Re: ご返事ありがとうございました。

[Kenichiro Ueda <ueken@pluto.dti.ne.jp>]

うえけんです。細かいことを書いてもしかたないので、概論的な
話になってしまいますが。

まず、きつい言い方に読めたかもしれませんが、嫌味を言いたい
わけではないです。ハードウェアにまったく不向きな方法で作る
のは徒労に終わるからやめたほうがよい、ということです。

ラインバッファの場合、ＶＲＡＭは操作するものではなく画像を
置いておく物置のようなものです。さらにＣＰＵが遅いとなると、
事実上「全キャラの転送」は実用的な速度で動きません。

キャラジェネアニメの効果的な使い方は、ＲＰＧのフィールドを
考えるとわかりやすいと思います。草原、海、山、平地のキャラ
があったとして、草原を風になびかせたいとします。その場合、
草原のキャラだけを数Ｖブランクおきに転送するだけで、画面上
のすべての草原がアニメするわけです。間違っても１画面分転送
しようなどと考えてはいけません。

あと「遅かったからアセンブラで書き換えよう」というのもやめ
たほうがいいです。少なくとも書き換える前に考えるべきことが
たくさんあるはず。

１．本当に遅いのか？
単純にキャラジェネを転送する場所と走査中のラスターが重なっ
ていただけ、ということもあります。水平表示数制限を超えたた
めにちらついただけということもあります。

２．ロジックに問題はないか？
今回のように全キャラ転送など無理なことをしている場合とか、
遅い書き方をしている場合などはロジックを改善したほうが効果
はあります。逆にロジックが同じならアセンブラにしても大して
早くなりません。

このようなことをまず考えてみるべきです。基本的にアセンブラ
でぎりぎりの最適化が必要になる場面はそんなに多くありません。

Ｃで最適化する場合の注意点は、

１．とにかくテーブルにする。switch - case はテーブル引きに
置きかえる。ifの連発はやめる。算術計算が入る場合は、固定値
をテーブルで持てないか考える。

２．構造体のメンバー配置に気をつける。確かターボＣは構造体
をそのまま並べて配置したはずなので、奇数番地から２バイトの
メンバーが開始しないようにする。

３．引数の多い関数は作らない。パラメータを多く渡したい場合
は構造体につめて、ポインタを渡す。

４．ビットフィールドは使わない。unsignedも使わない（多くの
場合unsignedは不要）。２のべき乗の乗除算はシフトにする。
扱う数値にマイナスがありえないからといって、安易にunsigned
を使わないこと。

５．ループのアンローリングはすべきではない高速化だが、最後
の最後で必要なら適用することも考える。

これくらいやれば多少は効果があると思います。ロジックの検討
はそれ以前の問題として当然やるべきです。その上で、どうして
もこの部分がピンポイントで遅い、という場合にはアセンブラを
使って最適化してもいいでしょう。

ゲームマシンは設計によってそれぞれ得意なことや不得意なこと
が極端に出たりします。少なくともハードウェアリソースは限り
があるので、力任せの方法はまずうまくいきません。そういうこ
とを良く考えて作りましょう。