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

[keito94]

ちなみに、これが現在のコードです。
現在は移動量に依存していた部分を取り除いたところです。実行しても、落下状態にあるので、めり込んでしまいます。
CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。（混乱を招く回答すいません…。）

[ISLe]

現在は移動量に依存していた部分を取り除いたところです。

前に一度CCollision::GetMoveからも取り除かれたのに、今は復活してますね。

CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。（混乱を招く回答すいません…。）

それはわたしがNo.84で書いた表現をなぞっているだけですね。

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



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

[keito94]

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

なん…だと…。地上にいるというのは振る舞いだけだったのか…。

前に一度CCollision::GetMoveからも取り除かれたのに、今は復活してますね。

今度こそ取り除かれたのではないのでしょうか？

[ISLe]

なん…だと…。地上にいるというのは振る舞いだけだったのか…。

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

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

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

今度こそ取り除かれたのではないのでしょうか？

余計なことをしなければ、No.74で達成できていたのに。



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

[keito94]

とりあえず、No.81で言われた方法にしてみました。
現在確認されているバグは、

• 着地すると、キャラがぴょんぴょん跳ねる。
• 左の壁に衝突すると、キャラが上に上がる。

となります。
壁に当たった時、キャラをずらすアルゴリズムの例を上げてくれますか。

[ISLe]

壁に当たった時、キャラをずらすアルゴリズムの例を上げてくれますか。

これはつまり…
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さんが望む例ではないですよね。
これは何かの哲学ですかね。

とりあえず、No.81で言われた方法にしてみました。
現在確認されているバグは、

• 着地すると、キャラがぴょんぴょん跳ねる。
• 左の壁に衝突すると、キャラが上に上がる。

となります。

というわけで、No.81で言った方法になってない(不十分)です。

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



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

コードの切り貼りしたいだけなら、結果がどうあれ、その状況を楽しめばいいんじゃないでしょうか。
そういうことなら、他人に正解(?)を求めるのは楽しみ方として間違っていると思います。
巻き込まないでください。

オフトピック

同じことを3回繰り返したら、もはやサンプルとしての価値もない。

[keito94]

ごめんなさい、座標をずらす部分をむやみにいじってしまいました…
No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、
上下の当たり判定で、めり込んで左の壁まで行ってしまいます。
後、重力の部分を分割してみました。

[ISLe]

オフトピック

現時点で気になることを書き残しておきます。

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

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

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

[keito94]

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

今の発言を受けて、当たり判定のサイズを変更してみました。

[ISLe]

後、重力の部分を分割してみました。

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


もし、万が一、意味もなくやったのだとしたら…
(※下線加筆)

ごめんなさい、座標をずらす部分をむやみにいじってしまいました…
No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、
上下の当たり判定で、めり込んで左の壁まで行ってしまいます。
後、重力の部分を分割してみました。

正に舌の根の乾かぬうちにってやつですね。


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

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

[ISLe]

オフトピック

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

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

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

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

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

[keito94]

正に舌の根の乾かぬうちにってやつですね。

そうです…。

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

もしかしてこうではないのでしょうか？

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

たしかにそれは言えている…。

たしかにそうなんですよね…。

[ISLe]

(※下線加筆)

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

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

これ、いますぐやっちゃダメって読めないですかね。
わたしの文章がおかしいのかな。


あと、不思議な文言があるのに気づきました。
#前後のインパクトのほうが大きかったもので

No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、
上下の当たり判定で、めり込んで左の壁まで行ってしまいます。

「左右の当たり判定の部分は完成した」？


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


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

[ISLe]

オフトピック

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

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

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

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

[keito94]

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

[ISLe]

正確には当たり判定のコード自体は完成していたのですが、

例えば、CCollision::GetXPosition関数の中にあるコード…
(Collision.cpp:267行目～)

コード:

		if (block.x < *myx) {
			*myx = (float)((block.x - 1) * 16 + 8 + OffsetR - 0.1f);
		}

