Geistburg

元ネタがアレであることを思えばこうなって至極当然ではあるのだけれども、同時に、少なからず驚きを以て迎えられると確信しているデモ動画を撮った。


多重スクロールする画面が主人公のジャンプ挙動に合わせて縦にも動く、という、MSXのみならず、同世代のレトロPC向けゲームとしては極めて珍しい実装を試みてみた。それがわかる人には縦方向の動きが印象的に過ぎて、どこかで聴いたようだが混ぜるな危険なBGMや遅れて右から出てくる主人公よりさらにデカい僧兵風のオッサン……我ながら白々しい物言いだ……が返ってインパクト失ってるかも。

と言うか、今になって自分で気づいたのだが、どうもボクはこういうの……画面全体がダイナミックに動くが、実は技術的には大したコトはやっていなくて、でも一見してそれがわからない……をするのが好きなのだ。佛陀斬の背景スクロール、Shoulder Blade OVERDRIVEのやはり縦にも動く奥向きスクロール、Shoulder Blade OUTERSPACEの視点移動、全部同じ発想である。逆に言えば、固定画面（スクロールの有無は直接は関係がない）でチマチマと小さなキャラクタが動くのは、まぁ自分でもそういうのを少なからず作っておいてアレゲだが、好みではない。

まぁそんなことはどうでもいい。

もちろんボクは嬉しがりなので、コレをどうやって実現しているか、について書き遺すのである、と言うか書きたいのである、と言うかこういうのを書きたくて技術的にはくだらないが際限なく面倒臭いことをやっているのである。

閑話休題（まぁそんなことはどうでもいい、の別の言い）。

上掲動画を見て何が起こっているのか、一発でわかった人は以降は読むに及ばない。また、たちまちにわからなくても、「画面が縦にも動いている」という先入観をちょっと脇へ置いて、よくよく冷静に今一度動画を見てみると、ダイナミックに全体が動いているようではあるが、実は主人公のジャンプに合わせて前景と敵キャラクタがたかだか6ピクセル動いているだけだ、ということに気がつけば、何をやっているかは想像がつくだろう。

で、以下ネタバレ。

開発着手したコレの画面をどうやって作っているか、という話をする。もちろん、誰かの参考になることを願って、ではなく、こうして書いておかないと、いつも言っていることであるが他ならぬボク自身が何をやったか忘れるから、である。っつーか、ボク以外の人がこういう面倒臭いことを敢えてするとは思えない。

MSXに詳しい人であれば、本作がTMS9918のMULTI COLORモード、MSX BASICでいうところのSCREEN 3であることは一目瞭然だろう。このモードはデフォルトのVRAMの構成に難があってアクションゲームには使い難いが、ちょっと一工夫することで後述する制約がありつつも、使えなくはないことは以前書いた。

かくして、1フレームにつき64÷2×48＝1,536バイト、VRAM上のパターンジェネレータテーブルに然るべきデータを書き込めば、メモリ構造と画面表示の関係が90度捻られていることを除けば、普通のゲームプログラミングの手法で任意の図柄を表示することができる体制は整った。ここで“任意の図柄”と言っているのは、無印MSXのゲーム開発で常々問題になる「8ドット中2色」の制約がここにはない、ということである。文字通り“マルチカラー”なのである（なのだろうか？


その代わり、色制約とは違う他の制約が、当然のことながらいろいろとある。

・言わずもがなだが、画面解像度が64×48ピクセルしかない。平たく言えば絵がめっちゃ粗くなる。
・バイト単位のコピーを前提とした場合、縦方向は1ピクセル単位の操作が可能だが、横方向は2ピクセル単位が基本になる（MSX2 GRAPHIC4におけるVDPコマンドHMMCに課せられた制約と本質的に同じ）。
・1フレーム1,536バイトは結構重い。

画面解像度は、つきつめればどう使うかのセンス次第であり、本作については自分では何とかなっている、と勝手に思っているのだが、これは人それぞれの好みにもよるだろうから深入りはしない。

横方向2ピクセル単位、はゲームプラットフォームとしてはなかなか深刻な問題なのだが、まぁ同じVDPでやることだから当たり前と言えば当たり前なのだが、よくよく考えてみれば、マルチカラーモードにおける2ピクセルは他モードの8ドット＝1 PCGキャラクタなのであって、これはたとえばShoulder Bladeシリーズのボスキャラと同じになるが、キャラクタの動きが横方向に限ってそれになる、というだけの話ではあるのだ。まぁ、これも使い方のセンス次第だろう。

ちなみに、前稿に示した動作デモ動画において、二重スクロールする奥側の背景は横方向に1ピクセル単位で動いているように見える。これは、圧縮状態でROMのページ0に収蔵してある背景データをRAMに展開する際、元絵の他に横方向へ4ビットシフトしたものをもう1枚生成しておいて、1フレーム毎に交互にこれをフレームバッファへコピーすることで実現している。

背景以外の図柄についても同じことをしてはならない法はないが、そんなことをしていたらメモリがいくらあっても足りないので、今のところはそこまでするつもりはない。同じ動画の手前側前景（登場人物をときどき隠している竹）は2ピクセル単位で動いているのだが、奥手がピクセル単位で動いているのとの速度差もあって、さほどその粗さは気にならないのではないか、と個人的には勝手に思っている。


で、本稿本題は、全画面書き換えのコストとしては破格に少ない、とは言え、MSXのハードウェア性能からすれば十分に大きい1,536バイトのVRAM転送をどうしたか、という話になるのであるが。

久しぶりに裏山を歩いたらこの子に出会った。


この時期のウグイスは、山中であれば上掲写真のように笹の藪、街中であればボックスウッドや生け垣の中で、ひたすらヂッ、ヂッと地鳴きしながら虫を食んでいることが多い。この子たちもバカではないので、一葉撮らんと近づくとだんまりを決め込むのだが、こちらがしばし気配を殺すとまたぞろ地鳴きを始める。

これを頼りに大まかな位置に当たりをつけて待つことしばし、ひょこっと様子を覗いに顔を出したところを捉えたのがコレ、ということになる。尻を隠して頭隠さず、いや、それじゃ逆か。


もう一羽そばにいて、互いに特に牽制もしていなかったから多分番いなのだろう。丁度いい感じに日差しの下に出て来てくれたので、動画も撮ってみた。


この季節は紅葉エナガちゃんを狙うのが恒例なのだが、かすかに気配はあったものの今日は巡り会えず終い。諸事情でしばらく山歩きできないので今年は駄目かも。