実行速度

ゲームなどの実行速度を決めるのは、大きく分けて2つの要因がある。
「環境」と「アルゴリズム」だ。
環境はCPUやGPU、メモリ、バス、OS、ドライバ、ライブラリなどで、アルゴリズムはゲーム側でどのように描画や計算をするか、という話だ。

2つのうち、どっちかが遅かったとしても、もう片方で取り返すことができる。
つまり、ライブラリがしょぼかったとしても、それを売り込むためのゲームを真剣に作れば、かなりのものが作れる可能性がある、ということだ。
もちろんそんなことをすると、期待して使った人がしょんぼりしてしまうわけだが。
逆に、売り込み用のゲームがしょぼしょぼだったとしても、ハードやライブラリがしっかりしていれば、それだけでなんとかなる。
DXRubyが狙っているのはそっちのほうだ。

だが、サンプルシューティングはどうなのかというと、キャラ数などについてはDXRubyのサポートでかなりなんとかなるが、ライブラリでどうにもならない部分がしょぼい。
具体的には全画面にかけている半透明フィルタだ。
あれを含めて約3画面分ぐらいの描画を毎フレームしているのではないかと思う。
DXRubyの仕組みだと、ソフトレベルではそんなことしても平気だ。
問題になるのはGPU側のピクセルフィルレートで、ターゲットをPentium3クラスに考えるなら、サンプルのゲームもそのあたりの世代を考えておかないといけなかった。
CPUじゃなくて、GPUのほう。

「GPUが遅い人用」としてエフェクトカット機能もつけてあるにはあるが、何が遅いかきちんと判断できる人ばっかりでもないし、対策を考えるか。
そのサイズの絵を用意するからデータ量が増えて、内蔵チップセットだとメインメモリに置いたテクスチャを参照するから、メモリ帯域が問題になったりするわけだ。
そういえばPentium3のPCで遅くてフィルタ外したりもしてたな。
外すんじゃなくて、代替の策を考えよう。1ピクセルのイメージを作って640*480に引き伸ばすとか。
っつっても、それだとピクセルフィルレートじゃなくてメモリ帯域の問題の解決にしかならないのか。
純粋なピクセルフィルレートならそのあたりの世代でもたぶん間に合ってるはずだから大丈夫かな・・・。
絵のほうを修正すれば解決するんだけど、そっちは俺がいじれるものではないしな。
サンプルシューティングも安定版ベースにしたいところだし、ちょうどいい。
安定版リリースの次のミッションはサンプルシューティングの最適化か・・・ｗ