RECT型を使ってのめり込み防止の実装について。検索RECT型を使ってのめり込み防止の実装について。連絡するウェブサイトRECT型を使ってのめり込み防止の実装について。2年前C++初心者です。1の言うことに従って、RECT型で当たり判定を実装していますが、当たり判定の部分は実装できました。めり込み防止の部分となるとどうも考えがつきません。今現在僕が考えているルーチンは、1プレイヤーが衝突したら、地面の座標を返す。2地面の座標とプレイヤーの座標を比較する。3めり込んでいたら、プレイヤーをずらして当たる前にまで戻す。RECT型の当たり判定で、地面の座標を新しく作る予定の当たり判定プログラムに教える方法がわかりません。すればいいのでしょうか?それを教える方法が完成すれば後は楽にできるんです。添付してあるコードは一部のみなので、単体では動きません。回デバッグは投げ捨てるものではない。今までの質問でこれは学んだこと。質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。仕様書の大切さを改めて思い知った...。RECT型を使ってのめり込み防止の実装について。RECT型で当たり判定を実装していますが、当たり判定の部分は実装できました。ここは、敵キャラとの当たり判定だけにRECT使っています。いまやろうとしているのは、ブロックとの当たり判定にRECTを導入しようということではないのでしょうかね。そのまんま引っ張ってきて、無意味だ無駄だってやりとりを何度も繰り返すばかり。コード理解しようとしてくださいよ。オフトピックそもそもネットに転がってるサンプルコードがなあ。RECT型を使ってのめり込み防止の実装について。2年前ごめんなさい...。RECTは敵キャラとの当たり判定でしたか...。ルーチンはそのままなんですが、効率が良くて汎用性のあるブロック当たり判定がどうしても思いつかないんです...。衝突したブロックの座標を返すサンプルコードをくれませんか...。コード理解しようとしてくださいよ。デバッグは投げ捨てるものではない。今までの質問でこれは学んだこと。質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。仕様書の大切さを改めて思い知った...。RECT型を使ってのめり込み防止の実装について。効率が良くて汎用性のあるブロック当たり判定がどうしても思いつかないんです...。衝突したブロックの座標を返すサンプルコードをくれませんか...。いますぐやるべきは、CCollision::CheckMap関数にある、キャラとブロックの当たり判定をRECT構造体を使うように書き換えること。いまは動作そのものは変えなくていい。衝突したブロックの座標云々はRECT構造体使って衝突したブロックが分かるようにできてから。RECT型を使ってのめり込み防止の実装について。2年前ISLeさんに言われてRECT構造体に書き換えてみたのですがバグだらけです。回デバッグは投げ捨てるものではない。今までの質問でこれは学んだこと。質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。仕様書の大切さを改めて思い知った...。RECT型を使ってのめり込み防止の実装について。ISLeさんに言われてRECT構造体に書き換えてみたのですがバグだらけです。なにか、アドバイスはないのでしょうか?バグだらけなのはわたしの責任なんですか?何か書いても、書いた内容を理解する気はないように見えるし、無関係なところも含めてあちこちテキトーにいじくり回して問題を増やすし、さらにはその責任を押し付けられるのでは、何も書きたくないすなあ。No.1に添付してるRectCollision.cppとか、大元からめちゃくちゃいじくり回してるけど、No.5ではわざわざIntersectRect関数とは別に関数作ってたりするし、ほんとにコードいじくり回すだけで理解してないんだなって思います。#もちろん理解した上で使わないという選択肢はある。コードいじくり回す時間を、コードを理解する時間に回して欲しい。CCollision::CheckMap関数には、もうひとつ別の大きな問題があるんだけど、keito94さんが自力でそれに気付くのは無理かな。RECT構造体使って、点でなく形での当たり判定を想像したら、それに気付くと期待するのだけど、想像しないから。3めり込んでいたら、プレイヤーをずらして当たる前にまで戻す。「当たる前にまで戻す」?また方針転換ですか?あるいは、そもそもRECT構造体を使う理由を理解してないってことでしょうか。RECT型を使ってのめり込み防止の実装について。方針転換ですか?ごめんなさい...。ブロックに当たったら当たる前の座標に戻すでしたね...。頭のなかで勘違いしてしまいました...。後、添付しているソースコードでは、左の当たり判定の部分は実装されたのですが、右の当たり判定の部分がバグっているようです。回デバッグは投げ捨てるものではない。今までの質問でこれは学んだこと。質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。仕様書の大切さを改めて思い知った...。RECT型を使ってのめり込み防止の実装について。2年前http://dixq.net/forum/blog.php?u=2409&b=6635これを読んで下さい。今のコードはどうせバグバグ祭りだと思いますので...。理由はそこに書かれてあると思います。デバッグは投げ捨てるものではない。今までの質問でこれは学んだこと。質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。仕様書の大切さを改めて思い知った...。RECT型を使ってのめり込み防止の実装について。2年前プログラムを書けないのは仕方ないが、せめて最後にISLeさんにお詫びやお礼は書けないのだろうか。RECT型を使ってのめり込み防止の実装について。RECT型を使ってのめり込み防止の実装について。2年前ISLeさん、今まで色々ご迷惑をかけてごめんなさい...。C言語の素質がないことをようやく知りました...。ありがとうございました!!デバッグは投げ捨てるものではない。今までの質問でこれは学んだこと。質問する時は、必ずちゃんと調べた上に問題をもとにした仕様書を作ってから質問すること。仕様書の大切さを改めて思い知った...。RECT型を使ってのめり込み防止の実装について。ブロックに当たったら当たる前の座標に戻すでしたね...。頭のなかで勘違いしてしまいました...。いやいや、さらに酷くなってますよ。A.「当たったら」とは当たっていない状態から当たっている状態への『変化』B.「当たっている」とはその時点で当たっているという『状態』AとBの違いが分からないですかねえ。状態×変化のAは、状態だけのBより複雑になるのは明らか。わたしはずっと「めり込みの補正」と表現してますよ。Pythonを学んでこのような日本語のニュアンスの違いが分かるようになるといいですね。RECT型を使ってのめり込み防止の実装について。2年前オフトピックやたらサンプルコードよこせ言ってたけど、うちのブログは参考にならんかったかな。2010年の記事だしJavaだし。実験要素山盛りなのでそのままコピペはよろしくないから、せめて自力で見付けられるくらい意欲ある人でないとな。RECT型を使ってのめり込み防止の実装について。2年前やや雑談な書き込みです前の方の質問でことごとくズレた受け取り方をするのでデバッグ頑張れという形の認識になっただけマシかなと思っていましたが最近のスレの流れを見ると残念な形になってますね感覚的にはアクションゲームを作るには圧倒的に技術不足でオセロや五目並べレベルの簡易ゲームを作るべきなのでは?という感じ。RECT型を使ってのめり込み防止の実装について。2年前CCollision::CheckMapを改造。戻り値のRECTは、矩形ではなく、各方向に何ピクセルめり込んでいるかを表す。rcMoverは、CMoverクラスから直接持ってきたいところだが、引数周りを変えると変更点が多くなりすぎるので先送りとする。Game->MapData().GetChipHeight();//レイヤー1が四角形床。cheight;//坂道の当たり判定があるのなら、-2を返す。ミクプラは自由にリンクできます。