最適化の余地

DXRubyは0.0.6リリース後、しつこいと怒られそうなぐらい最適化をしてきた。
実際、ゲームのパフォーマンスに影響する基本的な部分はほぼ手をつけ終えた状態だ。
ここから先はほんとに細かい修正を積み上げるか、なんらかのトレードオフを受け入れて、制限を付けつつ大きく性能向上させるかのどちらかとなる可能性が高い。

細かい修正ポイントはまだまだたくさんあって、それぞれ小さい向上幅かもしれないが、全部合わせれば2割3割は速くなる余地があると思っている。
いわゆるカリカリのチューニングだ。
これは一気にやるにはしんどい作業で、地道に修正→確認を繰り返していくしかない。
Pentium4に特化するわけにもいかないから、ある程度のところで限界になる。

トレードオフのほうは、あまり使われない機能について性能を落とすことで、よく使われる機能に特化したコードに書き換えるような感じだ。
昨日の修正も、フォント描画の性能を微妙に落として画像描画の性能を大きく上げている。
まさかフォントを60fpsで数百個とか表示することはあるまい、という判断だ。
同様に、2Dゲームではエフェクト無し描画が多いはずだという判断に至れば、エフェクトあり/なしをスプライト情報に埋め込んで、描画時に判定して計算を省くやりかたもあって、エフェクトありの場合に判定が増えるのでトレードオフの関係にあると言える。
しかしこれは単にif文が1個増えるだけではなく、高速ループを行う描画処理内で予測不可能な分岐が発生することで、分岐予測が外れた場合のパイプラインストールが痛く、エフェクトあり/なしが混在するとほとんど性能が伸びないばかりか、逆に下がる可能性がある。
こういう修正は、ベンチマークには強いが実ゲームではそれほどでもない、という状態に陥りやすいので、あまり熱くなってもよろしくない。
ともあれ、DXRubyの最適化はそのレベルに達しているということだ。

それにしてもRuby/SDLの速さには参った。
特性が示す通りソフトで描画しているとすれば、画像が小さくなればなるほど速いわけで、どこまで最適化しても小さい画像でDXRubyがRuby/SDLを上回ることはないだろう。
逆に、ソフトで描画しているのなら、処理時間は画像の面積に比例するわけで、背景の上に重ねる画像が多ければ多いほど、そして、その画像が大きければ大きいほど不利になる。
また、8*8ピクセルの画像で640*480を埋めるようなゲームを作る、とかになるとそれだけでRuby側の処理が厳しくなるから、小さい画像を大量に使う用途というのもいまいち現実的ではない。
ゲームの実行に必要十分な性能というのは、そういう方向のものではないのだ。