![Retro Computer People [annex]](/_images/blog/_fba/retrocomputerpeople/rcp-e6a98.png)
Thunderbolt さん
遠い過去の物となってしまった８／１６ビット時代のパソコンとゲームに関するブログです。
初めての方でも気軽にコメントしてください。
また、過去の記事にもコメントして頂ければありがたいです。
-
nice! 111
記事 110
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
過去の遺産という形でゲームの画面イメージ、パッケージ、マニュアル等を取り上げておりますが、もし不都合がございましたら「プロフィール」に記してあるメールアドレスよりご連絡頂けますようお願いいたします。
C.P.U. フォーマット 2/2 [お絵かき]
前回の記事「C.P.U. フォーマット 1/2」はこちら
３色ペイント部分拡大画像
「２色ペイント」は２色が市松模様で並びます。
「３色ペイント」は横方向には３色が、縦方向には２色が規則的に並びます。
「単色ペイント」はもちろん同色が連続しています。
この３種類のタイルペイントを効率よく格納するために考えられた方法が「縦方向変則RL圧縮」です。
横方向に圧縮しようとすると、「AB」「ABC」「AA」の３パターンを考慮しないといけないですが、縦方向だと、どのタイリングペイントでも、「２色が交互に並ぶ」か「１色が連続する」の２パターンだけを考慮すれば、効率的に圧縮が行えることになります。
しかし、「１色が連続する」のパターンを「２色が交互に並ぶ」場合のひとつと考えれば、考慮するパターンはひとつだけで済むことになります。
まず、PC-8801 や FM-8 のグラフィックは色数が８色なので、2³ = 8 ですから１ピクセルは３ビットで表せます 。
縦方向の２ピクセルを１パターンとして格納するには、２色分の色情報に６ビットが必要です。
１バイトは８ビットなので、残りの２ビットに「繰り返し回数」を格納します。
２ビットで表せるのは０から３までですが、繰り返し回数が１から３の場合は「繰り返し回数」にそのまま格納し、４以上の場合は「繰り返し回数」を０にして、次の１バイトに「繰り返し回数」を格納します。
例として色Aを黒色（ビットパターンでは000）、色Bを白色（ビットパターンでは111）と仮定すると、
繰り返し回数が３以下の場合
繰り返し回数が４以上の場合
となります。
繰り返し回数が１００回（２００ピクセル分）までとなっているのは、FM-8 版の「お絵かきプログラム」の制約だそうです。
繰り返し回数が４以上の場合に、「回数 - 3」を格納するようにすれば、最長で２５８回（５１６ピクセル分）までを２バイトで済ませることができたのですが、互換性のためには仕方がありません。
画像の色情報は保存範囲の左上端から下（Y座標軸方向）へ走査され、下端へ到達すると右隣の列（X座標軸方向）の上端から走査が継続されます。
例として下のパターンを圧縮する場合、色２を赤色（ビットパターンでは010）、色６を貴色（ビットパターンでは110）、色７を白色（ビットパターンでは111）、色０を黒色（ビットパターンでは000）と仮定すると、
実際に生成されるデータストリームは、
となります。（合ってるのか？＾＾；）
元データのサイズは 9 pixels × 12 pixels × 3 = 324 bits
生成されたデータは 31 bytes × 8 = 248 bits
なので、圧縮率は 248 ÷ 324 ≅ 0.765 となります。
実際の画像では、
前の記事でお絵かきした画像です。
「LEN :1945」となっています。１６進数なので１０進数に直すと、6,469 bytes です。
複雑な絵ではないので極端な例になってしまいますが、48 KB が約 6.5 KB になっているので圧縮率は約 0.135 です。
現在 Windows や Mac で使用されるデータファイルのフォーマットでは、ファイルの先頭に数バイトの識別用 ID が設けられる事が多いですが、当時はファイル名か拡張子で画像ファイルであるかどうかを「人間」が判別していました。 特に PC-DOS ではファイル名が２９文字まで許されていたので全く困らなかったということもあります。
実際に圧縮されたデータがファイルに格納されるには、データストリームの前にヘッダが付きます。
横方向の画像サイズ、縦方向の画像サイズがそれぞれ２バイトのビッグエンディアンで格納されます。
640 × 200 サイズの画像だと、02 80 00 C8 となります。
エンドマークの類は存在しません。
追記ここから
実際に圧縮して格納されたデータのサンプルを 256 Bytes 分だけ載せておきます。
どんな絵が出来るのかはナイショです。
追記ここまで
なかなか優秀な圧縮フォーマットだと思うの（手前味噌です＾＾；）ですが、皆さんの判定はどうでしょう？
３色ペイント部分拡大画像
「２色ペイント」は２色が市松模様で並びます。
ABABABABABAB BABABABABABA ABABABABABAB BABABABABABA ABABABABABAB BABABABABABA
「３色ペイント」は横方向には３色が、縦方向には２色が規則的に並びます。
ABCABCABCABC ABCABCABCABC BACBACBACBAC BCABCABCABCA ABCABCABCABC ABCABCABCABC BACBACBACBAC BCABCABCABCA ABCABCABCABC ABCABCABCABC BACBACBACBAC BCABCABCABCA
「単色ペイント」はもちろん同色が連続しています。
AAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA
この３種類のタイルペイントを効率よく格納するために考えられた方法が「縦方向変則RL圧縮」です。
横方向に圧縮しようとすると、「AB」「ABC」「AA」の３パターンを考慮しないといけないですが、縦方向だと、どのタイリングペイントでも、「２色が交互に並ぶ」か「１色が連続する」の２パターンだけを考慮すれば、効率的に圧縮が行えることになります。
しかし、「１色が連続する」のパターンを「２色が交互に並ぶ」場合のひとつと考えれば、考慮するパターンはひとつだけで済むことになります。
★
まず、PC-8801 や FM-8 のグラフィックは色数が８色なので、2³ = 8 ですから１ピクセルは３ビットで表せます 。
縦方向の２ピクセルを１パターンとして格納するには、２色分の色情報に６ビットが必要です。
１バイトは８ビットなので、残りの２ビットに「繰り返し回数」を格納します。
XXX YYY NN XXX: 色１ YYY: 色２ NN: 繰り返し回数
２ビットで表せるのは０から３までですが、繰り返し回数が１から３の場合は「繰り返し回数」にそのまま格納し、４以上の場合は「繰り返し回数」を０にして、次の１バイトに「繰り返し回数」を格納します。
例として色Aを黒色（ビットパターンでは000）、色Bを白色（ビットパターンでは111）と仮定すると、
繰り返し回数が３以下の場合
000 111 NN N: 繰り返し回数(1～3)
繰り返し回数が４以上の場合
000 111 00 | NNNNNNNN N: 繰り返し回数(4～100)
となります。
繰り返し回数が１００回（２００ピクセル分）までとなっているのは、FM-8 版の「お絵かきプログラム」の制約だそうです。
繰り返し回数が４以上の場合に、「回数 - 3」を格納するようにすれば、最長で２５８回（５１６ピクセル分）までを２バイトで済ませることができたのですが、互換性のためには仕方がありません。
画像の色情報は保存範囲の左上端から下（Y座標軸方向）へ走査され、下端へ到達すると右隣の列（X座標軸方向）の上端から走査が継続されます。
★
例として下のパターンを圧縮する場合、色２を赤色（ビットパターンでは010）、色６を貴色（ビットパターンでは110）、色７を白色（ビットパターンでは111）、色０を黒色（ビットパターンでは000）と仮定すると、
626026726726 262072672672 626000000726 260072672672 006026726726 262072672672 626026726726 262072672672 626026726726
実際に生成されるデータストリームは、
110 010 10 | 000 010 01 | 110 010 11 | 110 000 01 | 110 010 11 | 110 000 01 | 110 010 10 | 110 000 01 | 000 000 00 | 00000001 | 010 111 01 | 000 111 01 | 010 111 10 | 010 110 01 | 010 000 01 | 010 110 11 | 111 110 01 | 000 110 01 | 111 110 10 | 111 010 01 | 111 000 01 | 111 010 11 | 110 010 01 | 000 010 01 | 110 010 10 | 110 111 00 | 00000010 | 010 111 00 | 00000001 | 010 110 00 | 00000010
となります。（合ってるのか？＾＾；）
元データのサイズは 9 pixels × 12 pixels × 3 = 324 bits
生成されたデータは 31 bytes × 8 = 248 bits
なので、圧縮率は 248 ÷ 324 ≅ 0.765 となります。
★
実際の画像では、
前の記事でお絵かきした画像です。
「LEN :1945」となっています。１６進数なので１０進数に直すと、6,469 bytes です。
複雑な絵ではないので極端な例になってしまいますが、48 KB が約 6.5 KB になっているので圧縮率は約 0.135 です。
★
現在 Windows や Mac で使用されるデータファイルのフォーマットでは、ファイルの先頭に数バイトの識別用 ID が設けられる事が多いですが、当時はファイル名か拡張子で画像ファイルであるかどうかを「人間」が判別していました。 特に PC-DOS ではファイル名が２９文字まで許されていたので全く困らなかったということもあります。
実際に圧縮されたデータがファイルに格納されるには、データストリームの前にヘッダが付きます。
横方向の画像サイズ、縦方向の画像サイズがそれぞれ２バイトのビッグエンディアンで格納されます。
640 × 200 サイズの画像だと、02 80 00 C8 となります。
エンドマークの類は存在しません。
追記ここから
実際に圧縮して格納されたデータのサンプルを 256 Bytes 分だけ載せておきます。
どんな絵が出来るのかはナイショです。
追記ここまで
★
なかなか優秀な圧縮フォーマットだと思うの（手前味噌です＾＾；）ですが、皆さんの判定はどうでしょう？
自分の場合、こういう圧縮などの仕組は、なぞなぞの問題のような感じで、後で説明を聞いて、なんとなく理解できるんですけど、自分で考えて応用してみろとか言われると さっぱりなんです。（苦笑）
FDを買う金が惜しければ、頭を使ってデータ圧縮をなんとかする技術というのは、FDが安価だったら、遅れていた技術だったかもしれませんね。（そんなことないか・・・）
by M_t (2009-05-01 13:18)
M_tさん、コメント & nice! ありがとうございます。
FD にセーブされたデータの中に同じデータが延々と連なっていたら領域の無駄遣いだと思う私は古い人間なんでしょうかね（笑）
by Thunderbolt (2009-05-01 20:28)
リン・ミンメイとか...当時はよく題材にされていましたよね。
あとラムちゃんとか、アイドルの似顔絵とか。
細かい技術的なことは分からないのですが...笑
そういえば盗作の記事も読みましたが、そんなことがあったんですね...ちょっとびっくりしました、汗
by あやちだいち (2010-06-23 00:38)
あやちだいちさん、コメントありがとうございます。
>リン・ミンメイとか...当時はよく題材にされていましたよね。あとラムちゃんとか、アイドルの似顔絵とか。
アイドルやアニメ主人公の人気度が投稿数に反映されてましたね。
８色しか出せないPCでも、絵が描けること自体が嬉しかった時代です。 「限られた環境の中で如何にして綺麗に表現するか」が追求された時代でもあります。
>そういえば盗作の記事も読みましたが、そんなことがあったんですね...
「テ○ノポ○ス」と「表紙集」でググれば、画像データを作った本人がコメントしているページが見つかるかもしれませんｗ
by Thunderbolt (2010-06-23 17:27)