第九十七回　必要な部分は少しだけ

少しずつ暑くなってきた６月下旬。

何度も言いますが、開発室は寒いです。

クーラーがガンガンについているので、
ホットコーヒーがおいしく感じます。

最初、開発室に来た時に、
長袖を着ている人が多いのは不健康な人が多いから
（かなり失礼で、かなりの偏見）だと思っていたのですが、

ただ寒かっただけだと、このあたりで気がつきました。

今や冬だろうが夏だろうが長袖は必須です。

夏でも長袖着て、煙草を吸いに行ってるから、
不健康そうに見えるんですね。

まあ、光を浴びると溶ける人が多いので、
不健康な職種だとは思いますが。

勤務時間の半分をバグチェックに、
もう半分をプログラムに回しているミナミですが、

午前は勤務時間の四分の一です。

プログラムの時間と同等の時点でおかしいです。

プログラムの方といえば順調に進んでいませんが、
まあ、バグチェックが始まったという事で、
少し周りがバタバタしてきました。

実は少しホッとしていたりします。

ホッしてなんていたらダメなんですが。

現状は表示の方は全体的にできた感じです。
もちろん、まだ表示しないとダメな物はありますが、
最低限度の表示はできたので、止まっていれば

ゲームに見えます。

スクリーンショット（開発中）っぽいです。

次に作るのは、メインの物体の動きです。
ちなみにかなり作っているゲームをぼやけて書いてますが、
（物体とかアクションゲームとか書いてますが）
少し細かく書くだけで、何を作っているのかわかるので、

お許しください。

いや、本当にすぐわかる。

メインの物体を表示させて、簡単な動きをつける時、
パラメーター系以外のＯＢＪ表示なしだと、

かなりシュールな絵になります。

メインの物体がポツンと１個。

寂し過ぎます。

メインに簡単な動きをつけたら、今度はマップとの当り判定。
前に作った当り判定とは別のを作ります。

前に作った当り判定は通過判定用。
簡単に言えば、その部分を通過したかどうかの当り判定のみで、
跳ね返ったりする用ではありません。

今回の当り判定はBitmapデーターから判別するという方式を
取らないとダメなようですが・・・・・・・

実は専門学校時代に無視した範囲なのです。

こんな所で使うのか！！

やっぱりいろいろやっておくべきですね。

専門学校時代に当り判定の種類を講師に教えてもらっていたのですが、
その時にこの方法がありました。

もちろん面倒そうだったので却下しましたが。

さて、ここで大事なのはデーターを読んでくるということ。
つまり、文字を読んで数値だけをテキストから抜いてくるわけですが、

Ｃ言語でやるのは、かなり面倒です。

Ｃ言語だけでなんとかなるとは思っていますが、
Ｃ言語でも、この部分だけは面倒です。

なら、別の言語でやればいいだろうという話なのですが、
何を考えてたかわかりませんが、ミナミはＣ言語でやろうとします。

面倒でもユーザーにはわからないし、
力技で何とかなるならいいじゃないか

とも、思うかも知れませんが（たぶん、当時のミナミはそう思っていた）
これは間違っていたりします。

BitMapデータですが、結構、膨大な量でして、

文字だけとはいえ、数十キロバイトしたりする物もあります。

しかし、使うと言えば、数キロバイト程度。

それなのに全部を持ってくるとは何事だ！！

容量はいくら余裕があるとはいえ、
いつでも軽い方がいいのです。

必要な部分だけ抜き出して、
自分で配列に置き換えるのが普通なのですが、
文字を読んでくるだけで精一杯なミナミには、

そんな事は考えられませんでした。

というか、読んで来た文字をアウトプリントするのが、
よくわかっていなかったという話もありますが。

数年後に作り直した時には、
きちんとツールを作って、抜き出した物を配列化しました。

つい先日、再び作り直しましたけどね。

数作は上の状態でやっていたので、
それこそ無駄に容量を使っていました。

「僕の所は、もう容量削れませんね！」

とか言っていましたが、

どうやら思いっきり削れていたようです。

では、このBitMapデータからの当り判定の細かい話は次回に続きます。
今回は短いですが、たぶんこの話をすると長くなると思うので。

しかし、当り判定の方法っていろいろありますね。

でも当り判定のプログラムほど、面白くない物は・・・・・・・

だって当り判定のバグの報告が一番多いんですもの！！

何回やっても、何回やっても・・・・・・

　　　　　　　　　　　　　　　　　　　　　　　　　　　　（素直に感心編へ）

日記：当り判定が直せない　作詞：大阪ミナミ

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