坂道の当たり判定を作っています。
Re: 坂道の当たり判定を作っています。
ちなみに、これが現在のコードです。
現在は移動量に依存していた部分を取り除いたところです。実行しても、落下状態にあるので、めり込んでしまいます。
CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。(混乱を招く回答すいません…。)
現在は移動量に依存していた部分を取り除いたところです。実行しても、落下状態にあるので、めり込んでしまいます。
CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。(混乱を招く回答すいません…。)
- 添付ファイル
-
- Collision.zip
- (5.4 KiB) ダウンロード数: 476 回
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
前に一度CCollision::GetMoveからも取り除かれたのに、今は復活してますね。keito94 さんが書きました:現在は移動量に依存していた部分を取り除いたところです。
それはわたしがNo.84で書いた表現をなぞっているだけですね。keito94 さんが書きました:CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。(混乱を招く回答すいません…。)
No.84では、それに対する問題の指摘も同時にしているのですが、理解できませんでしたか?
No.85を見たら理解しようという気概を感じられませんけどね。
画面右端のブロックに触れると右外に消えてしまう問題については、さらに前のNo.81で既に書いてます。
keito94さんが方針変更されると思ったのでオフトピになってますが。
Re: 坂道の当たり判定を作っています。
なん…だと…。地上にいるというのは振る舞いだけだったのか…。ISLe さんが書きました: キャラが地面にめり込むと地面に触れないぎりぎりの位置に座標補正されます。
次のフレームで、それは地上に立っていることになるのでしょうか。
今度こそ取り除かれたのではないのでしょうか?ISLe さんが書きました: 前に一度CCollision::GetMoveからも取り除かれたのに、今は復活してますね。
- 添付ファイル
-
- Collision.zip
- (5.38 KiB) ダウンロード数: 483 回
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
『CPlayerは』『CPlayer::GroundFlagによってのみ』振る舞いを変えることでCPlayerの独立性が高まります。keito94 さんが書きました:なん…だと…。地上にいるというのは振る舞いだけだったのか…。
CPlayer::GroundFlagの変化とは無関係になるので、キャラの挙動と、ブロックのあたり判定それぞれ別々にデバッグが可能になる。
という内容のことをNo.47で書いているんですけどね。
当時は理解できなかったとしても今は理解できるかもしれない。
何回も読み直して理解しようという気はないのでしょうか。
あと、バグの原因の特定も容易になる。
挙動の変化がおかしいならCPlayer::GroundFlagを書き換えている場所を探せばいい。
#CCollisionが直接書き換えているから問題をややこしくしているけども、まあそこは後回しでいい。
余計なことをしなければ、No.74で達成できていたのに。ISLe さんが書きました:今度こそ取り除かれたのではないのでしょうか?
で、次にやるべきことは既に示されている(No.81,92)わけですが?
Re: 坂道の当たり判定を作っています。
とりあえず、No.81で言われた方法にしてみました。
現在確認されているバグは、
壁に当たった時、キャラをずらすアルゴリズムの例を上げてくれますか。
現在確認されているバグは、
- 着地すると、キャラがぴょんぴょん跳ねる。
- 左の壁に衝突すると、キャラが上に上がる。
壁に当たった時、キャラをずらすアルゴリズムの例を上げてくれますか。
- 添付ファイル
-
- Collision.zip
- (5.42 KiB) ダウンロード数: 503 回
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
これはつまり…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さんが望む例ではないですよね。
これは何かの哲学ですかね。
というわけで、No.81で言った方法になってない(不十分)です。keito94 さんが書きました:とりあえず、No.81で言われた方法にしてみました。
現在確認されているバグは、となります。
- 着地すると、キャラがぴょんぴょん跳ねる。
- 左の壁に衝突すると、キャラが上に上がる。
既存のコードを理解すればそのバグは直せるはずですが。
keito94さんは、いつになったらプログラミングやデバッグを始めるつもりなんですか?
無意味で無関係なコードがまた復活してたり、認識してないはずのコードがテキトーに変更されてますけど。
コードの切り貼りしたいだけなら、結果がどうあれ、その状況を楽しめばいいんじゃないでしょうか。
そういうことなら、他人に正解(?)を求めるのは楽しみ方として間違っていると思います。
巻き込まないでください。
オフトピック
同じことを3回繰り返したら、もはやサンプルとしての価値もない。
Re: 坂道の当たり判定を作っています。
ごめんなさい、座標をずらす部分をむやみにいじってしまいました…
No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、
上下の当たり判定で、めり込んで左の壁まで行ってしまいます。
後、重力の部分を分割してみました。
No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、
上下の当たり判定で、めり込んで左の壁まで行ってしまいます。
後、重力の部分を分割してみました。
- 添付ファイル
-
- Collision.zip
- (5.45 KiB) ダウンロード数: 524 回
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
オフトピック
現時点で気になることを書き残しておきます。
CCollision::GetXPosition関数などで、キャラ座標はピクセル単位でブロックはタイル単位と異なる座標系が混在しており、さらにキャラ座標は中心が基準となっているところに、さらにx,yなど数値をバラバラにやり取りしているため混乱に拍車をかけている。
タイルのサイズは16ピクセルであるのに、-8~8という範囲(=17ピクセル)を使って重要な判定をしている。
座標およびサイズ情報と当たり判定メソッド(のプロトタイプ)を持つCMoverクラスがあるのに、どうしてそれを使わないのだろうか。
CPlayerはCMoverを継承しているのに、どうしてわざわざ情報をバラバラにして引数に渡すのだろうか。
CCollision::GetXPosition関数などで、キャラ座標はピクセル単位でブロックはタイル単位と異なる座標系が混在しており、さらにキャラ座標は中心が基準となっているところに、さらにx,yなど数値をバラバラにやり取りしているため混乱に拍車をかけている。
タイルのサイズは16ピクセルであるのに、-8~8という範囲(=17ピクセル)を使って重要な判定をしている。
座標およびサイズ情報と当たり判定メソッド(のプロトタイプ)を持つCMoverクラスがあるのに、どうしてそれを使わないのだろうか。
CPlayerはCMoverを継承しているのに、どうしてわざわざ情報をバラバラにして引数に渡すのだろうか。
Re: 坂道の当たり判定を作っています。
今の発言を受けて、当たり判定のサイズを変更してみました。ISLe さんが書きました: タイルのサイズは16ピクセルであるのに、-8~8という範囲(=17ピクセル)を使って重要な判定をしている。
- 添付ファイル
-
- Collision.zip
- (5.45 KiB) ダウンロード数: 555 回
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
これ、何か目的があるんですよね。keito94 さんが書きました:後、重力の部分を分割してみました。
コードに手を加えるというのは、バグを生む可能性を含みます。
プログラムを台無しにするのと引き換えにしてもいいくらい意味のあることなんでしょうね。
ちょっと分からないので説明していただけませんか。
もし、万が一、意味もなくやったのだとしたら…
(※下線加筆)
正に舌の根の乾かぬうちにってやつですね。keito94 さんが書きました:ごめんなさい、座標をずらす部分をむやみにいじってしまいました…
No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、
上下の当たり判定で、めり込んで左の壁まで行ってしまいます。
後、重力の部分を分割してみました。
No.67に書きました。
CPlayer::Moveから除けたいのは、あたり判定(を直接呼び出している)部分。
カオス過ぎていますぐそれはできないので、少しずつ改善しようとしているところ、ことごとく先回りして改善の芽を潰す。
ある意味keito94さんの才能かもしれませんね。
Re: 坂道の当たり判定を作っています。
オフトピック
CPlayer::GroundFlagがオンのときCPlayerは地上にいるように振る舞う。
CPlayerはCPlayer::GroundFlagによってのみ振る舞いを変える。
これは前提。
現状、座標補正によって、当たり判定の範囲外に移動するため、フレームごとにCPlayer::GroundFlagのオン/オフが繰り返される状況。
キャラの足元にブロックがあるあいだ、CPlayer::GroundFlagがオンのまま維持されて欲しい。
当たり判定の範囲と、めり込んでいるとする範囲をずらすという方法がある。
選択肢の一つであり何が正解というわけでないが、シンプルだし、現状においては変更点も少なく済む。
キャラの足元、1ピクセル重なってブロックがある場合
当たっている。が、めり込んでいない
キャラの足元、2ピクセル重なってブロックがある場合
当たっている。1ピクセルめり込んでいるとみなして押し戻す
というふうにする。
接しているかどうか判定するのは難しいけれど、重なっているかどうかなら簡単。
CPlayerはCPlayer::GroundFlagによってのみ振る舞いを変える。
これは前提。
現状、座標補正によって、当たり判定の範囲外に移動するため、フレームごとにCPlayer::GroundFlagのオン/オフが繰り返される状況。
キャラの足元にブロックがあるあいだ、CPlayer::GroundFlagがオンのまま維持されて欲しい。
当たり判定の範囲と、めり込んでいるとする範囲をずらすという方法がある。
選択肢の一つであり何が正解というわけでないが、シンプルだし、現状においては変更点も少なく済む。
キャラの足元、1ピクセル重なってブロックがある場合
当たっている。が、めり込んでいない
キャラの足元、2ピクセル重なってブロックがある場合
当たっている。1ピクセルめり込んでいるとみなして押し戻す
というふうにする。
接しているかどうか判定するのは難しいけれど、重なっているかどうかなら簡単。
Re: 坂道の当たり判定を作っています。
そうです…。ISLe さんが書きました: 正に舌の根の乾かぬうちにってやつですね。
もしかしてこうではないのでしょうか?ISLe さんが書きました: CPlayer::Moveから除けたいのは、あたり判定(を直接呼び出している)部分。
たしかにそれは言えている…。ISLe さんが書きました: 現状、座標補正によって、当たり判定の範囲外に移動するため、フレームごとにCPlayer::GroundFlagのオン/オフが繰り返される状況。
キャラの足元にブロックがあるあいだ、CPlayer::GroundFlagがオンのまま維持されて欲しい。
たしかにそうなんですよね…。
- 添付ファイル
-
- Collision.zip
- (6.38 KiB) ダウンロード数: 482 回
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
(※下線加筆)
わたしの文章がおかしいのかな。
あと、不思議な文言があるのに気づきました。
#前後のインパクトのほうが大きかったもので
コードは完成していて、動作は理想と違う
というのがkeito94さんの最終形なのでしょう。
少なくともkeito94さんの態度が改まらない限りそこから変化しないと思います。
keito94さんとわたしでは世界線が違う。
keito94さんとわたしがやり取りを続けても収束しません。
わたしがここ数回オフトピで投稿しているのはわたしの世界線を収束させるためのものです。
これ、いますぐやっちゃダメって読めないですかね。ISLe さんが書きました:No.67に書きました。
CPlayer::Moveから除けたいのは、あたり判定(を直接呼び出している)部分。
カオス過ぎていますぐそれはできないので、少しずつ改善しようとしているところ、ことごとく先回りして改善の芽を潰す。
ある意味keito94さんの才能かもしれませんね。
わたしの文章がおかしいのかな。
あと、不思議な文言があるのに気づきました。
#前後のインパクトのほうが大きかったもので
「左右の当たり判定の部分は完成した」?keito94 さんが書きました:No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、
上下の当たり判定で、めり込んで左の壁まで行ってしまいます。
コードは完成していて、動作は理想と違う
というのがkeito94さんの最終形なのでしょう。
少なくともkeito94さんの態度が改まらない限りそこから変化しないと思います。
keito94さんとわたしでは世界線が違う。
keito94さんとわたしがやり取りを続けても収束しません。
わたしがここ数回オフトピで投稿しているのはわたしの世界線を収束させるためのものです。
Re: 坂道の当たり判定を作っています。
オフトピック
坂道に沿って上り下りするというのは、キャラを基準に移動するだけでなくプラスアルファが必要。
特に坂道を下るのは、補正に頼るとキャラが浮いてしまったりしてうまくない。
#逆にそれが活きるデザインもあるが。
なので、坂道の上り下りの際は、キャラを主体ではなく客体とする。
どういうことかと言うと…
・坂に入ったら、キャラは見えない動く床に乗った状態になる
・ユーザーの操作で動くのは見えない床で、キャラはその床に対して位置を保ちつつ、その場で足踏み
・坂道の端を超えて移動するあるいは途中でジャンプするなど坂道を離れたら、見えない動く床は消滅し、キャラは通常運転に戻る
という具合。
もちろんこれも方法の一つに過ぎず正解というものではない。
この方法のメリットは…
・動く床やエレベーター、エスカレーターなど応用できる(というかこちらから発想を得ている)
・コース設定次第で波やループなどどんな形状にも対応できる
・応用の幅を広げてもキャラの実装が重くならない
特に坂道を下るのは、補正に頼るとキャラが浮いてしまったりしてうまくない。
#逆にそれが活きるデザインもあるが。
なので、坂道の上り下りの際は、キャラを主体ではなく客体とする。
どういうことかと言うと…
・坂に入ったら、キャラは見えない動く床に乗った状態になる
・ユーザーの操作で動くのは見えない床で、キャラはその床に対して位置を保ちつつ、その場で足踏み
・坂道の端を超えて移動するあるいは途中でジャンプするなど坂道を離れたら、見えない動く床は消滅し、キャラは通常運転に戻る
という具合。
もちろんこれも方法の一つに過ぎず正解というものではない。
この方法のメリットは…
・動く床やエレベーター、エスカレーターなど応用できる(というかこちらから発想を得ている)
・コース設定次第で波やループなどどんな形状にも対応できる
・応用の幅を広げてもキャラの実装が重くならない
Re: 坂道の当たり判定を作っています。
すいませんでした…。
正確には当たり判定のコード自体は完成していたのですが、
なかなか理想通りの動きになりません…。
どうしたら、理想通りの動き(地上にいるときだけGroundFlagがtrueになったまま)になるのでしょうか?
正確には当たり判定のコード自体は完成していたのですが、
なかなか理想通りの動きになりません…。
どうしたら、理想通りの動き(地上にいるときだけGroundFlagがtrueになったまま)になるのでしょうか?
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
例えば、CCollision::GetXPosition関数の中にあるコード…keito94 さんが書きました:正確には当たり判定のコード自体は完成していたのですが、
(Collision.cpp:267行目~) block.xは、左端のブロックを0番目として右へ何個目かという数値が入ってます。
*myxは、キャラの中心のX座標がピクセル単位で入ってます。
まったく意味の違う数値を比較しているこのコード、正しいですか?
どうすればいいか(あるいはそのためのヒント)は既にNo.98,No.101に(さらにそれ以降も)書きました。keito94 さんが書きました:なかなか理想通りの動きになりません…。
どうしたら、理想通りの動き(地上にいるときだけGroundFlagがtrueになったまま)になるのでしょうか?
ですが、どうしたらkeito94さんが理解できるかはわたしには分かりません。
Re: 坂道の当たり判定を作っています。
ISLeさんのご指摘を受けて、ブロックの単位ではなく、座標で判定して見るようにしてみました。
でも、また新たなバグが発生してしまいました…。
実行すると、着地せずに画面外に落下します。
でも、また新たなバグが発生してしまいました…。
実行すると、着地せずに画面外に落下します。
- 添付ファイル
-
- Collision.zip
- (6.43 KiB) ダウンロード数: 451 回
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
CCollision::GetXPosition関数内keito94 さんが書きました:ISLeさんのご指摘を受けて、ブロックの単位ではなく、座標で判定して見るようにしてみました。
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);
}
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でもCCollision::GetYPositionでも、ifの条件が両方同時に成立していることが確認できるはずですが。keito94 さんが書きました:でも、また新たなバグが発生してしまいました…。
実行すると、着地せずに画面外に落下します。
このコードでは、画面外に消えるのが正常。
keito94さんは、トピにしてもコードにしても見直すのがめんどうくさいのでしょうか。
デバッグするのもめんどうくさいですか?
もしそうなら、プログラミングが好きではないのでしょう。
好きでもないのにプログラミングするのはつらいだけなのでやめたほうがいい。
仕事でないならプログラミングできなくて困るわけでもないでしょう。
あと、ゲームを好きでもないのにゲームを作ろうとするのもやめたほうがいい。
キャラをどう動かしていいか分からない、のでなくて、そもそもキャラがどう動くか知らないでしょう。
プログラミングできなくても既存ゲームをプレイして研究するとかはできますよね。
ゲームをプレイするのはめんどうくさいですか?
自分の作ってるゲームがどう動いているかにも興味ないですものね。
Re: 坂道の当たり判定を作っています。
ブロックの座標で当たり判定を実装しようとしています。
現在考えているのは、衝突したら一ブロックずらした座標で判定するということです。
(キャラの座標が中央基準なので…。)
ですが、地上に着地せずにめり込んで左に移動してしまいます。
左右の判定は一応完成しました。
現在考えているのは、衝突したら一ブロックずらした座標で判定するということです。
(キャラの座標が中央基準なので…。)
ですが、地上に着地せずにめり込んで左に移動してしまいます。
左右の判定は一応完成しました。
- 添付ファイル
-
- Collision.zip
- (6.43 KiB) ダウンロード数: 475 回
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
ブロックが等間隔に並んでいることが前提条件になりますよね。keito94 さんが書きました:現在考えているのは、衝突したら一ブロックずらした座標で判定するということです。
(キャラの座標が中央基準なので…。)
ですが、地上に着地せずにめり込んで左に移動してしまいます。
わざわざブロックが等間隔に並んでいないといけなくするメリットって何でしょう。
オフトピック
むしろ、坂道を実装するには邪魔になりそうな前提条件は排除していきたいが。
こちらも同時に成立する条件。
あいだにelseを入れたので、前回は常に右へ下へだったのが、今回は常に左へ上へとなった。
それだけ。
本質的に何も変わってない。
そうですか。keito94 さんが書きました:左右の判定は一応完成しました。
おつかれさまでした。
Re: 坂道の当たり判定を作っています。
添付されているソースファイルは、そうならないようにCPlayer::GroundFlag書き換えている箇所を移動してますね。keito94 さんが書きました:ですが、地上に着地せずにめり込んで左に移動してしまいます。
どうしてでしょうね。
Re: 坂道の当たり判定を作っています。
どうやって排除するのですか?ISLe さんが書きました: むしろ、坂道を実装するには邪魔になりそうな前提条件は排除していきたいが。
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
keito94さんは、“坂道を実装するには邪魔になりそうな前提条件”が何なのか分かっているのでしょうか。
分かっていないなら、差し当たって、目の前のコードを理解するところから始めましょう。
分かっているなら、どこがどうして問題なのか、説明して見せてください。
どうやって排除するか、を考えるのはそのあとです。
分かっていないなら、差し当たって、目の前のコードを理解するところから始めましょう。
分かっているなら、どこがどうして問題なのか、説明して見せてください。
どうやって排除するか、を考えるのはそのあとです。
Re: 坂道の当たり判定を作っています。
その問題というのは、CheckMapや、マップチップを確認する部分にあります。ISLe さんが書きました: 分かっているなら、どこがどうして問題なのか、説明して見せてください。
ブロックを左から何個目にあるかを判定する都合上、動いているブロックやキャラのX座標の位置がずれることが前提の上下の当たり判定で、
(今のコードでは)左へ上へ行ってしまうバグが起きてしまうことです。
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
分かっている、を選択しておいて、分かっていませんね。
キャラはピクセル単位で動くのだから、ピクセル単位で座標がずれるのは最初から想定内ですよ。
“坂道を実装するには邪魔になりそうな前提条件”は、たぶんkeito94さんが完璧だと思っているところ、にありますよ。
キャラはピクセル単位で動くのだから、ピクセル単位で座標がずれるのは最初から想定内ですよ。
そうなるようにコードを書き換えたのはkeito94さんですよ。keito94 さんが書きました:(今のコードでは)左へ上へ行ってしまうバグが起きてしまうことです。
「どこが」はまあ合ってますけど、たまたまですかね。keito94 さんが書きました:その問題というのは、CheckMapや、マップチップを確認する部分にあります。
“坂道を実装するには邪魔になりそうな前提条件”は、たぶんkeito94さんが完璧だと思っているところ、にありますよ。
Re: 坂道の当たり判定を作っています。
オフトピック
そういえば、No.47でリンクしたトピで、ブロックに当たったら当たる前の座標に戻す、という方針を採用する方向だったはずだけど、いまのコードには欠片も見当たらない。
当たる前の座標に戻せば、当たっていない状態に戻る、というのが悪魔の証明なので、それ以降スルーしてたのに。
前提条件がなければ、当たっていないとすることを保証できないのだから。
前提条件を積み重ねたコードはトピが解決してもずっと爆弾抱えたまま。
当たる前の座標に戻せば、当たっていない状態に戻る、というのが悪魔の証明なので、それ以降スルーしてたのに。
前提条件がなければ、当たっていないとすることを保証できないのだから。
前提条件を積み重ねたコードはトピが解決してもずっと爆弾抱えたまま。
Re: 坂道の当たり判定を作っています。
もしかしてめり込み防止の部分ですか?ISLe さんが書きました: “坂道を実装するには邪魔になりそうな前提条件”は、たぶんkeito94さんが完璧だと思っているところ、にありますよ。
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
「もしかして」?keito94 さんが書きました:もしかしてめり込み防止の部分ですか?
あてずっぽうですか?
あてずっぽうであたったとして何の意味があるんでしょう。
場所はCCollision::CheckMapで合ってると書いたのに。
#そこだけとは言ってないけど
ひとつは、ブロックとキャラが当たってるかどうか調べるのに、縁を何点かだけ調べているところですよ。
これは、ブロックが固定で等間隔に並んでいて、尚且つキャラとブロックが同一サイズというのが前提になる。
#keito94さんサイズ変えたらうまくいかないっていう質問を前にしてましたよね。
この前提では、ブロックがあるところは、全面ブロックである。
だから、ピクセル座標とブロック単位の座標が混在してもテキトーに誤魔化せてしまう。
いま実装しようとしてる坂道は、45度傾いていて、当たり判定のあるところとないところが半々に交じってる。
前提から外れたことを同じやり方でやろうとしたらどうなりますかね。
Re: 坂道の当たり判定を作っています。
ごめんなさい…やっぱりあってたんですね…ISLe さんが書きました: 場所はCCollision::CheckMapで合ってると書いたのに。
そりゃ、バグが発生するわけですね…。ISLe さんが書きました: 前提から外れたことを同じやり方でやろうとしたらどうなりますかね。
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
オフトピック
今思うと問題点だらけだったんだな…。
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
>>ISLeさん
…つまり、何が言いたいんですか?
…つまり、何が言いたいんですか?
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
Re: 坂道の当たり判定を作っています。
ブロックとキャラの当たり判定を書き直す必要がある、ということですよ。
keito94さんは、そこで使うべき方法を既に知っています。
RECT型の当たり判定について
こんどは返信がもらえるように頑張りましょう。
坂道の実装までまだまだ遠いので、新たにトピたてて仕切り直したほうが良いかもしれません。
keito94さんは、そこで使うべき方法を既に知っています。
RECT型の当たり判定について
こんどは返信がもらえるように頑張りましょう。
坂道の実装までまだまだ遠いので、新たにトピたてて仕切り直したほうが良いかもしれません。
Re: 坂道の当たり判定を作っています。
了解しました!ISLe さんが書きました:ブロックとキャラの当たり判定を書き直す必要がある、ということですよ。
keito94さんは、そこで使うべき方法を既に知っています。
RECT型の当たり判定について
こんどは返信がもらえるように頑張りましょう。
坂道の実装までまだまだ遠いので、新たにトピたてて仕切り直したほうが良いかもしれません。
一応この記事は今度こそ解決とさせてください!!
デバッグは投げ捨てるものではない。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。
今までの質問でこれは学んだこと。
質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。
仕様書の大切さを改めて思い知った…。