BG追加…スクロールさせなくて良いのであれば、使ってない文字を潰してテキストで書き割り表示とかですかね。山とか空のグラデとか。 あとは水をスプライトでなんとかしてしまうしかなさそうです。水面と単色塗りつぶしとかでうまくやれば枚数は減らせそうですが…データや処理的にはちょっと手間そう。 あ、もし多重スクロールではないのでしたら、手前レイヤーを水レイヤーと兼用にしてしまうってどうでしょう？高さを倍にして上半分だけ水をかいて、BGANIMで上下を交互に表示、スクロールはBGHOMEでとか。

ちょっと乗り遅れちゃいましたが、室内とかの場合は影をつけるとかどうでしょうか？ ためしにマップチップを見て影のON/OFFを試してみたんですが、境界での嘘は動いていれば案外気にならなさそうな感じです。 【 RQ3E443 】 マップチップにフラグ増えたり、スプライト消費したりというデメリットはありますが、表現力は増すかなぁと。

メモリ節約ネタ。 どうも文字列リテラルを変数に入れないように使えばメモリを消費しないっぽい(?)ので、試しにあんまりメモリを使わずにフォントを描画するルーチン作ってみました。 【4KRE3NNV】 描画用バッファ・パレット・高速化のためのテーブル、で合計4k程度使います。実験用なので機能は最低限というか、とりあえず動くよレベルです。 フォントデータはM+ FONTSの mplus-1p-medium.ttf から生成してます。6階調8403文字。固定幅も作りたいなーと思ってるけど、12x12に収めようとするとはみ出す文字があって調整めどいのでまた必要になったなら;)

そのStack overflowは無限に自分自身を呼びだそうとして失敗してます。再帰ってやつですね。 DEF FUNC:FUNC:END と同じ状況になってます。8行目の書き方でOKなのは、8行目のSUM()を呼び出す前にSHIFTによって配列の要素が取り覗かれるので、最終的にからっぽになり5行目で終了するため、無限にSUMが呼び出されないからです。3行目と4行目の間に ?"SUM()";LEN(D) とか実行してみるとわかりやすいかと。 ちなみに8行目のやりかたの場合でも、A%の要素数を3000個くらいにするとStackoverflowになるはずです。 というわけで最初のコードも、今回のコードも引数に配列を渡したことが原因ではないので、安心して渡しちゃってください:) ところで、これSUM()実行後、A%が空っぽになるけど大丈夫ですかね？いわゆる参照渡しなので…。

返り値セットしとけばRETURNだけでもエラーにならないので、最初のコードならこんな感じで書くのがナウいのでは！なお今後のバージョンで動かなくなる可能性があります:p VAR A[10]:FILL A,2 ?SUM(A) DEF SUM D OUT S S=0 GOSUB @SUB RETURN @SUB VAR I,L=LEN(D)-1 FOR I=0 TO L:S=S+D[I]:NEXT RETURN END

あれ、これ今のバージョンだとDEF内でGOSUB使えるようになってますね…まじか。バグじゃなかった…？いやでもマニュアルとは挙動が異なるけど。 GOSUBからのRETURNの場合でも返り値の有無はチェックされるので最初のコードはエラーになったっぽい。そしてGOSUBの時に返り値設定されるので、もし関数から抜ける時RETURNなくてもUninitialized〜は起きないと。 というわけでいつの間にかGOSUB使えるようになってたが正解だった。

あーバグですね、これｗ (ラベルを除いた)次の行のRETURNが有効になるっぽい。後のRETURNを消すと正常な動作。スタックおかしくなってるのかなぁ？色々まずいことできそうな予感。

DEF内のGOSUBはエラーにはなりませんが、DEFのRETURNが優先されるため事実上使い物にならなくなってます。RETURNできない=GOTOと一緒なので。正常に使えるのは GOSUB "1:@LABEL" という呼び方でDEF外のラベルにジャンプするケースのみです。こんな中途半端な機能残さずエラーにした方がよかったと思うんですよね。エラー出ないと何を間違えたか把握しづらいし。 というわけで、DEF内のGOSUBをGOTOにすれば、なぜRETURN Lでエラーでなかったか理解できると思います。できればRETURN Sの方が良いと思いますが:p

