動くゼビモドキ(仮称)

2017/1/24 | 投稿者: ghost

このままだと“ゼビモドキ”がゲーム名として既成事実化してしまいそうだが、そういうつもりはない。そのうち洒落た名前が思いつくこともあろう。それはともかくとして、とりあえずデモ的にコア部分が動くようになったので動画を撮ってみた。


現時点で動作しているのは自機の登場と操作、および背景のスクロールまで。前稿で触れたフレームレートについては、とりあえず現時点では20fpsで動作させている。処理速度的には十二分に余裕があるようなので、以降大きな問題が生じなければこのまま行きそう。背景スクロールは暫定的に3.3回/秒(18/60秒毎)。これは現在着手中の浮遊要塞重ね合わせ処理との兼ね合いで要調整だろう。

本家ゼビウスでは、背景画像は大きな一枚絵からエリア毎に細長い短冊状の部分を切り出して流していて、各エリアの地形は一意に決まっている。ゼビモドキではゼビウスの全体マップに相当するような絵を保持するメモリ的な余裕がないので、背景はランダムに生成している。

具体的には、6パターンの192✕32ピクセルの背景を事前に用意していて、32ピクセル分スクロールする(8ピクセル毎にガタガタスクロールなので、その4回に相当)毎に、6パターンのどれかをランダムに選ぶ、という方法を採っている。ただ、これだと単調に過ぎるので、実際には横幅192ピクセルのうちの128ピクセルのみを表示に使用し、この切り出し位置をやはりランダムに左右に揺らすことで変化をつけている。これは、上掲デモでは海岸線が画面内で左右に移動する演出に対応している。

ちなみに、動画の33秒以降、戦闘機が登場してからあらぬ正方形が画面内をうろうろしているように見えるかとおもうが、これはバグではなく、MSXシステムレベルではこの時点で既に任意のコマンド入力を受け付けるBASICのダイレクトモードに復帰していて、戦闘機へのカーソル操作入力と同時にBASICのカーソルも画面内を動き回っているからである。つまり、ゼビモドキはBGM/SEドライバと同じレベルで動作するプログラムとして書かれている。56秒目に至って画面右下に「A=USR2(0)」と打ち込んでいるが、これはBASICインタプリタのタイマー割り込みルーチンに食い込んでいるゼビモドキの処理の切り離しを命じているものに当たる。

極端な話、ゼビモドキを動かしながら、BASICのプログラムを入力したり実行したりすることもできる。そんなことをして何の意味があるのか、と問えば、特に実用的な価値はないのであるが、少なくとも今後本格化していくゼビモドキ自身のデバッグの役には立つ。動作が怪しいときに、任意の調査プログラムを書いて、ゼビモドキを動作させながらのテストができるからだ。あ、無理に理解しようとしてくれなくていい。これは技術、というよりは病気の類の所業なので。

もう1つ、昔から一度やってみようと思っていたMSX(厳密にはVDP、TMS9918)の変態的な仕様を逆用したちょっとした演出を組み込んでみた。


MSXでGRAPHIC2と呼ばれている画面モードがそれなのだが、このモードでは256✕192ピクセルの画面が、8✕8ピクセルのパターン768個を敷き詰めることで表現されている。これは、1つのパターンを文字と解釈すれば、画面上に768文字表示することができるのと等価であり、ここまでの話であれば決して突飛な仕様ではない。GRAPHIC2が変態的なのは、この768種のパターンを8ビット処理系に収めるために画面を256✕64ピクセル毎に上・中・下に三分割している点である。

8ビットは10進法で書けば0〜255、256種の値を取り得る処理系である。この系内において768種のパターンを扱おうとすると、8ビット=1バイトに収まりきらず、少なくとも10ビットの情報量を必要としてしまう。TMS9918はこれを回避するために、画面の上部・中部・下部それぞれ対して256パターンを分割して割り当てる実装をとった。これは何を言っているかというと、画面上部においてたとえばパターン8番が示す図柄と、画面中部のパターン8番の図柄は、実際には異なる場所に記録されていて、同じ8番であっても図柄が同じにならない、という意味である。

