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

フォーラム(掲示板)ルール
フォーラム(掲示板)ルールはこちら  ※コードを貼り付ける場合は [code][/code] で囲って下さい。詳しくはこちら

トピックに返信する


答えを正確にご入力ください。答えられるかどうかでスパムボットか否かを判定します。

BBCode: ON
[img]: ON
[flash]: OFF
[url]: ON
スマイリー: OFF

トピックのレビュー
   

展開ビュー トピックのレビュー: 坂道の当たり判定を作っています。

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

#123

by keito94 » 6年前

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

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

坂道の実装までまだまだ遠いので、新たにトピたてて仕切り直したほうが良いかもしれません。
了解しました!
一応この記事は今度こそ解決とさせてください!!

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

#122

by ISLe » 6年前

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

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

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

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

#121

by keito94 » 6年前

>>ISLeさん
…つまり、何が言いたいんですか?

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

#120

by keito94 » 6年前

オフトピック
今思うと問題点だらけだったんだな…。

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

#119

by keito94 » 6年前

ISLe さんが書きました: 場所はCCollision::CheckMapで合ってると書いたのに。
ごめんなさい…やっぱりあってたんですね…
ISLe さんが書きました: 前提から外れたことを同じやり方でやろうとしたらどうなりますかね。
そりゃ、バグが発生するわけですね…。

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

#118

by ISLe » 6年前

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

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

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

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

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

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

#117

by keito94 » 6年前

ISLe さんが書きました: “坂道を実装するには邪魔になりそうな前提条件”は、たぶんkeito94さんが完璧だと思っているところ、にありますよ。
もしかしてめり込み防止の部分ですか?

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

#116

by ISLe » 6年前

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

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

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

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

#115

by ISLe » 6年前

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

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

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

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

#114

by keito94 » 6年前

ISLe さんが書きました: 分かっているなら、どこがどうして問題なのか、説明して見せてください。
その問題というのは、CheckMapや、マップチップを確認する部分にあります。
ブロックを左から何個目にあるかを判定する都合上、動いているブロックやキャラのX座標の位置がずれることが前提の上下の当たり判定で、
(今のコードでは)左へ上へ行ってしまうバグが起きてしまうことです。

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

#113

by ISLe » 6年前

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

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

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

#112

by keito94 » 6年前

ISLe さんが書きました: むしろ、坂道を実装するには邪魔になりそうな前提条件は排除していきたいが。
どうやって排除するのですか?

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

#111

by ISLe » 6年前

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

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

#110

by ISLe » 6年前

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

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

#109

by keito94 » 6年前

ブロックの座標で当たり判定を実装しようとしています。
現在考えているのは、衝突したら一ブロックずらした座標で判定するということです。
(キャラの座標が中央基準なので…。)
ですが、地上に着地せずにめり込んで左に移動してしまいます。
左右の判定は一応完成しました。
添付ファイル
Collision.zip
(6.43 KiB) ダウンロード数: 301 回

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

#108

by ISLe » 6年前

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

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


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

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

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

#107

by keito94 » 6年前

ISLeさんのご指摘を受けて、ブロックの単位ではなく、座標で判定して見るようにしてみました。
でも、また新たなバグが発生してしまいました…。
実行すると、着地せずに画面外に落下します。
添付ファイル
Collision.zip
(6.43 KiB) ダウンロード数: 292 回

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

#106

by ISLe » 6年前

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さんが理解できるかはわたしには分かりません。

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

#105

by keito94 » 6年前

すいませんでした…。
正確には当たり判定のコード自体は完成していたのですが、
なかなか理想通りの動きになりません…。
どうしたら、理想通りの動き(地上にいるときだけGroundFlagがtrueになったまま)になるのでしょうか?

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

#104

by ISLe » 6年前

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

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

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

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

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

#103

by ISLe » 6年前

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

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


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


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


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

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

#102

by keito94 » 6年前

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

たしかにそうなんですよね…。
添付ファイル
Collision.zip
(6.38 KiB) ダウンロード数: 304 回

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

#101

by ISLe » 6年前

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

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

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

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

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

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

#100

by ISLe » 6年前

keito94 さんが書きました:後、重力の部分を分割してみました。
これ、何か目的があるんですよね。
コードに手を加えるというのは、バグを生む可能性を含みます。
プログラムを台無しにするのと引き換えにしてもいいくらい意味のあることなんでしょうね。
ちょっと分からないので説明していただけませんか。


もし、万が一、意味もなくやったのだとしたら…
(※下線加筆)
keito94 さんが書きました:ごめんなさい、座標をずらす部分をむやみにいじってしまいました…
No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、
上下の当たり判定で、めり込んで左の壁まで行ってしまいます。
後、重力の部分を分割してみました。
正に舌の根の乾かぬうちにってやつですね。


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

カオス過ぎていますぐそれはできないので、少しずつ改善しようとしているところ、ことごとく先回りして改善の芽を潰す。
ある意味keito94さんの才能かもしれませんね。

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

#99

by keito94 » 6年前

ISLe さんが書きました: タイルのサイズは16ピクセルであるのに、-8~8という範囲(=17ピクセル)を使って重要な判定をしている。
今の発言を受けて、当たり判定のサイズを変更してみました。
添付ファイル
Collision.zip
(5.45 KiB) ダウンロード数: 337 回

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

#98

by ISLe » 6年前

オフトピック
現時点で気になることを書き残しておきます。

CCollision::GetXPosition関数などで、キャラ座標はピクセル単位でブロックはタイル単位と異なる座標系が混在しており、さらにキャラ座標は中心が基準となっているところに、さらにx,yなど数値をバラバラにやり取りしているため混乱に拍車をかけている。

タイルのサイズは16ピクセルであるのに、-8~8という範囲(=17ピクセル)を使って重要な判定をしている。

座標およびサイズ情報と当たり判定メソッド(のプロトタイプ)を持つCMoverクラスがあるのに、どうしてそれを使わないのだろうか。
CPlayerはCMoverを継承しているのに、どうしてわざわざ情報をバラバラにして引数に渡すのだろうか。

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

#97

by keito94 » 6年前

ごめんなさい、座標をずらす部分をむやみにいじってしまいました…
No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、
上下の当たり判定で、めり込んで左の壁まで行ってしまいます。
後、重力の部分を分割してみました。
添付ファイル
Collision.zip
(5.45 KiB) ダウンロード数: 338 回

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

#96

by ISLe » 6年前

keito94 さんが書きました:壁に当たった時、キャラをずらすアルゴリズムの例を上げてくれますか。
これはつまり…
CCollision::GetXPosition関数にある(あった)
*myx = (float)((block.x - 1) * 16 + 8 + OffsetR - 0.1f);
*myx = (float)((block.x + 1) * 16 + 8 + OffsetL + 0.1f);
とか
CCollision::GetYPosition関数にある(あった)
*myy = (float)((block.y + 1) * 16 + 8 + OffsetU + 0.1f);
*myy = (float)((block.y - 1) * 16 + 8 + OffsetD - 0.1f);
という文がそれであるということを認識する気もないっていう意味ですかね。
認識すらする気がないのにどうやったら、例をあげて示すことができるんですかね。
これ(↑)がそれですよ、ってのはkeito94さんが望む例ではないですよね。
これは何かの哲学ですかね。

keito94 さんが書きました:とりあえず、No.81で言われた方法にしてみました。
現在確認されているバグは、
  • 着地すると、キャラがぴょんぴょん跳ねる。
  • 左の壁に衝突すると、キャラが上に上がる。
となります。
というわけで、No.81で言った方法になってない(不十分)です。

既存のコードを理解すればそのバグは直せるはずですが。



keito94さんは、いつになったらプログラミングやデバッグを始めるつもりなんですか?
無意味で無関係なコードがまた復活してたり、認識してないはずのコードがテキトーに変更されてますけど。

