解決したようで何よりですが、後から見て自分のコードがいまいちに感じた(変数Dの扱いが気持ち悪い)ので一言補足というか別案を。 こんな感じに与えられた角度を-180～+180の範囲に変換する関数を用意して、 DEF NORMANG(A) WHILE A<-180:A=A+360:WEND WHILE A> 180:A=A-360:WEND RETURN A END -180～+180の範囲を超える可能性がある角度の値(ROTの値やSTCとROTの差など)はこの関数を通して、その結果を判定するようにした方が綺麗だし汎用性がある(例えば差の大きさで回転速度が変動するようにしたり)かなとも思います。

こんな感じでどうでしょうか?

もう数文字は縮められる余地があるとは思っていましたが、ファイル名チェックが入りましたか…脱帽です。 あと、最終的なコードと自分のコードを見比べて気付きましたが、私のはループの継続条件を間違ってましたね。お恥ずかしい。

構わないですよ。どうぞ使ってやって下さい。

すみません、画像の3行目のV=0は N=0のミスです。

ギリギリ128文字に入りましたが、こんなのどうでしょうか? - バージョン番号を16進法2桁で、FFまで達するとそれ以降はFFを上書き - ファイル名の文字数なんかはチェックしていない - 手動でバックアップを削除して連番に空きができると、次の保存時にそこを埋める形になってしまう みたいな仕様になってしまいましたが、一応KEYに入れて動作はするようです。

グラフィック関連の命令で色を指定する際はRGB各256段階で指定するようになっていますが、実際にプチコン上で表示出来る色がRGB各32段階でしかないことが原因で起こります。 描画された時点で端数(8で割った余り)の情報が消えてしまうため、GSPOITで再度取得した際のRGBの各値は (元の値 AND 248)の結果となってしまうので、比較なんかを行う際には注意が必要です。

理論的には大体95%の確率で±20000の範囲内に、約68%の確率で±10000の範囲に収まる感じになるかなと思います。 単純に「丁度0になる確率」だと、おおよそ0.008%くらいになりますかね…ちょっとこっちは自信ないです。

上のお二方が言われている点に加えて、現状出ているエラーは41行目にGOTOが無く@LOOPだけになっているために、9行目の@LOOPとでラベルの二重定義(Duplicate label)になっていることが原因かと思われます。41行目は`GOTO @LOOP`とすべきかと。 エラーメッセージの後の数字はエラーが発生したスロット:行番号になりますので、原因を見つける際の参考になりますよ。

きちんと理解しているという自信はありませんが GLOADでパレット配列を使用する際の引数は、 - 画像データ配列: 各ドットごとの色をパレットのインデックス値(パレット配列の何番目の色を参照するか)で指定 - パレット配列: 使用する色を32ビットARGB色コード(RGB関数の結果と同じ形式)で指定 という感じになります。 ※現状、パレット配列に実数型の配列を使用すると画像が正しく書き込まれない不具合があるので注意が必要です。 既知の不具合として公式に挙げられているので、来週の更新で改善されるとは思いますが。

引数を配列にしてその長さによって場合分けさせる、というのはどうでしょうか？ DEF HOGE(A) IF LEN(A)==0 THEN RETURN FUGA(0,1) IF LEN(A)==1 THEN RETURN FUGA(A[0],1) IF LEN(A)==2 THEN RETURN FUGA(A[0],A[1]) END いちいち配列を宣言して値を設定する手間とか、異なる型の引数を取れないとか問題は多々ありますが。

関数の呼び出し前(USEの代わり)に`EXEC スロット番号`を実行しておくと、そのスロットのグローバルにある変数の宣言等が実行されることになるので、関数からグローバル変数にアクセスできるようになりますよ。 EXECのヘルプには「元のプログラムには戻れない」とありますが、EXEC実行後はちゃんと呼び出し元の続きから処理が行われます。この記述は一体どういう意味なんだろう…

1行目の`S=0`、それと2行目の`FOR T=0`の部分、0(数字)でなくO(アルファベット)になっていませんか?

付属ツールのグラフィックエディタは、矩形塗りつぶし(FILL)で透明を選択しても黒で塗りつぶされてしまいますよね。私もやらかしてしまいました。

Web版ではその箇所(30:BASIC基本仕様)が省かれてますが、一応電子説明書にも書いてありますよ。 また命令一覧ポスターに「ショートカット付き」とありますので(一応実際に確かめてもみました)、さいとうさんのおっしゃる通りパフォーマンス的にいくらかお得になります。

ああ、確かに言われてみれば、立体視といえど3DSの画面を見せていることに変わりはないんですから、ピクセル単位に丸められちゃうのは当然ですよね。 そんなわけでざっと調べたところ、Zに整数値を与える限りでは -256～-237 -236～-209 -208～-174 -173～-131 -130～-75 -74～-1 (0) 1～105 106～265 266～537 538～1024 の10段階が、「はっきりと視差に現れる」範囲になるようです。 (0は左目画像が-1と、右目画像が1と同じになる両者の中間)

公開キー:V3E8VJ4F Z座標を1ずつずらしながらスプライトを並べただけのものなんですが、皆さんの環境でもZ=0前後で変な段差があるように見えるものなんでしょうか？ ついでといっては何ですが、HSV値をRGB色コード(プチコンの色指定で利用可能なもの)に変換する関数をつけてあります。良かったらどうぞ。

12行目のCLSで画面に表示した文字を消してしまっています。 12行目を削除するか、GOTOより後(ループの外)に持っていくかすれば表示されるようになるかと思います。

あまりこったことはしたことが（というか考えたこと自体が）ないですが、正規分布っぽい分布の乱数を得るために何個か乱数をとってその合計値なり平均値なりを使う、とかですかね。

常に画面のどこかに表示しておく、とはいきませんがPRGNAME$関数で指定スロットにあるプログラムのファイル名を取得できますよ。