ゼビモドキでは、この画面モードにおいてこのパターン配置情報を画面下方向へ向けて1個ずらすことで背景をスクロールさせている。スクロールが8ピクセル毎のガタガタになるのは、直接的にはここに由来する。前述したように、このスクロールするパターンが画面上部から中部、あるいは中部から下部へと画面三分の一の分割線を跨ぐ際、同じ図柄になるとは限らない。が、これでは実用上困るので、この画面モードでゼビモドキのようなスクロールゲームを作る場合、上・中・下部用の図柄情報として、同じものを3つコピーして使うのが定石になっているのだが、これはその方が都合が良いからやることであって、そうでなければならないワケではない。

ここにこの奇っ怪な仕様を逆用する隙が生じるのであるが、ゼビモドキのように上空から見下ろした光景を画面上に表現している場合、もしこの景色の中に画面手前に向かって(仮想的な)高さを有した塔状の物体が存在するとしたら、その見え方は画面上部・中部・下部で異なってくるはずである。具体的には、画面中部にあるときは、塔の屋根部分のみが見えることになろうが、画面上部にあるときは屋根に加えて塔の側面が画面下方向に見えるはずであり、画面下部にあるときはその逆になる。もちろん、そうしなければならないのではなくて、そのように描いてやれば、まるでここで言ったような塔が本来的に有しているであろう立体感を、見るものに錯覚させることができる、という話である。

というワケで、ここで改めて上掲ゼビモドキの動作動画を見ていただければ、と思うのであるが、砂浜や森といった自然物からなる背景のところどころに、灰色の人工物らしき何かが描かれていることにお気づきいただけるのではないかと思う。これに注目すると、画面上から下へ至る途中で、二度その姿が変化している。これが、上に書いたちょっとした演出、の結果であることは言うまでもない。

ちなみに、このテスト結果を受けて、テスト版のこの塔(?)の絵では説得力に欠くことに気づいたので、現時点ではもう一回り大きくしてよりわかりやすいものにデータを差し替えた。後日公開する動画にはそれが反映されていることだろう。

今日的な計算能力有り余るコンピューティングの観点からすれば、取るに足りない話ではあるのだ。各種の3Dライブラリを使えば、こんな演出はプログラマの意識にすら上らず当たり前のように処理されてしまう。が、80年代のコンピュータにあって、事前にパターンの準備さえしておけば、画面全体であってすら768バイトの転送処理だけでこの演出が可能だった、というのは特筆しておくべきだろう。同じことをビットマップ方式を採用していた当時の他のパソコンでやろうとすると、かなりの労力を要するのであるから。

念の為に補足しておきたいが、もちろん、これはボクが思いついたテクニックでは決してない。ボクがこの演出が可能であることに気づいたのは、コナミの『F1スピリット』というMSX用レーシングゲームを遊んだときまで遡る。確証はないが、多くのMSXプログラマが同じようなことを言っているので、同作がこの技法の初出ではないか、と思う。リンク先は同作の動画であるが、レース開始直後、“DUNLOP”だの“CABIN”と描かれたコース脇の看板に注目してみて欲しい。極めて地味な演出ではあるが、画面の上部、中部、下部にあるときに看板の形状が微妙に変化していることがおわかりいただけるだろうか。

ところで、30年前に発売されたゲームに今更ツッコむのも無粋な話ではあるが、どうしたことか“Marlboro”と書かれたコース上のゲートは、技術的には可能であるにもかかわらずこの演出から漏れていて、画面下部に流れた時点でも向かって下方向が開口してしまっているのはご愛嬌、と言うべきか。

閑話休題。この演出は、微妙に過ぎて、これにまったく気付かなかった当時のプレイヤーも少なくはなかった、と思う。というか、こうしてこのどうでもいい話を改めて書いているのも、このように書いてでもおかないと、ゼビモドキに対して同じ演出を仕込んだことを、他ならぬボク自身が忘れそうに思ったからである。何じゃそりゃ。
タグ: MSX Z80



コメントを書く

名前
メールアドレス
コメント本文(1000文字まで)
URL





AutoPage最新お知らせ