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

1085：御茶目菜子：2012/06/19(火) 21:55:54: プチコンでリソースを使う是非
昨日twitter上でプチコンのリソースについて盛り上がったにょ。
プチコン開発元のスマイルブーム社長の小林氏も加わりリソースを使用する意味について
みんなで語り合ったにょ。（ハッシュタグ #petitcom で検索すればそのログが読める）
プチコンではプログラム本体（PRG）とは別にさまざまなデータをリソースファイルとして
管理可能になっているにょ。

　PRGリソース・・・プログラム本体
　CHRリソース・・・スプライトキャラ（SPU）、BGキャラ（BGU）、コンソールキャラ（BGF）
　SCRリソース・・・BGスクリーン
　GRPリソース・・・グラフィック（GRP）
　COLリソース・・・カラーパレット
　MEMリソース・・・メモリ（MEM$に保存されているデータ）

　初代プチコンにおいてはネット上で不特定多数に公開する手段が用意されていなかったにょ。
確かにプチコンが入っている2台のDS本体を持ち寄れば上記のリソースファイルの受け渡しが
すべて可能であり全く問題は無かったのだけど直接受け渡しができない他人に実行してもらう
ためにはプログラムリスト（PRG）をテキストファイルとして書き下ろすか、編集画面を
写真撮影してそれを繋ぎ合わせて公開するという手段しかなかったにょ。
当然ながらその場合はPRGのみで動作するプログラムならば問題ないけど他のリソースが
必要な場合は、そのキャラやグラフィックを写真に撮って「これと同じものを自分で用意
してください」と言うしか方法は無かったにょ。

これがmkIIによってQRコード経由で公開できるようになって事態は一転したにょ。
自分でプログラムリストを手入力する必要が無くなったというだけではなく従来は不特定
多数に公開が不可能だった他のリソースファイルもQRコード経由で公開できるようになった
からね。
そのためmkIIが発売されてからはリソースファイルを使う人はかなり増えたのではないかと
思われるにょ。
ただし、QRコードはリソースごとに分かれていたら読み込むのが面倒とか、フォルダ管理が
できないプチコンではあまりファイル数を増やすと管理が大変になるとかいう問題も発生
してしまうにょ。
しかし、それもパッケージ化によって解決されているにょ。
パッケージ化されたプログラムは必要なリソースを読み込んだ状態で保存されているため
QRコードはそのプログラムだけで済むし、管理も1ファイルで済むにょ。
そして、そのプログラムをLOADする場合も必要なリソースファイルをプログラム内で別途
LOADする必要もないにょ。（ただし、パッケージ化されたプログラムはLOAD時にリソース
ファイルが自動読み込みされるためキャラの初期化などを行った場合には再度その
プログラムをLOADしなおす必要がある）

　◎リソースを使うメリット
　　(1)データのメインテナンス性が高い
　　(2)データの再利用が容易
　　(3)QRコードの枚数を減らせる

(1)プログラム本体でキャラデータを扱う場合には下記のようにDATA文の羅列によって表記
する必要があるにょ。

　DATA "0000F000"
　DATA "000FFF00"
　DATA "00FFFFF0"
　DATA "0FFFFFFF"
　DATA "000FF000"
　DATA "000FF000"
　DATA "000FF000"

このようにDATA文の羅列で表記する場合には少しでもメインテナンス性を高めようとする
ならば非圧縮になってしまうのだけどそれだとデータ数が増えた場合にはデータ量も行数も
非常に多くなってしまうにょ。
データ圧縮をすることでデータ量や行数は軽減できるもののその場合はメインテナンス性が
大幅に低下してしまうにょ。
そのデータはそれで完成だから弄らないというのならばそれでもいいのだけどそうでない
場合は厄介にょ。

またデータを変更する場合には、上記のメインテナンス性を高めた非圧縮のデータであっても
別途CHREDなどのエディタを使って編集する場合にはリソースデータをDATA文の形式に書き出す
という必要性が出てくるにょ。
したがって、メインテナンス性の面で見るとリソースデータをそのまま活用した方が遙かに
有利なのは言うまでもないことにょ。

(2)初代プチコンではDATA文で羅列されたデータを再利用する方法は無かったにょ。
そのため、そのデータを利用するためにはそのプログラムリストを元にDATA文を手入力する
必要があったにょ。
しかし、mkIIではAPPEND命令の追加によってそれは変わったにょ。
データごとに別のPRGファイルを用意すればそれをAPPENDして繋ぎ合わせるだけで再利用が
可能になったからね。