コードの切り貼りしたいだけなら、結果がどうあれ、その状況を楽しめばいいんじゃないでしょうか。
そういうことなら、他人に正解(?)を求めるのは楽しみ方として間違っていると思います。
巻き込まないでください。
オフトピック
同じことを3回繰り返したら、もはやサンプルとしての価値もない。

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

#95

by keito94 » 6年前

とりあえず、No.81で言われた方法にしてみました。
現在確認されているバグは、
  • 着地すると、キャラがぴょんぴょん跳ねる。
  • 左の壁に衝突すると、キャラが上に上がる。
となります。
壁に当たった時、キャラをずらすアルゴリズムの例を上げてくれますか。
添付ファイル
Collision.zip
(5.42 KiB) ダウンロード数: 309 回

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

#94

by ISLe » 6年前

keito94 さんが書きました:なん…だと…。地上にいるというのは振る舞いだけだったのか…。
『CPlayerは』『CPlayer::GroundFlagによってのみ』振る舞いを変えることでCPlayerの独立性が高まります。
CPlayer::GroundFlagの変化とは無関係になるので、キャラの挙動と、ブロックのあたり判定それぞれ別々にデバッグが可能になる。

という内容のことをNo.47で書いているんですけどね。
当時は理解できなかったとしても今は理解できるかもしれない。
何回も読み直して理解しようという気はないのでしょうか。

あと、バグの原因の特定も容易になる。
挙動の変化がおかしいならCPlayer::GroundFlagを書き換えている場所を探せばいい。
#CCollisionが直接書き換えているから問題をややこしくしているけども、まあそこは後回しでいい。


ISLe さんが書きました:今度こそ取り除かれたのではないのでしょうか?
余計なことをしなければ、No.74で達成できていたのに。



で、次にやるべきことは既に示されている(No.81,92)わけですが?

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

#93

by keito94 » 6年前

ISLe さんが書きました: キャラが地面にめり込むと地面に触れないぎりぎりの位置に座標補正されます。
次のフレームで、それは地上に立っていることになるのでしょうか。
なん…だと…。地上にいるというのは振る舞いだけだったのか…。
ISLe さんが書きました: 前に一度CCollision::GetMoveからも取り除かれたのに、今は復活してますね。
今度こそ取り除かれたのではないのでしょうか?
添付ファイル
Collision.zip
(5.38 KiB) ダウンロード数: 298 回

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

#92

by ISLe » 6年前

keito94 さんが書きました:現在は移動量に依存していた部分を取り除いたところです。
前に一度CCollision::GetMoveからも取り除かれたのに、今は復活してますね。
keito94 さんが書きました:CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。(混乱を招く回答すいません…。)
それはわたしがNo.84で書いた表現をなぞっているだけですね。

No.84では、それに対する問題の指摘も同時にしているのですが、理解できませんでしたか?
No.85を見たら理解しようという気概を感じられませんけどね。



画面右端のブロックに触れると右外に消えてしまう問題については、さらに前のNo.81で既に書いてます。
keito94さんが方針変更されると思ったのでオフトピになってますが。

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

#91

by keito94 » 6年前

ちなみに、これが現在のコードです。
現在は移動量に依存していた部分を取り除いたところです。実行しても、落下状態にあるので、めり込んでしまいます。
CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。(混乱を招く回答すいません…。)
添付ファイル
Collision.zip
(5.4 KiB) ダウンロード数: 277 回

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

#90

by keito94 » 6年前

ISLe さんが書きました: 移動量撤廃の方針を続けるならこのトピで続ければよいのでは。
ごめんなさい、解決を撤回させてください。この方針を続けようと思います。

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

#89

by keito94 » 6年前

オフトピック
とんでもない勘違いをしてしまった…。

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

#88

by keito94 » 6年前

解決させたのは撤回させてください。
移動量撤廃を続けたいと思います。

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

#87

by ISLe » 6年前

移動量撤廃の方針を続けるならこのトピで続ければよいのでは。

移動量を使うなら、元の木阿弥だという意味ですよ。
同じことの繰り返し。
新しいトピを立てても同じ内容のトピができるだけだと思うけども。

そもそもkeito94さんがこのトピを読み直しているようすが見えない。

わたしがkeito94さんのアップロードしたソースコードを過去の分も全部保存して、返信する都度、比較してここが変わったあそこが変わった、また同じことしてるだの、というふうなことをしているわけだけども。

別に、わたしが苦労しているのを分かれだとか、何かを押し付けようというつもりはないよ。

最低限そのくらいしないと内容を理解できないだろってこと。

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

#86

by keito94 » 6年前

http://dixq.net/forum/viewtopic.php?f=3&t=19267
一からトピックをやり直してみました。
これ以降のめり込みなどに関する質問はここに書き込んでください。
この件は一応解決とさせていただきます。

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

#85

by keito94 » 6年前

ISLe さんが書きました: コードを上から下になぞるだけでなく、実際に動いているときの流れを意識してください。
はーい、わかりました。

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

#84

by ISLe » 6年前

keito94さんは、CPlayer::GroundFlagが真のとき、地上に立っている状態と説明しました。

CPlayer::GroundFlagが真のとき、キャラは地上に立っているように振る舞います。
そこでは、実際にキャラが地上に居るかどうかは関係ありません。

キャラが地面にめり込むと地面に触れないぎりぎりの位置に座標補正されます。
次のフレームで、それは地上に立っていることになるのでしょうか。


コードを上から下になぞるだけでなく、実際に動いているときの流れを意識してください。

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

#83

by ISLe » 6年前

オフトピック
そろそろXとYで関数を分ける必要もない段階まできてたわけだけども。
そうなると、
めり込みを許容して押し戻すマリオ(ブラザーズ)タイプ

めり込みを許容せず一気に移動のロックマンタイプ
を選択する余地も生まれるのだけども。

マリオ(ブラザーズ)タイプ、ロックマンタイプってのはわたしが勝手に分類して言ってるだけだけども。

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

#82

by keito94 » 6年前

ISLe さんが書きました: #むしろ無限ループを楽しんでください。
それはやだやだ!!!
ISLe さんが書きました: 移動量を使わないでどうやって判定するのか?といういちばんのキモを質問しないのですね。
やっとここまで問題点をピンポイントであぶり出せたのに。
ごめんなさい、その質問をしようと思っていたところでした…。
ISLe さんが書きました: 間違った理解でコードをいじるからおかしなことになるのと違いますか。
ごめんなさい、ちゃんとソースコードをしっかり読んでからやりたいと思います…。

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

#81

by ISLe » 6年前

オフトピック
いちおう移動量を使わない方法を書いておきます。

めり込んでいる対象のブロックは分かっているので、ブロックの座標とキャラの座標を比較して、どちらにずらしたほうが良いか決定します。

移動量で決めると、例えばトンネル状のマップを抜けるとき、うっかりジャンプして天井ブロックに触れると、一気に入り口まで戻されるという現象が発生します。

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

#80

by ISLe » 6年前

No.76のkeito94さんが書いたCPlayer::GroundFlagの説明は正しいのでしょうか。
間違った理解でコードをいじるからおかしなことになるのと違いますか。
そもそも、コードに「~となるはず」なんてコメントありえません。
引き算のつもりで足し算書いたのをPCが忖度して直してくれるはずもない。

- + - + -

引数の移動量が復活してますね。
ここにきて、移動量撤廃の方針をひっくり返しますか。

移動量を使わないでどうやって判定するのか?といういちばんのキモを質問しないのですね。
やっとここまで問題点をピンポイントであぶり出せたのに。

いや、別にいいんですよ。
どういう方針を選ぶかはkeito94さんの自由ですから。
ただ、そちらを選ぶのなら、わたしはもうサポートできません(しません)。

