あとは一応、DATAからマップを作るのと逆のことをすれば良いことにもなります。 DATAから文字を読み取ってその文字をBGPUTの数値に変えて配置しているわけなので、その逆にBGGETでマップの情報を取得してその数値を文字に変換できればDATAに戻せる、と言うことにもなるので。 直接マップデータから変換できなくても一度マップをBGに表示して、その表示したBGの内容をDATAに変換できればという感じですね。 余裕があれば、凄く簡易的なサンプルぐらいなら作れるかもしれませんが、とりあえずはそんなイメージです。

あー、なるほど。ナルミンチョさんの発言ですね…。 この人は独自にマップデータを解析してDATA文に変換するプログラムを作ったのだと思います。 基本的にはマップ表示ルーチンと似たような処理で実際にBGPUTするのではなく、それをDATAの文字列に変換するようなプログラムを組む感じになると思いますが、色々とルールを決める必要があるので、自分である程度組めないと難しいかもしれません。 以前、自分のツール（PUCHI-MAP）にこのDATA書き出し機能を実装しようかと検討したことがありますが、DATA形式やUIの問題があって見送った経緯もあります。 専用のツールとして新設すれば可能かもしれませんが、とりあえずちょっと今は予定にはないですね…。すいません。

？ 前の投稿って誰のですか？

正直、僕もREPEATを使う機会はそんなに多くはないです。通常のループであれば、プログラムを頭から読んだときに終了条件がすぐ目に付くWHILEの方を使います。 なので頭の中でそんなのがあると覚えておいて、もし1回は実行して欲しいみたいなケースが発生したときに、そういえば！って感じで思い出せればいいと思いますよ。 ということで、なんだかんだで色々と話が飛んでしまった気もしますが、これからも頑張ってください！

ばいしさんの覚えようとする姿勢はとても良いと思いますし上達すると思いますよ！ ちなみにWHILEとREPEATの使い分けで僕が意識的によく使うのはボタン待ちの時ですね。たとえばAボタンを押すまでループさせる場合、 WHILE BUTTON(2)!=#A:WAIT:WEND と REPEAT:WAIT:UNTIL BUTTON(2)==#A の2通りの書き方があります。一見同じような処理に見えますが、実はこの場合は下のケースの方がよりベストだったりします。 理由はBUTTON命令はVSYNC（やWAIT）のタイミングでボタン情報が更新されます。なので上のケースだとボタン情報が更新される前の状態でチェックされてWHILEが実行されない（正確にはすぐ抜けてしまう）という状態になる可能性が残ってます。 下のケースの場合、必ずWAITを通ってから判定がはいります。

一つ前の投稿と内容がかぶってるかも？ 使用している読みこみ方法はレイヤー（BGSCREEN）形式のセーブデータみたいですが合ってますか？　もし合ってないならマップデータ形式の為の読みこみプログラムが必要になります。 もしマップ形式の場合は、一つ前の投稿で書いたリンク先の投稿に色々書いてあるので、そっちも参考にしてみてください。

ツララさんのFORはちょっと特殊なやり方の部類ですね。（終了条件によるFORによるカウンタ処理）　ただ覚えておくと便利なところもあるかも。 使い分けという面では、WHILEとREPEATがあると思います。両方とも条件によるループですがREPEATの場合は必ず1回は実行される差があります。 通常はWHILEで考えると思いますが、場合によってはREPEATの方が適しているケースもあったりして、そういう場合は使い分けられるようになると便利だったりしますね。 それに使い分けといってもループ系は、GOTO（プログラムに慣れたら非推奨？）、FOR、WHILE、REPEATの4種類ぐらいじゃないかとも思うので、それほど難しくもないですから、少しずつ使ってみるといいと思いますよ。

なんとなくでも分散のイメージが掴めたのなら良かったです。 今はまだVSYNCやWAITの数値による制御が多いですが、その辺は経験で減らせていければ良いんじゃないかと思います。 あと必ずしもそうしないといけないというわけではなくて、必要に応じては部分的な処理（ループ）で画面の一部だけ更新するような場合もあります。（平行動作させる必要がない部分的な演出など） なのでケースバイケースですが、複数のオブジェクトを同時に動かす際には、この平行動作の考え方は出てくると思うので、少しずつ覚えて使っていけるようになればいいなと思います。 ちなみに複数のオブジェクトを同時に動かすようになると配列などの出番も増えます。 という感じですが、これからも頑張ってください！

大きな流れとしては、 メインループ ｛ 　・ボタンなどの処理 　・カーソルの処理（表示含む） 　・顔文字の処理（表示含む） 　・VSYNC（ここで1枚の絵が表示されるイメージ） ｝ という感じです。そして各処理の間ではWAIT（やVSYNC）を入れないのがポイントです。あくまで表示タイミングはメインループ最後のVSYNCに一括して任せて、それまでは1コマの絵（1フレーム）の画面を作るだけの処理にする感じです。 そうすると必然的にタイミングや状態を管理する為の変数が増えることになったりもしますが、その辺はいずれどちらにしても必要になってくる事なので、試しながら覚えておくといいと思いますよ。

