Petitverse

Smartphone Mockの"世界時計"で、
そのような機能を実現しているので参考にどうぞ。

スワイプ自体は、タッチ開始した場所を覚えておいて、そこからタッチを離すまでの位置（距離）と時間などを参照してどの方向にスワイプしたか判定する（処理はタッチが離れたときに確定）感じですね。

ただスワイプ中（タッチをしてから離すまでの間）の処理をどうするかはケースバイケースで、単純にスワイプの判定だけならタッチを離した時に確定すればいいですが、タッチ中に動かしているときに画面が変化する（ページがめくれる途中が表示される等）場合は、タッチしている間に動かした量から実際の画面を描画して途中を作るなどの処理が必要になりますね。

途中の状態はアプリ内容によって変わるので単純にこれってやり方は無いと思いますよー。

とりあえずスワイプ量をSX, SYなどに求めるようにして、その変数の値を元にどういう画面になるかを決める感じでいくしかないんじゃないのかな？

もし画面切り替えなどで利用する場合、画面そのものを座標位置をずらして表示出来るような関数化などをして、それを前の画面と重ねて表示するなどの工夫が必要になるような気がしますね。

途中まででもやってるようなものがあれば、それを元にどうするのが良いか考えたりも出来るんですけどねー…

TOUCH命令がイマイチならまずTOUCH命令から慣れていくのがいいんじゃないですかね？

たとえば下画面にスプライトを置いて、それをタッチでドラッグすると動かせて離すとまたそのスプライトは元の位置に戻ってしまう（出来れば瞬時でなくアニメーションで戻る）って動作は作れますか？　スプライトは1つでもいいですが複数あると尚良い、という感じですね。

GPUTCHRを使うと言うことはグラフィック画面オンリーで画面を作るのかな？（コンソールやスプライトは使わない）

グラフィックオンリーならコンソールやスプライト、BGなどが組み合わさっている画面よりは全体を制御しやすいので画面全体を動かしやすいかもしれないですね。

へぇ〜(無関心)

無関心とは

解決してると思うけどいちおう補足。

スワイプ処理はTOUCH命令から画面をタッチしているときだけ移動量を取得できる。(BGなどは無関係)

画面が移動する処理はBGやGRP0などを何かの移動量から移動する。(TOUCHなどは無関係)

スワイプを十字キーやスティックに置き換えても、画面移動をSPRITEやPRINTした値に置き換えても問題ないので、スワイプの処理と画面移動の処理は別々に考える必要があります。
(別々に考えられるということは別々のGOSUBやDEFに出来る)

スワイプの処理自体はみなさんの書き込み(でんぺんさんの「スワイプ量をSX, SYなど」)からいちおう解決済みなので、このSX,SYを移動距離として移動処理に渡すようにします。

ここの流れから、画面を移動する処理がまだ出来ていないようなので、まずは移動するモノを実験用に適当に決めてみて、移動距離を渡したときに移動出来る処理を作ると良いと思います。(下画面にスプライトを置いてドラッグして移動するだけの処理など、移動距離の値だけ元の位置から移動する処理)

TOUCHがめんどうならSTICK命令からスティック入力の値そのままや、十字キーで変数の値を増やしたり減らしたりした値を移動距離として取得したりなど、別の入力方法で移動距離を取得する方法を試してみるのも手です。



実際のスワイプ処理の場合、早くスワイプして指を離した場合にもまだスクロールが続いたりするので、それはもうちょっと考えないといけなかったりします。
TOUCHの前回の位置と今回の位置の差分を取っておいて、タッチが離されたときに、その差分量の距離をタッチが離れた状態でも移動しつづけて、その差分量を移動のたびに減らし続けて、差分が0以下になったら移動を止める、みたいな処理が必要です