画面右外に消えてしまう原因を見付けて、直したのでしょう。
わたしが提案する方針よりも、最初に見付けたサンプルコードのやり方を優先した。

それだと坂道の実装でうまくないからこのトピができたのではないかと思うのですが…
少なくともこのトピの内容を一からやり直すことは確定ですね。
絶対不可能というわけではないと思うので、無限ループにならないように、頑張ってください。
#むしろ無限ループを楽しんでください。

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

#79

by keito94 » 6年前

新たなバグを発見しました。地上にいる時は、Y座標の移動量を0にしようとしているつもりなのですが、
ブレークポイント無しで実行するとソースコードに書いてあるバグが発生して、地面にめり込んだ状態になります。
原因はどこにあるのでしょうか?また仕込んだのではないのでしょうか?
添付ファイル
Collision.zip
(5.55 KiB) ダウンロード数: 364 回

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

#78

by ISLe » 6年前

オフトピック
クラスやメンバなどの役割りを決め、その役割り通りに且つ役割りを発揮できるように構成を考え、それらを繰り返し練っていく、というのがプログラミングの本質であると思う。
コーディングは、それのアウトプットに過ぎない。
いきなりコーディングという場合でも、過程においてのコーディングは思考を補助する役割りであると思う。

役割りを考えず、役割りに基づいてコードを書いていないのであれば、それはプログラミングではない。
プログラミング言語を使ったラクガキだ。

ラクガキだから楽しいというのはあるかもしれない。
であればラクガキを楽しめばいい。

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

#77

by ISLe » 6年前

keito94 さんが書きました:CCollisionと言うのは当たり判定の処理を行うクラスです。
それはCCollisionの説明になっていませんね。
CPlayerも当たり判定の処理をしてますよね。CCollisionのメソッドを呼び出しているから。
もっと言えば、このプログラム自体も当たり判定の処理をしてますよね。
そんな中でCCollisionの役割りとは何なんですか?

それを説明できないから何でもかんでもCCollisionでやろうとしてCCollisionがないと動かないコードになってしまうのでしょう。

keito94 さんが書きました:CPlayer::GroundFlagと言うのは、キャラが地上に居るかどうかを管理する変数です。
CPlayerで移動処理をして、CCollisionで当たり判定をチェックします。
ジャンプした、もしくは空中にいる時はGroundFlagが偽になります。
地上にいる時はGroundFlagが真になります。
GroundFlagが真になっている時は落下を行わないはずです。
これで間違いないですよね?
CPlayer::Moveにはキャラが空中にいてもGroundFlagを真にするコードがありますよ。
keito94さん自身が最近追加したコードですよね。
説明と矛盾してますよ。
この説明は聞かれたから考えたものなのですか?

keito94 さんが書きました:あと、質問用のソースコードをリポジトリに上げてみました。
GitHub云々書いたのは、バージョン管理ソフトを利用すれば変更の取り消しとか楽になると思ったからです。
まあ、公開レポジトリなんかだとコンパイルエラーがある段階でリビジョン上げるのは良くないのでしょうかね。
オフトピック
わたしは、今回ので例えるとaddy,addx削った時点でレポジトリ更新してコメントにきちんと目的を書き、コンパイルエラーを潰すためであればそれはそれでリビジョンを消費するといった感じに、作業過程を細かく記録します。
そういう使い方だとGitHubは大げさなので、Subversionでローカルレポジトリ作ってやってますけどね。
リポジトリとしてはひどいものだけど、開発の過程を見る・知る資料として有用である気がしてます。
keito94 さんが書きました:追記:今のコードで確認されている不具合は、左の当たり判定と、右の当たり判定が同時に出ていることと、落下を全くしないことと坂道を登りきると、
キャラが消えてしまうことです。
あとジャンプボタン押してもジャンプしませんね。

キャラが消えてしまうというのは、画面の右端のブロックに触れた時点で座標補正されて画面の右側の外に消えるということですかね。
こちらで確認してみた限りでは坂道を登りきるだけでは消えないみたいですが。
ブレークポイント使ったりトレース実行したり、変数の値をウォッチしたりというデバッグはしていないのでしょうか。

それらの不具合は全部No.71のあとからNo.74までのあいだに発生したものですよね。
keito94さん自身が仕込んだもので、環境依存等で勝手に生まれたバグではない。
いちいち頭使って考えなくても、コードの差異を見れば原因の特定は難しくないと思うんですけどね。

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

#76

by keito94 » 6年前

>>ISLeさん
簡単に説明します。
CCollisionと言うのは当たり判定の処理を行うクラスです。
CPlayer::GroundFlagと言うのは、キャラが地上に居るかどうかを管理する変数です。
CPlayerで移動処理をして、CCollisionで当たり判定をチェックします。
ジャンプした、もしくは空中にいる時はGroundFlagが偽になります。
地上にいる時はGroundFlagが真になります。
GroundFlagが真になっている時は落下を行わないはずです。
これで間違いないですよね?
あと、質問用のソースコードをリポジトリに上げてみました。
プロジェクトにこのコードを追加してください。
こちらです。
オフトピック
変にいじると大変なことになるのね…。
追記:今のコードで確認されている不具合は、左の当たり判定と、右の当たり判定が同時に出ていることと、落下を全くしないことと坂道を登りきると、
キャラが消えてしまうことです。

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

#75

by ISLe » 6年前

そもそもCCollisionクラスって何なんですか?
クラスの役割りを説明できますか?
説明できないのにただいじくり回しているだけならキリがないのでやめましょう。
ISLe さんが書きました:No.47で書いたように、プレイヤーキャラは、地面に着いているから落下しない、のでなく、(プレイヤーキャラ自身が)落下する状態でないから落下しない、ようにすれば落下しなくなります。
そういう目的に使える情報は既にCPlayerクラスにありますよね。
CPlayer::GroundFlagってありますよね。
CPlayer::GroundFlagって何ですか?
これも役割りを説明できますか?

CCollisionのアウトプットとして、地面に突き上げられてるという情報を得る方法を作るというのであれば分かります。
CCollisionクラスにAirFlagというメンバを追加して、CPlayerがCCollisionを監視しなければならない依存関係を新たに作る意味が分かりません。

それと、新たにバグを仕込みましたねって伝えましたよね。
仕込んだところを直してほしい、というかただコードを元に戻せばいいだけなのですが…
どこが変わったか見れば一目瞭然だと思うんですが。
#GitHubとか何のためにあるのだろう

トピを見直しているようすが見られないところから、自分で考える気がないように見えます。

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

#74

by keito94 » 6年前

ISLe さんが書きました: (プレイヤーキャラ自身が)落下する状態でないから落下しない
それを自分なりに実装してみたのですが、今度はキャラが落下しません。
ジャンプすらできません。何か落下する状態を管理する部分にバグが有るようなのですがそれはどこなのでしょうか?
オフトピック
やっぱりプログラムって大変…。
添付ファイル
Collision.zip
(5.5 KiB) ダウンロード数: 346 回

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

#73

by ISLe » 6年前

keito94 さんが書きました:僕の頭の中のコードでは、どう頑張っても、めり込み補正の部分とY座標の部分で移動量に頼ってしまいます。
なので、移動量に頼らないめり込み防止のサンプルコードをください。
いちいち頭で考えなくても、引数の宣言からaddx,addyをまるまる取り除けば、変更が必要な部分はコンパイラが教えてくれますよ。
keito94 さんが書きました:なお、今上げたコードでは、常に落下しているので、最終的にはキャラが画面外に移動します。
常に落下してしまうのはどうしてなのか、というところに頭を使いましょうよ。