ただし、再利用性を高める場合にはDATA文によるデータは非圧縮であることが求められて
くるにょ。
データを圧縮した場合は同じ圧縮、展開ルーチンを使う必要があるにょ。
そうでないとデータごとに圧縮、展開ルーチンを別途用意する必要があるため圧縮する意味が
薄れてしまうからね。
自分しか使わないデータならば最初に考えた圧縮展開ルーチンを使い続ければいいだけの
話だけど他人にデータを使ってもらう場合には共通の圧縮展開ルーチンを求めるのも難しい
ために非圧縮である必要性があるにょ。

またプチコンの編集機能が今時のエディタと比べると大幅に貧弱であり、削除は1文字もしくは
1行ごとしか行えないのに加えて行単位での挿入もコピー＆ペーストで1行単位で行うしかない
ためにAPPEND命令を使用した場合には基本的にデータを順番に追加しかできないにょ。
そういう面を考えるとAPPEND命令によってPRGでのデータの再利用が可能になったとはいえ
再利用するならばファイルをそのまま読み込むだけのリソースと比べたら完全に劣っていると
思われるにょ。
もっともリソースファイルの最小単位はCHRリソースの場合は256キャラ分となっており
SPUならば1バンク単位となっているため再利用を前提として考えるならば1つのバンクに
利用したいキャラが集結していることが求められてくるにょ。
もっともエディタを使えばコピー＆ペーストによってその都度1つのバンクに集結させれば
済むとはいえそれなりの手間がかかってしまうため、「リソースファイルだから再利用性が
高い」という単純なものではないではないということにょ。（あくまでPRGと比べてたら
再利用性が高くなる場合が多いというだけ）

(3)上記のようにリソースを使わずDATAで表記した場合には1ドットが8bit（1バイト）の
GRPデータではどうなるかを考えてみるにょ。
プチコンでは制御文字がない（実質改行マークとタブのみ）であるため256文字のほとんどが
プログラム内で使用可能となっており、それを生かして256進数で表記してみるにょ。
その場合はプチコンの1行の最大が100文字であるためDATA文1つに付き64バイトのデータを
並べるとすれば1行当たり71バイトとなるにょ。
これで256x192ドット分、49152バイトのGRPデータをDATA文で表記した場合には54528バイト
となるためDATA文で表記した場合は256進数であっても4KB分多くなってしまうにょ。
ただし、これはGRPをフルに使ったデータである場合に限られるにょ。
RPGなどで大量のデータが必要であってもそれがフルに使用しているとは限らないのだけど
全体の9割未満の消費であればDATA文での表記の方が短くなるためリソースファイルの
方が短くなるとはいえないにょ。
何せリソースファイルを用いた場合には例え1KB分しか使用していなくてもGRPは1つで
49152バイト（プチコン内部に保存する場合はヘッダ込みで49164バイト）の記録領域が
必要になってくるからね。
したがって、「記録領域を少しでも減らしたい」という場合はリソースを使うよりも
使わない場合の方が有利になると思われるにょ。（もちろん非圧縮だとDATA文を使用した
場合にはデータ量が多くなるため256進数を使用するなどのデータ圧縮の方法を講じた
場合に限る）

しかし、これはQRコードにおいてはまた別にょ。
というのもQRコードの場合はzip圧縮がかかるからにょ。
これはLZ77符号化ととハフマン符号化アルゴリズムを組み合わせて圧縮しているのだけど
ハフマン符号化においては出現頻度の高いデータを短いbitを割り当てることで圧縮を
行っているにょ。
これがGRPによる1枚絵ならば使用している色に偏りがあるためハフマン符号化が有効に
働いているにょ。（均等に256色使われている場合にはほとんど効果がないためランダムで
描かれたドットを保存する場合にはあまり圧縮は期待できない）
またパターン化している部分があればLZ77のスライド辞書によって圧縮が可能になるため
特定パターンを繰り返して塗られているような絵ならば高い圧縮が期待できるにょ。
SPUのようなドット絵だとパターン化はそれほどないとはいえ、パレットが16色であるため
高い圧縮率となっているにょ。

