twitterで「スターソルジャー30周年ですね」と言われ「あっ」と思って、せっかくだから30周年を記念して、イロイロ野沢さんに聞いてみたら、まったく聞いたことがない話がいっぱい出てきたので、メモ書きとして残しておくシリーズ。
以下はリンク。
■スターソルジャー30周年記念(1)
■スターソルジャー30周年記念(2)

このブログに来る人で、知らない人はいない気がするけれど、お約束的に『スターソルジャー』について書いておく。
『スターソルジャー』はハドソンから1986/6/13にリリースされたファミコン用の縦スクロールシューティングゲームだ。販売本数は約100万本。
第二回の全国キャラバンに使われたソフトで、高橋名人の16連射を印象付けたソフトでもある（第二回の全国キャラバンあたりで高橋名人の人気がピークに達することになる）。

ところでwikipediaに書かれている『スーパースターフォース』の話の顛末は全く信じられないことを、前回、野沢さんの話をひいて載せたところ、いつの間にやら削除されていた。
それ自体はよいことだと思うが、どこから現れたのか全く分からないソース不明のヨタ話がお大事なはずの検証可能性とやらを無視して載っている自称百科事典のどこに信頼性があるのか。そんなヨタを書いているヒマがあったら、作者の野沢さんにインタビューの一つもするのが正しい態度というものだろう。

で、今回はプログラムの開発…のマップについて。
他の話も入れたかったのだけど、これを説明するだけでとんでもなく長くなってしまったのだ。




これについてはファミコンのBGの制約を知っていて、かつハドソン用語（だと思う）CELL（セル）を知らないとさっぱりわからない話なので、以下に一つずつ説明していく。

ファミコンの画面は背景画面（BG)＋スプライトでできてのだけど、今回の話はBGがキーなので、BGについて書いていく。

BGはどのような構造なのか？　BGは２つのパーツから出来上がっている。
１つがキャラクタジェネレータ、通称キャラジェネ（パターンジェネレータという呼び方もあった）。
キャラジェネは8x8ドットのキャラクタが256個で一組（１バンクとか１セットとか呼び方はイロイロ）になっているのが普通だった。なぜ256個なのかというと0-255が8ビットで扱える範囲だからだ。80年代後半のPCエンジン、メガドライブ世代になると一つの画面に対して複数のBGが使えるようなるのだけど、それでも１セットは256個という制限があった。キャラジェネって単語は長いので、以下ではCHRと略したい。
実際のCHRは当時のマシンではたいてい右図のような8x8ドットのピクセルデータだった。ここではサンプルとしてＡを描いている。１ドット空白を開けているのは、そうしないとつながって見づらくなるからだ。8x8ドットなのにも意味があるが、今回はパス。
そしてもう一つ、名前があちこちで違うので困るのだけどBGテーブル…とでもいうべきものがある。
BGテーブルは当時はVRAM(Video RAM)と呼ばれていたものになり、実際に画面に表示されるデータが書き込まれる場所だ。これまたBGテーブルは長いのでBGT、と略したい(PCエンジンではBAT、Background Attribute Tableなんて名前がついていた） 。

CHRとBGTの関係を示しているのが右図。
CHRの０番の絵にはハートが書かれている。そしてBGTの左上（VRAM）には数字の０が書かれている。
これは左上のハコにCHRの0番を表示しろという意味になるので、左上にはハートが表示される。
つまり――

１）BGTに書き込まれている数字を読み取る。
２）対応するCHRの番号のキャラクタを表示する。

こんな風に間接的にキャラクタが指定されて表示されていたわけだ。
なぜこんなまどろっこしい方法を取ったのかというと、当時、RAMはとんでもないお値段で(１キロバイトが5000円とかした)、この方法なら「ROMに書き込まれているパターンを少ないRAMで表示できる」メリットが圧倒的に大きかったのと、そもそもアーケードがこういう形だったからだ。
ただ、初期のファミコンのゲームでは使えるCHRの数が二つしかなく、グラフィックに非常に厳しい制限が出てしまい、このCHRを書き換え可能なRAMにしてカートリッジに積むなんて騒ぎになり、また圧縮しづらいといったデメリットが大きくなり、このあとの世代になるPCエンジン、メガドライブ、スーパーファミコンではCHRにあたる部分もすべてRAMになっている。
ちなみにこの構造のグラフィックスはPS/サターン/3DO世代でほぼ終了する（似たようなことは出来る）。
というわけで、少々余談も書いたが、画面に表示される実体をコントロールしているのはBGTと理解してほしい。

では、いくつのBGTでファミコンの画面は作られていたのか？
ファミコンの背景画面の解像度は256x240。
８ｘ８ドットの１キャラクタで絵を作るので256/8=32、240/8=30
32*30=960キャラクタ分のBGTで絵が作られていたことになる。
ファミコンのBGTは１キャラクタ＝１バイトだったので、960バイト。

そしてファミコンには２画面分のBGTのRAMとして２KB、すなわち2048バイトが搭載されていた。
2048/2=1024。１画面は1024バイト。
1024-960=64バイト。この余り64バイトをカラーの指定に使う。
カラーの指定は２ビットで４パターンの指定ができ、１バイトは8ビット。
8/2=4。4*64=256。
64バイトで256個分のカラーの指定が出来る。
と書くと「アレ？」となるだろう。
960キャラクタで画面が構成されているのに、色の指定は256個分。どうなっているのか？
答えは簡単で、ファミコンでは色の指定は2×2BGT毎でしか指定できなかった。
32/2=16、30/2=15。16x15=240で、足りるわけだ。
つまりファミコンでは絵は１BGT毎に指定できるが、カラーパターンは２ｘ２BGTでしか指定できなかった。
スーパーマリオもドラクエも2x2BGTサイズで絵を作るわけだ。
そしてハドソンでは、この２ｘ２BGTのことを"CELL"（セル）と表現していたわけだ。



ここで、野沢さんが言っていた言葉に戻る。



右図を参照しながら読んでほしいが、最初の「２ｘ２のキャラクタでファーストcellを構成して」が、ファミコンの２ｘ２単位のカラー指定できるブロックのことを意味している。
そして次の「ファストcellをさらに２ｘ２でセカンドセルをつくって、色アトリビュートつけてセカンドcellを構成し」で、実は『スターソルジャーでは』2x2BGT単位ではなく、4x4BGT単位でデータを扱うようにしているわけだ。4x4の単位でパレットなどを持つことでデータを小さくしていたわけだ。
そして、この２ｘ２セルで出来た2ndセルのラインをランレン圧縮（"RUN LENGTH"の略。同じものが続いたら続いた数＋そのコードにすることで縮める方法。単純なマップならそれでも結構縮む）して、さらにそれに番号をつけ、その番号を並べることでマップを生成する。


ここはわかりにくいと思うので、ちょっと具体的な例を右に用意した。
上の例のライン単位に０番が割り当てられていたとする。
マップのラインを０、０、０、０と指定すると、右図のようなマップが出来上がるという仕掛けだ。
つまりライン番号０番が4回コピーされるので、確かにこれなら、かなり縮むのだけど、これはもうマップ作るととエディタが超大変だったろうなあと思ったのである。

ところで、この圧縮まわりのこの記事を書いているとき、憶測で書くのもなんだなと思って、野沢さんに確認したときのfacebookのログが面白かったので、それもまとめてここに載せておく。



わかる人にはわかる、面白い会話のはずだ。