No.47で書いたように、プレイヤーキャラは、地面に着いているから落下しない、のでなく、(プレイヤーキャラ自身が)落下する状態でないから落下しない、ようにすれば落下しなくなります。
そういう目的に使える情報は既にCPlayerクラスにありますよね。

No.70に書いた、削らなくていいところというのは、その情報を書き換えている部分なので、ここでも新たにバグを仕込んでいるというわけです。
きちんと(物理的に)切り分けないとこういうことが頻繁に起きてキリがないのです。

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

#72

by keito94 » 6年前

オフトピック
やっぱり自分でプログラムするのっていいもんなんだな…。

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

#71

by keito94 » 6年前

僕の頭の中のコードでは、どう頑張っても、めり込み補正の部分とY座標の部分で移動量に頼ってしまいます。
なので、移動量に頼らないめり込み防止のサンプルコードをください。
なお、今上げたコードでは、常に落下しているので、最終的にはキャラが画面外に移動します。
添付ファイル
Collision.zip
(5.36 KiB) ダウンロード数: 291 回

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

#70

by ISLe » 6年前

あと、(いまのところ)削らなくていいものまで削ってますね。

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

#69

by ISLe » 6年前

keito94 さんが書きました:ISLeさんが考えている当たり判定のアルゴリズムに変えてみました。
ずいぶん中途半端に変更したのですね。
これをわたしが考えたと言われるのはかなり抵抗あります。
keito94 さんが書きました:addxとaddyを0にしないとまともに動作しません。(このステージでは関係ないんですが…。)
それはそうでしょうね。
わたしがNo.63で書いた、移動量を何回も加算してしまわないだろうか、と懸念していたことを新たにやらかしてます。
このステージでは関係ない…ほんとうにそうでしょうか。
例えば坂道を登りきる前に坂道の判定が消える、ような気がしますが。


もしかして中途半端なのは、CCollision::GetMoveにある落下に関する移動量の処理をどこに移動したらいいか分からなかった(あるいは移動させるのが面倒だった)から、その前後を適当に誤魔化したのでしょうか。

CCollisionから移動量を完全に排除しようという意志が感じられないですね。

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

#68

by keito94 » 6年前

ISLeさんが考えている当たり判定のアルゴリズムに変えてみました。
addxとaddyを0にしないとまともに動作しません。(このステージでは関係ないんですが…。)
オフトピック
なるほど、こうゆうことだったのか…。
添付ファイル
Collision.zip
(4.12 KiB) ダウンロード数: 320 回

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

#67

by ISLe » 6年前

現在位置 p
移動量 a

パターンA

コード:

移動関数() {
 aを生成
 当たり判定と補正を行う関数(p, a) {
  if (p + a がめり込んでいる) {
   pをめり込んでいない位置に補正
   aをリセット
  }
  pにaを加える
 }
}
パターンB

コード:

移動関数() {
 aを生成
 pにaを加える
 当たり判定と補正を行う関数(p) {
  if (p がめり込んでいる) {
   pをめり込んでいない位置に補正
  }
 }
}
パターンA,Bともに結果は同じです。
パターンAは、補正が必要なときに、pをいったん更新するのを避けられます。ただそれだけです。
pを格納する変数が更新されないだけで、計算はしますし、それは当たり判定の対象の数だけ繰り返されます。


純粋に移動だけのテストをしたいと思いました。
なので、それ以外を除外します。

パターンA'

コード:

移動関数() {
 aを生成
}
パターンB'

コード:

移動関数() {
 aを生成
 pにaを加える
}
パターンA'では移動しなくなってしまいました。
パターンAで移動の処理が正しいかテストするためには、当たり判定と補正の処理を(いちいち)調整しなければいけません。
ところが、当たり判定と補正の処理が正しく動作している保証がありません。
どうしたら、移動の処理が正しいか、当たり判定や補正の処理が正しいか、証明できるのでしょう。



パターンBは実際にはこのように変形して使います。

コード:

移動関数() {
 aを生成
 pにaを加える
}
当たり判定と補正を行う関数(p) {
 if (p がめり込んでいる) {
  pをめり込んでいない位置に補正
 }
}
移動するオブジェクトが、自分以外に何が存在するか知っている必要ありません。
知っていたら自分以外のオブジェクトが増えたりしたとき変更に巻き込まれることになるからです。

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

#66

by ISLe » 6年前

keito94 さんが書きました:出力する引数は、ポインタをつけろというわけですね…。
ここは(いまのところ)結果に影響を与えていないので、単に、引数に与えた値(特に現在座標と移動量)の変化を把握していないのではないかという疑問を補強する意味で指摘しました。
そういう意味では今回の変更においても疑問は一切解消されていません。
keito94 さんが書きました:あと、入れ子化していた部分を修正しました。
階層が1段増えましたね。
これを修正というのでしょうか。
わたしには改悪にしか見えませんが。

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

#65

by keito94 » 6年前

オフトピック
今の修正で、坂道の壁としての当たり判定も楽にできるかなって…。
今思うとはじめのコードは汚い上に、なんか変な要素満載だったな…。
早くに気づいていれば、良かったなと思うこの頃。

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

#64

by keito94 » 6年前

ISLeさん、ご指摘ありがとうございます。
出力する引数は、ポインタをつけろというわけですね…。
あと、入れ子化していた部分を修正しました。
添付ファイル
Collision.zip
(4.37 KiB) ダウンロード数: 358 回

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

#63

by ISLe » 6年前

keito94 さんが書きました:ISLeさんが指摘した、移動先座標での判定の部分を、移動量を足した判定に変更してみました。
CheckMapの部分は、addxかaddyのどちらかが、0でなければ正しく動作しない仕様となってます。
直しているとき、他に、移動量渡してない関数があることに気付きませんでした?

あと、現在座標と移動量のポインタを引数で渡して、当たり判定の結果によって、書き換えたり書き換えなかったりするわけですが、それが3段くらいの入れ子になっているので、書き換えた内容が上書きされるのではないだろうか、とか、移動量を何回も加算してしまわないだろうか、とかのうっかりミスをやらかしてしまっている可能性を考えるとキリがないですよね。
キリがないのでわたしは早々に考えることをやめてしまうのですが、keito94さんはその辺すべて把握されておられるのでしょうか。

マップから坂道の情報を取得するところで、ポインタではない引数を書き換えて、呼び出し元でそれを利用しようとしているところなんかを見ると、引数に対して無頓着なのではないかという気がするんですが。
この場合、書き換えた内容はとうぜん呼び出し元には返らないわけで。

どうしてわざわざ分かりにくくミスしやすくしているのかが、わたしには理解できないところです。

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

#62

by keito94 » 6年前

ISLeさんが指摘した、移動先座標での判定の部分を、移動量を足した判定に変更してみました。
CheckMapの部分は、addxかaddyのどちらかが、0でなければ正しく動作しない仕様となってます。
添付ファイル
Collision.zip
(4.21 KiB) ダウンロード数: 364 回

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

#61

by ISLe » 6年前

わたしがVector2の修正を指摘した時点では、それを適用すると上下動は無くなり、坂道に対する当たり判定そのものがなくなったように動作していました。
最新の状態では、上下動は再び発生しています。
原因が異なるであろうため前とは若干挙動が違います。

プレイヤーの移動処理をCPlayerクラスからCCollisionクラスに丸投げしているところで一気に読む気を削がれるのですが、何とか耐えて坂道関連の処理をひととおり読んでみました。
読んでみましたが理解するのは無理でした。

場所によって、移動先の座標で判定してその結果で移動元の座標を更新していたり、移動先の座標を引数で渡してさらに移動量を加えて使っていたり、当たり判定(の計算部分)が合っていようがまともに動くはずもなく、当たり判定が合っているかどうかなんてどうでもいい気持ちになりました。
まあ読む前に感じてたのと感想としては同じです。
それが確信に変わっただけでした。

