タッチ操作について、いくつかの疑問があるので、分かる方は答えてください！ 1.タッチした位置にスプライトを表示した時、少しズレた位置に表示されるのは、何故でしょう？ SPの原点は中心に設定しているので、原点が左上だからズレているというわけではありません。 SPを拡大していますが、それが影響しているのでしょうか？

タッチした場所に1×1ドットのスプライトも置いてみるといいんじゃないかな？ あとは座標も表示してみる感じだろうけど、実際にスプライトを置いた方がわかりやすいですよね。

»ズレ 原点が合っていてもズレているのであれば、 nobuさんの3DSのタッチ判定が壊れて いる可能性が…? DISPLAY 1:WHILE 1:VSYNC TOUCH OUT TM,TX,TF IF TM THEN GPSET TX,TF WEND みたいにして確認してみて下さい。

でんぺんさんが仰った通り、1×1の点スプライトをタッチで表示すると、タッチした位置ピッタリになるようですが、それってサイズが小さいから原点が関係なくなっている感じで……それで一体何が分かるのでしょう？

１×１の点のスプライトと他のスプライトを同時に表示すれば、その1×1のスプライトの位置は他のスプライトの原点に表示されるはずなので、まずそれが正しいかどうか見てみてはどうかと思いました。 あとはダニエルさんも言われているように、タッチ判定がズレている可能性もあるんで、それを確認するためでもありました。

言い切ってしまうと、何もしていないのにタッチ座標に移動させたときだけスプライトがずれる、なんて事はまずあり得ません。 ・ずれているスプライトのSPDEF ・ずれているスプライトのSPOFS（SPANIM） この２つのどちらか、もしくは両方がおかしいのかと思います。

普段はSPHOMEを使わず、左上を原点にしてSPOFSの位置を決めていたのですが、タッチした場合は左上が原点になる？ スプライトのサイズを3倍にしているので、SPHOMEで24,24を原点にしたら、TX,TYをそれぞれ-24するとタッチした位置に表示されるようになるみたいですけど…。

タッチした時だけ左上が原点になるなんてこともまずないと思います。 スプライトの拡大を1倍（デフォルト）にしてもその症状は起こりますか？

ん？　SPHOMEを使わずに左上を原点にしていたら左上になるのは当然なのでは？ ちなみにスプライトのサイズを拡大してもSPHOMEの原点の位置は拡大前のスプライトのサイズに対しての位置ですが、その辺間違ってる？？？

処理が ・タッチ座標取得（座標取得だけ、SP関係なし） ・SP拡大/SPSCALE+SPOFS/ SPHOME前かあとか ・SP座標指定/SPHOME+SPOFS / SPSCALE前かあとか の３つあるので、 デバッグとしてはそれぞれ単体でちゃんと動作してるか確認する必要があります。 タッチ座標はGPSETで正しいことが分かったので、TOUCH系は問題なさそうなので、 あとはタッチ取得結果を画面中央と仮定してコードを書いてみて、SPHOME+SPOFS, SPSCALE+SPOFS のどれがうまくいってないのか調べる感じになります。 ※たぶんSPSCALEで拡大したらSPHOMEの位置が正しく設定できないか、 SPHOMEで原点指定してSPSCALEすると原点ずれるとかそういうのかも？

拡大時のズレの増幅についてはBlackSoftさんの言われているような感覚になると思いますが3倍程度なら誤差の範囲でそれほど大きくズレていると感じないと思います。 ちなみにスプライトを３倍にする場合でもしない場合でも、元のスプライトのサイズが16×16の場合は、中心は8,8になるので、SPHOMEは、 SPHOME 0,8,8 のような感じになると思います。これは何倍にするとしても変わらないです。 一応その辺が間違っているのかなと思ったので補足しましたが、そんな感じでした。

間違ってたらすみません。 もし、SPANIMで表示位置が ずれているとしたら、SPHOMEではなくて SPDEFで、使うすべてスプライトの基準点 (SPDEFの説明では原点)を変えておけば ずれなくなるのではないかと思います。

