1ピクセルめり込んでいるとみなして押し戻すというふうにする。接しているかどうか判定するのは難しいけれど、重なっているかどうかなら簡単。坂道の当たり判定を作っています。後、重力の部分を分割してみました。これ、何か目的があるんですよね。コードに手を加えるというのは、バグを生む可能性を含みます。プログラムを台無しにするのと引き換えにしてもいいくらい意味のあることなんでしょうね。分からないので説明していただけませんか。上下の当たり判定で、めり込んで左の壁まで行ってしまいます。後、重力の部分を分割してみました。舌の根の乾かぬうちにってやつですね。No.67に書きました。CPlayer::Moveから除けたいのは、あたり判定(を直接呼び出している)部分。カオス過ぎていますぐそれはできないので、少しずつ改善しようとしているところ、ことごとく先回りして改善の芽を潰す。ある意味keito94さんの才能かもしれませんね。id=3,19205,145976]後、重力の部分を分割してみました。[/quote]これ、何か目的があるんですよね。コードに手を加えるというのは、バグを生む可能性を含みます。プログラムを台無しにするのと引き換えにしてもいいくらい意味のあることなんでしょうね。分からないので説明していただけませんか。上下の当たり判定で、めり込んで左の壁まで行ってしまいます。[u]後、重力の部分を分割してみました。[/u][/quote]正に舌の根の乾かぬうちにってやつですね。No.67に書きました。CPlayer::Moveから除けたいのは、あたり判定(を直接呼び出している)部分。カオス過ぎていますぐそれはできないので、少しずつ改善しようとしているところ、ことごとく先回りして改善の芽を潰す。ある意味keito94さんの才能かもしれませんね。坂道の当たり判定を作っています。タイルのサイズは16ピクセルであるのに、-8~8という範囲(=17ピクセル)を使って重要な判定をしている。今の発言を受けて、当たり判定のサイズを変更してみました。id=3,19205,145977]タイルのサイズは16ピクセルであるのに、-8~8という範囲(=17ピクセル)を使って重要な判定をしている。[/quote]今の発言を受けて、当たり判定のサイズを変更してみました。坂道の当たり判定を作っています。2年前オフトピック現時点で気になることを書き残しておきます。CCollision::GetXPosition関数などで、キャラ座標はピクセル単位でブロックはタイル単位と異なる座標系が混在しており、さらにキャラ座標は中心が基準となっているところに、さらにx,yなど数値をバラバラにやり取りしているため混乱に拍車をかけている。タイルのサイズは16ピクセルであるのに、-8~8という範囲(=17ピクセル)を使って重要な判定をしている。座標およびサイズ情報と当たり判定メソッド(のプロトタイプ)を持つCMoverクラスがあるのに、どうしてそれを使わないのだろうか。CPlayerはCMoverを継承しているのに、どうしてわざわざ情報をバラバラにして引数に渡すのだろうか。[offtopic]現時点で気になることを書き残しておきます。CCollision::GetXPosition関数などで、キャラ座標はピクセル単位でブロックはタイル単位と異なる座標系が混在しており、さらにキャラ座標は中心が基準となっているところに、さらにx,yなど数値をバラバラにやり取りしているため混乱に拍車をかけている。タイルのサイズは16ピクセルであるのに、-8~8という範囲(=17ピクセル)を使って重要な判定をしている。座標およびサイズ情報と当たり判定メソッド(のプロトタイプ)を持つCMoverクラスがあるのに、どうしてそれを使わないのだろうか。CPlayerはCMoverを継承しているのに、どうしてわざわざ情報をバラバラにして引数に渡すのだろうか。坂道の当たり判定を作っています。上下の当たり判定で、めり込んで左の壁まで行ってしまいます。後、重力の部分を分割してみました。上下の当たり判定で、めり込んで左の壁まで行ってしまいます。後、重力の部分を分割してみました。坂道の当たり判定を作っています。壁に当たった時、キャラをずらすアルゴリズムの例を上げてくれますか。0.1f);という文がそれであるということを認識する気もないっていう意味ですかね。認識すらする気がないのにどうやったら、例をあげて示すことができるんですかね。これ(↑)がそれですよ、ってのはkeito94さんが望む例ではないですよね。これは何かの哲学ですかね。No.81で言われた方法にしてみました。着地すると、キャラがぴょんぴょん跳ねる。左の壁に衝突すると、キャラが上に上がる。いうわけで、No.81で言った方法になってない(不十分)です。既存のコードを理解すればそのバグは直せるはずですが。keito94さんは、いつになったらプログラミングやデバッグを始めるつもりなんですか?無意味で無関係なコードがまた復活してたり、認識してないはずのコードがテキトーに変更されてますけど。コードの切り貼りしたいだけなら、結果がどうあれ、その状況を楽しめばいいんじゃないでしょうか。いうことなら、他人に正解(?)を求めるのは楽しみ方として間違っていると思います。巻き込まないでください。オフトピック同じことを3回繰り返したら、もはやサンプルとしての価値もない。id=3,19205,145958]壁に当たった時、キャラをずらすアルゴリズムの例を上げてくれますか。0.1f);という文がそれであるということを認識する気もないっていう意味ですかね。認識すらする気がないのにどうやったら、例をあげて示すことができるんですかね。これ(↑)がそれですよ、ってのはkeito94さんが望む例ではないですよね。これは何かの哲学ですかね。id=3,19205,145958]とりあえず、No.81で言われた方法にしてみました。現在確認されているバグは、[list][*]着地すると、キャラがぴょんぴょん跳ねる。[*]左の壁に衝突すると、キャラが上に上がる。[/list]となります。[/quote]というわけで、No.81で言った方法になってない(不十分)です。既存のコードを理解すればそのバグは直せるはずですが。keito94さんは、いつになったらプログラミングやデバッグを始めるつもりなんですか?無意味で無関係なコードがまた復活してたり、認識してないはずのコードがテキトーに変更されてますけど。コードの切り貼りしたいだけなら、結果がどうあれ、その状況を楽しめばいいんじゃないでしょうか。いうことなら、他人に正解(?)を求めるのは楽しみ方として間違っていると思います。巻き込まないでください。[offtopic]同じことを3回繰り返したら、もはやサンプルとしての価値もない。坂道の当たり判定を作っています。2年前とりあえず、No.81で言われた方法にしてみました。着地すると、キャラがぴょんぴょん跳ねる。左の壁に衝突すると、キャラが上に上がる。壁に当たった時、キャラをずらすアルゴリズムの例を上げてくれますか。回とりあえず、No.81で言われた方法にしてみました。現在確認されているバグは、[list][*]着地すると、キャラがぴょんぴょん跳ねる。[*]左の壁に衝突すると、キャラが上に上がる。[/list]となります。壁に当たった時、キャラをずらすアルゴリズムの例を上げてくれますか。坂道の当たり判定を作っています。なん...だと...。地上にいるというのは振る舞いだけだったのか...。『CPlayerは』『CPlayer::GroundFlagによってのみ』振る舞いを変えることでCPlayerの独立性が高まります。CPlayer::GroundFlagの変化とは無関係になるので、キャラの挙動と、ブロックのあたり判定それぞれ別々にデバッグが可能になる。いう内容のことをNo.47で書いているんですけどね。当時は理解できなかったとしても今は理解できるかもしれない。何回も読み直して理解しようという気はないのでしょうか。あと、バグの原因の特定も容易になる。挙動の変化がおかしいならCPlayer::GroundFlagを書き換えている場所を探せばいい。#CCollisionが直接書き換えているから問題をややこしくしているけども、まあそこは後回しでいい。今度こそ取り除かれたのではないのでしょうか?余計なことをしなければ、No.74で達成できていたのに。id=3,19205,145935]なん...だと...。地上にいるというのは振る舞いだけだったのか...。[/quote]『CPlayerは』『CPlayer::GroundFlagによってのみ』振る舞いを変えることでCPlayerの独立性が高まります。CPlayer::GroundFlagの変化とは無関係になるので、キャラの挙動と、ブロックのあたり判定それぞれ別々にデバッグが可能になる。いう内容のことをNo.47で書いているんですけどね。当時は理解できなかったとしても今は理解できるかもしれない。何回も読み直して理解しようという気はないのでしょうか。あと、バグの原因の特定も容易になる。挙動の変化がおかしいならCPlayer::GroundFlagを書き換えている場所を探せばいい。#CCollisionが直接書き換えているから問題をややこしくしているけども、まあそこは後回しでいい。id=3,19205,145934]今度こそ取り除かれたのではないのでしょうか?[/quote]余計なことをしなければ、No.74で達成できていたのに。坂道の当たり判定を作っています。キャラが地面にめり込むと地面に触れないぎりぎりの位置に座標補正されます。次のフレームで、それは地上に立っていることになるのでしょうか。なん...だと...。地上にいるというのは振る舞いだけだったのか...。前に一度CCollision::GetMoveからも取り除かれたのに、今は復活してますね。id=3,19205,145889]キャラが地面にめり込むと地面に触れないぎりぎりの位置に座標補正されます。次のフレームで、それは地上に立っていることになるのでしょうか。[/quote]なん...だと...。地上にいるというのは振る舞いだけだったのか...。id=3,19205,145934]前に一度CCollision::GetMoveからも取り除かれたのに、今は復活してますね。坂道の当たり判定を作っています。現在は移動量に依存していた部分を取り除いたところです。前に一度CCollision::GetMoveからも取り除かれたのに、今は復活してますね。CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。(混乱を招く回答すいません...。)それはわたしがNo.84で書いた表現をなぞっているだけですね。No.84では、それに対する問題の指摘も同時にしているのですが、理解できませんでしたか?No.85を見たら理解しようという気概を感じられませんけどね。画面右端のブロックに触れると右外に消えてしまう問題については、さらに前のNo.81で既に書いてます。keito94さんが方針変更されると思ったのでオフトピになってますが。id=3,19205,145913]現在は移動量に依存していた部分を取り除いたところです。[/quote]前に一度CCollision::GetMoveからも取り除かれたのに、今は復活してますね。id=3,19205,145913]CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。(混乱を招く回答すいません...。)[/quote]それはわたしがNo.84で書いた表現をなぞっているだけですね。No.84では、それに対する問題の指摘も同時にしているのですが、理解できませんでしたか?No.85を見たら理解しようという気概を感じられませんけどね。画面右端のブロックに触れると右外に消えてしまう問題については、さらに前のNo.81で既に書いてます。keito94さんが方針変更されると思ったのでオフトピになってますが。坂道の当たり判定を作っています。2年前ちなみに、これが現在のコードです。現在は移動量に依存していた部分を取り除いたところです。実行しても、落下状態にあるので、めり込んでしまいます。CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。(混乱を招く回答すいません...。回ちなみに、これが現在のコードです。現在は移動量に依存していた部分を取り除いたところです。実行しても、落下状態にあるので、めり込んでしまいます。CPlayer::GroundFlagはそれが真になっていると、地上にいるかのように振る舞うフラグです。(混乱を招く回答すいません...。坂道の当たり判定を作っています。移動量撤廃の方針を続けるならこのトピで続ければよいのでは。ごめんなさい、解決を撤回させてください。この方針を続けようと思います。id=3,145895]移動量撤廃の方針を続けるならこのトピで続ければよいのでは。[/quote]ごめんなさい、解決を撤回させてください。この方針を続けようと思います。坂道の当たり判定を作っています。2年前オフトピックとんでもない勘違いをしてしまった...。[offtopic]とんでもない勘違いをしてしまった...。坂道の当たり判定を作っています。解決させたのは撤回させてください。移動量撤廃を続けたいと思います。解決させたのは撤回させてください。移動量撤廃を続けたいと思います。坂道の当たり判定を作っています。移動量撤廃の方針を続けるならこのトピで続ければよいのでは。移動量を使うなら、元の木阿弥だという意味ですよ。新しいトピを立てても同じ内容のトピができるだけだと思うけども。そもそもkeito94さんがこのトピを読み直しているようすが見えない。わたしがkeito94さんのアップロードしたソースコードを過去の分も全部保存して、返信する都度、比較してここが変わったあそこが変わった、また同じことしてるだの、というふうなことをしているわけだけども。別に、わたしが苦労しているのを分かれだとか、何かを押し付けようというつもりはないよ。最低限そのくらいしないと内容を理解できないだろってこと。移動量撤廃の方針を続けるならこのトピで続ければよいのでは。移動量を使うなら、元の木阿弥だという意味ですよ。新しいトピを立てても同じ内容のトピができるだけだと思うけども。そもそもkeito94さんがこのトピを読み直しているようすが見えない。わたしがkeito94さんのアップロードしたソースコードを過去の分も全部保存して、返信する都度、比較してここが変わったあそこが変わった、また同じことしてるだの、というふうなことをしているわけだけども。別に、わたしが苦労しているのを分かれだとか、何かを押し付けようというつもりはないよ。最低限そのくらいしないと内容を理解できないだろってこと。坂道の当たり判定を作っています。2年前http://dixq.net/forum/viewtopic.php?f=3&t=19267一からトピックをやり直してみました。これ以降のめり込みなどに関する質問はここに書き込んでください。この件は一応解決とさせていただきます。http://dixq.net/forum/viewtopic.php?f=3&t=19267一からトピックをやり直してみました。これ以降のめり込みなどに関する質問はここに書き込んでください。この件は一応解決とさせていただきます。坂道の当たり判定を作っています。コードを上から下になぞるだけでなく、実際に動いているときの流れを意識してください。はーい、わかりました。id=3,19205,145889]コードを上から下になぞるだけでなく、実際に動いているときの流れを意識してください。[/quote]はーい、わかりました。坂道の当たり判定を作っています。2年前keito94さんは、CPlayer::GroundFlagが真のとき、地上に立っている状態と説明しました。CPlayer::GroundFlagが真のとき、キャラは地上に立っているように振る舞います。そこでは、実際にキャラが地上に居るかどうかは関係ありません。キャラが地面にめり込むと地面に触れないぎりぎりの位置に座標補正されます。次のフレームで、それは地上に立っていることになるのでしょうか。コードを上から下になぞるだけでなく、実際に動いているときの流れを意識してください。keito94さんは、CPlayer::GroundFlagが真のとき、地上に立っている状態と説明しました。CPlayer::GroundFlagが真のとき、キャラは地上に立っているように振る舞います。そこでは、実際にキャラが地上に居るかどうかは関係ありません。キャラが地面にめり込むと地面に触れないぎりぎりの位置に座標補正されます。次のフレームで、それは地上に立っていることになるのでしょうか。コードを上から下になぞるだけでなく、実際に動いているときの流れを意識してください。坂道の当たり判定を作っています。2年前オフトピックそろそろXとYで関数を分ける必要もない段階まできてたわけだけども。なると、めり込みを許容して押し戻すマリオ(ブラザーズ)タイプとめり込みを許容せず一気に移動のロックマンタイプを選択する余地も生まれるのだけども。マリオ(ブラザーズ)タイプ、ロックマンタイプってのはわたしが勝手に分類して言ってるだけだけども。[offtopic]そろそろXとYで関数を分ける必要もない段階まできてたわけだけども。なると、めり込みを許容して押し戻すマリオ(ブラザーズ)タイプとめり込みを許容せず一気に移動のロックマンタイプを選択する余地も生まれるのだけども。マリオ(ブラザーズ)タイプ、ロックマンタイプってのはわたしが勝手に分類して言ってるだけだけども。坂道の当たり判定を作っています。#むしろ無限ループを楽しんでください。移動量を使わないでどうやって判定するのか?といういちばんのキモを質問しないのですね。ここまで問題点をピンポイントであぶり出せたのに。ごめんなさい、その質問をしようと思っていたところでした...。間違った理解でコードをいじるからおかしなことになるのと違いますか。ごめんなさい、ちゃんとソースコードをしっかり読んでからやりたいと思います...。id=3,19205,145885]#むしろ無限ループを楽しんでください。id=3,145885]移動量を使わないでどうやって判定するのか?といういちばんのキモを質問しないのですね。ここまで問題点をピンポイントであぶり出せたのに。[/quote]ごめんなさい、その質問をしようと思っていたところでした...。id=3,145885]間違った理解でコードをいじるからおかしなことになるのと違いますか。[/quote]ごめんなさい、ちゃんとソースコードをしっかり読んでからやりたいと思います...。坂道の当たり判定を作っています。2年前オフトピックいちおう移動量を使わない方法を書いておきます。めり込んでいる対象のブロックは分かっているので、ブロックの座標とキャラの座標を比較して、どちらにずらしたほうが良いか決定します。移動量で決めると、例えばトンネル状のマップを抜けるとき、うっかりジャンプして天井ブロックに触れると、一気に入り口まで戻されるという現象が発生します。[offtopic]いちおう移動量を使わない方法を書いておきます。めり込んでいる対象のブロックは分かっているので、ブロックの座標とキャラの座標を比較して、どちらにずらしたほうが良いか決定します。移動量で決めると、例えばトンネル状のマップを抜けるとき、うっかりジャンプして天井ブロックに触れると、一気に入り口まで戻されるという現象が発生します。坂道の当たり判定を作っています。2年前No.76のkeito94さんが書いたCPlayer::GroundFlagの説明は正しいのでしょうか。間違った理解でコードをいじるからおかしなことになるのと違いますか。そもそも、コードに「~となるはず」なんてコメントありえません。引き算のつもりで足し算書いたのをPCが忖度して直してくれるはずもない。-引数の移動量が復活してますね。ここにきて、移動量撤廃の方針をひっくり返しますか。移動量を使わないでどうやって判定するのか?といういちばんのキモを質問しないのですね。ここまで問題点をピンポイントであぶり出せたのに。いや、別にいいんですよ。いう方針を選ぶかはkeito94さんの自由ですから。そちらを選ぶのなら、わたしはもうサポートできません(しません)。画面右外に消えてしまう原因を見付けて、直したのでしょう。わたしが提案する方針よりも、最初に見付けたサンプルコードのやり方を優先した。それだと坂道の実装でうまくないからこのトピができたのではないかと思うのですが...少なくともこのトピの内容を一からやり直すことは確定ですね。絶対不可能というわけではないと思うので、無限ループにならないように、頑張ってください。#むしろ無限ループを楽しんでください。No.76のkeito94さんが書いたCPlayer::GroundFlagの説明は正しいのでしょうか。間違った理解でコードをいじるからおかしなことになるのと違いますか。そもそも、コードに「~となるはず」なんてコメントありえません。引き算のつもりで足し算書いたのをPCが忖度して直してくれるはずもない。-引数の移動量が復活してますね。ここにきて、移動量撤廃の方針をひっくり返しますか。移動量を使わないでどうやって判定するのか?といういちばんのキモを質問しないのですね。ここまで問題点をピンポイントであぶり出せたのに。いや、別にいいんですよ。いう方針を選ぶかはkeito94さんの自由ですから。そちらを選ぶのなら、わたしはもうサポートできません(しません)。画面右外に消えてしまう原因を見付けて、直したのでしょう。わたしが提案する方針よりも、最初に見付けたサンプルコードのやり方を優先した。それだと坂道の実装でうまくないからこのトピができたのではないかと思うのですが...少なくともこのトピの内容を一からやり直すことは確定ですね。絶対不可能というわけではないと思うので、無限ループにならないように、頑張ってください。#むしろ無限ループを楽しんでください。坂道の当たり判定を作っています。新たなバグを発見しました。地上にいる時は、Y座標の移動量を0にしようとしているつもりなのですが、ブレークポイント無しで実行するとソースコードに書いてあるバグが発生して、地面にめり込んだ状態になります。新たなバグを発見しました。地上にいる時は、Y座標の移動量を0にしようとしているつもりなのですが、ブレークポイント無しで実行するとソースコードに書いてあるバグが発生して、地面にめり込んだ状態になります。坂道の当たり判定を作っています。2年前オフトピッククラスやメンバなどの役割りを決め、その役割り通りに且つ役割りを発揮できるように構成を考え、それらを繰り返し練っていく、というのがプログラミングの本質であると思う。コーディングは、それのアウトプットに過ぎない。コーディングという場合でも、過程においてのコーディングは思考を補助する役割りであると思う。役割りを考えず、役割りに基づいてコードを書いていないのであれば、それはプログラミングではない。プログラミング言語を使ったラクガキだ。ラクガキだから楽しいというのはあるかもしれない。あればラクガキを楽しめばいい。[offtopic]クラスやメンバなどの役割りを決め、その役割り通りに且つ役割りを発揮できるように構成を考え、それらを繰り返し練っていく、というのがプログラミングの本質であると思う。コーディングは、それのアウトプットに過ぎない。コーディングという場合でも、過程においてのコーディングは思考を補助する役割りであると思う。役割りを考えず、役割りに基づいてコードを書いていないのであれば、それはプログラミングではない。プログラミング言語を使ったラクガキだ。ラクガキだから楽しいというのはあるかもしれない。あればラクガキを楽しめばいい。坂道の当たり判定を作っています。CCollisionと言うのは当たり判定の処理を行うクラスです。それはCCollisionの説明になっていませんね。CPlayerも当たり判定の処理をしてますよね。CCollisionのメソッドを呼び出しているから。言えば、このプログラム自体も当たり判定の処理をしてますよね。そんな中でCCollisionの役割りとは何なんですか?それを説明できないから何でもかんでもCCollisionでやろうとしてCCollisionがないと動かないコードになってしまうのでしょう。CPlayer::GroundFlagと言うのは、キャラが地上に居るかどうかを管理する変数です。CPlayerで移動処理をして、CCollisionで当たり判定をチェックします。ジャンプした、もしくは空中にいる時はGroundFlagが偽になります。地上にいる時はGroundFlagが真になります。GroundFlagが真になっている時は落下を行わないはずです。これで間違いないですよね?CPlayer::Moveにはキャラが空中にいてもGroundFlagを真にするコードがありますよ。keito94さん自身が最近追加したコードですよね。説明と矛盾してますよ。あと、質問用のソースコードをリポジトリに上げてみました。GitHub云々書いたのは、バージョン管理ソフトを利用すれば変更の取り消しとか楽になると思ったからです。公開レポジトリなんかだとコンパイルエラーがある段階でリビジョン上げるのは良くないのでしょうかね。オフトピックわたしは、今回ので例えるとaddy,addx削った時点でレポジトリ更新してコメントにきちんと目的を書き、コンパイルエラーを潰すためであればそれはそれでリビジョンを消費するといった感じに、作業過程を細かく記録します。いう使い方だとGitHubは大げさなので、Subversionでローカルレポジトリ作ってやってますけどね。リポジトリとしてはひどいものだけど、開発の過程を見る・知る資料として有用である気がしてます。追記:今のコードで確認されている不具合は、左の当たり判定と、右の当たり判定が同時に出ていることと、落下を全くしないことと坂道を登りきると、キャラが消えてしまうことです。あとジャンプボタン押してもジャンプしませんね。キャラが消えてしまうというのは、画面の右端のブロックに触れた時点で座標補正されて画面の右側の外に消えるということですかね。こちらで確認してみた限りでは坂道を登りきるだけでは消えないみたいですが。ブレークポイント使ったりトレース実行したり、変数の値をウォッチしたりというデバッグはしていないのでしょうか。それらの不具合は全部No.71のあとからNo.74までのあいだに発生したものですよね。keito94さん自身が仕込んだもので、環境依存等で勝手に生まれたバグではない。いちいち頭使って考えなくても、コードの差異を見れば原因の特定は難しくないと思うんですけどね。id=3,19205,145864]CCollisionと言うのは当たり判定の処理を行うクラスです。[/quote]それはCCollisionの説明になっていませんね。CPlayerも当たり判定の処理をしてますよね。CCollisionのメソッドを呼び出しているから。言えば、このプログラム自体も当たり判定の処理をしてますよね。そんな中でCCollisionの役割りとは何なんですか?それを説明できないから何でもかんでもCCollisionでやろうとしてCCollisionがないと動かないコードになってしまうのでしょう。id=3,19205,145864]CPlayer::GroundFlagと言うのは、キャラが地上に居るかどうかを管理する変数です。CPlayerで移動処理をして、CCollisionで当たり判定をチェックします。ジャンプした、もしくは空中にいる時はGroundFlagが偽になります。地上にいる時はGroundFlagが真になります。GroundFlagが真になっている時は落下を行わないはずです。これで間違いないですよね?[/quote]CPlayer::Moveにはキャラが空中にいてもGroundFlagを真にするコードがありますよ。keito94さん自身が最近追加したコードですよね。説明と矛盾してますよ。id=3,19205,145864]あと、質問用のソースコードをリポジトリに上げてみました。[/quote]GitHub云々書いたのは、バージョン管理ソフトを利用すれば変更の取り消しとか楽になると思ったからです。公開レポジトリなんかだとコンパイルエラーがある段階でリビジョン上げるのは良くないのでしょうかね。[offtopic]わたしは、今回ので例えるとaddy,addx削った時点でレポジトリ更新してコメントにきちんと目的を書き、コンパイルエラーを潰すためであればそれはそれでリビジョンを消費するといった感じに、作業過程を細かく記録します。いう使い方だとGitHubは大げさなので、Subversionでローカルレポジトリ作ってやってますけどね。リポジトリとしてはひどいものだけど、開発の過程を見る・知る資料として有用である気がしてます。id=3,19205,145864]追記:今のコードで確認されている不具合は、左の当たり判定と、右の当たり判定が同時に出ていることと、落下を全くしないことと坂道を登りきると、キャラが消えてしまうことです。[/quote]あとジャンプボタン押してもジャンプしませんね。キャラが消えてしまうというのは、画面の右端のブロックに触れた時点で座標補正されて画面の右側の外に消えるということですかね。こちらで確認してみた限りでは坂道を登りきるだけでは消えないみたいですが。ブレークポイント使ったりトレース実行したり、変数の値をウォッチしたりというデバッグはしていないのでしょうか。それらの不具合は全部No.71のあとからNo.74までのあいだに発生したものですよね。keito94さん自身が仕込んだもので、環境依存等で勝手に生まれたバグではない。いちいち頭使って考えなくても、コードの差異を見れば原因の特定は難しくないと思うんですけどね。坂道の当たり判定を作っています。2年前>>ISLeさん簡単に説明します。CCollisionと言うのは当たり判定の処理を行うクラスです。CPlayer::GroundFlagと言うのは、キャラが地上に居るかどうかを管理する変数です。CPlayerで移動処理をして、CCollisionで当たり判定をチェックします。ジャンプした、もしくは空中にいる時はGroundFlagが偽になります。地上にいる時はGroundFlagが真になります。GroundFlagが真になっている時は落下を行わないはずです。これで間違いないですよね?あと、質問用のソースコードをリポジトリに上げてみました。プロジェクトにこのコードを追加してください。オフトピック変にいじると大変なことになるのね...。追記:今のコードで確認されている不具合は、左の当たり判定と、右の当たり判定が同時に出ていることと、落下を全くしないことと坂道を登りきると、キャラが消えてしまうことです。>>ISLeさん簡単に説明します。CCollisionと言うのは当たり判定の処理を行うクラスです。CPlayer::GroundFlagと言うのは、キャラが地上に居るかどうかを管理する変数です。CPlayerで移動処理をして、CCollisionで当たり判定をチェックします。ジャンプした、もしくは空中にいる時はGroundFlagが偽になります。地上にいる時はGroundFlagが真になります。GroundFlagが真になっている時は落下を行わないはずです。これで間違いないですよね?あと、質問用のソースコードをリポジトリに上げてみました。プロジェクトにこのコードを追加してください。[url=https://github.com/keito940/ActionQ.]こちら[/url]です。[offtopic]変にいじると大変なことになるのね...。[/offtopic]追記:今のコードで確認されている不具合は、左の当たり判定と、右の当たり判定が同時に出ていることと、落下を全くしないことと坂道を登りきると、キャラが消えてしまうことです。坂道の当たり判定を作っています。2年前そもそもCCollisionクラスって何なんですか?クラスの役割りを説明できますか?説明できないのにただいじくり回しているだけならキリがないのでやめましょう。No.47で書いたように、プレイヤーキャラは、地面に着いているから落下しない、のでなく、(プレイヤーキャラ自身が)落下する状態でないから落下しない、ようにすれば落下しなくなります。いう目的に使える情報は既にCPlayerクラスにありますよね。CPlayer::GroundFlagってありますよね。CPlayer::GroundFlagって何ですか?これも役割りを説明できますか?CCollisionのアウトプットとして、地面に突き上げられてるという情報を得る方法を作るというのであれば分かります。CCollisionクラスにAirFlagというメンバを追加して、CPlayerがCCollisionを監視しなければならない依存関係を新たに作る意味が分かりません。それと、新たにバグを仕込みましたねって伝えましたよね。仕込んだところを直してほしい、というかただコードを元に戻せばいいだけなのですが...どこが変わったか見れば一目瞭然だと思うんですが。#GitHubとか何のためにあるのだろうトピを見直しているようすが見られないところから、自分で考える気がないように見えます。そもそもCCollisionクラスって何なんですか?クラスの役割りを説明できますか?説明できないのにただいじくり回しているだけならキリがないのでやめましょう。id=3,19205,145860]No.47で書いたように、プレイヤーキャラは、地面に着いているから落下しない、のでなく、(プレイヤーキャラ自身が)落下する状態でないから落下しない、ようにすれば落下しなくなります。いう目的に使える情報は既にCPlayerクラスにありますよね。[/quote]CPlayer::GroundFlagってありますよね。CPlayer::GroundFlagって何ですか?これも役割りを説明できますか?CCollisionのアウトプットとして、地面に突き上げられてるという情報を得る方法を作るというのであれば分かります。CCollisionクラスにAirFlagというメンバを追加して、CPlayerがCCollisionを監視しなければならない依存関係を新たに作る意味が分かりません。それと、新たにバグを仕込みましたねって伝えましたよね。仕込んだところを直してほしい、というかただコードを元に戻せばいいだけなのですが...どこが変わったか見れば一目瞭然だと思うんですが。#GitHubとか何のためにあるのだろうトピを見直しているようすが見られないところから、自分で考える気がないように見えます。坂道の当たり判定を作っています。(プレイヤーキャラ自身が)落下する状態でないから落下しないそれを自分なりに実装してみたのですが、今度はキャラが落下しません。ジャンプすらできません。何か落下する状態を管理する部分にバグが有るようなのですがそれはどこなのでしょうか?オフトピックやっぱりプログラムって大変...。id=3,145860](プレイヤーキャラ自身が)落下する状態でないから落下しない[/quote]それを自分なりに実装してみたのですが、今度はキャラが落下しません。ジャンプすらできません。何か落下する状態を管理する部分にバグが有るようなのですがそれはどこなのでしょうか?[offtopic]やっぱりプログラムって大変...。坂道の当たり判定を作っています。僕の頭の中のコードでは、どう頑張っても、めり込み補正の部分とY座標の部分で移動量に頼ってしまいます。移動量に頼らないめり込み防止のサンプルコードをください。いちいち頭で考えなくても、引数の宣言からaddx,addyをまるまる取り除けば、変更が必要な部分はコンパイラが教えてくれますよ。今上げたコードでは、常に落下しているので、最終的にはキャラが画面外に移動します。常に落下してしまうのはどうしてなのか、というところに頭を使いましょうよ。No.47で書いたように、プレイヤーキャラは、地面に着いているから落下しない、のでなく、(プレイヤーキャラ自身が)落下する状態でないから落下しない、ようにすれば落下しなくなります。いう目的に使える情報は既にCPlayerクラスにありますよね。No.70に書いた、削らなくていいところというのは、その情報を書き換えている部分なので、ここでも新たにバグを仕込んでいるというわけです。(物理的に)切り分けないとこういうことが頻繁に起きてキリがないのです。id=3,19205,145809]僕の頭の中のコードでは、どう頑張っても、めり込み補正の部分とY座標の部分で移動量に頼ってしまいます。移動量に頼らないめり込み防止のサンプルコードをください。[/quote]いちいち頭で考えなくても、引数の宣言からaddx,addyをまるまる取り除けば、変更が必要な部分はコンパイラが教えてくれますよ。id=3,19205,145809]なお、今上げたコードでは、常に落下しているので、最終的にはキャラが画面外に移動します。[/quote]常に落下してしまうのはどうしてなのか、というところに頭を使いましょうよ。No.47で書いたように、プレイヤーキャラは、地面に着いているから落下しない、のでなく、(プレイヤーキャラ自身が)落下する状態でないから落下しない、ようにすれば落下しなくなります。いう目的に使える情報は既にCPlayerクラスにありますよね。No.70に書いた、削らなくていいところというのは、その情報を書き換えている部分なので、ここでも新たにバグを仕込んでいるというわけです。(物理的に)切り分けないとこういうことが頻繁に起きてキリがないのです。坂道の当たり判定を作っています。2年前オフトピックやっぱり自分でプログラムするのっていいもんなんだな...。[offtopic]やっぱり自分でプログラムするのっていいもんなんだな...。坂道の当たり判定を作っています。僕の頭の中のコードでは、どう頑張っても、めり込み補正の部分とY座標の部分で移動量に頼ってしまいます。移動量に頼らないめり込み防止のサンプルコードをください。今上げたコードでは、常に落下しているので、最終的にはキャラが画面外に移動します。僕の頭の中のコードでは、どう頑張っても、めり込み補正の部分とY座標の部分で移動量に頼ってしまいます。移動量に頼らないめり込み防止のサンプルコードをください。今上げたコードでは、常に落下しているので、最終的にはキャラが画面外に移動します。坂道の当たり判定を作っています。2年前あと、(いまのところ)削らなくていいものまで削ってますね。あと、(いまのところ)削らなくていいものまで削ってますね。坂道の当たり判定を作っています。ISLeさんが考えている当たり判定のアルゴリズムに変えてみました。中途半端に変更したのですね。これをわたしが考えたと言われるのはかなり抵抗あります。addxとaddyを0にしないとまともに動作しません。(このステージでは関係ないんですが...。)それはそうでしょうね。わたしがNo.63で書いた、移動量を何回も加算してしまわないだろうか、と懸念していたことを新たにやらかしてます。このステージでは関係ない...ほんとうにそうでしょうか。坂道を登りきる前に坂道の判定が消える、ような気がしますが。して中途半端なのは、CCollision::GetMoveにある落下に関する移動量の処理をどこに移動したらいいか分からなかった(あるいは移動させるのが面倒だった)から、その前後を適当に誤魔化したのでしょうか。CCollisionから移動量を完全に排除しようという意志が感じられないですね。id=3,19205,145782]ISLeさんが考えている当たり判定のアルゴリズムに変えてみました。[/quote]ずいぶん中途半端に変更したのですね。これをわたしが考えたと言われるのはかなり抵抗あります。id=3,19205,145782]addxとaddyを0にしないとまともに動作しません。(このステージでは関係ないんですが...。)[/quote]それはそうでしょうね。わたしがNo.63で書いた、移動量を何回も加算してしまわないだろうか、と懸念していたことを新たにやらかしてます。このステージでは関係ない...ほんとうにそうでしょうか。坂道を登りきる前に坂道の判定が消える、ような気がしますが。して中途半端なのは、CCollision::GetMoveにある落下に関する移動量の処理をどこに移動したらいいか分からなかった(あるいは移動させるのが面倒だった)から、その前後を適当に誤魔化したのでしょうか。CCollisionから移動量を完全に排除しようという意志が感じられないですね。坂道の当たり判定を作っています。2年前ISLeさんが考えている当たり判定のアルゴリズムに変えてみました。addxとaddyを0にしないとまともに動作しません。(このステージでは関係ないんですが...。)オフトピックなるほど、こうゆうことだったのか...。回ISLeさんが考えている当たり判定のアルゴリズムに変えてみました。addxとaddyを0にしないとまともに動作しません。(このステージでは関係ないんですが...。)[offtopic]なるほど、こうゆうことだったのか...。坂道の当たり判定を作っています。}}パターンA,Bともに結果は同じです。パターンAは、補正が必要なときに、pをいったん更新するのを避けられます。pを格納する変数が更新されないだけで、計算はしますし、それは当たり判定の対象の数だけ繰り返されます。純粋に移動だけのテストをしたいと思いました。それ以外を除外します。pにaを加える}パターンA'では移動しなくなってしまいました。パターンAで移動の処理が正しいかテストするためには、当たり判定と補正の処理を(いちいち)調整しなければいけません。ところが、当たり判定と補正の処理が正しく動作している保証がありません。したら、移動の処理が正しいか、当たり判定や補正の処理が正しいか、証明できるのでしょう。パターンBは実際にはこのように変形して使います。}}移動するオブジェクトが、自分以外に何が存在するか知っている必要ありません。知っていたら自分以外のオブジェクトが増えたりしたとき変更に巻き込まれることになるからです。{pをめり込んでいない位置に補正}}}[/code]パターンA,Bともに結果は同じです。パターンAは、補正が必要なときに、pをいったん更新するのを避けられます。pを格納する変数が更新されないだけで、計算はしますし、それは当たり判定の対象の数だけ繰り返されます。純粋に移動だけのテストをしたいと思いました。それ以外を除外します。{aを生成pにaを加える}[/code]パターンA'では移動しなくなってしまいました。パターンAで移動の処理が正しいかテストするためには、当たり判定と補正の処理を(いちいち)調整しなければいけません。ところが、当たり判定と補正の処理が正しく動作している保証がありません。したら、移動の処理が正しいか、当たり判定や補正の処理が正しいか、証明できるのでしょう。パターンBは実際にはこのように変形して使います。{pをめり込んでいない位置に補正}}[/code]移動するオブジェクトが、自分以外に何が存在するか知っている必要ありません。知っていたら自分以外のオブジェクトが増えたりしたとき変更に巻き込まれることになるからです。坂道の当たり判定を作っています。出力する引数は、ポインタをつけろというわけですね...。ここは(いまのところ)結果に影響を与えていないので、単に、引数に与えた値(特に現在座標と移動量)の変化を把握していないのではないかという疑問を補強する意味で指摘しました。いう意味では今回の変更においても疑問は一切解消されていません。あと、入れ子化していた部分を修正しました。階層が1段増えましたね。これを修正というのでしょうか。わたしには改悪にしか見えませんが。id=3,19205,145760]出力する引数は、ポインタをつけろというわけですね...。[/quote]ここは(いまのところ)結果に影響を与えていないので、単に、引数に与えた値(特に現在座標と移動量)の変化を把握していないのではないかという疑問を補強する意味で指摘しました。いう意味では今回の変更においても疑問は一切解消されていません。id=3,19205,145760]あと、入れ子化していた部分を修正しました。[/quote]階層が1段増えましたね。これを修正というのでしょうか。わたしには改悪にしか見えませんが。坂道の当たり判定を作っています。2年前オフトピック今の修正で、坂道の壁としての当たり判定も楽にできるかなって...。今思うとはじめのコードは汚い上に、なんか変な要素満載だったな...。早くに気づいていれば、良かったなと思うこの頃。[offtopic]今の修正で、坂道の壁としての当たり判定も楽にできるかなって...。今思うとはじめのコードは汚い上に、なんか変な要素満載だったな...。早くに気づいていれば、良かったなと思うこの頃。坂道の当たり判定を作っています。2年前ISLeさん、ご指摘ありがとうございます。出力する引数は、ポインタをつけろというわけですね...。あと、入れ子化していた部分を修正しました。回ISLeさん、ご指摘ありがとうございます。出力する引数は、ポインタをつけろというわけですね...。あと、入れ子化していた部分を修正しました。坂道の当たり判定を作っています。ISLeさんが指摘した、移動先座標での判定の部分を、移動量を足した判定に変更してみました。CheckMapの部分は、addxかaddyのどちらかが、0でなければ正しく動作しない仕様となってます。直しているとき、他に、移動量渡してない関数があることに気付きませんでした?あと、現在座標と移動量のポインタを引数で渡して、当たり判定の結果によって、書き換えたり書き換えなかったりするわけですが、それが3段くらいの入れ子になっているので、書き換えた内容が上書きされるのではないだろうか、とか、移動量を何回も加算してしまわないだろうか、とかのうっかりミスをやらかしてしまっている可能性を考えるとキリがないですよね。キリがないのでわたしは早々に考えることをやめてしまうのですが、keito94さんはその辺すべて把握されておられるのでしょうか。マップから坂道の情報を取得するところで、ポインタではない引数を書き換えて、呼び出し元でそれを利用しようとしているところなんかを見ると、引数に対して無頓着なのではないかという気がするんですが。この場合、書き換えた内容はとうぜん呼び出し元には返らないわけで。してわざわざ分かりにくくミスしやすくしているのかが、わたしには理解できないところです。id=3,19205,145756]ISLeさんが指摘した、移動先座標での判定の部分を、移動量を足した判定に変更してみました。CheckMapの部分は、addxかaddyのどちらかが、0でなければ正しく動作しない仕様となってます。[/quote]直しているとき、他に、移動量渡してない関数があることに気付きませんでした?あと、現在座標と移動量のポインタを引数で渡して、当たり判定の結果によって、書き換えたり書き換えなかったりするわけですが、それが3段くらいの入れ子になっているので、書き換えた内容が上書きされるのではないだろうか、とか、移動量を何回も加算してしまわないだろうか、とかのうっかりミスをやらかしてしまっている可能性を考えるとキリがないですよね。キリがないのでわたしは早々に考えることをやめてしまうのですが、keito94さんはその辺すべて把握されておられるのでしょうか。マップから坂道の情報を取得するところで、ポインタではない引数を書き換えて、呼び出し元でそれを利用しようとしているところなんかを見ると、引数に対して無頓着なのではないかという気がするんですが。この場合、書き換えた内容はとうぜん呼び出し元には返らないわけで。してわざわざ分かりにくくミスしやすくしているのかが、わたしには理解できないところです。坂道の当たり判定を作っています。2年前ISLeさんが指摘した、移動先座標での判定の部分を、移動量を足した判定に変更してみました。CheckMapの部分は、addxかaddyのどちらかが、0でなければ正しく動作しない仕様となってます。回ISLeさんが指摘した、移動先座標での判定の部分を、移動量を足した判定に変更してみました。CheckMapの部分は、addxかaddyのどちらかが、0でなければ正しく動作しない仕様となってます。坂道の当たり判定を作っています。2年前わたしがVector2の修正を指摘した時点では、それを適用すると上下動は無くなり、坂道に対する当たり判定そのものがなくなったように動作していました。最新の状態では、上下動は再び発生しています。原因が異なるであろうため前とは若干挙動が違います。プレイヤーの移動処理をCPlayerクラスからCCollisionクラスに丸投げしているところで一気に読む気を削がれるのですが、何とか耐えて坂道関連の処理をひととおり読んでみました。読んでみましたが理解するのは無理でした。場所によって、移動先の座標で判定してその結果で移動元の座標を更新していたり、移動先の座標を引数で渡してさらに移動量を加えて使っていたり、当たり判定(の計算部分)が合っていようがまともに動くはずもなく、当たり判定が合っているかどうかなんてどうでもいい気持ちになりました。読む前に感じてたのと感想としては同じです。それが確信に変わっただけでした。そもそもkeito94さんは、いまのコードで平らな面の上を水平に移動できている仕組みを理解しているのでしょうか。#面倒くさい上に誤魔化しにすぎない移動先判定をやめてしまえばいいのに。わたしがVector2の修正を指摘した時点では、それを適用すると上下動は無くなり、坂道に対する当たり判定そのものがなくなったように動作していました。最新の状態では、上下動は再び発生しています。原因が異なるであろうため前とは若干挙動が違います。プレイヤーの移動処理をCPlayerクラスからCCollisionクラスに丸投げしているところで一気に読む気を削がれるのですが、何とか耐えて坂道関連の処理をひととおり読んでみました。読んでみましたが理解するのは無理でした。場所によって、移動先の座標で判定してその結果で移動元の座標を更新していたり、移動先の座標を引数で渡してさらに移動量を加えて使っていたり、当たり判定(の計算部分)が合っていようがまともに動くはずもなく、当たり判定が合っているかどうかなんてどうでもいい気持ちになりました。読む前に感じてたのと感想としては同じです。それが確信に変わっただけでした。そもそもkeito94さんは、いまのコードで平らな面の上を水平に移動できている仕組みを理解しているのでしょうか。#面倒くさい上に誤魔化しにすぎない移動先判定をやめてしまえばいいのに。坂道の当たり判定を作っています。2年前もしかして、こうではないのでしょうか?CheckSlopeの部分で座標と移動量を参照しておくように変更しました。回もしかして、こうではないのでしょうか?CheckSlopeの部分で座標と移動量を参照しておくように変更しました。坂道の当たり判定を作っています。2年前こんばんはソース拝見しました。表示させたい数字が変わったいろんな数字を表示させたいとなった場合、処理をひとまとめにしてしまっているFunc関数だけでは不便な気がしませんか?処理を機能ごとに分割すれば、仕様に何か変更があってもソースの変更はほんのわずかで済みます。keito94さんの場合、単純にColSegmentsを別ファイルに分離しているだけなので見やすくはなったかもしれませんが、処理内容は変わっていないのでISLeさんのいう分離とは違うような気がしました^^;オフトピック最初私はColSegments内の処理が間違っているせいで坂道移動ががくがくすると思っていましたが、どうやら原因はVector2のほうにあったようですね。_)>こんばんはソース拝見しました。;//Add関数で計算、Print関数で表示している}[/code]たとえばこのようなコードがあったときに、[list][*]表示させたい数字が変わった[*]いろんな数字を表示させたい[/list]となった場合、処理をひとまとめにしてしまっているFunc関数だけでは不便な気がしませんか?処理を機能ごとに分割すれば、仕様に何か変更があってもソースの変更はほんのわずかで済みます。keito94さんの場合、単純にColSegmentsを別ファイルに分離しているだけなので見やすくはなったかもしれませんが、処理内容は変わっていないのでISLeさんのいう分離とは違うような気がしました^^;[offtopic]最初私はColSegments内の処理が間違っているせいで坂道移動ががくがくすると思っていましたが、どうやら原因はVector2のほうにあったようですね。坂道の当たり判定を作っています。2年前No.57のアルゴリズムをもとにしたソースをCollision.zipに添付します。追記:http://dixq.net/forum/blog.php?u=900&b=6581でISLeさんに指摘されたので、ColSegmentを分離しました。回No.57のアルゴリズムをもとにしたソースをCollision.zipに添付します。追記:[url]http://dixq.net/forum/blog.php?u=900&b=6581[/url]でISLeさんに指摘されたので、ColSegmentを分離しました。坂道の当たり判定を作っています。2年前ごめんなさい、わかりにくかったですね...。1プレイヤーが坂道のところに来たら、坂道のパラメーターを設定します。(坂道の線分を設定する。)2坂道のパラメーターをもとにプレイヤーのパラメーターを設定します。(具体的にはSlopeCondというパラメーターで、坂道か天井か、(右方向から見て)上りか下りかをもとにプレイヤーの線分を設定する。)3プレイヤーの足元の点(プレイヤーの線分の終点が、)が、坂道の開始地点と終了地点の間にいたら(坂道の線分の間にいれば)、プレイヤーの線分と坂道の線分で当たり判定を行います。4プレイヤーが坂道のところを離れたら、坂道の当たり判定を終了して、四角形の床の当たり判定を行います。5坂道にプレイヤーが衝突していたら、プレイヤーの座標に坂道の内分比を足してめり込み防止をします。6下りの時は、プレイヤーが衝突しないと思うので、プレイヤーの座標に内分比を引いてめり込み防止をします。7そして、プレイヤーが坂道を歩いているように見えたら完成です。オフトピックもしかしたらまだまだ、説明不足な点があるかも...。追記:少し修正しました。ごめんなさい、わかりにくかったですね...。1プレイヤーが坂道のところに来たら、坂道のパラメーターを設定します。(坂道の線分を設定する。)2坂道のパラメーターをもとにプレイヤーのパラメーターを設定します。(具体的にはSlopeCondというパラメーターで、坂道か天井か、(右方向から見て)上りか下りかをもとにプレイヤーの線分を設定する。)3プレイヤーの足元の点(プレイヤーの線分の終点が、)が、坂道の開始地点と終了地点の間にいたら(坂道の線分の間にいれば)、プレイヤーの線分と坂道の線分で当たり判定を行います。4プレイヤーが坂道のところを離れたら、坂道の当たり判定を終了して、四角形の床の当たり判定を行います。5坂道にプレイヤーが衝突していたら、プレイヤーの座標に坂道の内分比を足してめり込み防止をします。6下りの時は、プレイヤーが衝突しないと思うので、プレイヤーの座標に内分比を引いてめり込み防止をします。7そして、プレイヤーが坂道を歩いているように見えたら完成です。[offtopic]もしかしたらまだまだ、説明不足な点があるかも...。[/offtopic]追記:少し修正しました。坂道の当たり判定を作っています。坂道の当たり判定を作っています。2年前あと、なんとかスパゲッティコードを解消させてみました...。Collision.cppのGetMoveを見ればわかると思いますが、坂道にプレイヤーが居るのなら、ブロックとしての当たり判定を中断させ、坂道の当たり判定へ移行します。GetSlopeでdefaultのところへ来たらそれはブロックとして判定します。昇り降りは、まだ作っておりません。これから質問の答を参照して作りたいと思います。回あと、なんとかスパゲッティコードを解消させてみました...。Collision.cppのGetMoveを見ればわかると思いますが、坂道にプレイヤーが居るのなら、ブロックとしての当たり判定を中断させ、坂道の当たり判定へ移行します。GetSlopeでdefaultのところへ来たらそれはブロックとして判定します。昇り降りは、まだ作っておりません。これから質問の答を参照して作りたいと思います。坂道の当たり判定を作っています。ログインしたユーザーしか見ることができない場所に書かれた他人の文章を、ログインせず誰でも見ることができる場所に張り付ける行為。非常識ではないですか?すいません、ソースをはっきりさせたいと思います...。1坂道として判定されたら、坂道の線分を生成する。2プレイヤーの線分を生成する。3プレイヤーの線分の終点が、坂道の線分の間であれば、プレイヤーの線分と坂道の線分で線分の当たり判定を行う。4線分と線分が交差していたらそれは当たったことになる。5当たっていたのなら、プレイヤーの座標と坂道の内分比を引いてそれをプレイヤーの座標にしてめり込み防止を行う。6下りのときは交差されないと思うのでその場合はプレイヤーの座標と坂道の内分比を足してそれをプレイヤーの座標にする。7そして、プレイヤーが坂道を歩いているように見えたら完成。したらどこか間違っているのかもしれません...。id=3,19205,145698]ログインしたユーザーしか見ることができない場所に書かれた他人の文章を、ログインせず誰でも見ることができる場所に張り付ける行為。非常識ではないですか?[/quote]すいません、ソースをはっきりさせたいと思います...。http://dixq.net/forum/blog.php?u=900&b=6581のusaoさんの投稿で、アルゴリズムの説明がなされてないと指摘されてたので答えたいと思います。1坂道として判定されたら、坂道の線分を生成する。2プレイヤーの線分を生成する。3プレイヤーの線分の終点が、坂道の線分の間であれば、プレイヤーの線分と坂道の線分で線分の当たり判定を行う。4線分と線分が交差していたらそれは当たったことになる。5当たっていたのなら、プレイヤーの座標と坂道の内分比を引いてそれをプレイヤーの座標にしてめり込み防止を行う。6下りのときは交差されないと思うのでその場合はプレイヤーの座標と坂道の内分比を足してそれをプレイヤーの座標にする。7そして、プレイヤーが坂道を歩いているように見えたら完成。したらどこか間違っているのかもしれません...。坂道の当たり判定を作っています。2年前ログインしたユーザーしか見ることができない場所に書かれた他人の文章を、ログインせず誰でも見ることができる場所に張り付ける行為。非常識ではないですか?No.33と違い、No.51は明らかに無断転載でしょう。このトピックをログインせずに見るひとからしたら、まったく意味不明ですよ。いう脈略のないところがコードにも表れているのと違いますか。ISLeさん、言い方が悪かったみたいですね...。今書いているコードがスパゲッティコードになってるのは認めます。しても、坂道の当たり判定が、今のしか考えられないので、あなたが考えている方の当たり判定のサンプルコードを提示してください。No.47をちゃんと理解できたなら「あなたが考えている方の当たり判定」なんて言葉が出てくるはずないんですけどね。keito94さんがいま考えている坂道の当たり判定に注力できるようにするための方法を提案しているのですから。スパゲッティ状態を改善して、(keito94さんの考えた)坂道の当たり判定をデバッグできるようにしろと言っているのですよ。No.42,No.44にも、あの時点で、坂道の当たり判定はいまだスタート地点にも立ててないふうのこと書きました。いまもその状況はまったく変わってない。シグネチャに“只今デバッグトレーニング中。”とあるのは飾りですか。真剣さが一切伝わってきませんね。ログインしたユーザーしか見ることができない場所に書かれた他人の文章を、ログインせず誰でも見ることができる場所に張り付ける行為。非常識ではないですか?No.33と違い、No.51は明らかに無断転載でしょう。このトピックをログインせずに見るひとからしたら、まったく意味不明ですよ。いう脈略のないところがコードにも表れているのと違いますか。id=3,19205,145682]ISLeさん、言い方が悪かったみたいですね...。今書いているコードがスパゲッティコードになってるのは認めます。しても、坂道の当たり判定が、今のしか考えられないので、あなたが考えている方の当たり判定のサンプルコードを提示してください。[/quote]No.47をちゃんと理解できたなら「あなたが考えている方の当たり判定」なんて言葉が出てくるはずないんですけどね。keito94さんがいま考えている坂道の当たり判定に注力できるようにするための方法を提案しているのですから。スパゲッティ状態を改善して、(keito94さんの考えた)坂道の当たり判定をデバッグできるようにしろと言っているのですよ。No.42,No.44にも、あの時点で、坂道の当たり判定はいまだスタート地点にも立ててないふうのこと書きました。いまもその状況はまったく変わってない。シグネチャに“只今デバッグトレーニング中。”とあるのは飾りですか。真剣さが一切伝わってきませんね。坂道の当たり判定を作っています。2年前ISLeさん、言い方が悪かったみたいですね...。今書いているコードがスパゲッティコードになってるのは認めます。しても、坂道の当たり判定が、今のしか考えられないので、あなたが考えている方の当たり判定のサンプルコードを提示してください。ISLeさん、言い方が悪かったみたいですね...。今書いているコードがスパゲッティコードになってるのは認めます。しても、坂道の当たり判定が、今のしか考えられないので、あなたが考えている方の当たり判定のサンプルコードを提示してください。坂道の当たり判定を作っています。2年前http://dixq.net/fourm/blog.php?u=900&b=6581より。そんな基本的なところに気付けないくらいにコードが複雑化している現状がある。わたしはそれを解決するのが急務だと考えた。ええっ!?スパゲッティーコードだったんですか今書いていたコード!?そりゃ解決されないわけだ...。keito94さんはさっさと坂道を実装して終わらせたいと考えている。あればかみ合うはずがないっすね。ほんとそれですよ...。今となってはそりゃそうなっちゃうよな...。反省しています...。追記:ソース元を出しました。http://dixq.net/fourm/blog.php?u=900&b=6581より。[quote="ISLe"]そんな基本的なところに気付けないくらいにコードが複雑化している現状がある。わたしはそれを解決するのが急務だと考えた。[/quote]ええっ!?スパゲッティーコードだったんですか今書いていたコード!?そりゃ解決されないわけだ...。[quote="ISLe"]keito94さんはさっさと坂道を実装して終わらせたいと考えている。あればかみ合うはずがないっすね。[/quote]ほんとそれですよ...。今となってはそりゃそうなっちゃうよな...。反省しています...。追記:ソース元を出しました。坂道の当たり判定を作っています。わたしの書いた文章をちゃんと読みましたか。文字をなぞるだけでなく、意味を理解しましたか。さっきの発言はなかったことにしてください...。軽率かつ思い込みでした...。あの時はつい、Collision.cppは変える必要ないのかと...。>理解する気がないと思われるところに、説明を補完する役割としてのサンプルコードを提示する意義を感じませんし、そういうサンプルコードはお望みでありませんよね。いうわけで、あなたが考えている方の当たり判定のサンプルコードを出してください。あなたの発言の意味が飲み込めましたので...。オフトピック今となってはあの書き込み、反省しているよ...。追記:適切なものに直しました。id=3,19205,145652]わたしの書いた文章をちゃんと読みましたか。文字をなぞるだけでなく、意味を理解しましたか。[/quote]すいません。さっきの発言はなかったことにしてください...。軽率かつ思い込みでした...。あの時はつい、Collision.cppは変える必要ないのかと...。id=3,19205,145652]>理解する気がないと思われるところに、説明を補完する役割としてのサンプルコードを提示する意義を感じませんし、そういうサンプルコードはお望みでありませんよね。[/quote]そうですよね...。いうわけで、あなたが考えている方の当たり判定のサンプルコードを出してください。あなたの発言の意味が飲み込めましたので...。[offtopic]今となってはあの書き込み、反省しているよ...。[/offtopic]追記:適切なものに直しました。坂道の当たり判定を作っています。さんわたしの書いた文章をちゃんと読みましたか。文字をなぞるだけでなく、意味を理解しましたか。「それをもとにして、Collision.cppをプログラム」する必要があったら、それはもうわたしのやり方ではないのです。「それをもとにして、Collision.cppをプログラム」できるようなサンプルコードをわたしのやり方で書いたら、もはや何も(あるいはほとんど)変更する必要がないのですから、コードを入れ替える一択しかあり得ません。理解する気がないと思われるところに、説明を補完する役割としてのサンプルコードを提示する意義を感じませんし、そういうサンプルコードはお望みでありませんよね。#トピック自体は有意義であって欲しいので、そういう意味では考えておきます。さんわたしの書いた文章をちゃんと読みましたか。文字をなぞるだけでなく、意味を理解しましたか。「それをもとにして、Collision.cppをプログラム」する必要があったら、それはもうわたしのやり方ではないのです。「それをもとにして、Collision.cppをプログラム」できるようなサンプルコードをわたしのやり方で書いたら、もはや何も(あるいはほとんど)変更する必要がないのですから、コードを入れ替える一択しかあり得ません。理解する気がないと思われるところに、説明を補完する役割としてのサンプルコードを提示する意義を感じませんし、そういうサンプルコードはお望みでありませんよね。#トピック自体は有意義であって欲しいので、そういう意味では考えておきます。坂道の当たり判定を作っています。わたしが違う方法を使うというだけで、間違っているとは言っておりません。わけがわからなくなってしまいました...。(あれで完璧だったつもりなのに...。id=3,19205,145629]わたしが違う方法を使うというだけで、間違っているとは言っておりません。[/quote]ますますわけがわからなくなってしまいました...。(あれで完璧だったつもりなのに...。坂道の当たり判定を作っています。Collision.cppの当たり判定は間違っていたのか...。わたしが違う方法を使うというだけで、間違っているとは言っておりません。キャラが壁にハマってしまうわたしが使う方法は既に最初期にお伝えしてます。壁にめり込んでいるのを補正するなら、ただ壁にめり込んでいるのを補正するだけでいい、というふうなことです。やり方が違うというだけで、やること自体は変わりません。keito94さんのいまのコードでは、機能ごとに階層が深く複雑化していく構造です。機能ごとの依存度が高く、機能の変更や追加が他へ大きく影響するため、そのバランスを取ることに大量の時間を割くことになります。わたしが使う方法は機能ごとの実装に階層を持たせない方法です。それだけのことですが、コードの重複が減り応用範囲が広がるので、プラマイの相乗効果で効率として何百倍何千倍もの差が生まれます。プレイヤーキャラが坂道の上にいる(接している)という状態であれば、背景に坂道があろうかなかろうが、背景に何もなく見た目空中に浮いているようでも、設定した坂道のパラメータで上り下りするように振る舞えばいい。そこに背景として坂道を合成すれば、その坂道をプレイヤーキャラが上り下りしているように見える。プレイヤーキャラが坂道の上にいる(接している)という状態は、プレイヤーキャラが持っているものです。それを自由に制御できるようにする。プレイヤーキャラが坂道を上り下りする処理と、プレイヤーキャラが背景の坂道と接しているかどうか判定する処理は、まったく関係なく実装できるのです。最終的に、背景の坂道にプレイヤーキャラが接している場合に、プレイヤーキャラに対して坂道の上にいる(接している)と連絡する処理を加えればよいのです。あれば、最初からプレイヤーキャラが坂道の上にいる(接している)という状態で初期設定して動かしてテストしたり、特定のキーを押したら状態が切り替わるようにしてテストしたりなどシンプルな条件で単体テストを行うことができます。坂道移動のサンプルコードが手に入ったとして、いまのままコードに継ぎ足していっても効率は悪くなる一方ですよ。わたしは、わたしとは、やり方が違うと言っているのです。id=3,19205,145622]そうか、Collision.cppの当たり判定は間違っていたのか...。[/quote]わたしが違う方法を使うというだけで、間違っているとは言っておりません。[url=http://dixq.net/forum/viewtopic.php?f=3&t=18807]キャラが壁にハマってしまう[/url]わたしが使う方法は既に最初期にお伝えしてます。壁にめり込んでいるのを補正するなら、ただ壁にめり込んでいるのを補正するだけでいい、というふうなことです。やり方が違うというだけで、やること自体は変わりません。keito94さんのいまのコードでは、機能ごとに階層が深く複雑化していく構造です。機能ごとの依存度が高く、機能の変更や追加が他へ大きく影響するため、そのバランスを取ることに大量の時間を割くことになります。わたしが使う方法は機能ごとの実装に階層を持たせない方法です。それだけのことですが、コードの重複が減り応用範囲が広がるので、プラマイの相乗効果で効率として何百倍何千倍もの差が生まれます。プレイヤーキャラが坂道の上にいる(接している)という状態であれば、背景に坂道があろうかなかろうが、背景に何もなく見た目空中に浮いているようでも、設定した坂道のパラメータで上り下りするように振る舞えばいい。そこに背景として坂道を合成すれば、その坂道をプレイヤーキャラが上り下りしているように見える。プレイヤーキャラが坂道の上にいる(接している)という状態は、プレイヤーキャラが持っているものです。それを自由に制御できるようにする。プレイヤーキャラが坂道を上り下りする処理と、プレイヤーキャラが背景の坂道と接しているかどうか判定する処理は、まったく関係なく実装できるのです。最終的に、背景の坂道にプレイヤーキャラが接している場合に、プレイヤーキャラに対して坂道の上にいる(接している)と連絡する処理を加えればよいのです。あれば、最初からプレイヤーキャラが坂道の上にいる(接している)という状態で初期設定して動かしてテストしたり、特定のキーを押したら状態が切り替わるようにしてテストしたりなどシンプルな条件で単体テストを行うことができます。坂道移動のサンプルコードが手に入ったとして、いまのままコードに継ぎ足していっても効率は悪くなる一方ですよ。わたしは、わたしとは、やり方が違うと言っているのです。坂道の当たり判定を作っています。坂道に沿って動くプログラムです。高校生レベルの数学がわかればわかるはず、、、?添付ファイルpurin52002.zipキーボードのaとdで動きます。坂道に沿って動くプログラムです。坂道の当たり判定を作っています。2年前そうか、Collision.cppの当たり判定は間違っていたのか...。今の言葉でちょっと頭が混乱してしまったので、坂道移動のサンプルコードをくれませんか?それをもとにソースコードを変更したいと思うので...。Collision.cppの当たり判定は間違っていたのか...。今の言葉でちょっと頭が混乱してしまったので、坂道移動のサンプルコードをくれませんか?それをもとにソースコードを変更したいと思うので...。坂道の当たり判定を作っています。2年前Vector2.cppを修正してやっとまともにデバッグできる状況になるというだけです。坂道判定に関しては、ここからスタートですよ。ご自身で取り組んでください。Collision.cppに書かれてある当たり判定のアルゴリズムを残したままでいいのでわたしはこれを残したままのやり方を知りませんし考えたくもないです。シンプルに実装する方法を知っていますが、根本的に考え方が異なるのです。#某所に書いたのはそういうことであってコードが正しいとか正しくないとかいうことではない。Vector2.cppを修正してやっとまともにデバッグできる状況になるというだけです。坂道判定に関しては、ここからスタートですよ。ご自身で取り組んでください。id=3,19205,145617]Collision.cppに書かれてある当たり判定のアルゴリズムを残したままでいいので[/quote]わたしはこれを残したままのやり方を知りませんし考えたくもないです。シンプルに実装する方法を知っていますが、根本的に考え方が異なるのです。#某所に書いたのはそういうことであってコードが正しいとか正しくないとかいうことではない。坂道の当たり判定を作っています。坂道の当たり判定を作っています。2年前とりあえず、他は現状のままでよいので、Vector2.cppの下記の関数を変更してください。これでやっとまともに坂道判定にとっかかれると思います。*this;#endif}とりあえず、他は現状のままでよいので、Vector2.cppの下記の関数を変更してください。これでやっとまともに坂道判定にとっかかれると思います。坂道の当たり判定を作っています。2年前Y座標を坂道に合わせて移動させるというのはわかったけど...。坂道移動のアルゴリズムがちょっとよくわからないなぁ...。お手数ですが、Collision.cppに書かれてある当たり判定のアルゴリズムを残したままでいいので、坂道移動のサンプルコードをくれませんか?コメントにも書かれてあるように線分の衝突の部分判定のチェックの部分に間違いとかあるのかな...。ついでにちょっと調べてくれませんか?(以下のように修正してください。{//1は下の下り坂。};break;//2は上の上り坂。};break;//3は上の上り坂。};break;//0は下の上り坂。(0以外は想定していないのだ。PlayerCond;//式自体はあっているが...。レイヤーの数値獲得に原因がありそうだ。//プレイヤーの終点のX座標が、坂道のX座標の間なら、1。0;}//衝突した場合は座標に内分を足し、そうでない場合は内分を引く。//(間違っているかもしれない...。{//なるほど、あり得ない座標を代入したら、レイヤーの数値獲得もおかしくなるわけか...。res;}//ここまで来たら衝突していないということ。res;}Y座標を坂道に合わせて移動させるというのはわかったけど...。坂道移動のアルゴリズムがちょっとよくわからないなぁ...。お手数ですが、Collision.cppに書かれてある当たり判定のアルゴリズムを残したままでいいので、坂道移動のサンプルコードをくれませんか?コメントにも書かれてあるように線分の衝突の部分判定のチェックの部分に間違いとかあるのかな...。ついでにちょっと調べてくれませんか?(以下のように修正してください。{//1は下の下り坂。};break;//2は上の上り坂。};break;//3は上の上り坂。};break;//0は下の上り坂。(0以外は想定していないのだ。PlayerCond;//式自体はあっているが...。レイヤーの数値獲得に原因がありそうだ。//プレイヤーの終点のX座標が、坂道のX座標の間なら、1。0;}//衝突した場合は座標に内分を足し、そうでない場合は内分を引く。//(間違っているかもしれない...。{//なるほど、あり得ない座標を代入したら、レイヤーの数値獲得もおかしくなるわけか...。res;}//ここまで来たら衝突していないということ。坂道の当たり判定を作っています。さんが書きました:オフトピックええっ!?Y座標を坂道に合わせて動かせばいいんですか!?ちょっと甘かったです...。y座標動かさないと坂道のぼれないやないかーいwでもこれで不具合の原因がわかりましたね^^移動した座標が坂道だったら、坂道の傾斜に応じてy座標を変化させてやればいいわけですね。id=3,19205,145615][offtopic]ええっ!?Y座標を坂道に合わせて動かせばいいんですか!?ちょっと甘かったです...。[/offtopic][/quote]y座標動かさないと坂道のぼれないやないかーいwでもこれで不具合の原因がわかりましたね^^移動した座標が坂道だったら、坂道の傾斜に応じてy座標を変化させてやればいいわけですね。坂道の当たり判定を作っています。2年前myyと言うのはキャラクターの座標です。addyと言うのは、キャラクターの移動量です。あと、purinさんのご指摘に従い、Collision.cppを少し修正してみました。(中身に変わりはありません。)49行目の件はちょっと誤算でしたね...。オフトピックええっ!?Y座標を坂道に合わせて動かせばいいんですか!?ちょっと甘かったです...。回myyと言うのはキャラクターの座標です。addyと言うのは、キャラクターの移動量です。あと、purinさんのご指摘に従い、Collision.cppを少し修正してみました。(中身に変わりはありません。)49行目の件はちょっと誤算でしたね...。[offtopic]ええっ!?Y座標を坂道に合わせて動かせばいいんですか!?ちょっと甘かったです...。坂道の当たり判定を作っています。intで定義されていました。定数は別に整数である必要はなく、比較対象と同じ型にしたほうがいいと思います。{//座標を一時的に保存する。*addy;//ブロックとしての衝突判定。-2;//Y座標が衝突していなかったら。false;}//Y座標が坂道のレイヤーにいたら。SLOPE){//ブロックのレイヤー番号の獲得。(int)newy);//坂道の線分の宣言。Slope;//スロープの条件分離。0;break;}//ブロックとしての当たり判定。Layer);//坂道としての当たり判定。-2;//-2を返したら、ブロックとして扱う。newy;}}//ブロックの当たり判定。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になっている。intで定義されていました。定数は別に整数である必要はなく、比較対象と同じ型にしたほうがいいと思います。{//座標を一時的に保存する。*addy;//ブロックとしての衝突判定。-2;//Y座標が衝突していなかったら。false;}//Y座標が坂道のレイヤーにいたら。SLOPE){//ブロックのレイヤー番号の獲得。(int)newy);//坂道の線分の宣言。Slope;//スロープの条件分離。0;break;}//ブロックとしての当たり判定。Layer);//坂道としての当たり判定。-2;//-2を返したら、ブロックとして扱う。newy;}}//ブロックの当たり判定。0;}}[/code]22行目:SlopeCondが初期化されていません。(c++だと多分0で初期化されるけど)次のswicthで値を代入するならdefaultの状態も作ったほうがいいと思います。37行目:slope.yはfloat型、SLOPEOKはint型です。値の比較は型をそろえたほうがいいと思います。42行目、46行目も同じ。46行目:16行目でSLOPEと判定しているのにBLOCKかどうか調べるのはなんででしょうか?[color=#FF4000]以下ちょっと重要かも?[/color](addyとmyyがわかっていません。myyがキャラクターのy座標?)39行目:坂道にいるときにaddyが0になっている。坂道の当たり判定を作っています。2年前purinさんに言われてマジックナンバーを駆逐し、コメントによる解説を加えたソースを作りました。引き続き、Scene.cppとScene.h以外をプロジェクトに入れてください。オフトピックコメントをたくさん書く...ボクはそれに賛成ですね。回purinさんに言われてマジックナンバーを駆逐し、コメントによる解説を加えたソースを作りました。引き続き、Scene.cppとScene.h以外をプロジェクトに入れてください。[offtopic]コメントをたくさん書く...ボクはそれに賛成ですね。坂道の当たり判定を作っています。2年前プログラムを動かしてみたところキャラクターが坂道に差し掛かるとキャラが沈んだり、なぜか左右にものすごい勢いで動いたりしました。何が悪いのかとプログラムを読もうと思ったのですが、いわゆるマジックナンバーが多く正直私レベルだと理解できません。(っていうかしたくない^p^)出来ればマクロ、enum、定数などに置き換えたほうがいいと思います。(int)newy,*addx,*addy);//Y座標が衝突していなかったら。false;}//Y座標が坂道のレイヤーにいたら。Slope;//スロープの条件分離。Layer,SlopeCond);//-2を返したら、ブロックとして扱う。newy;}}//ブロックの当たり判定。0;}}マジックナンバーとはソース中にいきなり出てくる意味の分からない数字です。(0はまあ初期化って意味だろうし直さなくてもいいかなー、と思いました)数字だけだとややこしいので、名前を付けてやると見やすくなると思います。}のようにすると、他人が見た時や、時間をおいてからソースを見直すときにわかりやすいと思います^^プログラムを動かしてみたところキャラクターが坂道に差し掛かるとキャラが沈んだり、なぜか左右にものすごい勢いで動いたりしました。何が悪いのかとプログラムを読もうと思ったのですが、いわゆるマジックナンバーが多く正直私レベルだと理解できません。(っていうかしたくない^p^)出来ればマクロ、enum、定数などに置き換えたほうがいいと思います。(int)newy,*addx,*addy);//Y座標が衝突していなかったら。false;}//Y座標が坂道のレイヤーにいたら。Slope;//スロープの条件分離。Layer,SlopeCond);//-2を返したら、ブロックとして扱う。newy;}}//ブロックの当たり判定。0;}}[/code]マジックナンバーとはソース中にいきなり出てくる意味の分からない数字です。(0はまあ初期化って意味だろうし直さなくてもいいかなー、と思いました)数字だけだとややこしいので、名前を付けてやると見やすくなると思います。坂道の当たり判定を作っています。坂道の当たり判定を作っています。2年前ブログなどでみなさんがそこまで言うのなら、ソースコードを公開しますので、サンプルコード.zipのScene.cppとScene.h以外のソースコードをプロジェクトに追加してください。ブログで聞いた話によると、今のソースコードは色々と改善すべきところがあると思うので、ここで改善案を出していただければ、それを修正すると思います。回ブログなどでみなさんがそこまで言うのなら、ソースコードを公開しますので、サンプルコード.zipのScene.cppとScene.h以外のソースコードをプロジェクトに追加してください。ブログで聞いた話によると、今のソースコードは色々と改善すべきところがあると思うので、ここで改善案を出していただければ、それを修正すると思います。坂道の当たり判定を作っています。違います違います!!ColSegment自体は正しく動作しています!!ColSegments関数の仕業じゃないとすれば妖怪の仕業、、、?冗談はさておき、http://dixq.net/forum/blog.php?u=900&b=6581のISLeさんの投稿を見ると、GetXPosition周りが怪しいとか、、、。解決案としましては、GetXPosition関数とかの修正GetXPosition関数を使っている箇所の修正でしょうか?どちらの方法が絶対いい!とは言い切れないのでどちらの方法をとるかはkeitoさんが決めて下さい。あの、ブログ見ましたけど...。移動後の座標ではなく、現在の座標だったのですか!?ボクも気づきませんでした...。id=3,19205,145567]違います違います!!ColSegment自体は正しく動作しています!![/quote][/quote]ColSegments関数の仕業じゃないとすれば妖怪の仕業、、、?冗談はさておき、[url]http://dixq.net/forum/blog.php?u=900&b=6581[/url]のISLeさんの投稿を見ると、GetXPosition周りが怪しいとか、、、。解決案としましては、[list][*]GetXPosition関数とかの修正[*]GetXPosition関数を使っている箇所の修正[/list]でしょうか?どちらの方法が絶対いい!とは言い切れないのでどちらの方法をとるかはkeitoさんが決めて下さい。id=3,145568]あの、ブログ見ましたけど...。移動後の座標ではなく、現在の座標だったのですか!?ボクも気づきませんでした...。坂道の当たり判定を作っています。2年前あの、ブログ見ましたけど...。移動後の座標ではなく、現在の座標だったのですか!?ボクも気づきませんでした...。すいませんが、現在の座標ベースでの当たり判定のアルゴリズムを教えてくれませんか?あの、ブログ見ましたけど...。移動後の座標ではなく、現在の座標だったのですか!?ボクも気づきませんでした...。坂道の当たり判定を作っています。違います違います!!ColSegment自体は正しく動作しています!!そして、修正が一つ...。Layer,SlopeCond);に修正してください...。違います違います!!ColSegment自体は正しく動作しています!!そして、修正が一つ...。Layer,SlopeCond);[/code]に修正してください...。坂道の当たり判定を作っています。坂道の当たり判定を作っています。坂道の当たり判定を作っています。坂道とプレイヤーの線分が交差していたらColSegments関数にtrueを返してほしくて、でもColSegments関数はfalseを返すし、そのせいでブロック判定もうまくいかない。坂道とプレイヤーの線分が交差していたらColSegments関数にtrueを返してほしくて、でもColSegments関数はfalseを返すし、そのせいでブロック判定もうまくいかない。坂道の当たり判定を作っています。簡単に説明すると、1坂道のブロックにプレイヤーが入る。(ここはOK)2坂道のブロックの種類を識別する。(i+2を返す部分)3坂道の線分とプレイヤーの線分が設定される。4坂道の線分が、プレイヤーの線分の終点の間なら、線分の判定を行い、線分と衝突していたら、めり込み防止をした座標を返す。5...はずだったのだが、4が誤作動を起こし、その巻き添えで2も誤作動を起こし、普通のブロックとして判定されてしまう。?簡単に説明すると、[list][*]1坂道のブロックにプレイヤーが入る。(ここはOK)[*]2坂道のブロックの種類を識別する。(i+2を返す部分)[*]3坂道の線分とプレイヤーの線分が設定される。[*]4坂道の線分が、プレイヤーの線分の終点の間なら、線分の判定を行い、線分と衝突していたら、めり込み防止をした座標を返す。[*]5...はずだったのだが、4が誤作動を起こし、その巻き添えで2も誤作動を起こし、普通のブロックとして判定されてしまう。坂道の当たり判定を作っています。これは、真になるであろうパラメータを与えても真にならないということですか?そ、そういうことではなくてですね...。坂道のブロックにいると判定されているときに何故か真にならないということです。理解力ががが^p^坂道ブロックにいるときは真と判定してほしいのに、真と判定されない。id=3,19205,145544]これは、真になるであろうパラメータを与えても真にならないということですか?[/quote]そ、そういうことではなくてですね...。坂道のブロックにいると判定されているときに何故か真にならないということです。id=3,19205,145546]理解力ががが^p^坂道ブロックにいるときは真と判定してほしいのに、真と判定されない。坂道の当たり判定を作っています。