おちゃめくらぶ掲示板 - 1659321896

1423：御茶目菜子：2012/12/15(土) 23:50:41: CHRリソースでセーブデータを小さくしよう
何度も書いているようにプチコンmkIIはQRコードでプログラムやリソースのやりとりが
可能になったというのは非常に大きな進歩だけどその反面でネット上で公開されている
プログラムやリソースをどんどん取り込んでいるような人だとすでに「保存のための空き
容量が足りません。不要なファイルを削除してください。」という警告画面を見たことが
ある人も多いのではないかと思うにょ。
私自身はここ最近は頻繁に見ており、少しずつ削除して新しいQRコードを読み込んだり
新しいプログラムを作ったりしている状態にょ。

現状で発表されているプログラムはどうしようもないけどやはりこれから発表してもらう
プログラムでは少しでも多くの人に取り込んでもらうためには「いかに容量を抑えるか」
ということも求められてくるのではないかと思われるにょ。
その1つがCHRリソースなどを大量に使っているプログラムの場合だとリソースファイルを
別途に公開したり、パッケージ形式で公開せず、CHRリソースデータをPRGに埋め込んだ
状態で公開するというものにょ。
ただし、この場合、普通にCHRリソースデータをPRGにDATAで羅列してしまうとリソースで
別途公開した方がサイズが小さかったということにもなりかねないにょ。
そのため、16進数データを圧縮するという方法が求められてくるにょ。
すでに16進数データを256進数に圧縮するプログラムは公開されているのだけどそれを
使ってやれば保存領域の軽減が可能とはいえ、CHRリソースを大量に使っているゲームだと
制作者に多大な負担をかけてしまうにょ。（圧縮するためのデータのPRGへのやりとりも
大変だけど修正も難しくなる）
そして、9999行制限のためすでに数千行も使っているような超大作の場合は事実上PRGに
埋め込むことなんてできないにょ。

さて、そうなると最もお手軽な保存領域の軽減方法として考えられるのがGRPのセーブを
使わないということにょ。
プチコンで標準でデータセーブ用に用意されているMEMリソースは256バイト分しかセーブ
できないということでそれ以上をセーブしたい場合は256バイト単位で分割していく必要が
あるにょ。
しかし、それが数KBもしくはそれ以上のセーブデータになってしまうとファイル数ばかりが
膨らんでしまいユーザーにとってはデメリットでしかないにょ。（SAVE画面は必ずダイア
ログが出るため10分割したら1回セーブするたびに10回も「はい」を押す必要がある）
そのため256バイトに収まらないセーブデータはGRPリソースでセーブするというのが広く
普及しているにょ。

しかし、256バイトのMEMリソースから48KBのGRPリソースになり保存できる量は192倍
増えたのだけど保存領域もそれにしたがって増えているにょ。
GRPリソースは仮に1バイトしか記録していなくても保存するのに48KBの領域を占有して
しまうからね。
というわけで、MEMリソースよりも大きくGRPリソースよりも小さい8KBのCHRリソース
（SPU、BGU）を使ってセーブすれば保存領域は1/6に軽減できるにょ。
とはいうものの1バイト単位で記録ができるMEMリソースやGRPリソースとはCHRリソースは
32バイト単位でしか書き換えることができないにょ。
しかも、書き換えられるのは0～Fの16進数データのみであるため少しずつデータを書き
換えていくという用途には非常に使い勝手が悪いにょ。
すでにGRPリソースで記録するようにしているプログラムも大幅な改造が必要になってくる
ためCHRリソースを使ってセーブを行う作品は全く見かけないにょ。

そこで考えたのがランダムアクセスや1バイト単位での追記が難しいCHRリソースに随時
書き換えるのではなく普段はGRPに記録しているけどセーブの時だけ一時的にCHRリソースに
変換するというものにょ。
これならば今まで作ったプログラムをほとんど変えることなく変換プログラムを追加する
だけで対応できるため多くの人が利用できるのではないかと思われるにょ。