な…なるほど！でんぺんさんが書かれているように、「SPHOMEとSPSCALEを併用した際に、SPHOMEの数値を変える必要が無い」ということを知らなかったので、そこを間違えていました…。 しかし、「SPHOMEの数値を正しく直したのに、タッチしたペン先の位置がSPの左上であった」ので、「タッチの判定とSPHOMEには関係が無いのか？」と思っていました。 そこで気になったのが、マギーさんのご指摘で、「SPDEFの設定（原点）が左上になっている」ということに気が付きました！ つまり、「タッチした時の判定はSPHOMEではなく、SPDEFのほうで決まる」という認識で良いのでしょうか？ 入力した順番的には、SPDEF→SPHOMEなので、後から使ったほうに影響されると思っていたのですが、「タッチした位置はSPDEFの原点で表示される」ということですかね？

SPHOMEで指定した原点座標は、SPDEFで設定したものに上書きされるはずなので、 「タッチで取得した場合は」とかの特定の条件の時だけ原点座標が変わるということはないと思うのですが… これまでのコメントから、3DS本体のタッチ判定のズレはないみたいなので、 タッチで取得した変数になにか足し算や引き算してないかとか、 SPHOMEで指定しているスプライトの管理番号は間違えていないかとか、 そういった基本的なところで見落としがある可能性もありますが、いかがでしょうか？ ちなみに、SPSCALEは、原点座標を中心として拡大拡小するというイメージです。 なので、拡大してない状態から原点座標を真ん中に設定して、SPSCALEするとイメージが掴みやすいと思います。

他の人も書いてますがSPANIMでアニメーション（"I"）を使っていますか？　それによっても異なります。 I（定義番号）のアニメーションなど、スプライトを定義番号で切り替えた場合、定義には原点座標の情報も含まれるので、切り替えた時点で原点座標が変化します。なのでSPHOMEで原点座標を変更していても、その後定義番号を変更（SPANIMやSPCHR等で）したら原点座標は定義で設定されている値に戻ってしまいます。 これを回避するには定義の方の原点を変更しておく、ということになるのでSPDEFの時にきちんと原点を設定（変更）しておく、ということになる感じです。 SPSETやSPCHR後にキャラクタを変更しないのであれば、その後にSPHOMEして原点を変更すればそれは継続するので問題ないですが、アニメーションとかしている場合は注意です。

とりあえず、いろいろな情報を参考に、数値を変えて検証を繰り返した結果、タッチしたペン先がSPの中央になるように調節できました♪ その方法は、まず SPDEF で原点を 0,0 にしておき、 SPHOME は使わず、 SPOFS の座標を -24,-24 にするという組み合わせでした。 どうやら TOUCH の座標はSPの左上端になるようで、 SPDEF で原点を 8,8 にすると、タッチしている間に動いてしまうという現象が起きました！（原点が 0,0 なら動きません。） タッチした場所がSPの中心になるように設定したかったので、 SPのサイズに合わせた -24,-24に座標をズラすことにより、 目的通りの位置に表示できるようになったようです。 この結果に納得できない方は、ご自身で同じように入力して試してみてください！

TOUCHの座標だからSPの位置が左上端になるということは関係ないと思うので、なんらかのミスや思い違いをしているような気はしますが、とりあえず動作することは大事なので自分なりのやり方を見付けたならそれでもいいのかなとは思います。 ただ間違った情報になる可能性もあるんで、その場合はシンプルなサンプルプログラムを提示するなどした方がいいかもしれないですね。

SPって、いろいろな形になっていますけど、元々は四角じゃないですか？ 原点を変えることで、中心辺りを原点にできますけど、TOUCH の座標は四角の左上端と決まっているのでは？（そういう感じに思えました。） 公式ガイドの SPHOME の説明にも、位置移動や回転、拡大縮小、衝突判定の基準点と書いてありますが、TOUCH 座標が変わるとは書かれていないので、TOUCH の座標はSPの左上端になるように固定されているように感じました。 なので、SPのサイズによって SPOFS の座標を補正しなければ、SPの中心を指すようにできないのではないでしょうか？（何か間違っていますかね？）

