2020･6･28追記
野沢さんが覚えていた、ここで書かれている圧縮は同じ年の年末に発売された『ドラえもん』のマップの圧縮法で『スターソルジャー』は違った、という話を野沢さんに白状された。それで『スターソルジャー』の方は、野沢さんが自分でROMをディスアセンブルして確認した話があるので、近いうちにその記事を掲載しておきたい。

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

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

ところでwikipediaに書かれている『スーパースターフォース』の話の顛末は全く信じられないことを、前回、野沢さんの話をひいて載せたところ、いつの間にやら削除されていた。

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

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

■野沢さん
どうも、おまけでもう一丁。
当時はグラフィックエディターがまともな物がなくて実機でやってたが、それ以上に参ったのがコース。
ROM容量の制限がきつくて、圧縮なしには入らない感じですかね。で、どうやって圧縮するかで頭抱えたよ。
まあ、２ｘ２のキャラクタでファーストcellを構成して、ファストcellをさらに２ｘ２でセカンドセルをつくって、色アトリビュートつけてセカンドcellを構成し、それを並べてコースの横ラインを構成してランレン圧縮、その横いっぱいのコースラインにライン番号つけて、そのラインを並べてコースにする。
これで、結構縮まった。問題はコースが単調になりやすい事。　これは山本さんが職人ゲーでうまくごまかしてくれた。
ちなみにこのためだけに、圧縮プログラムは自分で作った。
しかも、メモリーダンプでコースデータをデバッガで吸い上げて、これをプログラムでも処理なんで、面倒なこと面倒なこと、でもこのおかげでうまく圧縮できた。
こんな処理のあと、テストプレイで地面に潜れとか言われて、出来るかと思ったよ。
（社長の鶴の一声でついた）
ファーストセルに特殊セルを追加、潜るセルと浮き上がるセル追加後、セカンドセルを更に追加、コースのどこがいいか検討しつつ、コースを編集、とりあえずテストプレイ。　まいい感じに仕上がったので良しとしました。
今思えば、よく短時間で追加したものだと自分でも感心する。プログラムは単純で自分の下のセルを確認し、表示フラグとあたりフラグの変更だけなんで、まあ速攻でした。

これについてはファミコンのBGの制約を知っていて、かつハドソン用語（だと思う）CELL（セル）を知らないとさっぱりわからない話なので、以下に一つずつ説明していく。
ファミコンの画面は背景画面（BG)＋スプライトでできてのだけど、今回の話はBGがキーなので、BGについて書いていく。

BGはどのような構造なのか？　BGは２つのパーツから出来上がっている。

１つがキャラクタジェネレータ、通称キャラジェネ（パターンジェネレータという呼び方もあった）。
キャラジェネは8×8ドットのキャラクタが256個で一組（１バンクとか１セットとか呼び方はイロイロ）になっているのが普通だった。
なぜ256個なのかというと0-255が8ビットで扱える範囲だからだ。80年代後半のPCエンジン、メガドライブ世代になると一つの画面に対して複数のBGが使えるようなるのだけど、それでも１セットは256個という制限があった。
キャラジェネって単語は長いので、以下ではCHRと略したい。

実際のCHRは当時のマシンではたいてい下図のような8×8ドットのピクセルデータだった。ここではサンプルとしてＡを描いている。１ドット空白を開けているのは、そうしないとつながって見づらくなるからだ。8×8ドットなのにも意味があるが、今回はパス。

そしてもう一つ、名前があちこちで違うので困るのだけど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と理解してほしい。

余談を書くと、PCエンジンでは１BGT単位でカラーコードが定義できるし、複数のCHRを一つのBGTに対して使うこともできる。つまり原理としては”CELL”を使う必要がなかったにも関わらず、和泉さんが作ったPC98上で動くグラフィックエディタDFではキャラ４つを集めて１ブロックの”CELL”として扱うのが標準的なマップモードになっていた（そして初めてPCエンジンの開発に携わったとき、なぜそうなっているのかわからなかった）。
ただ、これには合理的な理由はあったと思っている。
まず第一にDFにはファミコンモードがあったので、ファミコンモードとの互換を考えればそっちの方が便利だ。それにセルを単位にしてマップを作るとほぼ同じメモリ量で４倍のサイズのマップを作れるので、そうしたのだろうと思っている。
ところで、そもそものDFにはセルモードしかなかったのだけど『イース』のマップはもちろんこんなセルみたいな形では作られていない（１BGT単位で作られている）。
なのでPCエンジン版を作るときに、和泉さんに頼んで改造版のイースみたいなPCゲームの移植用の専用DFを作ってもらった。
で、イロイロ改造してもらっていたら、そのうち面倒くさくなったらしく、ソース丸ごとくれて「好きにしてよ」。
おおらかな時代だったと思うよ。

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

