おちゃめくらぶ掲示板 - 1659321896

1458：御茶目菜子：2013/01/28(月) 00:00:34: 拡大縮小回転はロマン・・・！？
次回のプチコン講座に予定しているのはGRP面（グラフィック面）の拡大、縮小、回転に
ついてにょ。
もちろん、プチコンにそのような機能はないためソフトウェアで実装する必要があるにょ。
それらは基本的にはそれほど難しくはないということで、とりあえず、講座用にサンプルと
なるゲーム「2D→3D RACE」を作ったので講座に先駆けて公開するにょ。
http://twitpic.com/byq6ew
http://www.youtube.com/watch?v=k6vrMHPMO8I

このゲームはGFILLのみで作られた縦スクロールレースゲームなのだけどリアルタイムで
X軸の回転処理を行っているため疑似3D表示となっているにょ。（PETIT RUNの疑似3D
表示はポケコンで作ったレースゲームでも使用していたアルゴリズムを採用した非常に
シンプルなものであり、速度重視となっているものの表示には少し誤差がある）
視点切り替えも可能でデフォ設定では[X]ボタンを押すことで90度見下ろしとなるにょ。
回転処理は一次変換を使用しているだけなので非常に簡単にょ。
さて、このゲームに関しては詳しくはその講座で書くとしてやはりプレイ開始前デモの
拡大縮小処理はF-ZEROをかなり意識したものとなっているにょ（笑）

さて、拡大、縮小、回転といえばやはりすぐに出てくるのがスーファミにょ。
当時はハードウェアでBG面に拡大、縮小、回転機能を搭載しているということで今までの
コンシューマゲームでは見ることができなかったようなゲームも多数作られたにょ。
F-ZEROもこの機能が搭載されていなかったら恐らく作られなかったと思うにょ。
GRPの回転処理そのものはそれほど難しくないのだけどZ軸を回転させると演算量が飛躍的に
増えてしまう（X軸回転だったら上記のゲームだと道路の部分だけ演算を行えば良いのに
対してZ軸回転はすべての座標を計算する必要がある）というのが大きいにょ。

やはり、作るならばZ軸だけではなくスーファミのような2軸回転をやってみたいにょ。
Z軸回転だけよりさらに演算量が増えてしまうのだけど工夫次第では速度面は何とかなると
信じて試しに作ってみたにょ。
http://www.youtube.com/watch?v=LoDkoQcveoU
いいGRPデータを用意できなかった（というか空き容量もないし）ということでプチコン
まとめwikiで公開されているoさんの作品「Petit Slash」の面データの上を走り回って
みたにょ。（ちなみにこれはまとめWikiに公開されているバージョンではなく初期の
バージョンの方）

32x12ドットx8倍拡大で10fps程度の速度となっているにょ。
GFILLで描画しているため拡大率は自由に設定できるのだけど概ね1秒間に3000ドット程度の
処理速度であるため30fps出そうとすれば縦x横で100ドット程度に抑える必要があるにょ。
これでも、かなり高速化処理をしているためここから大きな速度向上は難しいそうにょ。
拡大率8ドット固定であればGFILLではなくBGPUTを使用することで描画部分の速度は向上
できるものの演算速度がボトルネックとなっているため描画速度が2倍近く速くなったと
しても全体の速度向上はそれよりもかなり小さなものになるにょ。
ただ、現時点のバージョンでは少し不具合があるにょ。
2軸回転だから本来ならばカメラアングルを自由に変えることができるのだけど90度上から
見下ろしてもトップビューにはならないにょ。
どこかで計算式が間違っているだろうけど高速化のため複雑怪奇なことをしているため
なかなかそれを見つけ出すことができないにょ（笑）
講座でこの2軸回転を公開するならば何とかしてそのバグだけは潰さないといけないけど
現時点では原因不明であるためなかなか苦労しそうにょ。（※このバグは翌日あっさりと
改善されました）

書きたいことも大量にあるため次回の講座は完成はかなり先になりそうにょ。
それまでの穴埋めとして途中まで書いているギタープログラムの講座を書くかもしれないにょ。
こちらは難しいことは何もないし、書くことも極めて限られるからね。
といっても、需要もかなり限られそうだけど（笑）

《　1/28追記　》

上記のGRP2軸回転プログラムで表示部分のみGFILLからBGPUTに変更したらどうなるかを検証
してみたにょ。

　32x12ドット8倍拡大時
　GFILL　10fps　→　BGPUT 11fps

しかし、BGPUT使用時には上下画面でのGPAGE切り替えが不要になるのでそれを省略すれば
13fpsになったにょ。
これは表示をGFILLからBGPUTに変えたものよりも大きいにょ。
BGPUTではパレット0限定では引数を省略可能なのでそれを省略してみたにょ。
そうしたら、14fpsになったにょ。
2重ループの内側は処理速度の向上のため加減算しか実行してないためこれ以上の高速化は
無理に思えたけどコロンなどの省略できるものを省略して変数名を1文字にするなどの地道な
変更によって17fpsにまでなったにょ。

ちなみに各命令や演算速度を単独で計測してみた結果は下記の通りにょ。

10万回実行時のフレーム数（1フレーム＝1/60秒）
BGPUT　引数省略無し269　引数省略時172
GFILL　8x8　233
GPAGE??51
GSPOIT 65

A=1 　 59（代入処理）　※1文字変数の処理1つ当たり「15」が含まれた時間
A=A+2??81　加算　　　　　変数名の処理は1文字増えるごとに「2」増える
A=A-2??81　減算　　　　　四則演算は変数処理と代入処理を含んだ時間となっている
A=A*2??78　乗算
A=A/2??91　除算
改行　　5
コロン　7
FOR～NEXT 91（1回当たり）※FORとNEXTの間に何も含まない10万回ループで測定

　※同一処理、同一条件下でも測定するごとに微妙に処理時間が異なっているため複数回
　　計測して最も処理時間が短くなった値を記述した

これを見るとBGPUTは引数を省略しないとGFILLよりも遅いにょ。
それなのにGPAGEを省略する前にすでにGFILLより速くなっているのは変数の処理に時間が
かかっているためにょ。
それを込みで計算すると例えば G=GSPOIT(X,Y) は 59+65+15+15 で154となるにょ。
実際に G=GSPOIT(X,Y) を計測すると154フレームとなっており、その計算通りの時間と
なっているためこの表の数値に間違いないことが分かるにょ。
ただし、上記の値はすべて小数点以下は切り捨てであるため誤差が積み重なった場合には
無視できるレベルの誤差は十分に考えられるにょ。
上記の一覧では加算は81となっているけど代入が59含まれているということを考えると
加算や減算を1つ省略するよりも代入1つ省略する方が大きいといえるにょ。
実際G=GSPOIT(X,Y)を代入せずに使用したらだけで一気に2fps上がったにょ。
まぁ小数点以下は切り捨てだから2fpsといっても実際は1fps少々だと思うけど代入を1つ
省略するだけで処理速度が1割近く跳ね上がるというのは非常に大きいと言えるにょ。