TOUCHとSPはまったく別の命令なので関連するはずがないと思いますが...。 いっそのこと、そのプログラムをココに公開してみてはどうでしょう？ そうしないと私達も意味不明意図不明状況不明、推測で話すしかないので... 全部解決してスッキリするかもしれませんし。

これを試してみてください。 ちゃんとタッチの位置が原点なのがわかると思います。

一番最初に書いたことですが、SPに関する疑問は複数あるので、とりあえず次の疑問にお答えください！（タッチについては、後で修整できるので…。） 2.デフォルトのSPには、0～4095までの番号が付いていて、上下に同じSPを表示させることができます。けれど、自分で SPDEF を使って定義したSPを上下に表示させようとすると、範囲外のエラーになってしまうことがあります…。 ちゃんと DISPLAY で上下の画面を切り替えているので、それが原因の範囲外ではありません！ たぶん、上下合わせて512個までのSPしか使えないのに対して、SPの番号が最大448になっているせいだと思いますが、同時には表示しないように使うSPだけを SPSET して、使わなくなったSPは SPCLR しています。 この問題を解決するには、どういう対策をすれば良いのでしょうか？

う～ん、②の質問も状況が不明確過ぎて答えようがないので推測ですが… 「表示させようとすると範囲外のエラーになる」ということは、 「SPSETがOut of rangeになる」という認識で問題ないでしょうか。 そうだとすると「XSCREENで下画面にスプライトを振り分けていない」可能性が一番高いと思います。 次に高いのは「上下画面の管理番号の認識が間違っている」。 例えば512個のスプライトを256個ずつ上下に振り分けたとすると、 管理番号は「0~255」と「256~511」になるのではなく、 「0~255」と「0~255」になります。

というより、やはり説明が不十分なので、一旦症状の起こるプログラムを公開して、 そこで対策を募った方がお互い無駄な意見の交錯が無くて済むと思います。

上下合わせて512個のSPなので振り分けるとどうなるかはVillitさんの答えの通りです。おそらく振り分けた以上の番号を使おうとしているからエラーになってるんだと思います。 また表示しようとしたときにエラーになってるのはデフォルトのスプライトじゃなくて自分で定義（SPDEF）したスプライトだからと言うのは関係ないと思いますね。 管理番号と定義番号がごっちゃになってる可能性もありますが、どうも説明が不十分というか推測が必要部分が多いのは僕も感じもます。 ただそれ自体はわかってないことを質問しているのでしょうがない部分もあるとは思っていますが、原因を突き止めるためには症状が発生する短いサンプルとなるプログラムを作ってみるとか、実際に不具合があるプログラムを公開した方がいいような気はします。

ご指摘通り、管理番号と定義番号の関係性がよく分かっていないのですが、デフォルトの場合255を超える番号でも使えるのは何故ですか？ Villitさんが書かれたように、同時に表示するなら上下256個ずつになるのは分かっていますけど、同時に使うのは上画面14個と下画面14個だけなので、それ以外はボタンを押した時にSPの14個セットを入れ替えるという形式にしたいと考えているのです。（伝わりにくい？） たぶん、デフォルトの番号の秘密が分かれば、対処法が分かるような気がします。

管理番号はスプライトを画面に出すときにそのスプライトに番号を割り当てて管理する為のものです。なので１つ表示する為には１つの番号が必要です。 定義番号はそれとは違い、画像（グラフィック）に対してスプライトとして使う部分を定義したときに割り当てる番号です。なのでこっちの方は画面に出てなくても定義することで１つの番号を使います。こっちは画面表示とは関係ないので表示出来るスプライトの数以上の数を定義しておくことが出来ます。 （のでデフォルトでは同じ絵に対して原点が違うものと2パターン用意（定義）しているようです） 上画面、下画面で使うのが各14個だけなら、スプライトの管理番号は上画面も下画面も0〜13（合計14）番だけ使えばいいはずです。 ちなみに定義番号が400番のスプライトを表示する時には管理番号は400番を使わないといけないというわけではないですよ。

あーっ！そうか！4095とかは定義番号であって、管理番号じゃないから256や512を超えていてもオッケーなんですね。 今まで256個以下のSPしか使っていなかったので、管理番号と定義番号を同じにしていても問題なかったのですが、今回のように448個のSPを使いたい場合には、14個の管理番号に定義番号を入れ替えるようにすれば良いんですね。

