Seaside Laboratory

設計

処理の大まかな流れは、

1. 描画命令が呼ばれたら描画は行わず、座標や描画順位といった情報をリストに登録する。
2. 全てのゲーム処理が終わったら、リストの内容を描画順位でソートする。
3. リストを順に辿って描画する。

こんな感じ。

リストのソート方法としては以下の 2 パターンが考えられる。

• 描画命令が呼ばれる度にリストを走査して適切な位置に挿入する。
• 最後に一度だけ全体をソートをする。

スプライトを 8 回描画した場合の参照回数を比較してみた。

前者の方法での最悪なシナリオは描画順位が全部同じというケース。こうなった場合は描画命令が呼ばれる度にリストを最後まで見る羽目になる。

1 回目 = 0 (まだリストにデータがない)
2 回目 = 1 (さっき追加したデータを参照)
  :
  :
8 回目 = 7

合計 28 回。

後者の方法の場合は描画順位の値によって速度が変わったりはしない隣接交換法の場合だと、比較元は全部調べる必要があるが、比較先は最小値が決まる度に減っていく。

1 回目 = 8 (1 回目は全て参照)
2 回目 = 7 (最小値が 1 つ決定している)
  :
  :
8 回目 = 1

合計は 36 回。これに比較元の参照回数である 8 を加えると 44 回になる。

何も考えずに両方のコードを書いたが、どっちもクソ重てぇ！遅くなる原因になったのは Debug モードの STL。以前は Debug モードでも 50 FPS くらいでていたが、優先順位付描画を実装した途端、酷いケースだと 12 FPS まで低下してしまう。さすがに、ここまで遅いと実用レベルじゃねーです。Release モードなら速いんだけど。

実装

「ところで De を実装した KFM を見てくれ、こいつをどう思う？」

「すごく…重いです…。」

描画パケットの管理がヘボヘボなので Pentium 200MHz だと状況によっては結構厳しい。Pic は構造上、細かいセルをたくさん描画するので、飛び道具を使ってフラッシュさせたりすると処理が重くなって一瞬スローになる。今の平均的なスペックがあれば気になるような重さではないが、高速化の余地はまだあるので、そのうち改善してみるつもり。

yaneSDK を覗いてみたら描画パケットには vector が使われていた。最大描画パケット数を超過した瞬間に vector が拡張され大量コピーが発生しないのだろうか。