そもそもDEF内のGOSUB禁止ですよ。 このプログラムだとGOSUB自体でエラーは出なくて、10行目のRETURNでGOSUBでは無くDEFを抜けることになります。でも返り値が設定されていないので、Uninitialized variabled usedのエラーになります。 DEF FUNC() RETURN END と同じ状況になっています。

作曲講座の邪魔してすみませんっ！でも楽器のお勉強ってことでご容赦を:) ハープシコード＝チェンバロは弦をはじく楽器、対してクラビコードは弦を突く感じなので結構違う楽器です。クラビネットは雑に言えばエレキクラビコードです。ってわけでエレキギターとアコースティックギターぐらい違う楽器です。まぁ低容量なプチコンの波形で細かいこと言うのも何ですが。 エレキギターのようにクラビネットも色々エフェクトかけて使ったりします。なので曲によって全然違う音だったりしますね。癖が強かったのはワウがかかってたんじゃないかなぁ。

横からですが… ＞MNC2さん @0〜127と@128,129のドラムキットの音の並びは General MIDI という規格に合わせられています。ってことで、@7 はクラビネットであってるんですよー。 細かい話なんですが、違う楽器なので一応:)

デバッグお疲れ様です。とても丁寧な作りで完成が楽しみです:) キーリピート(BUTTON(1)のやつ)なんですが、他のプログラムの設定引きずることがあったと記憶してます。BREPEATで初期化しておくと良いかと。

CaseSensitiveだから小文字で書かなきゃねとか、'\n'と"\n"は型が違うよとか、最近のCだとgetsは廃止されててコンパイラによっては警告でるよとか、そういうツッコミ待ちでしょうか？:p

あ、下画面タッチすると色相変わります:)

カラーピッカーのあれをなるべく高速に描画してみる。ツイッターでネタになってたのと個人的に欲しくなったので。 【DKL4VE8E】 パレットごりごり計算してGLOADと、スプライトを2枚使って合成する方法の2種です。プログラムによってはスプライト必ずしも使えるわけじゃないので…。 GLOADの方は旧3DSのサイズ96x96でぎりぎり60FPSに届かないかなぐらい。おしい。スプライトは32x32を引き伸ばして表示してるのと、合成時の誤差(?)でちょっと綺麗じゃないです。でも軽い。下画面の左上に見えてるのがスプライト用の画像です。

挙動から考えると、Z座標によってずれる幅が整数じゃないって感じですかね。X座標に加算してからドット単位にまるめられるから、X座標によっては1dotずれると。たとえばズレ幅が1.5なら、X=1.4の時は1ドット、X=1.6の時は2ドットずれるという風に:)

コメントの量が変わってもFREEMEMは変わらないと思いますよ。一応確認のためコメント10000行のコード作ってみても変化は見られませんでしたし。プログラムバッファはスロット毎に2MBなので、一行50文字みっちり書いて2万行超えそうな人はコメント控えた方がいいかも:)

一応範囲外の音は O0C---- とかで対応できますが、できないならできないで実用上はそんなに困らないかと思います:) 表示については毎回MMLパースになるならちょっと大変そうですね…。既存MMLをカーソル位置分割までできてるのでしたら、一回実用的な長さのMMLで描画範囲抜き出すのを測定してみるのが良さそうです。数フレーム以内で出来るならなんとかなるでしょうし、ダメだったらデータの持ち方変更かも。MML以外で持つとメモリ問題も出てきそうで怖いですが。

僕のやつは全パターン網羅して一番条件にあってそうなヤツっていう頭の悪い方法なので、別途素敵アルゴリズムが見つかったならよかったです！ 別用途の流用だったのですが、ちょっと不適切でしたね、すみませんX) ただ、ふと思ったのですが、もしかして [R96]n とかでよかったのでは…とか。いや読み難くなるから微妙かな？

もう解決してる予感もするんですが… 【BRCX33AE】 「個数が少ない」「なるべく2^N分音符」「なるべく長い音符」という条件で、1小節未満の全ての長さについてMMLを生成しスロット1に出力するプログラムです。ただ小さいものを結合するだけでは最初と同じ問題にぶつかる気がしたので作ってみました。 結構重い処理になるので先に計算しておいてそれを使うことになるでしょうし、気にいらない部分は手で修正してDATA文とかでもっておけば良いかなと思います。 もしちゃんと拍ごとに区切るような方向を目指してたらごめんなさい！その場合は樹形図を作るような感じで割っていく形になるのかな…拍子によって割り方が変わるのでちょっとめんどくさそうです。