これならばPRGにDATA文で表記しても高い圧縮率が期待できそうだけど実際はプログラム
内で使用されている文字とDATAで使用されている文字を合わせて頻度やパターンを考慮
して圧縮が行われているためDATAで出現頻度が高くてもプログラム内全体でそこまで
高い文字でなければ短いbitは割り当てられずハフマン符号化による高い圧縮効果は
期待できないにょ。
これは256色のBMP画像をzip圧縮した場合にはグラフィックならば1/2～1/10の極めて高い
圧縮が期待できるけどテキストの場合はせいぜい1/2程度の圧縮しかできないのを見れば
一目瞭然だと思われるにょ。
出現頻度やパターンが異なるため圧縮するファイルは別々に用意した方が圧縮率が高く
なるということでプチコンにおいてはプログラム本体（PRG）とは別にリソースを用意
もしくはパッケージ化を行った方がより多くの圧縮が期待できるためQRコードの枚数の
削減に繋がるというわけにょ。
1枚絵より圧縮が効きにくいフォントデータにおいてもプチコンまとめwikiに投稿されている
美咲フォントはGRP版でQRコード30枚となっているけれどこれのプログラムリスト版を
PetitEditorを用いてQRコード化した場合には65枚になっており、リソースを別途用意する
方が少ないQRコードになるという意味がはっきり分かると思われるにょ。
http://wiki.hosiken.jp/petc/?Toukou%2F%B4%C1%BB%FA%A5%C7%A1%BC%A5%BF

プチコンで使っているQRコードは97x97のサイズであり、誤り訂正が最大の場合は1枚に
600バイト程度のデータが記録可能になっているにょ。
もちろん、これは上記のように圧縮後のデータであり、1/10に圧縮ができるならば1バンク
8192バイト（プチコン内部記録時で8204バイト）のCHRリソースでもQRコード1枚になる
可能性があるというわけにょ。
しかし、PRGの場合は圧縮率はせいぜい1/2程度であるため6KBのプログラムならばQRコードは
5枚前後になるにょ。
これがリスト短縮を行って6KBのプログラムを5KBに減らした場合にはzip圧縮による圧縮率も
低下してしまうのでQRコードの枚数はほとんど変わらない（5枚前後）になってしまうにょ。
私の経験ではリスト短縮をフルに行った場合にはQRコード1枚あたり800バイト程度しか
入らないためzip圧縮の効果はほとんどないものといえるにょ。（つまり、リスト短縮を行い
リストは短くなってもQRコードの枚数は減らない）

では、次にリソースを使わないメリットにはどのようなものがあるのかを考えてみることに
するにょ。

　◎リソースを使わないメリット
　　(1)使う必要がない
　　(2)PRGだけで完結できる

(1)80年代にBASICでのプログラミングを行っていてしばらくプログラミングから遠ざかり
プチコンによって再びプログラミングを始めたという人にとってはリソースは謎の存在
かもしれないにょ。
実際は上記のように単にそれぞれのデータを別ファイルとして管理されているというだけの
話なので難しいことは何もないにょ。
とはいえ、それを使うか使わないかはそれを生かせる使い方をするか否かというのも重要に
なってからね。
別途リソースファイルを使わなくてもプチコンはデフォで様々なデータが内蔵されているし
自前のキャラが必要な場合でもその時だけDATA文でキャラ定義をすれば済む話だしね。
したがって、リソースを使わない人の多くは「リソースと使う必要性に迫られていない」
「リソースファイルを使わなくても特に困っていない」というのが理由だと思われるにょ。

(2)は(1)と似ているようだけど根本的に(1)が消去法でリソースを使わない選択をしたのに
対してリソースを使わないという選択を積極的に行っているということにょ。
これは人によっては「謎のこだわり」と感じられる部分かもしれないにょ。
それはPRGで完結させるというのは初代プチコンならば上記のように不特定多数に向けて公開
するためには必要不可欠といっても良かったけどmkIIではQRコード経由の公開が可能になった
ためにPRGで完結させる必要性が無くなったためにょ。

それではなぜPRGで完結するような選択肢をとっているのかというとやはり古くからBASICで
プログラミングをしている人にとってはそれが馴染みが深いためにょ。
80年代はベーマガ、I/O、Pio、プログラムポシェット、ポプコム、The BASICなど読者からの
投稿プログラムを募集している雑誌がたくさんあったにょ。
そんな中でポケコンも専門誌「ポケコンジャーナル」が88年に創刊されたにょ。
当時は雑誌掲載のプログラムリストを手入力を行うというのが普通だったにょ。
中には工学社のように雑誌掲載のプログラムをカセットテープやFDに入れたものを販売する
という方法をとっているものもあり、手間をかけて雑誌のリストを手入力するか手間を
惜しんでお金で解決するかという二択があったにょ。