まあ、２ｘ２のキャラクタでファーストcellを構成して、ファストcellをさらに２ｘ２でセカンドセルをつくって、色アトリビュートつけてセカンドcellを構成し、それを並べてコースの横ラインを構成してランレン圧縮、その横いっぱいのコースラインにライン番号つけて、そのラインを並べてコースにする。

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

ここはわかりにくいと思うので、ちょっと具体的な例を下に用意した。

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

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

■僕
野沢 さん、ちょっとスタソルで確認ナンスが（もうすぐ３回目ｗ）！
１）あれは横にスクロールするから、BGは横２画面モードっすよね？
２）ファーストCELL*4で、2ndセル作って、2ndセルでまとめてライン作るのはわかったけど、このラインにいわば「ライン＜キャラクタ＞インデックス」がつけてあって、そのインデックスを並べてマップを作ったって理解でいいすよね？
例えばオール空白の＜ライン＞インデックスが０番だったら、実際のマップは００００と並べてあったってことですよね？　つーか、当時なら、あっしならそう作るんだけどなって確認ｗ
Ａ）マップのポインタから、ラインインデックスを取る。
Ｂ）ラインインデックスから、ラインを取り、ランレンを展開して2ndセルを得る。
Ｃ）2ndセルから、実際のセルを生成。
Ｄ）描画
と、こーいうことっすよね？
３）2ndセルにカラーつけてたと書いてあったけど、これは2ndセルに2×4＝８ビットで、カラーパレットが突っ込んであったってこと？
■野沢さん
１）については岩崎氏が思っている通りで、ちょっとでも横スクロールするものは横2画面が基本。
縦2画面だと横スクロールの際に書き換えが発生し、しかも書き換えが分かってしまうケースがおおい。当然8ドットで書き変えればオーバースキャンで見えないんだが、わざわざオーバースキャンなしのモードで見る人もいるんでやっぱり駄目ですね。 また、色は16ドット毎にパレットが変わるので、かなりの確率で書き換えが見えてしまうので、これもあるかな。
２）はその通りですね。まあ、セカンドセルに8ビットのパレットが付いてくる。 ４ｘ４キャラで8bitね。２ｘ２で2bitなのでｘ４で8bitです。パレット少なすぎだよな～。PCエンジンは天国だったなー。
面倒なのは描画。なんせV-Blankで書き込み制限が存在するんで、先に説明したとおり。で、展開した描画データを、ライトキューにアドレス＋書き込みバイト数＋書き込みデータアドレスでエントリーして、次のV-Blankで書き込むわけです。しかも、時間制限ありですけどね。
ちなみに、縦＋横のスクロール値もV-Blankの頭で毎回更新する事になります。 ぶっちゃけ1フレーム遅れて更新ですが、スプライトもBGも同じなんで気にしない。
結局のところ、一番活躍したのはコースエディターで、実機で動作していたが、ランレン圧縮はすいだした後、CP/Mのプログラムで圧縮してたのをアセンブラテキストでラベル付けて吐き出してた。
既に知っている通りですが、コースエディターは実機でしか動いていなかった。この当時CEとかDFとかが有ればどんなに楽だったか。
ちなみに隠れキャラや当たるキャラの判定セルはファーストセルで2×2キャラ単位でファーストセル番号で判定していたはず。
コース裏行きセルや表に出るセルも一緒。セル番号で判定ですね。
■僕
アリー！
疑問に思ってたところ＋アルファがわかったｗ
書き込み量の制限、それも厳しいのに展開しないといかんから、これきついよなあと思ってたら、やっぱキツイか！ｗｗｗｗ
■飛田さん
VBlankは時間制限があるから、なるべく沢山処理したいので余計な事はしないようにしてましたね。
展開処理はメインで行ってパレットのアトリビュート変更はビット演算が必要なのでメインメモリにコピーを置いて、そこで演算した結果をQueに登録するような事してました。
アトリビュートのコピーの128バイト？はスタック領域の後ろを使ってました。
■僕
ヒイｗｗｗｗｗ

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

Tweet

Pocket