Ruby側の負荷 - mirichiの日記

スクリプトから移動処理を省いて、描画のみをするようにしてみた。
これが最もシンプルなスクリプトで現時点での最大値である。

簡単な移動処理が入るだけでオブジェクト数が約6割になる、ということだ。
Ruby1.9.1を使ってこれなのだから、Rubyの動作の遅さはなかなかのものである。
Ruby1.8.7で同じスクリプトを動かすと15200個。
移動させると6000個だったから、移動するだけで4割になってしまう。
この倍率の差は、Ruby1.9.1と1.8.7のスクリプト実行効率の差だ。

動的なスクリプト言語なのだから遅いのは当たり前であり、静的なコンパイル言語を使えば速いのはこれも当たり前だ。
遅い言語を使うメリットは開発のしやすさであるのは言うまでも無い。
が、遅さにも限度というものがあって、まともにゲームが作れないような実行速度では困るのだ。
DXRubyもアレコレいじってはいるが、いいかげんそろそろほんとに限界かと思っている。
描画性能が2割3割上がるような最適化があればいいが、苦労して数サイクル削るような真似をしても、Rubyのメソッドが1個増えたら消し飛んでしまう。
そうすると重要になるのが、いかにしてRubyの処理を減らすかという話だ。

その可能性として、DXRuby周辺ライブラリの提供や、RubyInlineのようなものがある。
周辺ライブラリは用途ごとジャンルごとに設計していかないといけないから、そうそう簡単に作れるものではない。
RubyInlineは現状では実行するPCでコンパイルすることが前提になっているみたいだから、これも使えない。
原理としては、埋め込まれたCのソースを拡張ライブラリとしてコンパイル、動的リンクして呼び出すように見える。
つまり、原理的にはWindows限定なら、コンパイル結果を配布することもできるはずだ。
これらの共通点は、RubyからCに逃げるというところで、相違点は書くのが誰かというところである。
Cに逃げる場合の問題点は、Rubyのメソッド呼び出しの負荷が残ることだ。
それをなくすには、Rubyそのものにパッチを当てるか、ほぼ全てCで書くことになるから、現実的ではない。

正直なところ、純粋なRubyで派手な2Dアクションゲームを作るのは厳しい。
サンプルのシューティングだって、背景を1枚絵にして、DXRubyExtensionをフルに使ってかろうじてあれだけ動かすことができる程度だ。
なんだか行き詰まりを感じる。
あまり上ばかり見ていてもダメなのかもしれないが、俺はRubyで自由に2Dゲームを作れるようにしたかったのだ。
これがRubyそのものの限界ということならしょうがないわけだが。

おまけ。
1ポリゴンスプライトとZSortDisable状態で移動を省いたスクリプトをRuby1.9.1で動かしたもの。

これをリリースするのはアリエナイということを改めて念のため付け加えておこう。
でもちょっとZSortDisableは魅力的なオプションかもしれない。