Appendix

広告

Entries

スクリプトの更新とSpriteでいろいろ実験 その2

下記のスクリプトを更新しました。

乗り物擬似3D化 視界拡張
乗り物擬似3D化 計量化

ゲーム起動時にビットマップに変換するのがうまく動作してなかったので修正しました。
ついでに、ビットマップへの変換作業をゲーム起動時ではなく、ニューゲーム選択後やロード後の暗転時に行えるような機能を追加しました。

ゲーム起動までが長いとちょっとストレスになりそうだし、ちゃんと起動してるのか不安になるのに対して、ニューゲーム選択後やロード後に待たされるのって若干許される感じがするという理由でつけてみました。

ツクール製のゲームなのに読み込みあるって時点で違和感ありますけどね。



前回の続き。

実験その4・原点0,0での回転
130617a.jpg

大きめのピクチャを原点左上 座標 X:0 Y:0 で回転させた時の角度ごとのFPSを測ってみました。
結果はこんな感じ。

0~90度 : 20fps
90~360度 : 60fps

0~90度とはピクチャが少しでも画面に写っている状態です。
原点位置が0,0なので、90~360度の間は画面に表示されません。

結果から見て、スプライトを回転させても画面内に無ければ回転処理を一切行わないようです。
しっかりと計量化されてるんですね。

ちなみに原点位置をX:1,Y:1にして、90~360度でもわずかに画面に写るようにしてみたところ、常に20fpsまで下がってしまいました。
どうやら、わずかでも画面に写ると画像全体の回転処理が行われるようです。

実験その5・画面に写っていない部分をsrc_rectで削る
130617b.jpg
ひたすら横に長いスプライトで画面に写っていない部分をsrc_rectを使って削った場合のどうなるかという実験。
この実験では回転描写を使っていないので、とにかくでかいビットマップを用意して実験してみました。
Aは普通に表示。Bは画面に写っていない部分をsrc_rectで削った場合です。

A : 60fps
B : 60fps

と、ここで初めて差がでませんでした。
いくらビットマップを大きくしても、全体的な動作は不安定になりますが大きな差が出ることはありませんでした。
むしろ「src_rectで余計な部分を削る」という処理が行われる分、Bの方が若干重いかも?

今までの実験結果からして、「写ってなくても全体の描写がされるからsrc_rectでできる限り無駄な部分を削ったほうがよい」と思っていたのですが、それはどうやら回転描写に限ったことのようです。

なので、でかい画像だからって余計な部分を削る必要は無さそうです。
ここもしっかりと軽量化されてるんですね。

で、以上二つの結果から何が言えるかというと、「画面の外にあるスプライトを更新しない」系の計量化スクリプトは、実はそれほど効果がないということです。
ないことはないですが、「画面から離れてるイベントは自律移動させない計量化」に比べると効果が薄いです。


続きはあるようなないような。
スポンサーサイト
この記事にトラックバックする(FC2ブログユーザー)
http://woodpenguin.blog.fc2.com/tb.php/64-c4959c40

トラックバック

コメント

コメントの投稿

コメントの投稿
管理者にだけ表示を許可する

Appendix

プロフィール

木星ペンギン

Author:木星ペンギン
ほぼツクールのことばかり書いてます。
名前は↑から取りました。
木製ですが木星です。
トカゲは関係ありません。

ゲーム

  • 箱庭の勇者たち(体験版)
  • アクイ ト アイ
  • ぼくらの大革命!
  • 勇者がやらねば俺がやる!
  • 3Turn Battle!
  • 3TurnBattle!2nd 体験版

メールフォーム

wood_penguin@yahoo.co.jp

名前:
メール:
件名:
本文: