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

ISLe · #61

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

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

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

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

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

keito94 · #62

ISLeさんが指摘した、移動先座標での判定の部分を、移動量を足した判定に変更してみました。
CheckMapの部分は、addxかaddyのどちらかが、0でなければ正しく動作しない仕様となってます。

ISLe · #63

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

直しているとき、他に、移動量渡してない関数があることに気付きませんでした？

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

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

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

keito94 · #64

ISLeさん、ご指摘ありがとうございます。
出力する引数は、ポインタをつけろというわけですね…。
あと、入れ子化していた部分を修正しました。

keito94 · #65

オフトピック

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

ISLe · #66

keito94 さんが書きました:出力する引数は、ポインタをつけろというわけですね…。

ここは(いまのところ)結果に影響を与えていないので、単に、引数に与えた値(特に現在座標と移動量)の変化を把握していないのではないかという疑問を補強する意味で指摘しました。
そういう意味では今回の変更においても疑問は一切解消されていません。

keito94 さんが書きました:あと、入れ子化していた部分を修正しました。

階層が1段増えましたね。
これを修正というのでしょうか。
わたしには改悪にしか見えませんが。

ISLe · #67

現在位置 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をめり込んでいない位置に補正
　}
}

移動するオブジェクトが、自分以外に何が存在するか知っている必要ありません。
知っていたら自分以外のオブジェクトが増えたりしたとき変更に巻き込まれることになるからです。

keito94 · #68

ISLeさんが考えている当たり判定のアルゴリズムに変えてみました。
addxとaddyを0にしないとまともに動作しません。（このステージでは関係ないんですが…。）

オフトピック

なるほど、こうゆうことだったのか…。

ISLe · #69

keito94 さんが書きました:ISLeさんが考えている当たり判定のアルゴリズムに変えてみました。

ずいぶん中途半端に変更したのですね。
これをわたしが考えたと言われるのはかなり抵抗あります。

keito94 さんが書きました:addxとaddyを0にしないとまともに動作しません。（このステージでは関係ないんですが…。）

それはそうでしょうね。
わたしがNo.63で書いた、移動量を何回も加算してしまわないだろうか、と懸念していたことを新たにやらかしてます。
このステージでは関係ない…ほんとうにそうでしょうか。
例えば坂道を登りきる前に坂道の判定が消える、ような気がしますが。

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

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

ISLe · #70

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

keito94 · #71

僕の頭の中のコードでは、どう頑張っても、めり込み補正の部分とY座標の部分で移動量に頼ってしまいます。
なので、移動量に頼らないめり込み防止のサンプルコードをください。
なお、今上げたコードでは、常に落下しているので、最終的にはキャラが画面外に移動します。

keito94 · #72

オフトピック

やっぱり自分でプログラムするのっていいもんなんだな…。

ISLe · #73

keito94 さんが書きました:僕の頭の中のコードでは、どう頑張っても、めり込み補正の部分とY座標の部分で移動量に頼ってしまいます。
なので、移動量に頼らないめり込み防止のサンプルコードをください。

いちいち頭で考えなくても、引数の宣言からaddx,addyをまるまる取り除けば、変更が必要な部分はコンパイラが教えてくれますよ。

keito94 さんが書きました:なお、今上げたコードでは、常に落下しているので、最終的にはキャラが画面外に移動します。

常に落下してしまうのはどうしてなのか、というところに頭を使いましょうよ。

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

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

keito94 · #74

ISLe さんが書きました: (プレイヤーキャラ自身が)落下する状態でないから落下しない

それを自分なりに実装してみたのですが、今度はキャラが落下しません。
ジャンプすらできません。何か落下する状態を管理する部分にバグが有るようなのですがそれはどこなのでしょうか？

オフトピック

やっぱりプログラムって大変…。

ISLe · #75

そもそもCCollisionクラスって何なんですか？
クラスの役割りを説明できますか？
説明できないのにただいじくり回しているだけならキリがないのでやめましょう。

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

CPlayer::GroundFlagってありますよね。
CPlayer::GroundFlagって何ですか？
これも役割りを説明できますか？

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

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

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

keito94 · #76

>>ISLeさん
簡単に説明します。
CCollisionと言うのは当たり判定の処理を行うクラスです。
CPlayer::GroundFlagと言うのは、キャラが地上に居るかどうかを管理する変数です。
CPlayerで移動処理をして、CCollisionで当たり判定をチェックします。
ジャンプした、もしくは空中にいる時はGroundFlagが偽になります。
地上にいる時はGroundFlagが真になります。
GroundFlagが真になっている時は落下を行わないはずです。
これで間違いないですよね？
あと、質問用のソースコードをリポジトリに上げてみました。
プロジェクトにこのコードを追加してください。
こちらです。

