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

1472：御茶目菜子：2013/02/08(金) 23:59:59: プチコンでは画像にGRPリソースは使わない方がいい・・・？
MONOistのプチコン虎の穴も今回で10回目となったにょ。
http://monoist.atmarkit.co.jp/mn/articles/1302/07/news003.html
今回はコンソールキャラではなくグラフィック命令を使って女の子の絵を描くというものにょ。
プチコンではユーザーの手によって非公式ながらPCで作成したデータを使用可能になって
いるにょ。
例えばPC上で描いた絵や写真などをで256x192にリサイズしてBMP形式で保存すればそれを
プチコンで読み込める形式に変換可能になるようなツールはいくつも作られているにょ。
そのため1枚絵をふんだんに使ったギャルゲーなども作ることは可能なのだけど問題はQR
コードの枚数にょ。
公式変換ツールを使った際には1枚のQRコードには630バイト分のデータしか入らないからね。
256x192ドット256色の画像は無圧縮だと48KB（49152バイト）になるためQRコードの枚数は
単純計算で79枚に達するにょ。

しかし、QRコード化の際にはzip圧縮がかかるためサイズは大幅に軽減可能にょ。
とはいえ、半分のサイズに抑えられても40枚弱となるにょ。
例えば私が書いたこの桔音紺の絵があるにょ。
http://ww5.tiki.ne.jp/~ochame/CG/kon.jpg
これをプチコンで読めるように変換した場合にはQRコードは25枚になったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/kon/
これでもグラデーションを削るなどの多少の軽減措置は行っているものの枚数を減らす
ためにはアニメ調のベタ塗りやタイルパターンを使うか減色するしかないにょ。（PC上で
リサイズする場合にはサイズ縮小時に補完機能が働き逆に色数が増える場合がある）
しかし、減色によってサイズを半分にするためには単純計算では256色から16色にする
必要があるためかなり無理があるにょ。（実際にPC上で減色ソフトを使って256色の画像を
16色に減色してみれば分かるけどどんなソフトを使っても無理矢理減色した感じがはっきり
出てしまうため極端に減色するならば塗り直す必要がある）

QRコードの枚数は何とかなるという場合でも問題はプチコンの保存領域にょ。
具体的にどれくらいかは分からないけど私の感覚だと数MB（4～5MB程度）といった感じに
なっているにょ。
QRコードでは圧縮された状態となっているため色数を減らしたり塗りを単純化することで
枚数を減らせたとしてもプチコン内部に保存するときは無圧縮となっているためQRコード
1枚に収まるような単純なGRPでも48KBの保存領域を消費してしまうにょ。
それでも数10枚のGRPが保存できることになるのだけどそのプログラム1本だけ保存する
というのではなくWeb上で公開されているプログラムをどんどん保存しているような人
であればGRPは極力避けたいと思っているのではないかと思うにょ。

その1つの改善策となるのが私が作ったCHRセーバーとCHRローダーにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#05
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#06
これはプチコンで広まっているGRPによるセーブだけどほんの数KBのセーブデータであっても
上記のように48KBも保存領域が必要になるためそれを何とかしたいということで考えて作った
ものにょ。
CHRリソースは8KBなので8KBまでのGPRによるセーブデータならば単純計算で保存領域を1/6に
圧縮したのと同等の効果が得られるにょ。
ただし、CHRリソースは32バイト単位でないと読み書きできないという不便さがあるため
その手助けをするために作ったのがCHRセーバーとCHRローダーというわけにょ。（要するに
GRPの1/6の領域をCHRリソースに変換するだけのもの）
このCHRセーバーをGRPの1枚絵を保存するためにはGRPの絵を圧縮して8KB以内に抑える必要が
あるにょ。
GRPの圧縮そのものは難しくはないけど圧縮後のサイズは圧縮してみないと分からないため
8KBに収まらないときは絵の修正が必要になるという問題があるにょ。（CHRリソースを複数
使うという方法もあるけどその場合は圧縮効果が小さくなるし連番で何枚あるのかを別途管理
しなくてはならなくなってしまう）

そこで、プチコンでGRPによる1枚絵を用意するならば（保存領域やQRコード枚数の両面に
おいて）サイズ面で最もお手軽となるのが今回のプチコン虎の穴で使われているような
座標データを元にGLINEでつなげてGPAINTで塗るという方法にょ。
この方法はかつて8ビットパソコンにおいてもデータ量の関係から画像データとして1枚絵を
用意することが難しかったため同様の方式で描いていたゲームも多数存在したにょ。
MAG形式などの圧縮形式が確立した頃からようやく座標を元にプログラムで描くのではなく
1ドット単位で構成された画像データの1枚絵として用意されることになったにょ。
現在でもドロー系、ペイント系として両者は残っているけどそれぞれにメリットとデメリットが
あるため片方だけが残るということは今後もないと思われるにょ。

さて、現実的に考えると座標指定で女の子の絵を描く場合は少なく見積もっても200～300個
程度の線画用の座標が必要になるにょ。
1つのデータが3桁＋コンマの4文字でX、Y座標で合計8バイトとすると200個ならば1.6KB、
300個ならば2.4KBとなるにょ。
これにペイント用の座標が必要になるため2～3KBが最低ラインといえそうにょ。
仮に50枚用意したら100～150KBという（プチコンとしては）かなり大きなデータ量になって
しまうにょ。
しかし、これはあくまでDATA文で記述する場合であり、この頂点座標をGRPに入れるならば
また話は変わるにょ。
GRPでは1ドットで0～255が表現できるためX座標、Y座標の指定は2バイトで収まるにょ。
そうなるとDATA文による2KB分の頂点座標データはGRPならばわずか512バイト程度に収まる
計算になるにょ。
3KB分でもその1.5倍にょ。
1枚のGRP（48KB）にはこのレベルのデータ量ならば64～96枚はいる計算になるにょ。
1枚ごとに座標データが何個あるのかなどの管理データが別途必要であるものの1枚のGRPには
50枚程度の1枚絵は十分に入りそうな感じにょ。（もっとも200～300個の座標データという
のはかなり少なめであるためもう少し緻密な絵にしたければその数倍のデータ量になるけど）

私がその方式で描いた絵というのはダミーちゃん危機一髪での包丁のグラフィックがあるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/dmmy_chan.htm
ただし、これはDATAではなくGLINEを直打ちで作ったにょ。
それは短時間で作るには脳内座標をそのまま打てるGLINEの方が便利だったからにょ。（大量に
あればちゃんとDATAで作った方がいいけどこの程度ならばGLINEで記述してもそれほど多くの
サイズアップにはならない）
そして、今回はまた別の絵を使ったプログラム「神風の術」を作ってみたにょ。
http://twitpic.com/c1uyjv
2月1日に書いたラスタースクロール祭の時に続いて第3弾として作った簡単なものであるため
1枚絵といっても見ての通りの単純なものだけど今回も制作時間短縮のためDATAではなく
GCIRCLEの直打ちで作ったにょ。
GLINEではなくGCIRCLEなのは簡単に説明するとその方が自然な曲線が描けるからにょ。
包丁データを作った時は直線が多かったので楽だったけど今回はかなり長目の曲線が多用
されているためGLINEだと上手い曲線を引くには時間がかかるし、さらにデータも多めに
なってしまうからにょ。（ちなみに今回も脳内画面に円を描いてその脳内座標をプチコン上に
転写して誤差を修正したもの）
やはり、プチコンで1枚絵を使ったものならばGRPで1枚1枚の画像を用意するよりもこのように
プログラムで座標データを元に描くのが1番かもしれないにょ。