坂道の当たり判定を作っています。

フォーラム(掲示板)ルール
フォーラム(掲示板)ルールはこちら  ※コードを貼り付ける場合は [code][/code] で囲って下さい。詳しくはこちら
ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#101

投稿記事 by ISLe » 3年前

オフトピック
CPlayer::GroundFlagがオンのときCPlayerは地上にいるように振る舞う。
CPlayerはCPlayer::GroundFlagによってのみ振る舞いを変える。
これは前提。

現状、座標補正によって、当たり判定の範囲外に移動するため、フレームごとにCPlayer::GroundFlagのオン/オフが繰り返される状況。
キャラの足元にブロックがあるあいだ、CPlayer::GroundFlagがオンのまま維持されて欲しい。

当たり判定の範囲と、めり込んでいるとする範囲をずらすという方法がある。
選択肢の一つであり何が正解というわけでないが、シンプルだし、現状においては変更点も少なく済む。

キャラの足元、1ピクセル重なってブロックがある場合
当たっている。が、めり込んでいない
キャラの足元、2ピクセル重なってブロックがある場合
当たっている。1ピクセルめり込んでいるとみなして押し戻す
というふうにする。

接しているかどうか判定するのは難しいけれど、重なっているかどうかなら簡単。

アバター
keito94
記事: 264
登録日時: 3年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#102

投稿記事 by keito94 » 3年前

ISLe さんが書きました: 正に舌の根の乾かぬうちにってやつですね。
そうです…。
ISLe さんが書きました: CPlayer::Moveから除けたいのは、あたり判定(を直接呼び出している)部分。
もしかしてこうではないのでしょうか?
ISLe さんが書きました: 現状、座標補正によって、当たり判定の範囲外に移動するため、フレームごとにCPlayer::GroundFlagのオン/オフが繰り返される状況。
キャラの足元にブロックがあるあいだ、CPlayer::GroundFlagがオンのまま維持されて欲しい。
たしかにそれは言えている…。

たしかにそうなんですよね…。
添付ファイル
Collision.zip
(6.38 KiB) ダウンロード数: 103 回
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。

ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#103

投稿記事 by ISLe » 3年前

(※下線加筆)
ISLe さんが書きました:No.67に書きました。
CPlayer::Moveから除けたいのは、あたり判定(を直接呼び出している)部分

カオス過ぎていますぐそれはできないので、少しずつ改善しようとしているところ、ことごとく先回りして改善の芽を潰す。
ある意味keito94さんの才能かもしれませんね。
これ、いますぐやっちゃダメって読めないですかね。
わたしの文章がおかしいのかな。


あと、不思議な文言があるのに気づきました。
#前後のインパクトのほうが大きかったもので
keito94 さんが書きました:No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、
上下の当たり判定で、めり込んで左の壁まで行ってしまいます。
「左右の当たり判定の部分は完成した」?


コードは完成していて、動作は理想と違う
というのがkeito94さんの最終形なのでしょう。
少なくともkeito94さんの態度が改まらない限りそこから変化しないと思います。


keito94さんとわたしでは世界線が違う。
keito94さんとわたしがやり取りを続けても収束しません。
わたしがここ数回オフトピで投稿しているのはわたしの世界線を収束させるためのものです。

ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#104

投稿記事 by ISLe » 3年前

オフトピック
坂道に沿って上り下りするというのは、キャラを基準に移動するだけでなくプラスアルファが必要。
特に坂道を下るのは、補正に頼るとキャラが浮いてしまったりしてうまくない。
#逆にそれが活きるデザインもあるが。

なので、坂道の上り下りの際は、キャラを主体ではなく客体とする。
どういうことかと言うと…
・坂に入ったら、キャラは見えない動く床に乗った状態になる
・ユーザーの操作で動くのは見えない床で、キャラはその床に対して位置を保ちつつ、その場で足踏み
・坂道の端を超えて移動するあるいは途中でジャンプするなど坂道を離れたら、見えない動く床は消滅し、キャラは通常運転に戻る
という具合。

