Petitverse

こういちさんありがとうございます！

当たる直前に戻るのは簡単だったのですが、例えばですが、4ドット加算する処理をしていた最中に、3ドット向こうに壁があった場合、4ドット戻すと壁まで常に3ドット空いてしまうと思うのです。

でも「SPHITRCやSPHITVECを活用して」というのは、まさにこれだったかもしれません。
これって何の為にある命令なのか、リファレンスには「移動量x,y」項目はあるけどそれには触れられていなかったり、よく分かっていませんでしたが、こういう時に使えそうですね！
試してみます。

ありがとうございました！
早速試してみたところ、これならうまくいきそうです！
SPHITSPだとどうしても「重なった(当たった)後」の戻り処理になり一瞬のタイムラグが見えてしまいましたが、SPHITRCなら座標加算直後(表示前)に判定ができ、とても都合が良かったです。
まだ移動量x,yという項目が何なのかは試していませんが、とりあえず現状でも動いてます。
大変感謝します。助かりました。ありがとうございました！


他に何か当たり判定でテクニックありましたら、後学の為にどうぞお願い致します。

あきとさんありがとうございます！
まさにそれでした。
判定が出た時には、元の位置に戻すのではなくて、ハンパな空白分だけは移動させないといけませんね。
最初テストではそれ忘れていました。
(壁で止まりはしましたが、壁より少し前で止まってしまいました)

せいぜい最大5ドットの移動量なので、じゃあ何ドット先が壁なのかの判定も楽そうです。
ありがとうございました。

あきとさん重ねてありがとうございます。
自分は4号です。

お手数おかけしますが、よろしければ是非是非拝見させて下さい、

あきとさん、ありがとうございます！
いやサンプルとは言いながら操作するだけで面白く、まさかの多重スクロール！が綺麗で、しばらく夢中になって遊んでしまいました。
プログラム内を拝見してさらに、整いまくった綺麗な文体に恐れ入りました。
私も結構これに似た物を作っているところですが、私の方はプログラム内は相当滅茶苦茶でとても比較になりません…！
とりわけ、さりげなくこの一部画面内移動それ以上はスクロールというテクニックや、当たり判定部分の関数での集約具合に舌を巻きました。しかもこれだけ注釈や改行を入れてくれて200行程度、省けば100行ほどで収まろうかというコンパクトさとは…。

この合理的なプログラミングはどこで身につけられたのですか。関数などはいきなりこんなに纏められるのですか？最後に集約されるのですか？
まだ全然解析などできていないですが、おそらくドットの色情報？で当たり判定を見ていらっしゃる様ですが、これもやはり加速度が有って、おそらく1ドットずつの自機移動ではないと思うのですが、当たり判定には前述の、「次に判定が出る場合に1ドットずつ加速度内をチェックする方法」を使われているのですか？コンパクトに集約され過ぎていてとても一見では分かりそうもありません。

ともかく公開して下さって本当にありがとうございました。参考にして勉強します。
しかしこれは続きがやりたくなりますね。いつかゲーム化期待しております。