オフトピック

変にいじると大変なことになるのね…。

追記：今のコードで確認されている不具合は、左の当たり判定と、右の当たり判定が同時に出ていることと、落下を全くしないことと坂道を登りきると、
キャラが消えてしまうことです。

ISLe · #77

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さん自身が仕込んだもので、環境依存等で勝手に生まれたバグではない。
いちいち頭使って考えなくても、コードの差異を見れば原因の特定は難しくないと思うんですけどね。

ISLe · #78

オフトピック

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

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

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

keito94 · #79

新たなバグを発見しました。地上にいる時は、Y座標の移動量を０にしようとしているつもりなのですが、
ブレークポイント無しで実行するとソースコードに書いてあるバグが発生して、地面にめり込んだ状態になります。
原因はどこにあるのでしょうか？また仕込んだのではないのでしょうか？

ISLe · #80

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

- + - + -

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

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

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

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

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

ISLe · #81

オフトピック

いちおう移動量を使わない方法を書いておきます。

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

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

keito94 · #82

ISLe さんが書きました: #むしろ無限ループを楽しんでください。

それはやだやだ！！！

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

ごめんなさい、その質問をしようと思っていたところでした…。

ISLe さんが書きました: 間違った理解でコードをいじるからおかしなことになるのと違いますか。

ごめんなさい、ちゃんとソースコードをしっかり読んでからやりたいと思います…。

ISLe · #83

オフトピック

そろそろXとYで関数を分ける必要もない段階まできてたわけだけども。
そうなると、
めり込みを許容して押し戻すマリオ(ブラザーズ)タイプ
と
めり込みを許容せず一気に移動のロックマンタイプ
を選択する余地も生まれるのだけども。

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

ISLe · #84

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

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

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

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

keito94 · #85

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

はーい、わかりました。

keito94 · #86

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

ISLe · #87

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

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

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

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

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

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

keito94 · #88

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

keito94 · #89

オフトピック

とんでもない勘違いをしてしまった…。

keito94 · #90

ISLe さんが書きました: 移動量撤廃の方針を続けるならこのトピで続ければよいのでは。

ごめんなさい、解決を撤回させてください。この方針を続けようと思います。

keito94 · #91

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

ISLe · #92

keito94 さんが書きました:現在は移動量に依存していた部分を取り除いたところです。

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

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

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

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

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

keito94 · #93

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

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

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

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

ISLe · #94

keito94 さんが書きました:なん…だと…。地上にいるというのは振る舞いだけだったのか…。

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

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

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

ISLe さんが書きました:今度こそ取り除かれたのではないのでしょうか？

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

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

keito94 · #95

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

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

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

ISLe · #96

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回繰り返したら、もはやサンプルとしての価値もない。

keito94 · #97

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

ISLe · #98

オフトピック

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

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

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

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

keito94 · #99

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

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

ISLe · #100

keito94 さんが書きました:後、重力の部分を分割してみました。

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

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

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

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

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

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

ISLe · #101

オフトピック

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

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

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

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

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

keito94 · #102

ISLe さんが書きました: 正に舌の根の乾かぬうちにってやつですね。

そうです…。

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

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

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

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

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

ISLe · #103

(※下線加筆)

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

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

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

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

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

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

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

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

ISLe · #104

オフトピック

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

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

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

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

keito94 · #105

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

ISLe · #106

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

keito94 · #107

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

ISLe · #108

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

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

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

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

keito94 · #109

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

ISLe · #110

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

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

オフトピック

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

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

keito94 さんが書きました:左右の判定は一応完成しました。

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

ISLe · #111

keito94 さんが書きました:ですが、地上に着地せずにめり込んで左に移動してしまいます。

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

keito94 · #112

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

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

ISLe · #113

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

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

keito94 · #114

ISLe さんが書きました: 分かっているなら、どこがどうして問題なのか、説明して見せてください。

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

ISLe · #115

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

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

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

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

keito94 さんが書きました:その問題というのは、CheckMapや、マップチップを確認する部分にあります。

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

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

ISLe · #116

オフトピック

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

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

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

keito94 · #117

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

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

ISLe · #118

keito94 さんが書きました:もしかしてめり込み防止の部分ですか？

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

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

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

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

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

keito94 · #119

ISLe さんが書きました: 場所はCCollision::CheckMapで合ってると書いたのに。

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

ISLe さんが書きました: 前提から外れたことを同じやり方でやろうとしたらどうなりますかね。

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

keito94 · #120

オフトピック

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

keito94 · #121

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

ISLe · #122

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

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

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

keito94 · #123

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

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

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

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

		7月 2025
日	月	火	水	木	金	土
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31