もちろんこれも方法の一つに過ぎず正解というものではない。

この方法のメリットは…
・動く床やエレベーター、エスカレーターなど応用できる(というかこちらから発想を得ている)
・コース設定次第で波やループなどどんな形状にも対応できる
・応用の幅を広げてもキャラの実装が重くならない

アバター
keito94
記事: 264
登録日時: 3年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#105

投稿記事 by keito94 » 3年前

すいませんでした…。
正確には当たり判定のコード自体は完成していたのですが、
なかなか理想通りの動きになりません…。
どうしたら、理想通りの動き(地上にいるときだけGroundFlagがtrueになったまま)になるのでしょうか?
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。

ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#106

投稿記事 by ISLe » 3年前

keito94 さんが書きました:正確には当たり判定のコード自体は完成していたのですが、
例えば、CCollision::GetXPosition関数の中にあるコード…
(Collision.cpp:267行目~)

コード:

		if (block.x < *myx) {
			*myx = (float)((block.x - 1) * 16 + 8 + OffsetR - 0.1f);
		}
block.xは、左端のブロックを0番目として右へ何個目かという数値が入ってます。
*myxは、キャラの中心のX座標がピクセル単位で入ってます。
まったく意味の違う数値を比較しているこのコード、正しいですか?
keito94 さんが書きました:なかなか理想通りの動きになりません…。
どうしたら、理想通りの動き(地上にいるときだけGroundFlagがtrueになったまま)になるのでしょうか?
どうすればいいか(あるいはそのためのヒント)は既にNo.98,No.101に(さらにそれ以降も)書きました。
ですが、どうしたらkeito94さんが理解できるかはわたしには分かりません。

アバター
keito94
記事: 264
登録日時: 3年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#107

投稿記事 by keito94 » 3年前

ISLeさんのご指摘を受けて、ブロックの単位ではなく、座標で判定して見るようにしてみました。
でも、また新たなバグが発生してしまいました…。
実行すると、着地せずに画面外に落下します。
添付ファイル
Collision.zip
(6.43 KiB) ダウンロード数: 92 回
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。

ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#108

投稿記事 by ISLe » 3年前

keito94 さんが書きました:ISLeさんのご指摘を受けて、ブロックの単位ではなく、座標で判定して見るようにしてみました。
CCollision::GetXPosition関数内
Collision.cpp:267行目~

コード:

		int bpos = block.x * 16;
		int brpos = bpos + 32;
		int blpos = bpos - 32;
		bool Debug = true;
		if (brpos < *myx) {
			*myx = (float)((block.x - 1) * 16 + 8 + OffsetR - 0.1f);
		}
		if (blpos > *myx) {
			*myx = (float)((block.x + 1) * 16 + 8 + OffsetL + 0.1f);
		}
CCollision::GetYPosition関数内
Collision.cpp:297行目~

コード:

		int bpos = block.y * 16;
		int bbpos = bpos - 8;
		int btpos = bpos + 8;
		bool Debug = true;
		if (bbpos < *myy) {
			*myy = (float)((block.y - 1) * 16 + 8 + OffsetD - 0.1f);
			*jcount = 0;
			*gflag = true;
		}
		if (btpos > *myy) {	
			*myy = (float)((block.y + 1) * 16 + 8 + OffsetU + 0.1f);
		}
CCollision::GetXPositionでは32を足したり引いたり、CCollision::GetYPositionでは8を足したり引いたり…
どんな意味があるんです?
keito94 さんが書きました:でも、また新たなバグが発生してしまいました…。
実行すると、着地せずに画面外に落下します。
デバッグすれば、CCollision::GetXPositionでもCCollision::GetYPositionでも、ifの条件が両方同時に成立していることが確認できるはずですが。
このコードでは、画面外に消えるのが正常。


keito94さんは、トピにしてもコードにしても見直すのがめんどうくさいのでしょうか。
デバッグするのもめんどうくさいですか?
もしそうなら、プログラミングが好きではないのでしょう。

