« 人類皆プログラム作戦! | トップページ | バックアップ »

2009年10月19日 (月)処理を減らすための数学3・番外編

おはようございます。本日の当番、プログラマーのK.Yです。

今回は前回書きました【処理を減らすための数学3】番外編としまして、その時に紹介した2つの処理の違いを検証してみたいと思います。

というわけで、まずは前回の内容を軽くおさらい。

2009_1016_1

図のような感じの落下処理を関数で表すと以下のようになります。
―(1)――――――――――――――――――――――
x = v * t * cosf( θ );
y = v * t * sinf( θ ) - ( 0.5f * g * t * t );

――――――――――――――――――――――――――

この(1)の処理は常にスタート位置からの座標を計算しています。
次に紹介する(2)は1個前の状態からの変化量を加えていく処理です。
―(2)―――――――――――――――――――――――――――――――
static float move_x;     // X方向移動分
static float move_y;     // Y方向移動分
static float pos_x = 0.0f;  // X座標
static float pos_y = 0.0f;  // Y座標
static float gravity = 0.0f; // そのときの加速度

------------------------------------
// 開始時に値を設定
move_x = v * cosf( θ );
move_y = v * sinf( θ );

------------------------------------
// 毎フレーム以下の処理を行なう
pos_x = pos_x + move_x;      // 前の座標に移動分を足す
pos_y = pos_y + move_y - gravity; // 前の座標に移動分と加速度を足す
gravity = gravity + g;       // そして加速度を加える

―――――――――――――――――――――――――――――――――――

ここで(1)と(2)の処理でどのような差が出るのかを検証してみましょう。

検証結果を簡潔にするために初速度は0とします。
そうすることでX座標とY座標の等速運動分は検証する必要がなくなり、純粋に加速度の変化だけを見ることができます。

さらに結果を分かりやすくするため g = 1.0 として計算し、全てプラス方向への変化にしてみます。

というわけで検証結果

(1)の処理
  y = 0.5f * g * t * t;
  t = 0 : y = 0.5 * 1.0 * 0 * 0 = 0.0  変化量
  t = 1 : y = 0.5 * 1.0 * 1 * 1 = 0.5 → 0.5
  t = 2 : y = 0.5 * 1.0 * 2 * 2 = 2.0 → 1.5
  t = 3 : y = 0.5 * 1.0 * 3 * 3 = 4.5 → 2.5
  t = 4 : y = 0.5 * 1.0 * 4 * 4 = 8.0 → 3.5
  t = 5 : y = 0.5 * 1.0 * 5 * 5 = 12.5 → 4.5


(2)の処理
  pos_y = pos_y + gravity;
  gravity = gravity + g;
  t = 0 : pos_y = 0.0 + 0.0 = 0.0  変化量
  t = 1 : pos_y = 0.0 + 1.0 = 1.0 → 1.0
  t = 2 : pos_y = 1.0 + 2.0 = 3.0 → 2.0
  t = 3 : pos_y = 3.0 + 3.0 = 6.0 → 3.0
  t = 4 : pos_y = 6.0 + 4.0 = 10.0 → 4.0
  t = 5 : pos_y = 10.0 + 5.0 = 15.0 → 5.0


(1)(2)の結果共に等加速で値が変化しています。
しかし一番左の数値の変化量に注目してみますと全体的に 0.5 ずれてしまっています。

なぜこのような事が起こってしまうのでしょう?
下の図を見てください。

2009_1016_2

これは(2)の処理で毎フレーム足していく加速度をグラフで表したものです。
例えば3フレーム目ではグラフの青と黄色の部分を足しています。
しかし、ここでの実際の加速度は青の部分だけです。
というわけで毎フレーム黄色の分だけ多く加算していることになります。
これが(1)と(2)の検証結果のずれになっています。


ここで黄色の部分を足さないような処理にするためにはどうすればいいでしょう。
例えば1フレーム前の加速度と今回の加速度を足して2で割ったりするなどのひと手間が必要になってきます。

ゲームの仕様にもよりますが、きっちりと移動処理をしなければならない物に関してはこのひと手間が必要になるでしょうし、状況によっては(1)の処理の方が有効な場合もあります。
きっちりとした移動処理の必要がないものに関しては、(2)にひと手間を加えなくても重力加速度 g を大きくしたり小さくすることで速く落下したり空気抵抗があるかのようにゆっくり落下させるなどのバリエーションが使えます。

このように今回紹介した(1)(2)などの処理を場面場面で使い分けていくことで、結果処理軽減にはつながっていきます。
まだまだ軽くできるところはないか、現状の処理で満足せずにさらなる軽減処理を探していってみましょう。

follow us in feedly
result = encodeURIComponent( "http://www.accessgames-blog.com/blog/2009/10/post-3bee.html" );document.write( "result = " , result );&media=https%3A%2F%2Ffarm8.staticflickr.com%2F7027%2F6851755809_df5b2051c9_z.jpg&description=Next%20stop%3A%20Pinterest">

| | コメント (0) | トラックバック (0)

« 人類皆プログラム作戦! | トップページ | バックアップ »

プログラマー」カテゴリの記事

コメント

この記事へのコメントは終了しました。

トラックバック


この記事へのトラックバック一覧です: 処理を減らすための数学3・番外編:

« 人類皆プログラム作戦! | トップページ | バックアップ »