block.xは、左端のブロックを0番目として右へ何個目かという数値が入ってます。
*myxは、キャラの中心のX座標がピクセル単位で入ってます。
まったく意味の違う数値を比較しているこのコード、正しいですか？

なかなか理想通りの動きになりません…。
どうしたら、理想通りの動き（地上にいるときだけGroundFlagがtrueになったまま）になるのでしょうか？

どうすればいいか(あるいはそのためのヒント)は既にNo.98,No.101に(さらにそれ以降も)書きました。
ですが、どうしたらkeito94さんが理解できるかはわたしには分かりません。

[keito94]

ISLeさんのご指摘を受けて、ブロックの単位ではなく、座標で判定して見るようにしてみました。
でも、また新たなバグが発生してしまいました…。
実行すると、着地せずに画面外に落下します。

[ISLe]

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を足したり引いたり…
どんな意味があるんです？

でも、また新たなバグが発生してしまいました…。
実行すると、着地せずに画面外に落下します。

デバッグすれば、CCollision::GetXPositionでもCCollision::GetYPositionでも、ifの条件が両方同時に成立していることが確認できるはずですが。
このコードでは、画面外に消えるのが正常。


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

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


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

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

[keito94]

ブロックの座標で当たり判定を実装しようとしています。
現在考えているのは、衝突したら一ブロックずらした座標で判定するということです。
（キャラの座標が中央基準なので…。）
ですが、地上に着地せずにめり込んで左に移動してしまいます。
左右の判定は一応完成しました。

[ISLe]

現在考えているのは、衝突したら一ブロックずらした座標で判定するということです。
（キャラの座標が中央基準なので…。）
ですが、地上に着地せずにめり込んで左に移動してしまいます。

ブロックが等間隔に並んでいることが前提条件になりますよね。
わざわざブロックが等間隔に並んでいないといけなくするメリットって何でしょう。

オフトピック

むしろ、坂道を実装するには邪魔になりそうな前提条件は排除していきたいが。

そもそも、衝突したブロックの左にあるブロックがキャラより左にあって、衝突したブロックの右にあるブロックがキャラより右にある、というのは当たり前。
こちらも同時に成立する条件。
あいだにelseを入れたので、前回は常に右へ下へだったのが、今回は常に左へ上へとなった。
それだけ。
本質的に何も変わってない。

左右の判定は一応完成しました。

そうですか。
おつかれさまでした。

[ISLe]

ですが、地上に着地せずにめり込んで左に移動してしまいます。

添付されているソースファイルは、そうならないようにCPlayer::GroundFlag書き換えている箇所を移動してますね。
どうしてでしょうね。

[keito94]

むしろ、坂道を実装するには邪魔になりそうな前提条件は排除していきたいが。

どうやって排除するのですか？

[ISLe]

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

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

[keito94]

分かっているなら、どこがどうして問題なのか、説明して見せてください。

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

[ISLe]

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

キャラはピクセル単位で動くのだから、ピクセル単位で座標がずれるのは最初から想定内ですよ。

（今のコードでは）左へ上へ行ってしまうバグが起きてしまうことです。

そうなるようにコードを書き換えたのはkeito94さんですよ。

その問題というのは、CheckMapや、マップチップを確認する部分にあります。

「どこが」はまあ合ってますけど、たまたまですかね。

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

[ISLe]

オフトピック

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

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

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

[keito94]

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

もしかしてめり込み防止の部分ですか？

[ISLe]

もしかしてめり込み防止の部分ですか？

「もしかして」？
あてずっぽうですか？
あてずっぽうであたったとして何の意味があるんでしょう。

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

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

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

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

[keito94]

場所はCCollision::CheckMapで合ってると書いたのに。

ごめんなさい…やっぱりあってたんですね…

前提から外れたことを同じやり方でやろうとしたらどうなりますかね。

そりゃ、バグが発生するわけですね…。

[keito94]

オフトピック

今思うと問題点だらけだったんだな…。

[keito94]

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

[ISLe]

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

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

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

[keito94]

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

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

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

了解しました！
一応この記事は今度こそ解決とさせてください！！