そもそもkeito94さんは、いまのコードで平らな面の上を水平に移動できている仕組みを理解しているのでしょうか。

#面倒くさい上に誤魔化しにすぎない移動先判定をやめてしまえばいいのに。

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

#60

by keito94 » 6年前

もしかして、こうではないのでしょうか?
CheckSlopeの部分で座標と移動量を参照しておくように変更しました。
添付ファイル
Collision.zip
(4.19 KiB) ダウンロード数: 351 回

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

#59

by purin52002 » 6年前

こんばんは

ソース拝見しました。以前のものよりだいぶ見やすくなったと思います^^
ColSegmentsも分離したとのことで見てみましたが、うーん、、、^^;

ISLeさんに指摘されたとのことですが、おそらくISLeさんは「機能的に」分離してみては?と提案したんじゃないでしょうか?

コード:

void Func(int x, int y) 
{ 
    int add = x + y ;
    printf("%d\n", add) ;
}

int Add(int x, int y) { return x + y ; }
void Print(int num) { printf("%d\n", num) ; }

int main()
{
    Func(1, 2) ;//Func関数の中で計算も表示もしてしまっている
    Print(Add(1, 2) ) ;//Add関数で計算、Print関数で表示している
}
たとえばこのようなコードがあったときに、
  • 表示させたい数字が変わった
  • いろんな数字を表示させたい
となった場合、処理をひとまとめにしてしまっているFunc関数だけでは不便な気がしませんか?
処理を機能ごとに分割すれば、仕様に何か変更があってもソースの変更はほんのわずかで済みます。

keito94さんの場合、単純にColSegmentsを別ファイルに分離しているだけなので見やすくはなったかもしれませんが、処理内容は変わっていないのでISLeさんのいう分離とは違うような気がしました^^;
オフトピック
最初私はColSegments内の処理が間違っているせいで坂道移動ががくがくすると思っていましたが、どうやら原因はVector2のほうにあったようですね。紛らわしいこと言ってしまい申し訳ありません<(_ _)>

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

#58

by keito94 » 6年前

No.57のアルゴリズムをもとにしたソースをCollision.zipに添付します。
追記:http://dixq.net/forum/blog.php?u=900&b=6581でISLeさんに指摘されたので、ColSegmentを分離しました。
添付ファイル
Collision.zip
(4.52 KiB) ダウンロード数: 318 回

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

#57

by keito94 » 6年前

ごめんなさい、わかりにくかったですね…。
①プレイヤーが坂道のところに来たら、坂道のパラメーターを設定します。(坂道の線分を設定する。)
②坂道のパラメーターをもとにプレイヤーのパラメーターを設定します。
(具体的にはSlopeCondというパラメーターで、坂道か天井か、(右方向から見て)上りか下りかをもとにプレイヤーの線分を設定する。)
③プレイヤーの足元の点(プレイヤーの線分の終点が、)が、坂道の開始地点と終了地点の間にいたら(坂道の線分の間にいれば)、プレイヤーの線分と坂道の線分で当たり判定を行います。
④プレイヤーが坂道のところを離れたら、坂道の当たり判定を終了して、四角形の床の当たり判定を行います。
⑤坂道にプレイヤーが衝突していたら、プレイヤーの座標に坂道の内分比を足してめり込み防止をします。
⑥下りの時は、プレイヤーが衝突しないと思うので、プレイヤーの座標に内分比を引いてめり込み防止をします。
⑦そして、プレイヤーが坂道を歩いているように見えたら完成です。
オフトピック
もしかしたらまだまだ、説明不足な点があるかも…。
追記:少し修正しました。

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

#56

by usao » 6年前

オフトピック
なんか名前出されたから,ちょっとだけ書くけれども…
(ここにレスしていないということは,ここでのやりとりには参加する意思がないのだ,ということを,せめて理解いただきたいのだが)

>坂道として判定されたら
何が? どうやって? 「坂道として判定」されるのか

> 坂道の線分
> プレイヤーの線分
って何?

> プレイヤーの線分の終点が、坂道の線分の間であれば、
点が線分の間にある って,どういう状態のこと?

等々… それ以降の説明も,書いている本人にはわかるのだろうけど,
そのアルゴリズムについて何も知らない人がその文だけを読んで意味を把握するのは困難に思えます.

あなたが「言うまでもない」と思って省略している事柄は,他者にとっては説明が無いと全くわからない事柄なのかもしれない.
例えば,話の中で唐突に「ブロック」という単語が出てきますが,
その正体についての説明無しに,あなたと他者とで完璧に共通の認識を持てるでしょうか?
(マップのデータを2次元の格子で管理しているのだろうな,という想像くらいは付くかもしれませんが)
ブロックの大きさとプレイヤキャラクタの当たり判定の形や大きさとの関係はどうなのか?ということを知らずに,衝突判定処理の妥当性を話し合えるでしょうか?

#私向けの回答は不要です.

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

#55

by keito94 » 6年前

あと、なんとかスパゲッティコードを解消させてみました…。
Collision.cppのGetMoveを見ればわかると思いますが、坂道にプレイヤーが居るのなら、ブロックとしての当たり判定を中断させ、坂道の当たり判定へ移行します。また、GetSlopeでdefaultのところへ来たらそれはブロックとして判定します。昇り降りは、まだ作っておりません。これから質問の答を参照して作りたいと思います。
添付ファイル
Collision.zip
(3.71 KiB) ダウンロード数: 311 回

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

#54

by keito94 » 6年前

ISLe さんが書きました:ログインしたユーザーしか見ることができない場所に書かれた他人の文章を、ログインせず誰でも見ることができる場所に張り付ける行為。非常識ではないですか?
すいません、ソースをはっきりさせたいと思います…。

http://dixq.net/forum/blog.php?u=900&b= ... で答えたいと思います

①坂道として判定されたら、坂道の線分を生成する。
②プレイヤーの線分を生成する。
③プレイヤーの線分の終点が、坂道の線分の間であれば、プレイヤーの線分と坂道の線分で線分の当たり判定を行う。
④線分と線分が交差していたらそれは当たったことになる。
⑤当たっていたのなら、プレイヤーの座標と坂道の内分比を引いてそれをプレイヤーの座標にしてめり込み防止を行う。
⑥下りのときは交差されないと思うのでその場合はプレイヤーの座標と坂道の内分比を足してそれをプレイヤーの座標にする。
⑦そして、プレイヤーが坂道を歩いているように見えたら完成。
もしかしたらどこか間違っているのかもしれません…。
回答をお願いします。

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

#53

by ISLe » 6年前

ログインしたユーザーしか見ることができない場所に書かれた他人の文章を、ログインせず誰でも見ることができる場所に張り付ける行為。非常識ではないですか?
No.33と違い、No.51は明らかに無断転載でしょう。

このトピックをログインせずに見るひとからしたら、まったく意味不明ですよ。
そういう脈略のないところがコードにも表れているのと違いますか。

keito94 さんが書きました:ISLeさん、言い方が悪かったみたいですね…。
今書いているコードがスパゲッティコードになってるのは認めます。
しかし、どうしても、坂道の当たり判定が、今のしか考えられないので、
あなたが考えている方の当たり判定のサンプルコードを提示してください。
No.47をちゃんと理解できたなら「あなたが考えている方の当たり判定」なんて言葉が出てくるはずないんですけどね。
keito94さんがいま考えている坂道の当たり判定に注力できるようにするための方法を提案しているのですから。

スパゲッティ状態を改善して、(keito94さんの考えた)坂道の当たり判定をデバッグできるようにしろと言っているのですよ。

No.42,No.44にも、あの時点で、坂道の当たり判定はいまだスタート地点にも立ててないふうのこと書きました。
いまもその状況はまったく変わってない。

