GCLIPが書き込まない領域を指定する？？ GCLIP 0,～ はGページの表示範囲を指定（実際には描かれている） GCLIP 1,～ は書き込みの範囲を指定（この範囲外は描かれない） の２種類だと思います。

X,YがタッチされたらそこにSP7番を表示するなら、 SPSET 7 OUT S SPOFS S,X,Y でどうでしょ。 SPの表示数には上限があるので注意です。

一回のループで３発同時に出てるのが原因ですね。 一発しか出ていないようで、３発重なっているのです。 やり方は色々あると思いますが、一発打ったらその時のMAINCNT値を変数に保存しておいて、そこから何フレームか経過するまでは次を発射できないようにするとか。

＠～～と ’～～ だけを反転できたらプログラムが見やすくなりそうですね。

READでどのデータを読み込むのかを指定するのがRESTOREなので、読み込みたいデータがある場所を「RESTORE @名前」で指定してからREADします。 READ文とDATAで指定している変数の型と並びが同じであれば、少なくともREAD文でエラーになることはありませんよ。 あとはエラーで止まった時に、DIRECTモードで ？S$,C,A として、どのデータを読んだときにエラーが出ているのかを見てみるとか、調べ方は色々あります。

「BGGET」で、SP画像の後ろにあるBG番号を取得します。正確には、SP画像の原点（SPHOME）の位置にあるBG番号を取得します。 で、足元の下にBGがあれば落ちない、なければ落ちる、となると、例えばSP番号2544のキャラのように足元にSPの原点があるキャラなら、SP番号を「SP」、位置を「X,Y」とすると、 BGGET (SP,X,Y+1,1) で取得します。 なので落下は、 IF BGGET (SP,X,Y+1,1)！＝0 THEN Y=Y+1 みたいになります。 ただこれだと足元の一点しか判定していないので、大きいキャラなら２点３点と判定しなきゃだめですね。 BGGET (SP,X-4,Y+1,1)！＝0　|| BGGET (SP,X+3,Y+1,1)！＝0 ～ みたいに。

それでエラーは出なくなると思います。全行に DATA "-------I------",2,3 とかみたいに。 そもそも READ S$,C,A というのは、CとAにマップデータの何かを取得したいのではないのですか？ もしマップデータだけでよいのなら、 READ S$ だけにすればエラーは出ません。

@MAP001は全て文字列ですから、 READ 文字列、数値、数値 ではエラーになりますね。

はやっているゲームを見たらとりあえず作ってみる！ アマチュアゲームプログラマーの鏡ですね。

http://petitcom.net/3gou/manual/sample_sprite2 IF B2 AND 15 || B3 AND 15 THEN って行を打っていないからでは？

23～26行目を毎回通っているからですね。 十字キーが押されたとき(B2 AND 15)と、離されたとき(B3 AND 15)だけ通るようにすればいいかと。

なんか１つ１つループを抜ける感じになってますけど、タイトル画面からどの処理に飛ぶかだけだったら、 @DATASELECT B=BUTTON() IF (B AND #A) THEN @MASTER IF (B AND #B) THEN @DATA1 IF (B AND #Y) THEN @DATA2 IF (B AND #X) THEN @DATA3 IF (B AND #L+#R)==#L+#R THEN @KYORYOKU GOTO @DATASELECT みたいな感じでいいかと思いますか、やりたい事はこれでしょうか？

BGマップを作る時、公式ツールではサイズ変更ができないので、でんぺんさんのPUCHIMAPを使用させて頂いています。 あと日本語の長文を打つときは、公式の漢字一覧から1文字ずつコピペするのはものすごい労力なので、日本語入力支援のツール使ってます。 あとはお絵かきツールが何か使いこなせればいいんですが、私の絵心・知識・技術ではどれも難しくて追いつけず、公式のお絵かきツールでチマチマやってます・・・

ループ内でプログラムを手動で止めれば、最初の質問のようになるのは正常な動作なので、これは解決？ ぶるぶるぶるは（あえて想像で書くと）よくあるのは、 GOTO @SAVEDATAの前にどこかでBEEPしてるとかですね。 あとはBGM～系命令を色々試したりしていると、ずっと音が鳴って止まらない場合もあります。これはACLSやBGMSTOPでは止まらず、「BGMSTOP -1」すれば止まる場合があります。 そもそもこの選択肢っぽい３つをループ内で何度もPRINTする必要はないですし、全体の流れと、何をやっているかを１つ１つ見直したほうがいいかも。

画面外に色々ありそうですね・・・全部見えるようにするか、公開キー出すかしないと想像だと限界がありますねー。

この画面に入っているプログラムだけではありえないですね。 画面外に GOTO @SAVEDATA などがあって、途中でSTARTキーでプログラムを止めればこんな感じになると思いますが。

ここが違うという断定ではありませんが、READでType Mismatchということは予想していたのと違うDATAをREADしている可能性が高いですね。 上からDATAをREADしていればここから読むはず！というロジックは事故が多いかも。 DATAの頭に「@MAPDATA」のようなラベルを付け、READのループに入る前に「RESTORE @MAPDATA」みたいに書けば事故が減るし、違う場所をREADしてしまっているのか、DATA自体に問題があるのかの切り分けができると思います。

よく知らないんですが、グラフィック1ドットのデータって上位１６ビットに何もデータ持ってないんでしたっけ？

すばらしい。 でも疑問に思われている通り、何やら無駄が多い気がします。 ６行目のREADを18,19行目の間に持ってきて、 11,12行目は「setting」とだけ書けばいいのでは？ あと、C$・XY$は数値でいいのでは？ DATA文を DATA 1,500,120,5,10 にして、20～23行目はいらないかも。DATA文の中にマイナスは書けますし。 SPSETの行は「SPSET C OUT SP」、 SPFUNCの行は「SPFUNC SP,FORMAT$("enemy%02D",C)」 でどうでしょうか。

何となく、シューティングゲームの背景の宇宙＋星っぽいものかなと思ったんですが、そんな感じならグラフィックでもいいですがBGを使うのも手ですよ。 グラフィック画面と違ってBGは画面サイズを自由に変更可能なので、簡単なのは、最初にスーパーマリオのように横に長い画面を作ってBGANIMしておけばあとは放置してても勝手にスクロールしてくれます。 本当は２画面分のBGを作ってそれを入れ替えながらスクロールさせるのがよくやるやり方ですけどね。 V3.3から、８ドット単位のＢＧも使えるようになりました。