あ、最初に公開したプログラム、実行するとSLOT1に自分のファイルを読み込んで色を付けて表示、スライドパッドでコード移動、あとSLOT3に関数とラベルの情報など書き出します。

関数・ラベルの抽出だけまとめてやって、シンタックスハイライトは表示時に実行が無難かなぁと。現状だと30行で2フレームほどかかってしまうけどビューア程度ならきっと平気だといいなー。

スロットからコードを読んでシンタックスハイライトと関数・ラベル定義抽出。 【X5DX3EKE】 …なんだけど旧3DSで1行あたり1msくらいかかっていて1万行だと10秒以上、起動時にまとめて処理するのは厳しそうなので方針変更することに。ただそれなりに作るの面倒だったので、もったいないしネタとして公開します:)

スプライトのZ座標、2進数で小数点以下5桁までしか有効じゃないってどこか書いておいて欲しいなあ。スーさんに言われてはじめて気づいたので知識共有。 10進数だと小数点以下2桁目でもう意図しない順番になることがあるから、わりとはまりそうです(例えば0.01と0.02は同じZ座標) なんか順番がおかしいと思ったら、32倍して整数にしてから比べると良さそう。 例: FLOOR(32*Z) BIGでどうなるかは未確認。環境依存しないよう同じように丸めてるといいなー。

スプライトを表示するときに、恐らく16bitの固定小数点数でZを表してるんじゃないかと思います。たぶんハードの仕様。32倍して切り捨て(もしくは16倍して四捨五入かな?)で比較してみると納得できるのではー。 ちなみにスーさんの例だと、前から順に2進数で6桁目、5桁目、4桁目まで一致してます。だから2^5=32倍です:)

デバッグ機能としては、あとはバックトレースあたりを使いやすくしたいんだけど、再帰とか使って深くなっちゃうとスクロールアウトしちゃうのがなんとも……。 BACKTRACE()が欲しいなぁ。

画像(及び同梱のサンプル)の VAR DEBUG=FALSE 、その次で DEBUG=TRUE 'dbg という行を入れたつもりだったのが多分操作ミスで消えてる…;| 勝手にTRUEになるような仕掛けの予定でした。

開発中だけ実行する処理を書きたかったので、手動でマークしておいてコメントをつけはずしするプログラムを書きました。画像は書式参考用のサンプルです。 【TRENV334】 ようはASSERTっぽい事がやりたかったとか。

起動時にPISNIP.TXTが見つからない場合、ファイルを作成するダイアログが出ます。このファイルにサンプルと簡単な解説がありますので、スニペットの登録方法についてはそちらを参照してください。 ■操作 ・十字キー/スライドパッド上下 スニペット選択、高速移動(L/R押しながら) ・十字キー/スライドパッド左右 フィルタカーソル移動、先頭/末尾移動(L/R押しながら) ・A/リターン 決定 ・X/B 終了 ・Y/バックスペース フィルタバックスペース、フィルタクリア(L/R押しながら)

ぺっとん　たんた　すにぺっとん P/Snip v1.00【7ZE34344】 スニペットをクリップボードに設定するツールです。簡単なフィルタ機能がついているので数が増えてもそこそこ快適(だといいなあ)

この流れだと、答えはほとんど全部になっちゃうんだよね…。 もちろん期待している答えと違うのはわかるんだけど。 例えば、3DSのホーム画面のメニューみたいなのを作りたいです、どういう命令を使いますか、だったら「アイコンはBGを使って並べる、カーソルはスプライトで表示、上画面の絵はスプライトの拡大縮小使ってカードが裏返ってるようなアニメにするといいかな。なので、ボタン、タッチ、グラフィック、スプライト、BGの命令を一通り覚えるといいよ」とか答えられる…というかこの時点で既にほとんど全部だね;) プログラムって具体的な形がないとものすごく作りにくいものなので(よくわからない料理のレシピは書けないでしょ？)、質問する時はもっと細かく指定してみると良いと思うよ。上のホーム画面の例でもまだ大雑把すぎるぐらいなので:)

＞れいさん 無名DEFだとどうせGOSUB死ぬだろうから、BASICらしさを維持して追加するならC++で言うところのnamespaceがいいんじゃないかなと。小学生のころサブルーチン内の変数名で散々悩んだし、あったら喜んだと思う:)