好きでもないのにプログラミングするのはつらいだけなのでやめたほうがいい。
仕事でないならプログラミングできなくて困るわけでもないでしょう。


あと、ゲームを好きでもないのにゲームを作ろうとするのもやめたほうがいい。
キャラをどう動かしていいか分からない、のでなくて、そもそもキャラがどう動くか知らないでしょう。
プログラミングできなくても既存ゲームをプレイして研究するとかはできますよね。
ゲームをプレイするのはめんどうくさいですか?

自分の作ってるゲームがどう動いているかにも興味ないですものね。

アバター
keito94
記事: 264
登録日時: 3年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#109

投稿記事 by keito94 » 3年前

ブロックの座標で当たり判定を実装しようとしています。
現在考えているのは、衝突したら一ブロックずらした座標で判定するということです。
(キャラの座標が中央基準なので…。)
ですが、地上に着地せずにめり込んで左に移動してしまいます。
左右の判定は一応完成しました。
添付ファイル
Collision.zip
(6.43 KiB) ダウンロード数: 105 回
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。

ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#110

投稿記事 by ISLe » 3年前

keito94 さんが書きました:現在考えているのは、衝突したら一ブロックずらした座標で判定するということです。
(キャラの座標が中央基準なので…。)
ですが、地上に着地せずにめり込んで左に移動してしまいます。
ブロックが等間隔に並んでいることが前提条件になりますよね。
わざわざブロックが等間隔に並んでいないといけなくするメリットって何でしょう。
オフトピック
むしろ、坂道を実装するには邪魔になりそうな前提条件は排除していきたいが。
そもそも、衝突したブロックの左にあるブロックがキャラより左にあって、衝突したブロックの右にあるブロックがキャラより右にある、というのは当たり前。
こちらも同時に成立する条件。
あいだにelseを入れたので、前回は常に右へ下へだったのが、今回は常に左へ上へとなった。
それだけ。
本質的に何も変わってない。
keito94 さんが書きました:左右の判定は一応完成しました。
そうですか。
おつかれさまでした。

ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#111

投稿記事 by ISLe » 3年前

keito94 さんが書きました:ですが、地上に着地せずにめり込んで左に移動してしまいます。
添付されているソースファイルは、そうならないようにCPlayer::GroundFlag書き換えている箇所を移動してますね。
どうしてでしょうね。

アバター
keito94
記事: 264
登録日時: 3年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#112

投稿記事 by keito94 » 3年前

ISLe さんが書きました: むしろ、坂道を実装するには邪魔になりそうな前提条件は排除していきたいが。
どうやって排除するのですか?
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。

ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#113

投稿記事 by ISLe » 3年前

keito94さんは、“坂道を実装するには邪魔になりそうな前提条件”が何なのか分かっているのでしょうか。
分かっていないなら、差し当たって、目の前のコードを理解するところから始めましょう。
分かっているなら、どこがどうして問題なのか、説明して見せてください。

どうやって排除するか、を考えるのはそのあとです。

アバター
keito94
記事: 264
登録日時: 3年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#114

投稿記事 by keito94 » 3年前

ISLe さんが書きました: 分かっているなら、どこがどうして問題なのか、説明して見せてください。
その問題というのは、CheckMapや、マップチップを確認する部分にあります。
ブロックを左から何個目にあるかを判定する都合上、動いているブロックやキャラのX座標の位置がずれることが前提の上下の当たり判定で、
(今のコードでは)左へ上へ行ってしまうバグが起きてしまうことです。
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。

ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#115

投稿記事 by ISLe » 3年前

分かっている、を選択しておいて、分かっていませんね。

キャラはピクセル単位で動くのだから、ピクセル単位で座標がずれるのは最初から想定内ですよ。
keito94 さんが書きました:(今のコードでは)左へ上へ行ってしまうバグが起きてしまうことです。
そうなるようにコードを書き換えたのはkeito94さんですよ。
keito94 さんが書きました:その問題というのは、CheckMapや、マップチップを確認する部分にあります。
「どこが」はまあ合ってますけど、たまたまですかね。

