座標修正処理云々以前にのけぞり処理がおかしいことが判明（※嘘じゃないです）

言いたいことを図にまとめました。


こうなります。
要約すると「進行方向に障害物があったとしても移動先（代入先）で接触していなければ移動できてします」
とうことです。

何で気づかなかったんだろ・・・(´・ω・｀)

ってことは前座標修正処理のときにモノ君が行ってた「1ピクセルずつ調べていけばいい」と言う方法を取ろうかなと思います。

旧バージョンは「当たったら当たらなくなるまで座標を修正」
でしたが
新バージョンは「当たるまでか、一定距離移動」
に変えたいと思います。

「もっといい方法あるぞ」って方、よろしければアドバイスお願いします（＿ ＿）

ゲームプログラミングの上で、基礎システムは重要なので、ぜひ何回も書き直して最高のものを目指してください。
プログラムが大きくなってから基礎システムを変更すると大変ですからね。
・・・と、今まで大きなプログラムを書いたことがない人が言ってみる。

ちなみに私はレトロなRPGのソースコードを10回くらい0から書き直しています。
2年がかりの作業です。
さすがに遅すぎです。(時間が無いという原因もありますが。最初の面影は全くありませんｗ)
まあ、慎重になりすぎるといつまで経っても進めないということですね。
結局私は何が言いたかったのだろう。

10回も書き直したのか・・・
まだ1回しかやり直したこと無いけど10回はきついな・・・

今時間たっぷりあるから頑張ってますｗｗ

1フレームで20動くキャラクターというのは中々素早いですねｗ
そこまで厳密な衝突判定が必要になると、そのような1ピクセル単位の衝突判定か、
（まあ1ピクセルまで精度を高める必要は…3ピクセル程度で良いと思いますが）
あとは軌跡で判定するか、くらいしか私には思いつきませんね。
軌跡は線分で表します、つまり、移動前の頂点と、移動後の頂点の対応するものを結んだらできる4つの線分です。
この方法は正直めんどうだと思います。
おそらく線分と四角形の判定は、四角形の各辺を4つの線分に分けて、
その線分同士で判定することになるでしょうが、
そうすると処理の負荷的にはむしろ軌跡での判定のほうが負荷が高くなりそうです。

MNSさんもおっしゃってますが、20ピクセルの移動はそうとう速いです。
わたしならその程度すり抜けても気にしません。
実際プレイしても気にならないと思います。
#プレイしてどうしても気になるようであればあとから対処しますけど。
EがPの進行方向と逆方向に動いていたときはどうするのかとか考え出したらキリがないですし。

(追記)
ウチのブログで公開したサイドビューの実験プログラム(Javaですけど)は矩形判定なので、キャラとブロックの当たり判定で同様にすり抜ける仕様です。
動かしてみたらすり抜けが気になるかどうか参考になるかもしれません。

敵に当たってヒットバック（のけぞり）したときの処理です。説明不足でした＾＾；
通常の移動は1フレーム2ピクセルしか動きません。

軌跡は線分で表します、つまり、移動前の頂点と、
>移動後の頂点の対応するものを結んだらできる4つの線分です。
以前の日記にコメントしていただいていたあれですね。
自分には難しそうなのでとりあえず出来るほうをやってみようと思います。

<ISLeさん
たしかに今まで気づかなかった=気にならなかった
ということなんでしょうが、明らかにおかしい挙動をするときがあるのと
そっちのほうが座標修正処理も兼ねて作ることが出来るので、今回は向いているかなと思います

ブログのほう拝見させていただきます。