続・bulletml.jsでjgame.jsのパフォーマンス検証

以前書いたbulletml.jsによるjgame.jsのパフォーマンス検証、の続き。
http://d.hatena.ne.jp/tsugehara/20130202/1359818875

経緯

ざっと前回のエントリを要約すると、ちょっとやってみたけど思ったより遅いなと。
僕の考えた最強のフレームワークが・・そんなバカな。

まあそこまで悔しかったわけでもないんだけど、今回たまたま少し時間が出来たので、少し速度向上方法を検討してみることにした。
結果として、手っ取り早く速くしてみる方法を一個試してみたら、思ったより速度が出たので報告がてらこの記事を書いている次第。

デモ

まあとりあえず見てくれよと。

前回のがこれ。
http://tsuge.sub.jp/sugoroku/jgame/index3.html

今回のがこれ。
http://tsuge.sub.jp/jgame.js/BML/index.html

もっとも遅くなっていたのはこの瞬間で、前回は10fpsを切っていた*1。

今回のは手元のMacでのテストでは、最遅のポイントではどうしても60切るけど50強確保。肉眼でラグってるとはっきりわかるレベルにはならない形になった。
また手元のもう少し弱い東芝PCでも、最遅のポイントで30出てる。
実用レベルになったんじゃない？という気がする。

修正点

修正したのは一点で、大量のSpriteを画面に配置するというところから、Spriteとは違う描画単位でbulletml専用のコンテナ作って、画面に配置するのはこのコンテナだけにした、のみ。
Rendererが描くんじゃなくて、このコンテナが弾丸を画面に描くようにした。

難しそうな事言ってるけど、Rendererの管轄対象になると回転などの処理によるオーバーヘッドが入って遅くなることがわかっていたので、マップと同じようにRendererの管轄対象外にしたってだけ。
正直ここまで出ず、60fps出すためにはputImageData使わないと無理だと思ってたんだけど、案外実用レベルの速度は余裕で出せんだなと。CANVASもやるもんだね。

問題点

例によって衝突判定してないし、スクロールもサポートしてないので、その辺の計算処理入れてどんなもんかってとこかなと。

まあ、スクロールは全然問題ない。元々スクロール前提のマップと同じ仕組みだし。

ただ2500個の弾丸に衝突判定が入ると若干遅くなるかも。
まあそこまで極端に落ちる事はないと思われるのと、そもそも前回も衝突判定はさぼってたので、前回からこんだけ速くなったよって意味の今回の記事ではいらん項目だろということで省略。

ということで

なんとなく実用速度に達したくさいので、一応ソース公開します。
https://github.com/tsugehara/BML

まだこっち側で実用する予定が無いので何だけども。。
弾幕ゲーは俺自身がそんなに惹かれなくってなぁ・・。

ということで、こっちで実用する予定が無いので不足部分はかかないと使えない。
衝突判定はBulletContainerってクラスに適当に追加して、呼び出し元で適当にやってねって感じになる。スクロールは、BulletContainerのdrawメソッド内を修正必要あり。
あとライセンスもbulletml.jsとbulletmlをちゃんと調べてないので書いてないけど、その二つとかち合わなければいつも通りMITで。

jgame.js的には、高速なつもりのRendererで遅くなったので、どこがボトルネックになったのか少し調べないとなぁという感じ。

追記

ということで前回のを少し直して、ちょっと直したバージョンを作った。
http://tsuge.sub.jp/jgame.js/BML/index3.html
描画処理変更無し、弾丸の生成処理見直しをしたもの。

これだと30fpsくらい出てる。
ということで、描画ではなく弾丸の生成がボトルネックだったことを確認した。
マップ型と20fpsの差は、座標移動をcanvasのtranslateで移動しているか、drawImageで引数でやっているかが一番大きいと思うけど、マップ型にしなくてもまあ及第点かなと思われます。

大体調べ終わったので、いったんこの問題はクローズかなと。
WebGL対応でもするようなことがあったらまた書く。

*1:後述のちょっと直したバージョンでは、30強