そういうことで、GRPリソースのセーブデータをCHRリソースに変換するプログラムを
作ってみたにょ。

1行プログラム「CHRセーバー」
FOR I=0TO 255FOR J=0TO 31Z=GSPOIT(I%8*32+J,I/8)C$=C$*!!J+HEX$(Z,2)NEXT:CHRSET R$,I,C$NEXT
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#05

1行プログラム「CHRローダー」
FOR I=0TO 255CHRREAD(R$,I),C$FOR J=0TO 31Z=VAL("&H"+MID$(C$,J*2,2))GPSET I%8*32+J,I/8,Z:NEXT:NEXT
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#06

セーブする際にはCHRセーバーを使うのだけどまずは変数R$に一時保存用に使うリソースの名前
（SPU0～SPU7、BGU0～BGU3のいずれか）を入れておくにょ。
GPAGEの設定も忘れずにセーブをしているページに設定して実行するにょ。
そうすればGRPリソースがCHRリソースに変換されるので SAVE R$+":(ファイル名)" でCHR
リソースとしてセーブできるにょ。
ロードする際には同じように設定を忘れずに行いまずは変換されたCHRリソースデータを
LOAD R$+":(ファイル名)" で読み込ませるにょ。
そして、CHRローダーを実行すればGRPリソースのセーブデータとして元に戻るにょ。
つまり、すでにGRPリソースでセーブするプログラムを作っている人ならばわずか1行の
プログラムを2本（約200バイト）を追加するだけで後は無改変でCHRリソースによるセーブ
システムができあがるにょ。（ただし、SPUやBGUの空きが1つ必要となる）

これによって、48KBあったセーブデータが一気に8KBへと小さくなるためセーブデータが
8KB以下のプログラムならばこれによってセーブデータを1/6に圧縮するのと同等の効果を得る
ことができるにょ。
実際はほとんどのプログラムのセーブデータは8KBよりも小さいためこれで問題が発生する
ことはあまりないのではないかと思われるにょ。（リプレイデータを保存する場合には60fpsの
ゲームであっても8KBに2分16秒分記録できる）
とはいうものの、逆に8KBでも大きすぎるという場合もありそうにょ。
1KBや2KB程度のリソースデータがあればそれを使うという方法もあるけど8KBのCHRリソースの
下は一気に256バイトになるためなかなか難しいところにょ。

あと問題となるのはプチコンの保存領域の最小単位にょ。
HDDなどではクラスタサイズに相当するものだけどこれがプチコン（というか、DSiや3DSの
内蔵フラッシュメモリ）の場合はどうなのかということを考える必要があるにょ。
実際にギチギチに詰めて警告が出る状態で1枚のGRPを削除してそこにどれだけのものをセーブ
できるかを検証したら1バイトのプログラム（改行1つ＋ヘッダ）でさえ13回目のセーブで再び
警告が出たにょ。
これから保存領域の最小単位は4KBであると推測されるにょ。
そうなると1KBのリソースがあっても4KBのリソースと同じ分だけ占有されてしまうという
ことになるにょ。
確かにそれでもCHRリソースの8KBというサイズは1～2KBしかセーブしていない場合には無駄が
多いけれど保存領域の最小単位に適合するようなベストなリソースがないためこれが256バイト
超のセーブとしては最善ではないかと思われるにょ。
256バイトのMEMリソースを2つセーブすればCHRリソースとほぼ同じ分だけ保存領域が必要に
なってしまうということだからね。

プチコンmkIIの後継では3DSに対応によって保存領域の大幅拡大を望みたいのだけど保存する
リソースもユーザーで自由にサイズ選択ができるようになると利便性が高まりそうにょ。
個人的には一般的なBASICのように普通にファイルが扱えるようになるのがベターに感じる
けれど任天堂の厳しいチェックを通過できるためにはセキュリティ面を非常に重視している
ためにユーザーの利便性のみを高めたものをリリースするのは難しそうにょ。