Petitverse

ちょっと見てみましたがキャラがオリジナル（大きい）のでアニメーションの見栄えが良いですね〜。良い感じだと思います。

問題点は言われているように問題点２のY座標の位置が固定化されてないところですね。なので問題点２が解決すれば問題点１は自ずと解決する（足下の座標が固定化してわかるようになるので）って感じですよね。

と言うことでBGにぶつかったとき、その位置から正確に座標補正してBGの上に乗せることが出来れば問題は解決します。
BGは今回の場合は16ドット単位のブロックなのでスプライトの座標を16で割れば（小数点切り捨て）BGの座標になります。そして、そのBGの座標からスプライトの位置を計算して調整してY座標を決めてあげれば、きちんとした位置に補正することが出来ます。
例えばシンプルに今はY=Y-AのところをY=FLOOR((Y+55)/16)*16-56とするだけでも良い感じに補正されるんじゃないかな？　最後に-56しているのはキャラの位置に調整するためですが-55だと補正直後にまた地面に当たることになるので1ドット上にしてあげています。

一応そんな感じですが、他にも左右移動時の判定なども正確にしないと正しく補正されない（いきなりブロックの上に乗るとか）しちゃいますが、要領は同じ感じで出来るのでチャレンジしてみてください！

オマケでSPDEFする時に今は原点が全部キャラの右上ですが例えばキャラの中央足下を原点にするとかすると座標計算がしやすくなったりしますよ。左右で加算する数値の差が変わることもなくなりますしね。

IF BGGET(当たり判定) THEN
IF !FLAG THEN SPANIM 待機アニメーション:FLAG=1
ENDIF

IF ! BGGET(当たり判定) THEN FLAG=0

でもいけそう。

座標が接地点以下に行かない様にしたいなら、接地ラインにしたいY座標を取りあえずLAND_LINE、略してLLみたいな適当な変数で設定しておいて
毎フレームの座標計算時に
接地してるかどうかの判定フラグをA_FLAG、T_FLAGが1フレーム前のA_FLAGの状態を保存しておくフラグだとして

Y=Y+A
T_FLAG=A_FLAG
IF Y>=LL THEN A_FLAG=TRUE ELSE A_FLAG=FALSE
Y=Y-(Y MOD LL)
IF !T_FLAG && A_FLAG THEN SPANIM ~

みたいな処理を入れてみたらいいんじゃないです？
平らな地面と当たり判定を取りたいだけなら、別にBGの情報取得に拘らなくても良いと思いますけど。

基本的にでんぺんさんの言ってる方法で大丈夫だと思います。

ただ「座標を16で割って小数点以下を切り捨てる」という方法は「スクロール」がある場合あまりオススメできません。
BGOFS 0,0の状態では16ドットごとにBGの境目がある状態なのでそれでもいいんですが、BGOFS 0,1にするともちろん1ドットズレます。そこの補正を加えないといけないのでやや面倒です。
16で割らずにBGCOORDを使って変換するのがオススメ。

（ただ、プレイヤー座標を画面外まで考慮する形で管理しているなら16切り捨てで問題ないです）

＞Villlitさん
たしかにスクロールも加味するとその分座標修正が増えるので面倒になりますね。
BGCOORDはその点命令に任せられるので活用すれば便利ですね。
今回はY座標だけしか試さなかったのでスクロールがなくてチェックを見落としました…。

だいじょーぶだいじょーぶ
僕だってたくさん質問に答えたいし。

論理式はホントに便利だよ
例えばBUTTON()関数で自機を動かすプログラムも

B=BUTTON()
X=X-(B==4)+(B==8)
Y=Y-(B==1)+(B==2)
に縮められるし。

進んでいるようで良かったです！

プログラムを見た全体的なアドバイスというか僕が思ったのは、

1. IFのブロック(IF〜ENDIF）をあまり使っていないけど:で繋げて1行でやるよりもIFブロックを使った方が見やすくなったり効率が上がりそうな部分が多かった。

2, SPDEFを移動方向が変わったときなどに都度変更していたが、SPDEFはプログラムの始めに定義して利用する（後で変更しない）方が利用しやすいです。つまり反転した絵もあらかじめSPDEFで別の番号に登録しておく事になります。
（デフォルトで用意されている素材がそのような構成になっています）

3. 入力値を毎回IFでBUTTON()と書いて調べるよりも事前にB=BUTTON()として変数に入れておいてIFではそれを参照する方がシンプルで見やすくなります。
とくにBUTTONの値はVSYNCや一定時間しないと変化しないので変数に入れておいて参照する方が早いです。

と言うのがすぐに思ったことかな。
まあでも始めのうちは動かすのが大事で形にこだわらずに進めた方が進めやすいところもあると思うので、一応書きましたが楽しんでプログラムをする方を優先してください！

SPDEFはグラフィックページに反転した絵を描かなくて大丈夫ですよ！
SPDEFで定義するときにアトリビュートというのがあるので、それで横反転させて定義することが出来ますよ！

SPDEFのテンプレート定義番号は0〜4095までなのでそれ以上のパターンを作ろうとしたら定義が足りなくなるので切り替える必要がありますが、そうじゃなければ同じ画像を使って反転回転加算合成なんでもありなので便利だと思いますよ。同じ絵で原点を変えることも出来るので、剣を振るときにちょっと上に跳ねるような動き（位置）にするとか躍動感もつけやすいです。

この辺はもともとのサンプルが色々やってる（反転や原点を変えただけとか）ので見てみると参考になるんじゃないかなと思います。

SPDEFについては論より証拠というか例を見た方がわかりやすい気もしたので、ちょっと時間が作れたのでサンプルを作ってみました。
公開キー：Q3FDP3JD
SPDEF_SAMPLEを実行してみてください。グラフィックはそのまま使わせてもらって左右移動だけのアニメテストです。SPDEFで始めに定義するだけってのがわかると思います。

SPANIMはせっかくなのでDATAを使った指定方法を試してみましたが別に直の書き方でも問題ありません。アニメ速度的な数値はオリジナルに合わせたわけじゃないので適当です。

オマケで僕が前に作ったPUCHI-VIEWというプログラムをいれました。これはSPDEFで定義されているスプライトやBGを確認するだけのツールです。僕はスマイルツールに登録していますが、例えばスロット1などに読み込んでおいてRUN 1としても実行出来るので現在定義したSPDEFを確認出来ます。スマイルツールと比べて見ることに特化してシンプルなので使ってみてくださいな。

とりあえずそんな感じでした。