(自分で応答しなきゃいけないけど)動作中に弄れるのは結構楽しい感じですね。 あと単純にPRINTデバッグでログが遡れるのは便利です。 もうちょっとだけ公式でデバッグ周りのサポートくれたらツール作りも捗るんだけどなぁ、とか。デバッガ付けてとまでは言わないので:)

配列は初期化されるまでは uninitialized variable(関数の引数や戻り値に使う変数と同じ)扱い。知ってるとたまーに便利。 GOTO @S:VAR A[0],B[0],C[0]:@S A=1:B=3.14:C="HELLO" 代入時に型が決まるからOPTION DEFINTかどうか気にしなくていいし、READ文で使えば文字列でも数値でも代入できる。例えば前者は定数に、後者はMML用のDATA文(-1が終端)の読み取りになんかに使える。

■制限とか注意事項 MPSENDは一度に256bytesまでしか送れず、毎フレーム送るとバッファオーバーフローをおこします。そのため送信データは一旦内部バッファにためて2フレーム毎に送信するようになっています。さらに送られてきたデータはMPRECVで受け取らないとそのうちバッファが溢れます。よって以下の制限があります。 - 毎フレーム DBG_UPDATE を呼ぶ - 1フレームに付き64文字(128bytes)以上送り"続けない"(バッファが足りなくなるので) あと送信データをバッファにためている都合、プログラム停止時にDBG_FLASHを呼び出してバッファに溜まったメッセージを吐き出す必要があるかもしれません。ファンクションキーに設定しておくと便利かも。

■SAMPLE.PRG デバッグメッセージ送信と簡単なコマンドを受け付けるサンプルです。「ON」か「OFF」を送ってやると、デバッグ出力を制御できます。ちなみに送られたコマンドは整数か文字列を判別して分割しているので、命令の追加はしやすいと思います。 このプログラムの送ってるデバッグメッセージの量で結構ギリギリです。毎フレーム送らないとか、utf8とかに変換して圧縮するとか必要かもしれません。 もっとデバッガっぽいことをやろうかと思いましたが、面倒だし使わない予感がしたので省略しました(DBG_BP()とか呼ぶようにして、ブレークポイントとか) 特定のボタン押したらデバッグ情報送るーとかで十分な予感。

2台目の3DSを使ってPRINTデバッグをちょっと快適にする提案です。2DSLLもでましたし:) 【KDVN33NJ】 プログラムの書き方や文字数に制限がありますが、もしかしたらプチコンBIGより3号の方がデバッグ快適になる場合もあるかも……画面ちっさいしキーボードつながらないけど。BIGはデバッグ用にTVつかったりできるようになればいいのに。 以下説明。

■_DBGCON.PRG デバッグ用コンソール。デバッグ用メッセージ表示したりコマンド送ったりできます。 [スライドパッド] 上下でメッセージスクロール。L/R押しながらだと高速スクロール、LR両方押しながらでログの先頭/最後に移動(ログの先頭に居る時は常に最新の状態に更新されます) [↑↓] 入力窓の履歴をいったりきたり [←→] 入力窓のカーソル移動、L/R押しながらだと先頭/最後までジャンプ [A] コマンド送信 [B] メニュー [X] 終了 [Y] バックスペース。L/R押しながらで消去 通信については手動で開始/終了する必要があります。起動したらBボタンでメニューに入り、Connectを選んで通信を開始してください。親/子はどちらでも構いません。 メニューは改造しやすいように作ってます。プログラムにあわせて必要な機能を追加していくイメージです。

あ、一応プログラム試さなくても良いように。 3DSのフレームレートは、59.834Hz らしいです。ただしプチコン3号でBGMと同期するには 59.8312 くらいが上手くいくようです(59.834だと6分くらいでズレがでました) BIGの場合は 59.94Hz ですが、もしかすると 59.93995 の方が良いかもしれません(未確認です)

BGMVARで再生位置が求まるなら、わざわざ経過フレーム数から計算して求める必要なさそうに見えるかもしれませんが、当たり判定やマーカーの表示位置をテンポに依存せずに設定したりしたい時には使います。ゲーム次第ですね:) なお実際のゲームで使う場合、ホームに戻ったり画面閉じたりすると盛大にズレるので、両方のやりかたで取得するのが正解かも。盛大にずれたらBGMVARの値を使って補正したり。音ゲーでポーズはご法度だとは思うけど:)