そうそう、イメージとしてはそんな感じですね〜。 なので当然ですが別々の管理番号に同じ定義番号（絵）をSPSETして表示すれば、同じ絵を複数表示する事も当然可能ですし、それを上画面も下画面も同じものを表示する事も可能です。 基本的に管理番号と定義番号を同じにして扱うことはほとんど無いと思いますね〜。

以前に、でんぺんさんからSP命令の基礎を教わった際に、「管理番号と定義番号を同じにしていると数字を間違えにくいと思い込んでしまった」ため、なるべくそうするようにしていたのが問題でした…（苦笑）。 それでも、使うSPの数が少なかったため、特に問題になることはなかったのですが、今回は小さいSPをたくさん使用することになったので、管理番号が足りない事態（範囲外）となったという訳ですね。 ところで、SPを切り替える方法は、SPCLR からの再SPSET という以外に無いのでしょうか？

思い込みや勘違いでというのはまあありますからねー…。形だけでなく意味もしっかり覚えておくことが大事、みたいな感じですかね。 で、スプライトの絵（定義番号）を切り替えたいならSPCHRが便利ですよ。SPCLRからのSPSETだと座標情報とかほとんど初期化されちゃいますがSPCHRなら絵が切り替わるだけなので。 アニメーション（パラパラ系）の場合は、SPANIMで”I"（定義番号）を使えば一定時間毎に絵（定義番号）を切り替えてアニメーションっぽく見せることが可能です。

あ！SPCHR は管理番号,定義番号だから、すでに定義されている番号であれば、定義番号を入れ替えるだけで済むのですね。 つまり、わざわざ SPCLR して、SPSET から全てやり直さなくても、そのまま切り替えて続けられるんですね♪ 今まで曖昧に覚えて使っていたのが、きちんと性質を理解して使えるようになれそうです！

ん? キャラの定義番号を変えるだけなら、 SPSETでする場合でもSPCLRは いらないですよ。 このトピックの題に「研究」って ありますけど、nobuさんの場合、 「他人に教えてもらって知る」ことが多く、 「自分で実験してみて考察してみる」って のが少ないじゃないでしょうか? そういう実験してみるっていうのも プログラミングの楽しみ方の1つだと 思うんですが。

ちなみに、 SPCHRではなく、SPSETの場合は SPCOL等で設定したもの等が リセットされる仕様になっていた かと思います。 (SPVARの数値が変わらない 不具合があったような)

だにえるさんが言っているように同じ管理番号をゼロから再利用する場合は、SPCLRせずにSPSETから始めても大丈夫です。SPSETは基本的に設定が全てリセットされます。SPCLRは単純に不要になった管理番号を消したいとき（そしてすぐに利用するわけではないとき）に利用すると良いでしょう。 そしてご理解されたように絵だけ変えたい（切り替えたい）なら逆に他の初期化はして欲しくないケースが多いのでSPCHRで切り替えるだけでいいと思います。 また研究の仕方としては、僕が載せたプログラムのようにテストしたい部分のみの必要最低限のプログラムを書いてみて検証するのが良いです。プログラムは大きくなってくると要因が増えて特定がしづらくなる部分もありますからね。 また簡単なチェックぐらいならDirectモードでテストしてみるのもありです。僕自身も慣れない命令はDirectモードで試す事もあります

SPHOME命令というのはキャラ定義（SPDEF）の中心座標（基準点）そのものを書き換える命令ではないです。 SPDEFの基準点を一時的に変える命令でしかなくその効果の範囲も限られます。 その効果の範囲はヘルプに記述されているようにSPOSF使用時、回転や拡大・縮小使用時、衝突判定使用時です。 したがって、キャラの定義番号を変えた場合にはSPHOMEは有効に働かないわけです。 それを見越してアニメーション表示の際はSPHOMEは使わずにSPOFSで補正というのは解決策の1つとしては正しいです。