シグネチャに“只今デバッグトレーニング中。”とあるのは飾りですか。
真剣さが一切伝わってきませんね。

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

#52

by keito94 » 6年前

ISLeさん、言い方が悪かったみたいですね…。
今書いているコードがスパゲッティコードになってるのは認めます。
しかし、どうしても、坂道の当たり判定が、今のしか考えられないので、
あなたが考えている方の当たり判定のサンプルコードを提示してください。

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

#51

by keito94 » 6年前

http://dixq.net/fourm/blog.php?u=900&b=6581より
ISLe さんが書きました:そんな基本的なところに気付けないくらいにコードが複雑化している現状がある。
わたしはそれを解決するのが急務だと考えた。
ええっ!?スパゲッティーコードだったんですか今書いていたコード!?
そりゃ解決されないわけだ…。
ISLe さんが書きました: keito94さんはさっさと坂道を実装して終わらせたいと考えている。
であればかみ合うはずがないっすね。
ほんとそれですよ…。今となってはそりゃそうなっちゃうよな…。と反省しています…。

追記:ソース元を出しました。

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

#50

by keito94 » 6年前

ISLe さんが書きました: わたしの書いた文章をちゃんと読みましたか。
文字をなぞるだけでなく、意味を理解しましたか。
すいません。さっきの発言はなかったことにしてください…。
軽率かつ思い込みでした…。
あの時はつい、Collision.cppは変える必要ないのかと…。
ISLe さんが書きました:
理解する気がないと思われるところに、説明を補完する役割としてのサンプルコードを提示する意義を感じませんし、そういうサンプルコードはお望みでありませんよね。
そうですよね…。

というわけで、あなたが考えている方の当たり判定のサンプルコードを出してください。
ようやくあなたの発言の意味が飲み込めましたので…。
オフトピック
今となってはあの書き込み、反省しているよ…。
追記:適切なものに直しました。

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

#49

by ISLe » 6年前

> keito94 さん
わたしの書いた文章をちゃんと読みましたか。
文字をなぞるだけでなく、意味を理解しましたか。

「それをもとにして、Collision.cppをプログラム」する必要があったら、それはもうわたしのやり方ではないのです。
「それをもとにして、Collision.cppをプログラム」できるようなサンプルコードをわたしのやり方で書いたら、もはや何も(あるいはほとんど)変更する必要がないのですから、コードを入れ替える一択しかあり得ません。

理解する気がないと思われるところに、説明を補完する役割としてのサンプルコードを提示する意義を感じませんし、そういうサンプルコードはお望みでありませんよね。

#トピック自体は有意義であって欲しいので、そういう意味では考えておきます。

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

#48

by keito94 » 6年前

ISLe さんが書きました: わたしが違う方法を使うというだけで、間違っているとは言っておりません。
ますますわけがわからなくなってしまいました…。(あれで完璧だったつもりなのに…。)
では、あなたが考えてるやり方のほうのサンプルコードを出してください!!
それをもとにして、Collision.cppをプログラムしますから!!

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

#47

by ISLe » 6年前

keito94 さんが書きました:そうか、Collision.cppの当たり判定は間違っていたのか…。
わたしが違う方法を使うというだけで、間違っているとは言っておりません。

キャラが壁にハマってしまう
わたしが使う方法は既に最初期にお伝えしてます。
壁にめり込んでいるのを補正するなら、ただ壁にめり込んでいるのを補正するだけでいい、というふうなことです。
やり方が違うというだけで、やること自体は変わりません。


keito94さんのいまのコードでは、機能ごとに階層が深く複雑化していく構造です。
機能ごとの依存度が高く、機能の変更や追加が他へ大きく影響するため、そのバランスを取ることに大量の時間を割くことになります。

わたしが使う方法は機能ごとの実装に階層を持たせない方法です。
それだけのことですが、コードの重複が減り応用範囲が広がるので、プラマイの相乗効果で効率として何百倍何千倍もの差が生まれます。


プレイヤーキャラが坂道の上にいる(接している)という状態であれば、背景に坂道があろうかなかろうが、背景に何もなく見た目空中に浮いているようでも、設定した坂道のパラメータで上り下りするように振る舞えばいい。

そして、そこに背景として坂道を合成すれば、その坂道をプレイヤーキャラが上り下りしているように見える。

プレイヤーキャラが坂道の上にいる(接している)という状態は、プレイヤーキャラが持っているものです。
それを自由に制御できるようにする。

プレイヤーキャラが坂道を上り下りする処理と、プレイヤーキャラが背景の坂道と接しているかどうか判定する処理は、まったく関係なく実装できるのです。
最終的に、背景の坂道にプレイヤーキャラが接している場合に、プレイヤーキャラに対して坂道の上にいる(接している)と連絡する処理を加えればよいのです。
そうであれば、最初からプレイヤーキャラが坂道の上にいる(接している)という状態で初期設定して動かしてテストしたり、特定のキーを押したら状態が切り替わるようにしてテストしたりなどシンプルな条件で単体テストを行うことができます。


坂道移動のサンプルコードが手に入ったとして、いまのままコードに継ぎ足していっても効率は悪くなる一方ですよ。
わたしは、わたしとは、やり方が違うと言っているのです。

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

#46

by purin52002 » 6年前

坂道に沿って動くプログラムです。
高校生レベルの数学がわかればわかるはず、、、?
添付ファイル
purin52002.zip
キーボードのaとdで動きます。(windows用)
(8.12 KiB) ダウンロード数: 307 回

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

#45

by keito94 » 6年前

そうか、Collision.cppの当たり判定は間違っていたのか…。
今の言葉でちょっと頭が混乱してしまったので、坂道移動のサンプルコードをくれませんか?
それをもとにソースコードを変更したいと思うので…。

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

#44

by ISLe » 6年前

Vector2.cppを修正してやっとまともにデバッグできる状況になるというだけです。
坂道判定に関しては、ここからスタートですよ。
ご自身で取り組んでください。

keito94 さんが書きました:Collision.cppに書かれてある当たり判定のアルゴリズムを残したままでいいので
わたしはこれを残したままのやり方を知りませんし考えたくもないです。
もっとシンプルに実装する方法を知っていますが、根本的に考え方が異なるのです。
#某所に書いたのはそういうことであってコードが正しいとか正しくないとかいうことではない。

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

#43

by keito94 » 6年前

ISLeさん、ライブラリの欠点のご指摘ありがとうございます!!
少し変更したのをGithubにあげようと思います!!
これが坂道の当たり判定に関係するわけですよね?
修正済みのVector2.cppを使ったサンプルコードをください!!

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

#42

by ISLe » 6年前

とりあえず、他は現状のままでよいので、Vector2.cppの下記の関数を変更してください。
これでやっとまともに坂道判定にとっかかれると思います。

コード:

Vector2& Vector2::operator *=(const float& a)
{
#if 0
	return Vector2(x * a, y * a);
#else
	x *= a;
	y *= a;
	return *this;
#endif
}

Vector2& Vector2::operator /=(const float& a)
{
#if 0
	return Vector2(x / a, y / a);
#else
	x /= a;
	y /= a;
	return *this;
#endif
}

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

#41

by keito94 » 6年前

Y座標を坂道に合わせて移動させるというのはわかったけど…。坂道移動のアルゴリズムがちょっとよくわからないなぁ…。
お手数ですが、Collision.cppに書かれてある当たり判定のアルゴリズムを残したままでいいので、坂道移動のサンプルコードをくれませんか?
コメントにも書かれてあるように線分の衝突の部分判定のチェックの部分に間違いとかあるのかな…。
ついでにちょっと調べてくれませんか?(以下のように修正してください。)

コード:

Vector2 CCollision::CheckSlope(int x, int y, Segment& Slope, int layernum,int slopecond,float addy) {
	//当たり判定。
	POINT pt[] = {
		{ x + mPt[0].x,	y + mPt[0].y },//左上
		{ x + mPt[1].x,	y + mPt[1].y },//上真ん中
		{ x + mPt[2].x,	y + mPt[2].y },//右上

		{ x + mPt[3].x,	y + mPt[3].y },//左真ん中
		{ x + mPt[4].x,	y + mPt[4].y },//右真ん中

		{ x + mPt[5].x,	y + mPt[5].y },//左下
		{ x + mPt[6].x,	y + mPt[6].y },//下真ん中
		{ x + mPt[7].x,	y + mPt[7].y },//右下
	};
	DWORD cwidth = Game->MapData().GetChipWidth();
	DWORD cheight = Game->MapData().GetChipHeight();
	Segment Player;
	switch (slopecond) {
	//1は下の下り坂。
	case 1:
		Player.s = { (float)pt[2].x,(float)pt[2].y };
		Player.v = { (float)pt[5].x,(float)pt[5].y };
		break;
	//2は上の上り坂。
	case 2:
		Player.s = { (float)pt[7].x,(float)pt[7].y };
		Player.v = { (float)pt[0].x,(float)pt[0].y };
		break;
	//3は上の上り坂。
	case 3:
		Player.s = { (float)pt[5].x,(float)pt[5].y };
		Player.v = { (float)pt[2].x,(float)pt[2].y };
		break;
	//0は下の上り坂。(0以外は想定していないのだ。)
	default:
		Player.s = { (float)pt[0].x,(float)pt[0].y };
		Player.v = { (float)pt[7].x,(float)pt[7].y };
		break;
	}
	Vector2 res = { (float)x,(float)y };
	//デバッグ用。
	float T1;
	float T2;
	Vector2 Vres;
	int PlayerCond;
	//式自体はあっているが…。レイヤーの数値獲得に原因がありそうだ。
	//プレイヤーの終点のX座標が、坂道のX座標の間なら、1。間でないのなら、0。
	if (Slope.s.x >= Player.v.x && Player.v.x < Slope.v.x || Slope.s.x <= Player.v.x && Player.v.x > Slope.v.x) {
		PlayerCond = 1;
	}
	else {
		PlayerCond = 0;
	}
	//衝突した場合は座標に内分を足し、そうでない場合は内分を引く。
	//(間違っているかもしれない…。)
	if (PlayerCond != 0) {
		if (ColSegments(Slope,Player,&T1,&T2,&Vres)) {
			res.x = x-T1;
			res.y = y-T1;
			addy = T1*2;
			return res;
		}
		else {
			res.x = x + T1;
			res.y = y + T1;
			addy = T1*2;
			return res;
		}
	}
	else {
		//なるほど、あり得ない座標を代入したら、レイヤーの数値獲得もおかしくなるわけか…。
		res.x = -2;
		res.y = -2;
		return res;
	}
	//ここまで来たら衝突していないということ。
	res.x = -1;
	res.y = -1;
	return res;
}

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

#40

by purin52002 » 6年前

keito94 さんが書きました:
オフトピック
ええっ!?Y座標を坂道に合わせて動かせばいいんですか!?
ちょっと甘かったです…。
y座標動かさないと坂道のぼれないやないかーいw
でもこれで不具合の原因がわかりましたね^^
移動した座標が坂道だったら、坂道の傾斜に応じてy座標を変化させてやればいいわけですね。

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

#39

by keito94 » 6年前

myyと言うのはキャラクターの座標です。
addyと言うのは、キャラクターの移動量です。
あと、purinさんのご指摘に従い、Collision.cppを少し修正してみました。(中身に変わりはありません。)
49行目の件はちょっと誤算でしたね…。
オフトピック
ええっ!?Y座標を坂道に合わせて動かせばいいんですか!?
ちょっと甘かったです…。
添付ファイル
Collision.cpp
(10.55 KiB) ダウンロード数: 295 回

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

#38

by purin52002 » 6年前

マジックナンバーが定数に置き換えられてて見やすくなっていました^^
ただ(私がconst intって書いたせいかも知らないけど)定数がすべてconst intで定義されていました。
定数は別に整数である必要はなく、比較対象と同じ型にしたほうがいいと思います。

以下修正案

コード:

//collision.cpp
void CCollision::GetYPosition(float* myx, float* myy, float* addx, float* addy, int* jcount, bool* gflag) {
	//座標を一時的に保存する。
	float tempaddx = *addx;
	float newy = *myy + *addy;
	//ブロックとしての衝突判定。
	POINT block = CheckMap((int)*myx, (int)newy,*addx,*addy);
	const int OK = -1;
	const int SLOPE = -2;
	//Y座標が衝突していなかったら。
	if (block.y == OK) {
		*myy = newy;
		*gflag = false;
	}
	//Y座標が坂道のレイヤーにいたら。
	else if(block.y == SLOPE){
		//ブロックのレイヤー番号の獲得。
		int Layer = GetChipLayerNum((int)*myx, (int)newy);
		//坂道の線分の宣言。
		Segment Slope;
		//スロープの条件分離。
		int SlopeCond;
		switch (Layer) {
		case 2:
			Slope.s = GetMatrixPos(*myx, newy + 16.0F);
			Slope.v = GetMatrixPos(*myx + 16.0F, newy);
			SlopeCond = 0;
			break;
		}
		//ブロックとしての当たり判定。
		POINT slopeblock = CheckSlopeBlock((int)*myx, (int)newy, Layer);
		//坂道としての当たり判定。
		Vector2 slope = CheckSlope((int)*myx, (int)newy, Slope, Layer,SlopeCond);
		const int SLOPEOK = -1;
		const int BLOCK = -2;
		//-2を返したら、ブロックとして扱う。
		if (slope.y == SLOPEOK) {
			*gflag = true;
			*addy = 0;
		}
		//歩いていた場合は、
		else if (tempaddx != 0 && slope.y != BLOCK) {
			*gflag = true;
			*myy = slope.y;
		}
		else if (slope.y == BLOCK) {
			*gflag = true;
			*addy = tempaddx;
			*myy = newy;
		}
	}
	//ブロックの当たり判定。
	else {
		if (*addy < 0) {
			*myy = (float)((block.y + 1) * 16 + 8 + OffsetU + 0.1f);
		}
		else {
			*myy = (float)((block.y - 1) * 16 + 8 + OffsetD - 0.1f);
			*jcount = 0;
			*gflag = true;
		}
		*addy = 0;
	}
}

22行目:
SlopeCondが初期化されていません。(c++だと多分0で初期化されるけど)
次のswicthで値を代入するならdefaultの状態も作ったほうがいいと思います。

37行目:
slope.yはfloat型、SLOPEOKはint型です。値の比較は型をそろえたほうがいいと思います。
42行目、46行目も同じ。

46行目:
16行目でSLOPEと判定しているのにBLOCKかどうか調べるのはなんででしょうか?

以下ちょっと重要かも?
(addyとmyyがわかっていません。myyがキャラクターのy座標?)

39行目:
坂道にいるときにaddyが0になっている。
坂道に沿ってmyyを変化させなくていいんでしょうか?

44行目:
myyにslope.yを代入してるけど、slopeってSLOPEかBLOCKか判定する変数じゃないんでしょうか?

48行目:
addyにtempaddxを代入してるけど、y成分にx成分を代入していいのでしょうか?(y(x)=xみたいな意味?)

49行目:
myyにnewyを代入していますが、newyは5行目でmyy+addyと定義されており、addyはこの時点ではGRAVかGRAVMAXの値しかとらなさそうなんですけど、これは意図したとおりの計算ですか?

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

#37

by keito94 » 6年前