このプログラムでは再生位置をMMLで一番短い音符の192分音符(これを1tickとします)の数で求めますが、仕様上どうやっても1tickはズレがでます。そのため2tick以上ズレた場合をエラーとして検出しています(FIRST_ERRが最初にエラーが発生した時間、RECENT_ERRは最近発生した時間) そもそも1tickは大体のテンポで1フレームの長さより短いですし(テンポ120で約10.4msec、1フレームは約16.7msec)、仕様上フレーム単位でしかボタン判定できないし1tickの程度の誤差は気にしない！:p 一応新/旧3DS・BPM240 で1時間くらい2tick以上のズレは発生してません。もっと長くても多分大丈夫。

再生位置を「A:BGMVARを使って取得する方法」と「B:経過フレーム数から計算する方法」の2種で求めて、その差分を表示するプログラムです。音ゲーとかで使えます。 【4KF5K3H3】 そういえばリフレッシュレート調べたけど実際ちゃんと合うのか試してなかったので作りました。

VAR()を使わない正攻法だとCOMMON DEFを使う、かな？ 確か公式のトランプライブラリは↓みたいにやってた記憶。 VAR X COMMON DEF GET() RETURN X END COMMON DEF SET(N) X=N END

あとプチコン音ゲーで気をつけるのは、 - BGM系の命令は次のフレーム開始時に実行される - でもWAITしてすぐは、まだ曲が始まってなくて内部変数取れない場合がある - BGM系の命令は1フレームで256回まで。超えると失敗してうまく動かない(エラーにもならない) あたりかな。

あら懐かしい話題が:) 結論的には内部変数を使うで良いと思いますー。テンポチェンジとか楽だし。 3DSのリフレッシュレートはどっかのサイトだかフォーラムで見かけたけど、59.834Hzらしいです。で、MML内部変数とMAINCNTにらめっこしてリフレッシュレート調べたところ大体59.8312Hzくらい。同じプログラムをBIGでも試したところ59.9399Hzくらい。BIGは多分59.94Hzだろうから大体正しそう。これはMML内部変数使ってだした数値だからそれなりに合うんじゃないかなぁ。一応3DSは旧と新で大体同じ値だったのは確認済み。両機種対応する場合はご注意を。

ピッチをずらすのは@Dコマンドだよ。 @D32で半音の半分高くなる。 @D64 C は C+ と同じ高さ。

スパゲティというかインデントが嫌がらせのレベルなのでは…というのは置いといて:) この内容だとFORをREPEAT-UNTILに変えるだけでも結構速くなりそう。あと関数呼び出しも展開したいところ。4重ループ内での関数呼び出しはちょっと高くついちゃうからなぁ。

切り捨て処理の事忘れてた！ テスト漏れです、お恥ずかしい……＞＜

bluetoothな筆圧対応のスタイラス使ってPCで変調とかなら割とお手軽にならないかな。bluetooth機器のデータって簡単に取れるもんなのか全然知らないんだけども:)

'24ビット左にシフトしたとき、128以上の整数は符号付き32bit整数の範囲を越えoverflowとなる。128〜255の時だけ-256して-128〜-1に変換する。 'B%=A% DIV 128 '128〜255の時だけ1に、0〜127の時0 ARYOP #AOPMUL,B%,A%,1/128 'A%=B%*(-256)+A% 'A%が128以上の時だけB%には1が入っているので、-256倍して加算することで128以上の時だけ-256 ARYOP #AOPMAD,A%,B%,-256,A% '左シフト 'A%=A%*(1<<24) ARYOP #AOPMUL,A%,A%,1<<24

失礼しました…。コピペします:) 24ビット右にシフトした時0〜255が返ってきて欲しいんだけど、符号付き整数だから-128〜127になってしまう。128〜255が-128〜-1になってるので、負の時だけ+256して0〜255に変換する。これをARYOPだけで実現する。 '右シフト 'A%=A%>>24 ARYOP #AOPMUL,A%,A%,1/(1<<24) 'A%が負の時だけ-1、それ以外は0 'IF A%<-1 THEN B%=-1 ELSEIF A>0 THEN B%=0 ARYOP #AOPCLP,B%,A%,-1,0 'A%が負の時だけB%には-1が入っている。-256倍して加算することで負の時だけ+256。 'A%=B%*-256+A% ARYOP #AOPMAD,A%,B%,-256,A%

朝のミスってるとこあったので、3DSで実行して確認したやつ貼っておきます:) ついでにコメント入れて先頭8bitのコードを取り出す/戻す処理に変えときました。あとAOPMULが早いそうなのでAOPDIVやめたり。 すえさんのコードも見ましたがやってることはほぼ同じですね。符号なしから符号ありに変換するのはこっちが速いと思うけど実測してません。 …上位ビットの削除って、符号ありだとシフトの時1で埋まって困るって話で良かったのかな…。