なぜ、SPHOMEでSPDEFの基準点を書き換わらないかというとスプライトの管理番号と定義番号は別物だからです。 これはMiiversに例えると管理番号というのはnobuさんのdivine-creator、私のochame_nakoが相当します。 定義番号というのはnobuさんのMii、私のMiiが相当します。 Miiというのは使いまわしが可能であり、私がnobuさんのMiiを使うことは可能なわけです。 それと同じく別の管理番号のスプライトで同じキャラ（定義番号）の絵を使いまわすことが可能です。 その時にSPDEFの内容が勝手に変わったら困ります。 例えば私がnobuさんのMiiを使い、目や鼻の位置を変えたらnobuさんが使用しているMiiまで変わってしまったら困りますよね？

それと同じく同じ絵を使っているスプライトに影響を与えないようにSPHOMEはその管理番号のみ有効になっていてSPDEFまで影響を与えないようになっているのです。 管理番号と定義番号はこのように全く異なるものなので混同しないことがスプライトを使いこなすためには重要です。（SPSETでSPDEFを介さずに設定できるため混同してしまうのはやむを得ないですが） 基本的に分からないことがあった場合にはヘルプを見ると良いです。 ヘルプ自体が間違っている場合もまれにありますがそういう例外を除けばヘルプを見れば大抵のことは書いてあるし、それを見ても分からないことはMiiverse等で質問をすれば答えてくれると思います。

これまでに知り得た情報により、管理番号と定義番号を直して、不要となった部分を消し去ったら、正しく SPDEF の原点(8,8)が、タッチペンの先になるようにできました♪ これで、簡単な方のタッチアニメは完成ですが、後は難しい方のタッチアニメをどうするかですね…。 タッチした位置に向かって歩いていくアニメの需要ってあるんですかね？ まぁ、できた方が何かの役に立つかもしれませんけど…。

とりあえず、十字キーで動かすCAT_WALKも、TOUCHと同様に管理番号のムダを無くし、切り替えシステムを修整したら、以前より良いプログラムになりました♪ TOUCHと違って、下画面には表示しないのですけど、プログラムの形式が似ているほうが、応用しやすいと思ったので、他のプログラムも修整することにしました。

SPDEF： GRP5のどの領域をどのように表示させるかなどの情報を登録（定義番号） SPSET： SPDEFで定義した情報でスプライトを使えるように登録（管理番号） と、２つの情報があるのが実は公式の操作説明書やヘルプからだとわかりづらいのもあったり （ヘルプからいろんな疑問を解決していくとそういう結論に行き着く感じ） BASICっていろいろとあんまり考えずに操作できるようになっていて、電子マニュアルでもとりあえずSPSETしてSPOFSして操作できるような作りになってるけど、 そこからちょっと考えて操作するようになると、いろいろと構造を理解しないといけなくて、その理解しなくちゃいけない情報を調べていくのが結構大変というのも。 （公式で機能ごとのそういう使い方のユーザーズマニュアルほしいって言ってるんですがさすがに対応大変そうで）

でんぺんさんも書いてますが、何かおかしいことが起きてるならコード見てもらった方が早いので、今作ってる動きがおかしいプログラムから、今回ならTOUCH,SPDEF,SPSET,SPHOME,SPSCALE あたりを抜き出した小さいプログラムを書いてみて、それでも動作がおかしいかの確認をするといいですよ。 その小さなプログラムを作るときに、実は使い方が間違ってることに気づくかもしれないし、質問される側も今回のように管理番号と定義番号が混同していることに気づけるので。

ところで「タッチした位置」＝「SPOFSで指定する座標」の意味で書いているとは思うんですが、「タッチした位置に表示されない」と書いているので みんなは「TOUCHで座標取得したときだけSPOFSがおかしい」と認識してる流れだったりします。 たぶんコードの流れとして説明に出てきたこと以外も結構やってそうなので、それも含めてそういった動きであろうと思い込んだと見えるので なにかおかしいなと思ったら最小コードを書いてみることをおすすめします。 （こういったデバッグ作業もいろいろ経験して初めて分かることも多かったりします）

