＞otta777さん おお。やっぱりそうでしたか〜。 BGのキャラクターサイズってバージョンアップで実装されましたが、その前までは16で割るのが手っ取り早い感じがありましたが、こうなるとBGCOORDを使うメリットが増えそうですね。

投稿数が回復したので、少しだけコメントをプラスします。 主な改良としては、たくさんある配列がほとんど使い捨て程度にしか使われてなかったのでバッサリと削除しました。スプライトが使用されているかどうかはSPSET前ならSPUSEDという命令が利用出来るので、それを利用して使用スプライト（管理番号）を判別しています。 またCALL SPRITEで呼び出されるスプライトはCALLIDXで管理番号を得られるので、その番号をそのまま生かせば配列は不要になるので、そこも変わっています。 と言うことで今生きている配列は、３秒毎にスプライトを登場させる時に同じ場所（目的地？）に出ないようにチェックする為の配列だけになっています。 改良したプログラムも完全な意味で最適というわけじゃなくて、今の動作をトレースしつつ無駄を省くという感じで書き換えた感じです。その意味での問題は残ってるかも？

個人的には公式互換のマップツールを作っている事もあって、もう少しマップツールを使った作品があってもいいのになぁ…って思うときはありますね。 ただスマイルマップはイマイチ操作性が悪かったりバグがあったり（バージョンアップで直ってるかもですが）、何故かマップサイズの変更が出来なかったりと公式の割には色々と不都合が多いので、余計に使われなくなったんじゃないかなと邪推してしまいます…。 マップデータの読みこみに関してはレイヤー形式も用意したことで少しはハードルが下がったのかなとも思いますが、マップサイズは相変わらずなので容量は大きいですしファイル数も増えてしまうので、色々と微妙に感じてしまうところなんでしょうねぇ…。 逆に今度、マップツールを使って作った作品とかを尋ねてみたら面白いかもしれませんね。（あるのかな…？）

申し訳ないんですが、トピックと関係がない投稿は、折をみて削除させてもらうかもしれません。よろしくお願いします。

オワたず(^p^)ゝさんにあらかた言われたような気がしますが、僕なりに解釈すると、DATAで作る事のメリットは、 ・小規模なゲームの場合は1ファイルにまとめることが出来る。（公開時もフォルダ不要） ・プログラムを見てBGのイメージが掴める。またその場で改良しやすい。 ・データ量が少ない。（マップデータは圧縮されてないので基本大きい） ・ツールを頼らず自分で全てプログラムをしているような感覚が気持ちいい？ みたいな感じですかねー？　デメリットとしては、 ・複雑なマップを作るのが大変。 ・使うマップキャラ数が多くなると文字にマッピングするのも大変になってくる。 ・セーブしたマップデータの読みこみ方法を覚えないといけない。 って感じかなぁ。と言うことで、プチコンではDATAでマップする方が好まれているような印象を受けています。

＞くもきさん ごめんなさい。今回の投稿内容と話題が違うので別のトピックで新規投稿で質問してもらえますか？　そしたらそこに書きます。よろしくお願いします。

とりあえずの意図はわからない部分もあるのですが、今行われている処理と同様の処理を無駄が少なくなるように改変してみたプログラムをアップしました。 公開キーは：TE54F3KJです。 とりあえず今の処理は配列を使っている意味が実はほとんど無くて、最低限の部分だけ残すと公開キーで公開したようなプログラムになるんです。 もしかして削りすぎたことで今後追加していく上で問題があるのかもしれませんが、とりあえず現時点での動作は再現出来ているはずですので参考にしてみてください。 改変したプログラムについてなんでそうなったのかとかの説明が欲しいときは、質問してくれれば答えますのでー…。 と言いつつ実は今日投稿できる回数があと4回になってしまっています…。いつ回数が増えるかわからないですが、そんな感じなので投稿できなくて返事が遅れることがあるかもしれませんが、その時はすいません。

まず軽く見た感じの動作と確認です。 今想定している動作ってどういう動作なイメージですか？ とりあえず3秒毎に2体ずつスプライトが登場しているっぽいですよね？　それはイメージ通りですか？ ちょっと見た感じだと管理番号の管理がゴチャゴチャしている感じで、本当に意図通りの動作なのか謎でした。（たまたまそう見えるだけなのか、とか） なので出来れば、今実装しているプログラムが、どういう処理のイメージなのかとかわかれば、その通りの動作なのかなどがわかると思います。 一応こっちでも再度見てみたりしますが、もし良かったら色々と確認させてください！

公開キーどうもですー。そうなんですよね。手軽なのが良いところですよね。 DLして動作やプログラムを見てみたいと思っています。 ちょっとすぐに返事が出来ない可能性もありますが、必ずチェックしますので〜。

実は色々混ざっているのでどんな風に動いているのかがあまり想像できないんですよねー…。部分的には見れてるんですが…。 もし公開キーを出す事に抵抗がなければ、現時点のプログラムの公開キーを出してもらえれば、その動きとプログラムを見てみてコメントをすることも出来ますが、どうでしょうね？ でも公開キーを出す事に抵抗があれば、そういう人の気持ちもわかるので大丈夫です。嫌って次から発言しないとかはしませんので、笑

＞ごごちーさん ありがとうございます！　もしわからない箇所があったときは遠慮なく聞いてくださいね〜。なかなか過不足無く書くのも難しいので抜けてる点もあると思いますし…。