プログラムの見えない部分（上の方）がわからないので正確にはわからないのですが、プログラムの流れを頭から追ってみるといいと思います。 そうすると必ず15行目のGOTOで別の場所に飛びます。それで、その別の場所からはGOTOで@MYCに飛ぶ（戻る）ような動作になっていますが、そうなると16行目から下にプログラムが流れることがないことになりますよね。 （ラベルのある21行目から下はGOTOなどで飛ぶので流れる可能性がありますし、実際に流れてますが） という感じで見ていくとデットコードになっているのに気づけると思います。 ばいしさんはまだプログラムの流れの一部で処理をしようとし過ぎている印象がありますね。なので、その流れの一部で処理が止まる（ループ）してしまって、他の部分が動作が並列して動かせないわけです。 なので、全体を大きな流れとしてとらえられるようになるといいですね。

今のプログラムでは、16〜19行は実行されないデットコードになっていますが、その辺ってわかってますか？　プログラムの流れを理解してないとなかなか動作のイメージが掴みづらいだろうと思ったので…。 変更したプログラムも並列動作させるプログラムとしては、ちょっと微妙な部分もあるんで悩ましい感じもありますね。まあでもとりあえず目的通りに動いたのならいいのかな…。 並列的なプログラムのイメージはパラパラ漫画を作るのにも近いです。1フレーム（VSYNC）の間に1コマの絵を作ります。3つの物を動かすとしたら3つが1コマだけ動いた状態にするわけです。ウエイトをしたい場合は、しばらく動かさない（変更しない）という感じにして60コマ目に動かせば（VSYNCは1／60なので）1秒後に動くプログラムに見えるわけです。 という感じではありますが、少しずつ動かして理解を深めていく感じだと思います。

キャラクターを動かしながらカーソルを動かしたい、などの場合、23行目や25行目のように長時間のVSYNC（WAIT）を使ってしまうと、そこで動きが止まってしまうので希望通りの動作にならないと思います。 なので基本全ての処理を平行して動くように工夫する必要があります。そうするとメインループの中は基本的にはVSYNC（1／60）のみになって、それ以外でVSYNCやWAITで止めることはほとんどしません。（処理が一時的に止まっても問題ない時を除いて） おそらく今までボタンの処理がうまくいかないと感じているのはその辺が関係あるんじゃないかと思います。

見えてある範囲のプログラムではボタンの処理がないのでランダムに動く（ボタン関係ない）というのは、そういう動作のプログラムに見えますね。 具体的にどうしたいかを書きつつ、その付近のプログラムを載せる（もしくは公開キーを出す）と色々とアドバイスがもらえるかもって思います。

と言うことで、実際はSTICKで求めた値を現在の座標に足すことでスプライトを動かすことが出来ます。足すときにそのまま足すと上記のように-1〜1の移動量なので、それだと遅いと思う場合は足す値に対して10倍なり数字をかけて速度を上げます。 またWHILEからWENDの間はメインループ（繰り返し）になりますが、メインループの場合はVSYNCを入れて画面同期をとる（通常1/60）のが定石です。なので、WHILEの下かWENDの上辺りにVSYNCを入れましょう。 （どちらに入れた方がいいかは好みもあるので述べませが1箇所で良いです）

とりあえず質問にだけ素直に答えると、X100,Y100と書いてしまうとX100という変数名になってしまうので、今のままだと0（初期値）で動きません。 で、移動量を速くしたくて100倍にするという意図だとすると、 SPOFS 0,X*100, Y*100としてしまうと、現在の座標を100倍しているので表示位置は変わりますが移動量としては正しくありません。 みんなが言っているようにSTICKはスティックの動かした量（-1〜1）を返す命令なので、その値をそのままSPOFSするのではキャラクタの移動にならないです。（0,0から動かした量の相対位置には表示出来るけど）

プチコン3号を使ったことがないなら動作するコードを書くのは難しい（というかわからない）かも…。 それなら逆に擬似コードみたいな感じで、実際のコードではない書き方で教えた方が混乱が無いかもしれませんね。

もしブロックがスプライトだとしたらBGにした方が結果的には楽になると思います。

僕もSoybeanmanさんと同意見で、BUTTON入力がある場合などもVSYNC（もしくはWAIT）を挟んだ方がベターかなと思っています。 ただ入れる箇所は、22〜23行目の間の方がより良いかな？　つまりボタン判定をする前に一度VSYNC（WAIT）を通しておくことで、よりボタンが安定します。 これはBUTTONの引数が0よりも1以上の時の方がより顕著な感じもありますね。

BGとの当たり判定は座標からBGキャラ番号を求める事で判定します。 SPとの当たり判定ならSPの座標は分かるはずなので、その座標を元にBGGET命令でその位置にあるBGを調べます。コロウさんの書いているプログラムみたいな感じです。 実際は移動だったらBGを調べてからスプライトを移動させるか判断したり、移動後に座標の補正をしたりするような感じになります。 とりあえずBGGET命令を実際に使ってみて返ってくる値を調べてみたりすると感じが分かってくると思いますよ。

otta777さんに同意。 身近にそんなに頼りになる方が居るなら、その人に頼るのが一番だと思います。