SPDEFを介さずにSPSETで直接定義までできてしまうからさらに複雑なんですよね。 私もプチコン3号に関して100％熟知しているとは言い難いのですが、それだからこそ分からない部分はいろいろ試してみて自分の中での理解を深めています。 その結果得られたものはプチコン3号入門講座等で記述しています。 私の場合は作品作りの時間よりそういった実験的な試行錯誤の時間の方が長いかもしれません。

他の命令もそうなのですけど、特に SPDEF と SPSET は使い方に幅があって、良く言えば自由度が高いとなりますが、初心者にとってはどの使い方が良いのか分かりづらいとなりますね…。 私はでんぺんさんから教わった時に、SPDEF と SPSET を併用すれば SPSET が簡単な形で入力できると知って、それ以来 SPDEF を必ず使うようにしているのですけど、他の人は SPSET のみで使っている場合があり、そちらの方法はよく知らないままの状態です。 自分が分かりやすい方法を選ぶので良いとは思っていますが、どの方法が一番使い勝手が良いかは全く分かっていません。 そう考えると、初心者向けのサンプルと言っても、どんなプログラムが適切なのか？は分かりませんね…。 理想的なサンプルというのがあるのか不明ですが、「どんなサンプルでも結局は一例に過ぎない…。」というような気がします。

私は20年以上前からいろいろなメディアにおいて初心者向け講座を書いていますが、「初心者向け」と一言でいっても何をもって初心者向けとするかという明確なものはないと思います。 要するに「絶対的な初心者向け」というものはなく「自分が考える初心者向け」「多くの人が考えているであろう初心者向け」しかないと思います。 しかし、実際に不特定多数にアンケートでも採らない限りは多くの人が考えているものなんて分かりません。 というわけで、「自分が考える初心者向け」で正解だと思います。 その際にはこのやり方のどの辺が初心者向けなのかを理解しておくと良いと思います。 方法自体は無数にあるうちからその方法を選んだのだからそれなりの理由があるはずです。 それが、自分の中でしっかりしたものであれば「一例」とはいえ十分に納得できるものになると思います。

アニメーションがなくてわざわざ定義するほどでもないものであればSPDEFせずにSPSET出来るのは便利なんですが、確かに使い方が多いと混乱が増えるというデメリットはありますね。 この辺は経験である程度は回避（推測）出来るのですが、逆に初心者は経験がないわけなので難しくなってしまう部分があるんだと思います。 「どんなサンプルでも結局は一例に過ぎない」というのはその通りでプログラムの場合はとくにその面が強いと思います。なので逆に同じような内容の処理でもたくさんのやり方のサンプルに触れた方が勉強になりますし頭が柔軟にもなります。 僕はサンプルとして適しているのは目的に特化した感じでリストが短い（出来れば1画面内）ものかなと思っています。（ので自分がそういうサンプル作ってましたし） また出来るだけ公開キーでダウンロードするよりも自分で打ち込んだ方がいいと思ってもいます。

そうですね♪ プログラミングが苦手であるにもかかわらず、私が初心者向けのサンプルを作っている理由は、自分が分かるようなプログラムであれば、他の人でも理解しやすいだろう…という考えがあるからです。 もちろん、今回作っているプログラムは、デフォルト素材をアレンジしたオリジナル素材を使っていて、独自の構成で作っているため、プログラミングを始めたばかりの人では難しいと思います。 もし始めたばかりの頃の自分がこれを見たら、「全く分からん！」となるのは確実です…。 けれど、比較的簡単な仕組みで作っていて、ある程度の基礎知識を身に付けた初心者が、「アニメーションするスプライトを使えるようになりたい！」と思った時に、参考になるような内容のプログラムにはなっていると思っています♪

SPDEFに関しては、定義用のファイル(SYS/DEFSP.GRPやSYS/DEFBG.GRPみたいな)が、別途用意されてる訳でもなくプチコン起動時(またはSPDEFを引数なしで実行時)SYS/DEFSP.GRPに合わせた定義がされてしまう(デフォルトでROMに焼かれてて変更できない的な)仕様になってるのが、分かりにくいところです。 なんとなく、デフォルトで、BGみたいに16X16均等割で、SYS/に定義用のファイルが有って.GRP同様、起動時とかACLS時に都度読み込むという仕様の方が分かりやすい気がしますが、なぜこんな仕様になっているんだろう・・・ まあ、デフォルトのGRPを(同一枠内で)一部変更して使う分には、あまり意識しない部分ですが

