Petitverse

91行目、右に壁があるかを判定するところだと思うのですが、
このIF文の条件って、「(I,Y)の位置に壁があったら」ってことですよね。
そうすると、壁があったとき、X=I、つまり壁がある位置にプレイヤーを移動させてませんか?
つまり、X=I:XX=Xではなく、X=XXとして位置を移動前に戻すのが正しいかと。
左、下、上の判定も同様です。

違ってたらすみません。
追記 違ってました。X=XXだと壁よりさらに手前で止まってしまいます。

よく考えたらX=XXは間違いでした。

>ホーム座標が8,15なので
SPHOME 0,7,15と書いてあるんですが...

>操作キャラの外側が壁と同じ座標になるとストップ
なるほど、外側か
それだったら、そのストップした位置では外側(キャラの1ドット隣)に壁がある状態のままなのですから、BEEPが鳴り続けるのは正しい挙動だと思いますよ。

>何故かBボタン長押し(上昇)しながらだと横移動が出来ないんですよねこれ
確かに上昇中は横移動できますが天井にぶつかっていると移動できませんね。
このプログラムでは右→左→下→上の順にチェックしていますよね。
天井にぶつかっているとき、まず右をチェックした瞬間はまだ上にめり込んでいる状態なので、右にも壁がある判定になってしまい、動かないのではないでしょうか。
だから上を先にチェックすればいい...と言いたいところですがそうするとこんどは左右の壁に触れている間上昇できなくなってしまいます。
それで、解決策ですが、Y=Y+Aを右左のチェックの後にすればいいのです。
つまり縦方向にめり込んでいない状態で右左をチェックし、横方向にめり込んでいない状態になったうえで上下に動かし、上下をチェックすればいい、ということです。

>+1しないとめり込む現象
ホーム座標が7,15なので、右方向は+9、左は-8、下は+1、上は-16であってると思いますよ。

>カメラ動作しないと1ドット浮く
カメラが動作すると1ドット沈むほうが間違いです。
(原因が分かったとは言ってない)

カメラが動作すると1ドット沈む問題、解決しました。
Y座標は、Xと違って小数になりますね。
だから、FORで1ずつ調べると間を飛ばしてしまいます。
Y方向をチェックするFOR文のところをSTEP 0.1、STEP -0.1とかに変えたらBEEPはならなくなりました。
あとはSPOFSです。YもBYも小数になるので、(FLOOR(Y)-FLOOR(BY))*SCLとすると、表示も沈まなくなりました。

判定の式を不等号でやれば加速度がいくら高くても判定は一回で済むし
めり込まないんじゃないんです？
背景キャラクターをラインで区分けして文字列に変換して判定に使ってやれば
障害物と操作キャラクターの位置関係も一発で出せますし

確かにループを細かくするのは速度的に気になりますよね。
基本は当たっていたら戻すだと思うので当たるまで細かく加算は重いと思います。
BGのようにブロック的な背景は最小サイズが決まっているので、それも考慮して処理すると効率が上がりますね。
例えば16ドットサイズのブロックなら少なくとも16ドット以上の移動量でなければ1回の加算ですり抜ける事はないので、そこまでは一気に足して判定しても問題ないと思います。
ぶつかった時も対象が綺麗に並んだ16ドットサイズのブロックならどこに戻せばぶつからないかは1回の計算で出せるはずです。
この考え方に移動量が多すぎる時の事も考慮して処理を作れば今よりは速くなると思いますよ。

原因わかりました!
SPOFSは画面のドット単位なので、(X-BX)*SCL,(Y-BY)*SCLであっているのですが、
BGOFSはキャラのドット単位なので、例えばサイズ2倍の時にBGOFSで1ドット動かすと、画面では2ドット動くのです!
だからBGOFS 0,BX,BY
これで動きます。

今更ですが解決策。
画面座標を使うと座標が小数になって誤差が出ます。
だったらキャラ座標を使えば誤差は出ないのでは?
BGGET(0,(I-BX+9)*SCL,(Y-BY)*SCL,1)
↓
BGGET(0,(I+9)/16,Y/16,0)
SCLがどんな値でも使えます。
ただしマップ外にでるとOut of rangeするのでそこはチェックする必要があります。