シューティングゲームチャレンジ ＃１１

背景との当たり判定実装

背景と自機、波動砲に当たり判定をつけてみました。
敵機に関しては、壁に衝突（自爆）するような飛ばし方はしないので今のところ必要ないなと。
あ、床を歩き回るような移動砲台には必要か。

自機と敵機で使ったような円の当たり判定だと、直線主体の判定ラインがボコボコになってしまいます。
小さな円を線に沿って沢山並べればカバーできますが、それを一つ一つ判定するのは余りに効率が悪い。
と言うわけで、最初に線と円の接触判定を考えてみました。
えーと、背景の線分Ｐ-Ｑと自機の中心点Ａの距離を求めるには、角ＡＰＱと角ＡＱＰが90度以内の時はＡＰ×sinθで、いや、待てよベクトルが使えたような・・・とやってるうちに馬鹿馬鹿しくなりました（笑）
わかりやすく言うなら、めんどくさくなりました。
そこまで厳密にやる必要があるか？と。
自機の範囲を表す四角形と背景の範囲を表す四角形で良くね？と。
当たり判定をシビアにするか甘くするかは、厳密なラインが無くても自機や背景の範囲を実際に表示されている絵より大きくしたり小さくしたりでカバーできると思われます。
その点は円の当たり判定も一緒ですが、直線メインで描かれる背景は四角で表現した方が判定対象となるオブジェクトの数を少なく出来るでしょう。
頭の中で考えただけでも、明らかに四角形の当たり判定の方が処理が軽そうだし、それでカバーできないほど複雑な形のマップを描いてしまったら、またその時に考え直せば良いかと。


















こんな感じで四角形AとBを描いて各座標の状態を調べます。
Aの左上・右下の座標を（X0,Y0）、（X1,Y1)
Bの左上・右下の座標を（X2,Y2）、（X3,Y3)　とした時に
X座標、Y座標それぞれについて、接触しない状態を考えます。
『接触しない』状況を考えた方が最終的になぜたった4つの条件で判定できるのか理解しやすいと思います。
例えばAがBの左側から近づいて行った場合をX座標でみると、AのBよりの座標X1がBのAよりの座標X2より小さいうちは接触しません。
右側から近づいた場合はお互いさっきと逆側の座標で比較します。つまり、X0がX3より大きいうちは接触しません。
同じ事を上下方向から近づいた時のY座標でも考えます。
そして、これらの条件は『接触しない』条件ですから、この条件の不等号を逆にしてやると『接触する』条件が現れます。
その条件はたった4つ。

X0＜X3、X2＜X1、Y2＜Y1、Y0＜Y3

これだけです。
当たっていればTRUEを返す関数をコードにすると

～前略～
if ( (X0<X3) && (X2<X1) && ( Y2< Y1) && (Y0<Y3) ) return TRUE;
～後略～

って感じです。これは見るからに軽そうです。

で、サクッと実装できると思ったんですが意外と苦労しました。
スクロールに合わせて当たり判定の位置も動くからです。
背景の当たり判定用の四角形の座標を1ドットスクロールするたびに全て動かすのは、あまりに頭が悪そうだな（効率悪そうだな）と思ったので、自機や波動砲に2つの座標を持たせました。
1つは前からあった画面に表示するときに使う画面上の座標。
で、もう1つが新しく増えた背景座標系内の座標。
この座標は表示サイズよりも大きい背景画面の何処にキャラクターがいるか表す座標で、画面上の座標にスクロールしたドット数を足すと求められます。
この座標をもとに当たり判定の四角形の座標を求め、同じ座標系の背景の四角形の座標と比較して当たり判定を行うわけです。

今はまだ背景がループするので、その辺の処理がまた余分に面倒でした(笑）
1ステージ分の背景を作りきってしまった方が、ループが無いので処理はシンプルそうな気がします。
ただその場合、背景の四角形も相当な数になるので、沢山の中から画面内に入っている分に関してだけ当たり判定を行うようにしないと無駄が多くなる気がします。

実行ファイルを。
申し訳ありませんが見た目は何も変っていません。
ソースもいつも通り同梱です。
http://multip.net/view/f10PgPvBrW

そろそろ関数とかを整理してソース見通しを良くしておかないと自分でもいじりずらくなるかな・・・。