最近（というかWindows普及後）だったらCD-ROMやDVD-ROMにフリーウェアを詰め込んだ雑誌は
多数存在するけど当時はそれができなかった理由としては記録媒体の価格が高価であった
ことと記録媒体が統一化されてなかったことが挙げられるにょ。
80年代初頭だとまずFDDは高値だった（外付けFDDが10～20万円していた）上に記録媒体である
FDそのものの価格も高価であったために雑誌の付録にFDを付けるなんてことはまず現実的な
選択としてはあり得なかったにょ。
FDDが一般的なパソコンに内蔵されるようになった80年代半ばにはある程度価格が下がったとは
いえ記録媒体は5インチに加えて3.5インチが登場したし、記録面も片面、両面があるだけでは
なく記録密度も標準、倍密度、高密度と様々だったからね。
当然のことながらFDDを搭載していない機種（オプションの機種）も多かったためそういう
機種においてはカセットテープに記録していたにょ。
ならば、複数のメディアを雑誌に付ければ良いと考えるかもしれないけど空のメディアでも
1枚数100円もするようなメディア（2～3年前のBD-Rレベルの価格）のものを複数付録で付ける
というのはかなり難しい問題だったにょ。（というか、雑誌の付録の規制緩和が行われた
のは2001年であり、それまでは材質などの規制があった）
したがって、80年代半ばだとPioのようにソノシートを付けるのが精一杯だったにょ。
これが90年代に入ると国内ではPC-98が圧倒的なシェアとなり記録媒体も5インチから3.5インチ
への移行が進んできたために雑誌の付録もPC-98用のフリーウェアを入れたFDを付けたものが
増えてきたけれどこれはBASICの話とは離れていくので割愛するにょ。

90年代になり、8ビットパソコンは市場からほとんど姿を消した後でもベーマガなどの雑誌では
BASICによるプログラム投稿が盛んに行われていたにょ。
これは根強いユーザーがいるというのも理由だけど基本的に旧世代のBASICはプログラムリスト
の形で完結しているため雑誌掲載がしやすいためだと思われるにょ。
93年のWin3.1、95年のWin95の発売によってWindowsが急速に普及しはじめたけどそのためVB
などのGUIによるプログラミング環境が増えることになったにょ。
そうすると雑誌の紙面では完結できないという問題点が浮上することになるにょ。
Win95以降のCD-ROM搭載率の大幅な増加とCD-ROMのプレスコストの低下によって2000年代に
入ってからはCD-ROMを雑誌に搭載することが容易になってきたけどそうなったときには
ベーマガのように読者投稿プログラムを集めた雑誌とTECH WINのようにユーザーの投稿
ソフトを集めた雑誌の差別化が難しくなってきたにょ。

ベーマガの最大の特徴としては多くの投稿プログラムを掲載しているという点ではないかと
思われるにょ。
80年代は○○機種××本掲載というようにそれを煽り文句にしていたくらいだからね。
それも90年代から徐々に減っていき上記のようにWindows普及後はGUIによるプログラミング
環境が普及したために「超大作プログラム」と称してプログラムリストが誌面に掲載されない
ものが増えてきたにょ。（当初はCD-ROMの付録は無かったのでWebサイトにて公開）
これは誌面だけでは完結できないためやむを得ないとはいえこれによってプログラムリスト
公開の雑誌の限界が見え始めたにょ。
ということで、ベーマガ休刊の最大の理由は一世風靡した旧世代BASICの衰退にあると
思われるにょ。
したがって、もしも旧世代BASICが栄えており高い需要があれば未だにベーマガは健在
だったと確信しているにょ。（あり得ない仮定を持ち出しても仕方ないけど）

以上の流れを踏まえて考えるとやはり旧世代BASICを名乗るならばプログラムリストの
形で完結することが必要不可欠だと思われるにょ。（確かに旧世代BASICの中には別途
スプライトデータが必要なリストも掲載されていたけどそれは一部の例外に止まった）
だから個人的には「プログラムリストで完結する」というのは非常に大きな意味を持つ
ことになるにょ。
しかし、これは現行のプログラミング言語を否定するようなものではなく古き良き文化の
維持という感じのものだと受け止めて欲しいにょ。

確かにグラフィックを使いまくったプログラムを作るならば上記のようにリソースには
メインテナンス性と再利用に優れているというメリットがあるためプログラム単体で
完結するように作るよりも遙かに楽だけど個人的にはそこまで使いまくったものは
作らないし、いかに短いリスト（小さいファイルサイズ）で面白いものを作るかという
ことを考えているため必要性に迫られない限りはデフォキャラをいかに使うかということを
考えてしまうので結果的にリソースを使う機会もほとんどないことになるにょ。（まぁ
セーブデータ用でMEMリソースを使うくらいか）
小さいリストサイズ（ファイルサイズ）に拘っているのは面白さを天秤に掛けた場合に長い
リストだから面白くできるというわけではないからにょ。
その長いリストや大きなファイルサイズに似合った面白さが用意できるならば別だけど
私の場合はそれが難しいので自分に向いている選択肢をとっているというだけのことにょ。
この辺の融通が利くのが趣味によるプログラムの醍醐味といえるにょ。