“坂道を実装するには邪魔になりそうな前提条件”は、たぶんkeito94さんが完璧だと思っているところ、にありますよ。

ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#116

投稿記事 by ISLe » 3年前

オフトピック
そういえば、No.47でリンクしたトピで、ブロックに当たったら当たる前の座標に戻す、という方針を採用する方向だったはずだけど、いまのコードには欠片も見当たらない。

当たる前の座標に戻せば、当たっていない状態に戻る、というのが悪魔の証明なので、それ以降スルーしてたのに。
前提条件がなければ、当たっていないとすることを保証できないのだから。

前提条件を積み重ねたコードはトピが解決してもずっと爆弾抱えたまま。

アバター
keito94
記事: 264
登録日時: 3年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#117

投稿記事 by keito94 » 3年前

ISLe さんが書きました: “坂道を実装するには邪魔になりそうな前提条件”は、たぶんkeito94さんが完璧だと思っているところ、にありますよ。
もしかしてめり込み防止の部分ですか?
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。

ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#118

投稿記事 by ISLe » 3年前

keito94 さんが書きました:もしかしてめり込み防止の部分ですか?
「もしかして」?
あてずっぽうですか?
あてずっぽうであたったとして何の意味があるんでしょう。

場所はCCollision::CheckMapで合ってると書いたのに。
#そこだけとは言ってないけど

ひとつは、ブロックとキャラが当たってるかどうか調べるのに、縁を何点かだけ調べているところですよ。
これは、ブロックが固定で等間隔に並んでいて、尚且つキャラとブロックが同一サイズというのが前提になる。
#keito94さんサイズ変えたらうまくいかないっていう質問を前にしてましたよね。

この前提では、ブロックがあるところは、全面ブロックである。
だから、ピクセル座標とブロック単位の座標が混在してもテキトーに誤魔化せてしまう。

いま実装しようとしてる坂道は、45度傾いていて、当たり判定のあるところとないところが半々に交じってる。
前提から外れたことを同じやり方でやろうとしたらどうなりますかね。

アバター
keito94
記事: 264
登録日時: 3年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#119

投稿記事 by keito94 » 3年前

ISLe さんが書きました: 場所はCCollision::CheckMapで合ってると書いたのに。
ごめんなさい…やっぱりあってたんですね…
ISLe さんが書きました: 前提から外れたことを同じやり方でやろうとしたらどうなりますかね。
そりゃ、バグが発生するわけですね…。
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。

アバター
keito94
記事: 264
登録日時: 3年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#120

投稿記事 by keito94 » 3年前

オフトピック
今思うと問題点だらけだったんだな…。
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。

アバター
keito94
記事: 264
登録日時: 3年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#121

投稿記事 by keito94 » 3年前

>>ISLeさん
…つまり、何が言いたいんですか?
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。

ISLe
記事: 2648
登録日時: 9年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#122

投稿記事 by ISLe » 3年前

ブロックとキャラの当たり判定を書き直す必要がある、ということですよ。

keito94さんは、そこで使うべき方法を既に知っています。
RECT型の当たり判定について
こんどは返信がもらえるように頑張りましょう。

坂道の実装までまだまだ遠いので、新たにトピたてて仕切り直したほうが良いかもしれません。

アバター
keito94
記事: 264
登録日時: 3年前
連絡を取る:

Re: 坂道の当たり判定を作っています。

#123

投稿記事 by keito94 » 3年前

ISLe さんが書きました:ブロックとキャラの当たり判定を書き直す必要がある、ということですよ。

keito94さんは、そこで使うべき方法を既に知っています。
RECT型の当たり判定について
こんどは返信がもらえるように頑張りましょう。

坂道の実装までまだまだ遠いので、新たにトピたてて仕切り直したほうが良いかもしれません。
了解しました!
一応この記事は今度こそ解決とさせてください!!
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。

返信

“C言語何でも質問掲示板” へ戻る