Meteorite KISSちょっと詳細(1)

@製作途中版配布@MSXセクション@鈴見咲サイト

平成一二年四月一七日

まったく無反応だったらどーしよー、とか思ってたが見てる人は見てくれていたので(^^;何か書いてみます。もっとも現状でおおっぴらに公開すべきかどうか?というのもあるんだけどさ。

現物をみてもらえればわかるとおり、やってることは必ずしも複雑怪奇ではないです。が、これだけのことをそれなりに納得の行く処理速度でできるかどうかというのが結構考えどころです。

画像は掲示板でも回答したとおりの SCREEN 4 。
同モードで横方向ドット単位スクロールが可能なことはいくつかの市販ソフトや同人ソフトなどでも示されているとおりです。ただ、「横方向強制スクロール+縦方向2画面任意スクロール」というのを縦横ともドット単位でやったのは多分 Meteorite KISS が最初なんではないかと思います。

MSXではscreen4に限らずハードウェアで縦256ライン以外のスクロールをさせることは不可能ですから、そこは頑張ってソフトウェアでまかなうことになります。縦に強制で横に任意というのなら2+のscreen5とかで可能ですが、やりたかったのはMSX以外のグラディウスではたいてい実現されているあの感覚だったので、縦横を反すわけにはいきません。

さて、実際の方法ですが、4×4文字(32×32ドット)を一チップとして、「各チップの内容そのもの」と「チップの配置データ」の二つを用意します。チップ定義数は最大256個、配置データは最大128×16チップで結果として512×64文字=4096×512ドット=16×2画面が構成されることになります。前者が4KB、後者が2KBになりますね。これをVRAMに配置しておきます。

これをゲーム進行に合わせてメインRAMに展開していきます。最低で32×64文字分のワークが必要となります。64の方が縦です。縦方向に任意に動かさなくてはならないので。

さらにこれを背景処理一回毎に(!)、いったん別のメインRAMに転送します。これは32×25文字、つまり実際に見えている分だけでOKなわけです。

その後、文字で表現されたキャラクタ(といっても配布版では入り口とかをふさいでいる柱だけですが)と流れる星を重ね書きしてその後でやっとVRAMに転送します。
320HバイトのメインRAM→メインRAM→VRAMの転送が毎回行われるわけで…当然重いです。

読む方も疲れるだろうから細かいところは以下次号。
にょきっとでてくるアイツは一次展開されたほうのデータをいじっているのだ。


@製作途中版配布@トンベイ参加情報@MSXセクション@鈴見咲サイト鈴見咲ホームページへ
Copyright (C) 2000 Suzumizaki-kimitaka
メールはこちらまで( suzumizaki@excite.co.jp / suzumizaki@geocities.co.jp ) / 感想フォーム+掲示板入り口