行数オーバーしちゃったので続き。 簡単に解説すると、画像をパレットととして考えればGRPには連番を入れるだけで良い。パレット範囲外の値は透明色になるみたいだから、それを使ってフォント展開すればいい。字の大きさが固定ならGRPに入れる連番は、先に用意しておいてコピーしておけば更に処理は減る。これでARYOP使わなくても倍速にはなると思うよ。

もう終わってるのかな…でも思いついたので書きます:) フォント展開部分とか色々省略して書くけど、 '元のやりかた FOR M=0 TO H-1:FOR N=0 TO W-1 GRP[M,N]=CC[M,N] NEXT:NEXT GLOAD X,Y,W,H,GRP,0,FALSE '上の処理を高速化 VAR I=0,SZ=W*H,GRP[SZ] REPEAT GRP[I]=I:I=I+1 UNTIL SZ<=I GLOAD X,Y,W,H,GRP,CC,FALSE

ひゃっはー作りかけの自己満足フレームワークが火を吹くぜー、と恐らくスーさんが苦手そうなスタイルで超単純なペイントプログラム作ってみました:p トリッキーなので仕組み把握出来てないと(できてても？)大変読みにくいのではないかと！ 【 NDYD43YD 】 376〜579行目あたりがお絵かき本体で、あとはそれを上手く動かすための仕掛けです。ツールを追加する場合はペンツール(507〜549)みたいな感じで作って、メニューにボタン追加してやれば完了、のはず。色々雑なので実際やろうとするとボロがでるでしょう。趣味丸出しですがオブジェクト指向だのイベントドリブンだの意識するとこんな感じかなーって雰囲気掴めるくらいのサンプルになっていると思いたい。 さて自己満足な書き方は置いておいて、正直プログラムの書き方なんかよりBIGとかPC使って広い画面で作業するのが一番書きやすいしメンテしやすいと思います！

そうか、最初から専用チャンネルにしなくても、単純に「テンポチェンジは一番近い音の切れ目で実行される」って仕様なら問題なさそうですね。 （基本的には音の後がいいのかな？） スーさんのイメージは素直にMMLを編集するツールになっていてとても素敵です:) 自分の妄想は普通のMIDIシーケンサを再現する方向で考えていたからちょっと無理がでてくるんだなぁと。 ご存知かもしれませんが、ポルタメントとスラー(タイ)は2つが絡むと大変素敵な挙動になるのでお気をつけを。その仕様だと気をつけないと落とし穴にハマるかもしれません。 例えば C4_G&G4 と C4_G&C4 だと最後の音の長さ変わります。 C4&C4_G はきっと思ってるのと違うフレーズになります(C4_C4_Gがイメージ通りのはず) 最近MMLの仕様を詳しく調べてたんですが、大体把握したもののまだ罠がありそうで怖い。

とても素敵デザインで使いやすそうなのですが公開キーはまだでしょうか:) 僕も丁度欲しいなぁと思っていたのでとても妄想が膨らみます。 テンポについてですが、発音中にテンポ変更がある場合は音を分割してやる必要があって面倒なので、1音減りますがテンポ専用のチャンネルを用意するのもありかもしれません。 (ポルタメントとか入ってくると結構手間です…というか互換性捨ててでも仕様変えて欲しいレベル;p) ついでにそのチャンネルで内部変数使ってカウントしておけば、再生位置が手軽に取得できるようになりますし。

僕もARM全然知らないんですけども、ベクトル化されたらそんなものかなーぐらいの気持ちで前のコメントしました。 32bit境界が期待できない文字列の場合で処理が違ってるようなので、まあ最適化による仕様だろうなと。 速度のインパクトですけど、どれくらい差があるかはわかりませんが、プチコンから使うことを考えるとまず無いでしょうね。 参考程度にnewlibっていう組み込み向けのライブラリのソース眺めてみましたが、memmoveとmemcpyの差は重複チェックして場合によっては逆からコピーに変えてるだけでした。 同じことをプチコン側もやってくれれば、恐らくみんな幸せな気がします。 前のコメントの「パフォーマンスに影響でますし」は迂闊でした、撤回させていただきます:)

あ、256bytesじゃない。256bits=32bytesの間違いです。お恥ずかしい。

ちなみに最初の例だと[0,0,1,2,3,4,5,6,7,7]ではなく [0,0,1,2,3,3,5,6,7,7]になってたかと。 [0123]456789 => 0[0123]56789 0012[3567]89 => 00123[3567]9 00123356[7]9 => 001233567[7] って感じで。