たしか、&HFFFFFFFEだと-2なんだよね 符号bitが立つときは、&Hや&Bでの「見かけの数」が小さくなると、絶対値が小さくなる。

2の補数だと「bitが立つほど絶対値が小さくなる」という認識でいいだろうか？ &HFFFFFFFFで 16進数は1桁で4bit 4*8=32bitで全部のbitが埋まる。 そうなると「一番絶対値が小さいマイナスの数」として-1になる、というのがいい表現かは分からないけど。

バグではないぞ。 32bit「符号付き」整数 これがミソか。 一番上のbitは「符号bit」 符号bitが立つ→マイナスの数になる じゃあなぜマイナス「1」かといえば、2の補数ってやつらしいけど説明できない、ヘルプミ―。

正確に保てるのは左側の16桁ぐらいだけなんだっけね

浮動小数点数は大きすぎると、右側の数桁が正しくなくなるので、infにならなくても注意が必要だったりする（余談）

無限大 ざっくりいうと大きすぎる数

コメント行か

ヒント：白い命令はダメかも

LPF300#とかまで普通の変数にするのは億劫なのでFOR-NEXTで一要素ずつコピーするように。VAR関数の活躍

ネックの計算式は LPF#[0]をLPF_0#みたいなノリで置き換えたんだけど、 さあ動くか…テストはまだ。 あ、LPF300#とかから渡されてるのもちゃんと処理したよ。

ちなみに==0を!に置き換えると速くなる。 等号だと左辺・右辺の2値を評価（だっけ）するからだろう。

LPF#がたくさんある計算式ね

ゲージ類の描画は IF (変数 MOD 値)==0 THEN 的なIF文の中にあるので、効果はあんまりない。 やはり、計算式の中に配列がいっぱいあるので多分ここがネック。

プログラムが実行できるソフト

置換機能で楽々変数名変更

OPTION STRICTじゃなかったので暗黙の宣言に甘えますね

（どこぞの謎日本語版とは関係はありませんww）

配列は激重なので、配列を普通の変数にすると効きそうなんですが 変数宣言が長くなるので悩ましい

【PetitModem無印対応化計画】 計画というほどじゃないけどね。 データ輸送に欠かせないれいさんのPetitModem。 「※無印3DSは未確認」と書いてあるように無印だと若干不都合が。 無印で単方向受信を使うと、音量ゲージの追従が遅れて、そのうち音声を落とすのか歯抜けが起きます。 処理を軽くすれば落とさないんじゃないかと思って考えてます。

シンプレックスは圧倒的横文字だな