purinさんに言われてマジックナンバーを駆逐し、コメントによる解説を加えたソースを作りました。
引き続き、Scene.cppとScene.h以外をプロジェクトに入れてください。
オフトピック
コメントをたくさん書く…
ボクはそれに賛成ですね。
添付ファイル
サンプルコード.zip
(21.69 KiB) ダウンロード数: 309 回

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

#36

by purin52002 » 6年前

プログラムを動かしてみたところキャラクターが坂道に差し掛かると
キャラが沈んだり、なぜか左右にものすごい勢いで動いたりしました。

何が悪いのかとプログラムを読もうと思ったのですが、いわゆるマジックナンバーが多く正直私レベルだと理解できません。(っていうかしたくない^p^)

出来ればマクロ、enum、定数などに置き換えたほうがいいと思います。

コード:

void CCollision::GetYPosition(float* myx, float* myy, float* addx, float* addy, int* jcount, bool* gflag) {
	float tempaddx = *addx;
	float newy = *myy + *addy;
	POINT block = CheckMap((int)*myx, (int)newy,*addx,*addy);
	//Y座標が衝突していなかったら。
	if (block.y == -1) {// -1 is magic number ( mn )
		*myy = newy;
		*gflag = false;
	}
	//Y座標が坂道のレイヤーにいたら。
	else if(block.y == -2){// -2 is mn
		int Layer = GetChipLayerNum((int)*myx, (int)newy);
		Segment Slope;
		//スロープの条件分離。
		int SlopeCond;
		switch (Layer) {
		case 2:
			Slope.s = GetMatrixPos(*myx, newy + 16.0F);// 16 is mn
			Slope.v = GetMatrixPos(*myx + 16.0F, newy);// 16 is mn
			SlopeCond = 0;
			break;
		}
		POINT slopeblock = CheckSlopeBlock((int)*myx, (int)newy, Layer);
		Vector2 slope = CheckSlope((int)*myx, (int)newy, Slope, Layer,SlopeCond);
		//-2を返したら、ブロックとして扱う。
		if (slope.y == -1) {// -1 is mn
			*gflag = true;
			*addy = 0;
		}
		else if (tempaddx != 0 && slope.y != -2) {// -2 is mn
			*gflag = true;
			*myy = slope.y;
		}
		else if (slope.y == -2) {// -2 is mn
			*gflag = true;
			*addy = tempaddx;
			*myy = newy;
		}
	}
	//ブロックの当たり判定。
	else {
		if (*addy < 0) {
			*myy = (float)((block.y + 1) * 16 + 8 + OffsetU + 0.1f);// 16,8,0.1 is mn
		}
		else {
			*myy = (float)((block.y - 1) * 16 + 8 + OffsetD - 0.1f);
			*jcount = 0;
			*gflag = true;
		}
		*addy = 0;
	}
}

マジックナンバーとはソース中にいきなり出てくる意味の分からない数字です。
(0はまあ初期化って意味だろうし直さなくてもいいかなー、と思いました)

数字だけだとややこしいので、名前を付けてやると見やすくなると思います。

コード:

#define SLOPE -1
const int SLOPE -1 ;
enum ChipType { SLOPE = -1 } ;

if( slope.y == SLOPE ) { ... }
のようにすると、他人が見た時や、時間をおいてからソースを見直すときにわかりやすいと思います^^

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

#35

by purin52002 » 6年前

坂道に入ると
Run-Time Check Failure #3 - The variable 'SlopeCond' is being used without being initialized.
という例外が出て止まってしまいます@_@

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

#34

by keito94 » 6年前

ブログなどでみなさんがそこまで言うのなら、ソースコードを公開しますので、
サンプルコード.zipのScene.cppとScene.h以外のソースコードをプロジェクトに追加してください。
ブログで聞いた話によると、今のソースコードは色々と改善すべきところがあると思うので、ここで改善案を出していただければ、
それを修正すると思います。
添付ファイル
サンプルコード.zip
(20.73 KiB) ダウンロード数: 302 回

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

#33

by purin52002 » 6年前

purin52002 さんが書きました:
purin52002 さんが書きました: 坂道とプレイヤーの線分が交差していたらColSegments関数にtrueを返してほしくて、
でもColSegments関数はfalseを返すし、
これはColSegments関数の不具合ということですか?
keito94 さんが書きました:違います違います!!
ColSegment自体は正しく動作しています!!
ColSegments関数の仕業じゃないとすれば妖怪の仕業、、、?

冗談はさておき、
http://dixq.net/forum/blog.php?u=900&b=6581のISLeさんの投稿を見ると、
GetXPosition周りが怪しいとか、、、。

解決案としましては、
  • GetXPosition関数とかの修正
  • GetXPosition関数を使っている箇所の修正
でしょうか?

どちらの方法が絶対いい!とは言い切れないのでどちらの方法をとるかはkeitoさんが決めて下さい。
(なんかほかにもっといい方法あるかも^p^)
keito94 さんが書きました:あの、ブログ見ましたけど…。
移動後の座標ではなく、現在の座標だったのですか!?
ボクも気づきませんでした…。
すいませんが、現在の座標ベースでの当たり判定のアルゴリズムを教えてくれませんか?
すみませんが元のアルゴリズムも対して理解していないので
こっちに関してはもう、、、「がんば^p^」というしか、、、

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

#32

by keito94 » 6年前

あの、ブログ見ましたけど…。
移動後の座標ではなく、現在の座標だったのですか!?
ボクも気づきませんでした…。
すいませんが、現在の座標ベースでの当たり判定のアルゴリズムを教えてくれませんか?

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

#31

by keito94 » 6年前

違います違います!!
ColSegment自体は正しく動作しています!!
そして、修正が一つ…。
最初のプログラムの177行の部分を、

コード:

POINT slope = CheckSlope((int)*myx, (int)newy, Slope, Layer,SlopeCond);
に修正してください…。

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

#30

by purin52002 » 6年前

purin52002 さんが書きました: 坂道とプレイヤーの線分が交差していたらColSegments関数にtrueを返してほしくて、
でもColSegments関数はfalseを返すし、
これはColSegments関数の不具合ということですか?

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

#29

by keito94 » 6年前

そういうことです!!

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

#28

by purin52002 » 6年前

線分と線分が交差していたらtrueを返すのがColSegments関数で、
坂道とプレイヤーの線分が交差していたらColSegments関数にtrueを返してほしくて、
でもColSegments関数はfalseを返すし、
そのせいでブロック判定もうまくいかない。

ということですか?

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

#27

by keito94 » 6年前

簡単に説明すると、
  • ①坂道のブロックにプレイヤーが入る。(ここはOK)
  • ②坂道のブロックの種類を識別する。(i+2を返す部分)
  • ③坂道の線分とプレイヤーの線分が設定される。
  • ④坂道の線分が、プレイヤーの線分の終点の間なら、線分の判定を行い、線分と衝突していたら、めり込み防止をした座標を返す。
  • ⑤…はずだったのだが、④が誤作動を起こし、その巻き添えで②も誤作動を起こし、普通のブロックとして判定されてしまう。
でしょうか?

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

#26

by purin52002 » 6年前

keito94 さんが書きました:
purin52002 さんが書きました: これは、真になるであろうパラメータを与えても真にならないということですか?
そ、そういうことではなくてですね…。
坂道のブロックにいると判定されているときに何故か真にならないということです。
purin52002 さんが書きました:理解力ががが^p^

坂道ブロックにいるときは真と判定してほしいのに、真と判定されない。
という不具合だと思ったのですが違うのですか?
理解力がががががが^p^p^
ちょっと状況がわからなくなってしまったので詳しく説明してもらってもいいですか?

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

#24

by purin52002 » 6年前

理解力ががが^p^

坂道ブロックにいるときは真と判定してほしいのに、真と判定されない。
という不具合だと思ったのですが違うのですか?

ページトップ