この投稿をする以前に、スライドパッドでのアニメーション歩行はできていたのですが、ここで知り得た情報を活かして修正を加えた結果、何故か一時的に不具合が発生して、それを直すのに時間がかかりました…。 スライドパッドでの方向判定は、おちゃめさんのサンプルを参考にして、XとYの大小による方法を選んでいたので、それを応用すればタッチでの方向判定もできそうだと思ったのですけど、スライドパッドとタッチではマイナス方向への数値が異なるため、左と上向きへの方向転換がうまくいきませんでした！orz

おちゃめさんの投稿にも質問を書いたのですが、こちらでも分かる方に答えていただきたいです！ たぶん、スライドパッドは左がマイナスになるのに対し、タッチにはマイナスが無いため、そこが上手く変えられなかったせいで失敗しているのだと思います…。 また、スライドパッドのY軸はプラスとマイナスが逆になっていることも影響しているのだと分かるのですが、それをどう修正すれば良いのか？が分かりません！ イメージ的には何となく分かっていても、実際にそれを表す式が作れないのです…OTL。 おちゃめさんのサンプルプログラムを見て、それをタッチ操作に応用するアイディアを思い付いた方は、是非お知らせください！

あっ！別に、スライドパッドと同じが良いというわけではないので、タッチした位置に向かって歩行アニメをさせる方法が分かれば、それでも構いません。 元の位置からタッチした位置への向きを判定する方法が分からないので、それができれば解決です。 スライドパッドと似たような判定になるのかな？と思ったため、それを元に作ろうとしたのですけど、左方向と上方向への転換が上手くいきませんでした…orz。 タッチされた方向を四つに判定する方法が考えられないんですよね…(´・ω・`)。

書き直そうと思って消したら返事が…。 タッチした方向に動く場合、タッチした場所にまっすぐ歩いてくる感じですか？ 基本的には追尾に近い処理になるので三角関数の出番ですね。

一応、歩く動きはスライドパッドの方法で上手くいっているんですよね。 ちゃんとタッチした位置に向かって歩いてくれています。 元の位置からまっすぐタッチした位置まで歩いて止まります。 失敗しているのは、向きを変える判定だけなので、たぶん判定の部分の式を正しくできれば良いと思っています。 ただ、充分な理解ができないまま、おちゃめさんのサンプルをアレンジしただけで使っている状態のため、タッチ式への改造ができないというのが現状です…。

おちゃめさんのプログラムを独自にアレンジしたのが、画面写真のプログラムで、×が付いている部分が、正しい方向にならない所です。

タッチでマイナス方向を作るには、元の位置をBTX,BTYという変数にして、タッチされた位置TX,TYから引けば、プラス方向とマイナス方向が出るので、それで左右や上下を判断できると考えましたが、斜め方向への移動の場合に上下になるのか？左右になるのか？を判定する方法が分からないんですよね…。 おちゃめさんのスライドパッドでのサンプルは、その判定を見事に判断しているのに感心します。

画面のアレンジを見た感じ、アレンジを間違っていますね。STICKとTOUCHは違うので、単純に命令を入れ替えたようなアレンジではうまくいかないですよ。 元の位置からタッチされた方向を利用して方向を出すという考えは間違ってない部分もあります。その考え方の元、おちゃめさんのプログラムを応用する感じにしないと目的の動作にはならないと思いますねー…。

ボタンは押したボタンによって直接方向がわかるけどスライドパッドはアナログなのでその値（移動量）から方向を算出しています。通常はATANなどを使って角度から方向を求めますが、おちゃめさんの場合は４方向なら単純な移動量比較で求められるというところが優れているところです。 TOUCH命令の場合は、戻ってくる値は移動量ではないので、まずは移動量を求める必要があります。それが出来ればその移動量はSTICKの値に近い値として扱えますが、STICKと違い画面上での移動量はY座標の符号が反転するので、そこだけ逆にします。その上で、その移動量から方向（向き）を求める（やり方はおちゃめさんの応用で出来るはず）ようにすれば、目的の動作になるんじゃないかと思います。

スライドパッドでアニメーションしながら上下左右に動かすプログラムは私が作ったこのサンプルプログラムを参考にしたそうですが、なぜSX、SYの大小比較だけで上下左右の4方向のどちらに向いているかが分かるかという根本的な部分を知っていればそれをそのままタッチで使うことが可能です。

大小比較でなぜ4方向の判断が可能かというのは一次関数y=xとy=-xのグラフを描いてみれば実は一目瞭然なのです。 例えばy>xというのはy=xのグラフよりも上の方の領域、y>-xというのはy=-xのグラフよりも上の方の領域となります。 そうなるとy>xかつ、y>-xの場合はその2つの領域が重なる部分となるため原点を中心とした上方90度の領域となります。 これを4パターンで判断すれば上下左右が判定可能になるわけです。 実はこの方法はベクトルの外積を使って行う判定と根本部分は同じでこのやり方を覚えておけばベクトルの外積にも応用が可能です。

これを踏まえてタッチへの応用ですが、重要なのはキャラがどこからどこへと動くかということです。 十字ボタンであれば右を押せばキャラは現在の座標から右に動きます。スライドパッドでもそれと同様です。 そのためボタンやスライドパッドの場合は押してない状態が原点となるわけです。 タッチの場合はキャラのいる座標を原点座標として考えればボタンやスライドパッドと全く同じ考えで処理が可能です。 現在のキャラより左側をタッチするとX軸の相対座標（移動座標の量）はマイナスとなるため上記のグラフによる判断と同じ方法で可能なことが分かると思います。

ちなみにX、Yの大小比較（具体的には上記のようにY=X、Y=-Xとの比較）だと基準が斜め45度であるためそれを境目にした判定が可能になるのはグラフを見れば一目瞭然（斜め45度の矩形も判定が可能）なのですが、X、Yの値だけで判断するとX軸、Y軸に平行な線を境目とした判定となるためそれに応じた判定しかできないため斜め方向の判定は行うことができません。 「なぜこのように判定できるのか」というのを理解して他の人が作ったプログラムを読むとより深い部分が見えてくるため脱初心者を目指すならば個人的にはオススメしたいです。

でんぺんさん、さすがに私でも明らかに間違っているのは分かっています。 とりあえず、タッチに置き換えたらどうなるか？を見てから、どう変えたら良いかを考える途中の状態だったというだけです。 おちゃめさんの分かりやすい解説のおかげで、何とか正しく動くようにできました！ 色分けされたグラフがとても分かりやすかったです♪

途中段階なのはわかっていますが、STICKをTOUCHに変えただけのようなプログラムを出したら、始めは僕のような回答になると思いますよー…。基本的には提示した内容に対してのアドバイスが基本で、その先まで読むかどうかは別の問題なので…。 元がおちゃめさんのプログラムなので、おちゃめさんが回答してくれたのはわかりやすくて良かったと思います。実際それで出来たみたいですしね。 ちなみに僕が次にアドバイスするとしたら提示しようと思っていたプログラムは次のようなものでした。もう不要だと思いますがせっかく用意してあったので載せるだけ載せておきますね。 ということで、これからも頑張ってください！

だいたい同じような形式ですね。 私の方はスプライトの並びやアニメの設定が異なっていますが、計算式は同じです。(違っていたら変ですけど…w。) これで、今回のトピックで知りたかった疑問は全て解決できました♪ でも、まだ使ったことのない命令に関しては、分からないことだらけなので、また別の機会に質問すると思いますけど、その時もよろしくお願い致します！ このトピックは、しばらくしたら予告無しに終了します。

変数D絡みの部分は不要に見えますが、主な処理は同じ流れですね〜。

あっ！スライドパッドからのアレンジの残骸ですね…(苦笑)。 タッチなので、TM==0 か TM>=1 のどちらかだけですね。

そうですね〜。 TMの所はELSEを使っても良さそうですね。

猫の日なので、完成したリニューアル版SPRITE_MOVESを公開するのニャ♪ 【JK2KQXZM】特に問題が無い限り、これで最終版とするのニャ！