上書き保存をしたとき、上書きされた側のプログラムファイルは"@BACKUP.PRG"という名前でプロジェクトフォルダ内に残るようになっているので、 同じプロジェクトで別の上書き保存を行う前であれば@BACKUP.PRGから元に戻せるかもしれませんよ。

そんな、わざわざ謝らなくても… というより2つ上のコメントで触れられていますし、スルーされているとは感じていないので気にしなくてもいいですよ。

結果の値は「実際の割り当て番号 + 上画面スプライト割り当て数(※)」になっているようですので (※:XSCREEN命令で指定した値 指定していなければ画面モード2,3でのデフォルトは256) 画像のコードだと222行目の後に SLZERO = SLZERO - 上画面スプライト割り当て数 とすると一応正常に動作するかと思います。 ただし、後にバージョンアップでこの不具合が修正されると逆にエラーになってしまいますのでその点注意をというか、現状は(公式で推奨されているように)DISPLAY 1ではスプライトの自動割り当てを使わないようにするのが無難かなという気はします。

エラーはOut of rangeですよね? DISPLAY 1の状態でスプライトの自動割り当てを行うタイプのSPSETを使用した際、結果として得られる値と実際に割り当てられた番号が一致しない不具合 (公式サイトの障害情報で「DISPLAY 1時に関数型のSPSETが正しく動作しない」となっているものです) が原因かと思われます。

「文字列型と数値型との比較演算」が3を返すようになっていたとは。 過去に型を判定する方法について頭を悩ませたことがありますが、これだと一発ですね。 正直、演算子の挙動を変える(3.0ではType mismatchだったはず)こと自体はともかく、そのことについて公式にアナウンスが無いのは何だかなという気もしますが… 特に3は真偽値的にはtrueになっちゃいますし。

Windows7電卓のプログラマモードなら、通常の数値表示窓の下にある2進表示部分の0/1をクリックすることで、そのビットのON/OFFを切り替えられます。 BUTTON関数の結果のようなビット単位のフラグを扱う際に、「こことここのフラグを立てた数値はいくつになるか」みたいなことをポチポチっと確認できるのでいい感じです。 キーボードだとカーソル左右とスペースキーでも同じ操作ができます(現在どのビットを選択しているのか分かりにくいですけど)。

そうか、InfやNaNのことまで考えてませんでした。 というかそれらを利用すれば普通に演算で空文字列と0を分けられるとは。勉強になります。 (Inf*0って0じゃなくNaNだったのか) >けいさん 実は当初「0や空文字がネックですが」とその辺りだけをコメントするつもりでしたが、投稿直前にふとBGMPLAYに気付いたもので… さすがにちょっとどうなんだとは自分でも思いましたが

文字列か数値かの判定、こんな方法を思いつきました。 '引数が文字列ならtrue, 数値ならfalseを返す関数 DEF CHKSTR(X) IF X==X*0 THEN '0と空文字列の判定 BGMPLAY X WAIT 2 RETURN !BGMCHK(0) ENDIF RETURN X==X*1.5 END 0か空文字列が入力されたときに2フレーム待ち&BGMに影響を与えるので、実用的かと言われれば疑問ですが。

わざわざありがとうございます。 同じRETURNという命令が、サブルーチンからの復帰にもユーザ関数の終了にも用いられるせいで、ちょっと変なことになっちゃうんですね。

ちなみに文字列は単純に添字でアクセスできるだけでなく、PUSH,POP,SHIFT,UNSHIFT,COPYのような配列用の命令を使うこともできたりしますね。 (文字列[添字]への代入もそうですが)参照先を直接変更しちゃうので文字列操作的にはあまりよろしくないですが。

FORMAT$で桁数の前に空白を入れた際の動作は、(負の数だったときにマイナス記号が入る分、)正の数を表示するとき先頭に空白を一つ入れて表示するというもののようです。 結果としてその分、数字の入るスペースが1文字分減ってしまうので、一見FORMAT$内で指定した値と同じ桁数の数値でも収まりきらずに表示がずれるようになってしまいます。 (その例だと% 3Dでは数字の入る幅が2文字分になってしまうため、3桁の数値を入れると表示がずれる)

