Petitverse

技術的な話
改良前：色を常に16bitで記録
改良後：直近15色以内にあった色なら4bit、ない色なら20bitで記録
というやり方にしました

（プチコン向けでないが）最近新しくできた画像圧縮形式で
QOIというものがあって、それの解説を見ると辞書参照は6bit分（64色）が一番効率がいい、という研究結果が書かれていたので

このライブラリもその結果を考慮して辞書の幅を6bitにするか迷ったのですが
6bit幅を持たせた場合、プチコンの整数型配列に格納しようとすると
配列1要素あたり格納できる個数が32/6=5あまり2となり
無駄な2bitを捨てるか、要素の境界を超えて書き込む複雑な処理を実装するかのいずれかを選ぶことになります。

一方で4bit幅を持たせた場合
配列1要素あたり格納できる個数は32/4=8となり
要素境界跨ぎの処理を考慮しなくても無駄なbitを捨てる必要が無くなります。

速度と圧縮効率の片方を犠牲にして難しい方法をやるより、簡単な方法を実装することにしました。

参考：QOI形式について参考になる記事
https://zenn.dev/yohhoy/articles/intro-qoi-format

QOI形式自体が「原始的な圧縮方法を組み合わせて高速に処理ができる形式」という感じのコンセプトになっており
プチコンに移植することも不可能ではない（PNG形式より単純）な設計になっています。

ただし、私の場合は既にSRI形式を自作しており、QOI形式を規格通り実装すると根本部分の作り直しになり、手間と効果が見合わないことから
辞書参照のアイデアだけ借りてSRI形式の改良型として作ることにしました

ちなみに、データの単位を4bitにする地味な利点があって
配列の中身を確認するときに
?HEX$(配列[添字])
というやり方をすると1データ=1桁になって確認しやすい、というのがあります

とりあえず公開しました。（データ形式を変えない改良は今後します）
sbkey=D3RE CN4V
（2022/5/25、23時ごろ差し替え）
スロット0で実行するとデモモードです。
ライブラリで使う時はスロット1〜3に読み込んでください。

キー差し替えの変更点：
・圧縮時に検証機能の残骸が残っていて遅かった問題の修正
・SRDSAVEFILE命令を追加
・ファイルヘッダのバージョンを&H50に変更（旧SRI形式との区別を容易化するため）
・解凍処理の大幅な高速化（ループ数削減）
・デモモードの見直し

'ライブラリの初期化（xは1〜3のスロット番号）
'初期化時にBACKTRACEの都合でCLSが実行されるので、プログラムの初期化段階で使うことを推奨します。
EXEC "PRGx:SRDLIB.PRG"

’セーブの例
SRDSAVEFILE beginX,beginY,width,height,"DAT:ファイル名"

’ロードの例
SRDLOADFILE beginX,beginY,"DAT:ファイル名"

ロード時間を短縮できたので上げました。
キーはsbkeyのレスに書いてあります。

そういえば面積あたりの大きさを調べてみたところ
DEFSPの場合は1pxあたり3〜5bitという結果になりました。
無圧縮のデータが1pxあたり16bitなので、約1/4の大きさに。

もう1つのテストケースで、絵合わせゲームの画面写真を試したところ
もっと小さい1pxあたり1.4bit程度になりました。
これはすごい、と思ったのですが…

れいさんのLZSS圧縮ならこれより4割以上圧縮できることが分かり、ショック！

絵合わせゲームの画面写真（SS21073001）
PZG形式：7.9kBytes
SRD形式：13.4kBytes
SRI形式（バージョン4.1w）：29.4kBytes
GRP形式（相当）：153.6kBytes

※GRP相当サイズについて
実際には512px四方でしか保存できないが、換算値として2Bytes×320px(W)×240px(H）

圧縮データを圧縮する奇襲を実行
少し小さくなったw
（その分だけ解凍時間は長くなりますが、PZGよりは爆速です）

仕様が固まったので、wikiに作品ページを作りました。
今後の更新はこちらに載せますので、このスレッドは締め切ります。
http://wiki.hosiken.jp/petc3gou/?Toukou%2FSRD%20LIBRARY