第九十八回　BitMapデータの当り判定は好きです

暖かくなってきて、露店売っている弁当が、
少し気になりはじめた６月下旬。

それでもアルバイトにとっては、
できるだけ昼食は安くしたいところ。

少し腹が痛いとか、
少し熱が出たりとか、
寝不足で体調悪くても、

休んだりしません。

アルバイト時代は、卒業式など以外では、

無遅刻無欠勤だったりします。

ちょっと体調悪いぐらいじゃあ、
無理でも会社に行っていた、

あの頃が懐かしい。

今はいろいろと無理ですね。

さて、BitMapデータで当りを判別する方法ですが、
BitMapデータから色を読み取り、

この色がついている部分は跳ね返る、
この色がついている部分は特殊な跳ね返り方をする、

などの名前からして予想通りの当り判定方法です。

でもメインではないので、なぜかその色は
画面上には表示され無い仕組みなんですよね。

説明されましたが、何で表示されないのか、
今でもよくわかっていません。

予想としては表示なんてしてなくて。
ただ１ドット単位で並べられたデーターを、
読んできているだけだと思うのですが、

その場合、やっぱり前回言ったように、
無駄データーを大量に持っていたようですね。

実はこの方法は好きだったりします。

なぜかって？

プログラマーがしないといけない事って、
けっこう少ないからですよ。

３Ｄの当り判定は、どれだけ計算を軽くするとか
考えないといけませんし、普通の２Ｄの当り判定でも、
座標とか調べないといけませんが、

これなら１発です。

この方法での当り抜けの場合、

デザイナーさんのミスの可能性が高いです。

見つけれなかったバグを他人のせいにする気はないですが、
それらを修正したりするのは面倒なので、

できればデザイナーさんの方で、
直してもらった方が楽です。

BitMapデータで当り抜けが発生した時は、

申し訳ない顔で、データー修正してもらうのがコツです。

いろいろと波風が立たないように、
生きていく事もコツですから。

あと、この方法が好きな理由として、

当り判定としては細かい部分まで判定できることです。

計算にすると、どうしても信じられないようなバグが
起こる時があるので、こちらの方が安心です。

信じられないようなバグにも対応するのが、
ゲームプログラマーという仕事なのですが。

動いてるのはコンピューターですが、
作っているのは人なので限界があります。

ミナミの限界は、すぐにやってきます。

では、ついでにこれの弱点を。

弱点と言いましても、
当時作っていたゲームにおいてと、
ミナミの個人的なスキルの問題からで、
先に言っておきますが、

普通のプログラマーにしたら、
弱点でも何でもありません。

何度も言いますが、これは便利です。

当時、作っていたのが、
２Ｄで３Ｄを表現するという物だったので、
斜め見下ろし型のＭＡＰで、
壁の高い部分に当ったと表現する時、

ハマります。

物体が高い部分に当り、跳ね返ったとしても、
地面に落ちる間も、BitMapデーターの当り判定の部分に
接しまくっているので、きちんと処理しないと

空中で浮いて止まります。

物体が当っている音は止まらず、連続で鳴っていますが。

単純に跳ね返って、当り判定をしない時間を作るだけじゃあ、
ダメなんですよね（一番、使う方法）。
物体のスピードによっては、
壁の真下に物体が落ちる時もあるので、

壁の真下でガンガンいって止まることになります。

無理やり押し出したり、跳ね返った後、
当り判定が発生している場所は空中なので、
いろいろやったりと面倒くさいです。

それだけです。すみません。

当り判定としては、しっかりしているんだから、
それぐらいのプログラムは組まないといけません。

思い出してみると、この頃は当り抜けで、
悩まされる事がなかったなあと思います。

今はいろいろ大きくなって、調べるのも大変です。

では今も使えば？と思われるかもしれませんが、
完全に３Ｄになった今では不可能な技ですね。

使えないわけではありませんが、
完全３Ｄでは使うにも、かなり面倒だったりします。

じゃあ、２Ｄのプログラム限定で使えばと思われますが、
デザイナーさんに、当りデータを作ってくれと言ったら、

二度手間で、間違いなく嫌な顔をされるので言えません。

いろいろと波風が立たないように、
生きていく事もコツです（２回目）。

次回は、日記で宣言した通り、
要点だけをまとめた記事１回目を書きたいと思います。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　（とりあずこれ編）

↓記事がおもしろかったらクリックおねがいします。