スロットが違うと同名でも別の変数扱いになって直接参照することはできないですが、 こんな風に呼び出す側に自分の変数を渡す関数を作って '**スロット0** VAR A,B,C COMMON DEF GETTER OUT X,Y,Z X=A:Y=B:Z=C END A=100:B=200:C=300 EXEC 1 ------------------ 呼び出された側でそれを受け取る、とやるのはどうでしょう？ '**スロット1** VAR A,B,C GETTER OUT A,B,C PRINT A,B,C

追記を最小限に、条件式が一つの比較演算で済むように。 逆にごちゃごちゃになった感がしないでもないですが WHILE TRUE BC=B:B=BUTTON(0) IF ((NOT(BC AND &H30) AND B) AND &H3F)==&H30 THEN BEEP VSYNC 3 WEND

引数BCに与える直前のボタン情報は、 一応`(BUTTON(0) AND NOT BUTTON(2)) OR BUTTON(3)`とかやれば現在のBUTTON関数から求めることはできますが、 そんなことするより自前で記録するようにした方が早いですしプログラムが60fpsでない際の判定も安定させられます また、関数として公開している関係上ボタン入力情報B0,BCを引数として与えていますが、 実際使うときはグローバル変数を直接参照するようにすれば呼び出しの記述をもっとシンプルにできるかと思います。その辺りはお好みで修正を。 (B0,BCは20行目以降のRETURNでしか使っていません)

引数 BSTR$:判定したいボタンを文字列で指定 - "↑↓←→ABXYLRlr"を認識します(ZL,ZRは小文字のl,r) - 複数の文字を含んでいればそれらの同時押しを判定 - 末尾に">"があると押された瞬間、"<"があると離された瞬間、それ以外は現在押されているかを判定 B0:現在のボタン入力情報 - 現在のボタン情報(BUTTON(0)で取れる値) BC:直前のボタン情報 - 一つ前のフレームにおけるボタン入力情報 - 押された瞬間や離された瞬間の判定に用いるので、それらが必要無ければ0を入れておけばいいです

使い方: 画像のような感じで。 戻り値は指定条件を満たしていればゼロ以外の値、そうでなければ0を返すので、そのままIFに入れて使えます。

ボタン入力判定用の関数を作ってみました。 判定したいボタンを文字列で指定できる(パッと見分かりやすくなる)というだけのものですが、「複数ボタンを同時に押した瞬間」みたいな判定がちょっといい感じにできるようにもしています。

`(B AND 48)!=0`(AまたはBのどちらかが押された)と `(B AND 48)==48`(AとBの両方が押された)では 結果が変わってしまいますから、複数ボタンの判定には注意が必要ですよね。 その辺がややこしいと感じる場合は、けいさんの言われるように各ボタン個々の判定結果を&&,||で連結するようにした方が無難かなと思います。 ビット演算子(AND, OR)と論理演算子(&&, ||)の使い分けについては 「条件式中には比較演算をおく(ゼロとの比較を省略しない)」ことを徹底した上で - ビット演算子:数値どうしの計算を行うもの - 論理演算子:比較演算による結果どうしを組み合わせるもの という認識でいると間違えにくいかなと思っています。

どうやらラベル文字列を使ったラベル参照(RESTOREを除く)では スロット番号を省略: グローバルからの場合、実行中スロットの(グローバルな)ラベルを検索 ユーザ関数からだとその関数のスコープ内のみを検索 スロット番号を指定: 呼び出し元に関わらず指定スロットのグローバルにあるラベルを検索 という挙動になっているみたいですが、ただ本来はDEFのヘルプに書いてある内容が想定している挙動であって、 (スロット番号指定により)外のラベルにジャンプできるというのはイレギュラーな挙動なんじゃないかなという気はします。実際のところは分からないですけど。

こんな感じのコードで確認してみた限りでは、ユーザ関数から呼び出されたものであってもサブルーチン内からはグローバル変数にアクセスし、またサブルーチン呼び出しでローカル変数が破壊されるということも無さそうです。 ちなみに更新データを削除した前バージョンでも、この方法を使えば関数外のラベルにアクセスできていたみたいですね。 (確認しようと「追加コンテンツ」を削除するつもりが、間違って「追加データ」を削除してしまったのは内緒)