CALENDAR
S M T W T F S
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
<<  2021 - 04  >>

PROFILE
同人誌 電子書籍版
Re:ゼロから始める
ゲームシナリオ


ライトニング伝説


さよならハドソン


ドラクエとFFと
ToHeart


誰得ゲームライフ


ときめきメモリアル
の時代

イースI・II製作メモ

頒布ページ
LINKS
NEW ENTRIES
CATEGORIES
COMMENTS
    イースⅠ・Ⅱ通史(3):『リグラス』から『ロマンシア』
  • タムロ (02/03)
    イースⅠ・Ⅱ通史(1):PC88MkⅡSRの発売
  • tamuro (01/05)
  • おお! (01/03)
TRACBACKS
OTHERS
SEARCH BOX
POWERED BY
POWERED BY
ぶろぐん
DESIGN BY
ブログンサポート

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

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

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

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



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

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

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

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

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

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


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

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

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

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


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

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


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


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

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

■僕
野沢 さん、ちょっとスタソルで確認ナンスが(もうすぐ3回目w)!

1)あれは横にスクロールするから、BGは横2画面モードっすよね?

2)ファーストCELL*4で、2ndセル作って、2ndセルでまとめてライン作るのはわかったけど、このラインにいわば「ライン<キャラクタ>インデックス」がつけてあって、そのインデックスを並べてマップを作ったって理解でいいすよね?
例えばオール空白の<ライン>インデックスが0番だったら、実際のマップは0000と並べてあったってことですよね? つーか、当時なら、あっしならそう作るんだけどなって確認w

A)マップのポインタから、ラインインデックスを取る。
B)ラインインデックスから、ラインを取り、ランレンを展開して2ndセルを得る。
C)2ndセルから、実際のセルを生成。
D)描画

と、こーいうことっすよね?

3)2ndセルにカラーつけてたと書いてあったけど、これは2ndセルに2x4=8ビットで、カラーパレットが突っ込んであったってこと?

■野沢さん
1)については岩崎氏が思っている通りで、ちょっとでも横スクロールするものは横2画面が基本。
縦2画面だと横スクロールの際に書き換えが発生し、しかも書き換えが分かってしまうケースがおおい。当然8ドットで書き変えればオーバースキャンで見えないんだが、わざわざオーバースキャンなしのモードで見る人もいるんでやっぱり駄目ですね。 また、色は16ドット毎にパレットが変わるので、かなりの確率で書き換えが見えてしまうので、これもあるかな。

2)はその通りですね。まあ、セカンドセルに8ビットのパレットが付いてくる。 4x4キャラで8bitね。2x2で2bitなのでx4で8bitです。パレット少なすぎだよな~。PCエンジンは天国だったなー。
面倒なのは描画。なんせV-Blankで書き込み制限が存在するんで、先に説明したとおり。で、展開した描画データを、ライトキューにアドレス+書き込みバイト数+書き込みデータアドレスでエントリーして、次のV-Blankで書き込むわけです。しかも、時間制限ありですけどね。
ちなみに、縦+横のスクロール値もV-Blankの頭で毎回更新する事になります。 ぶっちゃけ1フレーム遅れて更新ですが、スプライトもBGも同じなんで気にしない。

結局のところ、一番活躍したのはコースエディターで、実機で動作していたが、ランレン圧縮はすいだした後、CP/Mのプログラムで圧縮してたのをアセンブラテキストでラベル付けて吐き出してた。
既に知っている通りですが、コースエディターは実機でしか動いていなかった。この当時CEとかDFとかが有ればどんなに楽だったか。
ちなみに隠れキャラや当たるキャラの判定セルはファーストセルで2x2キャラ単位でファーストセル番号で判定していたはず。
コース裏行きセルや表に出るセルも一緒。セル番号で判定ですね。

■僕
アリー!
疑問に思ってたところ+アルファがわかったw
書き込み量の制限、それも厳しいのに展開しないといかんから、これきついよなあと思ってたら、やっぱキツイか!wwww

■飛田さん
VBlankは時間制限があるから、なるべく沢山処理したいので余計な事はしないようにしてましたね。
展開処理はメインで行ってパレットのアトリビュート変更はビット演算が必要なのでメインメモリにコピーを置いて、そこで演算した結果をQueに登録するような事してました。
アトリビュートのコピーの128バイト?はスタック領域の後ろを使ってました。

■僕
ヒイwwwww


わかる人にはわかる、面白い会話のはずだ。
|| 08:47 | comments (3) | trackback (0) | ||

このエントリーをはてなブックマークに追加

コメント
まあWikipediaの怪しげな記述も、自分が分かってて
無視するのは簡単でしょうけどね〜
それで世の中に嘘が真実のように刷り込まれていく事を考えると、
何かしらの形で反論を残すのも大事だと思います。
| 通りすがり | EMAIL | URL | 16/11/04 20:51 | MO43AqjQ |
日本人は自称xx通が余計なエピソード等をやたら書き足したがる傾向にありますから、そういうところは最初から信憑性に欠けるものとして読むか無視すればいいんですよ
憤慨する気持ちもわかりますけどね
| J | EMAIL | URL | 16/10/24 00:32 | 8TDUaX1Q |
地面に潜るアイデアも含め、幾つかのアイデアはコロコロ誌上で募ったものが採用されたように記憶しています。間違っていたらすいません…
| ヘクター17 | EMAIL | URL | 16/10/22 15:23 | omLFlYcc |
この記事のトラックバックURL :
トラックバック