なんとなくスプライト番号とか配列の管理がうまくいってないような感じがしますねー…。 本来ちゃんと矛盾がなければ配列でも動作するような気がしますが、それがうまくいってないのはその辺りが原因かと…。 まあCALLIDXの場合は、呼び出し元のスプライト管理番号が必ず入るので、そういう面では間違いないですが、逆に配列との矛盾が生じる可能性はありますね…。

BGOFSがBGを動かす命令ですよー。 BGOFSでBGを縦に動かす（ずらす）ことで絵との位置を合わせた感じです。横の座標を変えれば横に動きますよ。 ただBGとスプライトは同期して動くわけではないので、スプライトも動かしたい場合は、BGの移動に合わせてスプライトも動かすことになります。

と言うことで、これで解説終わりです！ なんとなく雰囲気が掴めればいいなぁ、と思って作ったサンプルだったのですが、色々試してみないとわからない部分もあると思いますし、質問等があれば答えますが、冒頭で書いたように、ちょっとしばらくまた来れなくなるかもしれないので、質問など答えられるのは今日明日、ぐらいまでになっちゃうと思います。 それ以降の質問があったときは気づいたときに早めに返事できたらと思っていますが、今のうちならすぐに回答できます。 という感じで、久しぶりの解説で僕もちょっと勝手がわからなくなる部分などもありましたが、よろしくお願いします＆ありがとうございました！ それでは、ではでは…。

と言うことで、SPCHKの戻り値に対して、ビット演算（AND）をつかって#CHKXY（XY移動）の部分だけ取り出して、それが0（停止）かどうかをチェックしています。このようにANDをつかうと部分的な状態を調べられるのですが、ビット演算に詳しくないと？な部分もあると思いますので、とりあえずは形で覚えてしまうか、ビット演算の勉強をしてみるといいと思います。 で、これが0の時は移動していない（画面外到着）ので、SPCLRでスプライトを消去しています。ここで登場時と同じように？（PRINT）で確認用に値を表示しているので、消去したスプライト管理番号がわかります。 29: @SPFCでのサブルーチンの終了です。 この場合は、CALL SPRITE命令によって一斉に呼び出されているので、9行目で呼び出されるスプライトの数と速度はその時出現しているスプライト数に依存します。

で、直接CALLIDXを変数としてプログラムを書いても良いんですが、ちょっと変数名が長いので、手っ取り早くNという変数に移して、以降Nで処理しています。まあこれは好みです。とくに1回しか出てこないならCALLIDXのままでも良いような気がします。 16〜18: 出現中のスプライトが移動中かを判断して、停止していたらスプライトを消去する処理です。 SPCHK命令はSPANIMで動かしたアニメーションの状況を調べることが出来る命令です。返値としてはアニメーション中のフラグのようなものを返します。 もしSPANIMしているものが1つだったら単純に0（停止）してるかどうかのチェックで十分なのですが、今回は移動とキャラクタ切り替えの2つを同時に実行しています。なので移動が終わってもキャラクタの切り替えは終わらない（無限ループなので）ので、単純な0チェックでは判断できません。

25: ここもSPFUNCを使った場合の一つのポイントになります。 前にCALL SPRITEによって全てのスプライトのSPFUNCされた命令（今回の場合はこのサブルーチン）が呼び出されると書きましたが「全て」と言うことは、SPFUNCが設定されているスプライトが1体ならば1回、5体とか複数あれば複数回、そのスプライトに対してこのサブルーチンが呼び出されます。と言うことで「呼び出されたスプライトを区別」する必要が出てきます。 この区別のために使うのが、CALLIDXというシステム変数です。これはSPFUNC（やBGFUNC）を利用したときに意味を持ち、この変数には呼び出されたスプライトの定義番号が入っています。 と言うことで以降、SPFUNC用のサブルーチンの中では、このCALLIDXの定義番号のスプライトに対しての処理を書くことになります。

キャラクタの切り替えは"I+"指定で行っています。"I+"はキャラクタ定義番号の相対していなので、6フレーム毎に0,1,2,3と切り替わるようにしてループ（0指定）させています。 相対指定なので0の場合は、1036, 1で1037と始めにSPSETで指定した1036番を基準としたアニメーションになります。 21: このサブルーチンの終わりのRETURNです。RETURNがないと戻れないので忘れないようにしましょう。 24: ここがSPFUNCで指定したサブルーチンのラベルです。CALL SPRITEで呼び出されるのはこのサブルーチンになります。

17〜20: 表示したスプライトに対して位置やアニメーションを設定しています。 17行目のRND命令で、出現キャラのY座標とスピード（S）をランダムに決めています。18行目では、その求めた位置にキャラを移動しています。この時にちょっとスピードに合わせてZ軸（奥行き）も設定していますが、単なる遊びです。 その後は、SPANIM命令でキャラクタの切り替えアニメと移動を行っています。 移動は"XY"指定でのSPANIMになります。ここで時間と位置を指定して1回だけ（つまりループしないように）移動アニメーションを実行しています。

16: ここも一つのポイントとなるSPFUNC命令です。 SPFUNCで今回割り当てたスプライト（N）に対して、@SPFCラベルを設定しています。こうすることで先ほど出てきたCALL SPRITEが呼び出された時に、このスプライトに対して@SPFCサブルーチンを呼び出すことが出来るようになります。 今回何故SPFUNCを割り当てたかというとキャラの移動が終わった際に、そのキャラを消去する為です。消去しないと、どんどんとスプライト管理番号を使ってしまい、いずれ枯渇（512を超える）してエラーになってしまいます。 他にも処理を加えれば、出現中のキャラに対して様々なアクションを起こすことも出来ますが、今回はこの消去用の後始末処理のためだけに利用してます。