suzukiplan
commented
10 months ago 冗長データ削減を試みてみたが効果としてはイマイチなので、データ構造の最適化がベターかもしれない。
VGS の BGM データは、
struct _NOTE {
unsigned char type;
unsigned char op1;
unsigned char op2;
unsigned char op3;
unsigned int val;
};という固定長バッファ（8byte）で、以下のような用途で使っている。
- type: ノート種別（1〜10）
- 1: NTYPE_ENV1
- 2: NTYPE_ENV2
- 3: NTYPE_VOL
- 4: NTYPE_MVOL
- 5: NTYPE_KEYON
- 6: NTYPE_KEYOFF
- 7: NTYPE_WAIT
- 8: NTYPE_PDOWN
- 9: NTYPE_JUMP
- 10: NTYPE_LABEL
- op1: チャネル（0〜5）
- op2: KEYON 時の 音色（0〜3）
- op3: KEYON 時の 音程（0〜84）
- val: 以下のパラメタ
- 1: NTYPE_ENV1
- 2: NTYPE_ENV2
- 3: NTYPE_VOL
- 4: NTYPE_MVOL
- 7: NTYPE_WAIT
- 8: NTYPE_PDOWN
- 9: NTYPE_JUMP
かなり最適化余地がある。
まず、type と op1 は合わせて1バイトにできる
| bit7〜4 | bit3〜0 |
|---|---|
| type | op1 |
そして type 毎に可変長にすれば良い。
一番多く出現する type は KEYON と KEYOFF だが、KEYON のサイズは 8 → 3 (0.375)、KEYOFF は 8 → 1 (0.125) に圧縮できるので、全体でおよそ 1/4 程度までデータ圧縮できるのではないかと考えられる。
VGS の BGM データは内部的に miniz で圧縮されている。
圧縮済みのデータはフラッシュに書き込む（ソース等と同じメモリ領域に展開される）ので中国製のラズパイPico互換機ならプログラム込みで16MBまでデータを格納できる。（※公式のラズパイPicoなら2MB）
ただし、再生時は RAM（最大256KB）へ展開する必要がある。
無圧縮状態のデータをチェックしてみたところ、東方紅魔郷、東方妖々夢、東方永夜抄の3作品の中では、東方妖々夢の TH07-16 (少女幻葬 〜 Necro-Fantasy) が 330KB（338,336）で限界突破している。
当然ながらプログラム側で使いたいRAM領域もあるので、曲データに使用する RAM 領域は最大でも 128KB 以下（できれば 64KB 以下）程度に抑えたいところだが、結構な数のデータが 128KB 上限でも収まりきらない状況である。
データ構造は変更せず MML コンパイルの最適化で必要サイズを圧縮できるのがベター。 それで無理ならデータ構造の変更が必要になりそう。（※おそらく無理と想定している）