Geistburg

想定通り、頭が作曲モードに切り替わってBGMの増備をやっているので、ゲーム本体に目に見える進捗はない。


本稿では暇潰しに、ささやかな差異を含みつつもゼビモドキ以来踏襲している拙作における敵キャラクターの管理手法と、関連して、今更気づいたMSXの謎仕様について触れる。MSXのゲームプログラミング自体に関心のない人からすればどうでもいい話になるが、それを言ったらボクの書くことはすべてそうだ。

今日的なビデオゲーム開発においては……ここでいう「今日的な」は、ゲームプログラマは自身でメモリの物理アドレスを意識することがない、の意味になるが……敵、に限らずゲーム上のキャラクタは、そのデータ構造の雛形から登場毎にメモリ上のどこかに生成（コピー）され、必要がなくなれば削除（当該メモリの解放）されるもの、ということになる。

主にプログラマから見て予測不可能なメモリ確保のオーバーヘッドを回避してパフォーマンスを向上させるために、今日においても予め確保済みの枠から必要に応じてキャラクタに割り当てる手法は普通に存在するが、この場合でも通常プログラマはそれがメモリのどこであるかは意識する必要がない。

対して、MSXを含む、プログラマが直接メモリの物理アドレスを管理するゲームプログラミングにおいては、予め一定範囲（このサイズが同時登場キャラクタ数の上限になる）のメモリを確保しておいて、必要に応じてその中から1キャラクタ分のメモリを利用する、といったことをおこなう。

この枠組みの中では、ゲーム中の任意の場面において新たなキャラクタを登場させるに際し、上述の一定範囲（実体として項目×キャラクタ数の表構造になるので、ボクは管理テーブルと呼ぶ、以下同）の中から、現時点で使用されていないアドレスを探し出す、あるいは現時点で上限に達しているのでこれ以上キャラクタの生成は出来ないと判断する処理が必要になる。

常日頃言っているように、これもまたくだらない車輪の再発明に過ぎないのだが、ボク個人の体験としてはドラコニックスロウンの開発に際し確立した方法論を使い回している。一見してドラコニックスロウン、佛陀斬、INQ&SUQは横スクロールシューティングという共通点を除けばまったく異なるゲームだが、実はアセンブラレベルの実装はほとんど共通している。

さて、MSXにおいてキャラクタと言えば何はさておきスプライトなのだが、拙作における敵キャラクタ管理テーブルは、MSXの基本仕様の1つとなるスプライトアトリビュートテーブル（のメインRAM上のコピー）の拡張を基本としている。

スプライトアトリビュートテーブルは、32枚あるスプライトそれぞれについて、その表示位置2バイト、表示パターン番号1バイト、表示色＋付加情報1バイトの計4バイトが順に並んでいる総計128バイトのデータ構造だ。MSXにおいてスプライトを動かす、というのは、VRAM上のスプライトアトリビュートテーブルの位置情報の値を更新することに他ならない。

とりあえず週末の進捗をば。


まだ表示テストの域を出てないけども、とりあえずプレイヤーキャラクタとなるロボットが登場。まぁ、この辺りは予定調和みたいなもんなのでサラッとスルー。

閑話休題。

西和彦氏の以下の発言をMSX Resource Centerで知って以来、いろいろと考えさせられている。

#143 次世代MSXとIoT MSX
2018-08-07

次世代のMSXを開発している。CPUはARMとR800。FPGAの上で何にでもプログラムできるハードウェアでRaspberry Piと同じ大きさの基盤にした。年内に発表したいと思っている。名前は未定。

IoTの分野とMSXとの接点は、ワンチップでMSXと無線通信機能を一体化した5ミリ角のシリコンチップのダイを開発中である。来年の秋ぐらいまでに発表したい。組込用のコントローラーとして。

nishi.org より

MRCフォーラムのこの話題を取り上げているスレッドは、基本的には歓迎ムードで推移しているっぽい。心底楽観主義者というか懲りない奴らというか微笑ましい限りなのだが、ボク個人は、決して西氏に対してなんらかの意趣があったりするワケではないし、上引用が具体的に何を生み出すのか興味がないワケではないが、極めて身勝手な見解であることは承知の上で、今更構わないでよ、というのが正直なところだ。

繰り返すが、以下はボク個人の勝手な嗜好によるもので他者の理解や賛同を求めるものではない。とにかく、ボクは適度に忘れ去られた世界の片隅でゴニョゴニョやるのが好きなゴキブリのような人間なので、そのような意味において住み心地の良い･･････繰り返すがこれはボクの勝手な見解である･･････現在のMSX界隈に、改めて公というか一般大衆的な目線が注がれ、ビジネスやマネタイズの可能性･･････既に小銭稼ぎをやっておいて言うのもアレゲだが･･････が生じることは望まない、というか、ぶっちゃけ迷惑千万なのである。

無論、これが身勝手な主張であることを自覚しないほど阿呆ではないし、むしろ正統な権利は西氏の方にあることは百も承知（個人的にはコレに得心しない欧州勢の一暴れが杞憂とは思いつついささか心配）なので、上に引いたようなことに何か抗おうだとかそういう大それたことを考えているワケではない。

とりあえず今手掛けているゲーム開発は、MSXdevのフリースタイル部門連覇を本気で狙っているので完遂させると思うが、正直なところ西氏の今更MSXが何らかの目に見える成果に至るとは俄かに信じ難いのだが、万が一にも何かが成し遂げられ、その結果として界隈の住み心地が（あくまでもボクにとって）悪くなるようであれば、再びのシフトの時を迎えることになりそうである。

近三作は、特にそれにこだわっていたワケでもないが、いずれも横スクロールシューティングだった。今回は……ここまでにチラ見せしていたグラフィックから既に気づいていた人もいるだろうが……画面奥に向かって進んでいくレイルシューターを作っている。


奥に進むのみならず、同時に左右にも画面が流れるので、MSXの描画能力について詳しい人から見ればインパクトがあるかも知れないが、そんなに大したことをしているワケではない。要するにこれは単なるパラパラ漫画であり、その切り替えに繰り返し述べてきたVRAMのベースアドレス変更を使っている。

やや特殊な点……これとて過去に前例がないワケではないと思うが……を挙げるとすれば、奥方向と横方向で、実はスクロールさせている原理が異なっている。直感的にわかりやすい横方向から先に触れると、これは単純に絵柄（パターンジェネレータテーブル）のパラパラ漫画になっている。対して奥方向の流れは色（カラーテーブル）でまかなわれている。


絵柄のデータの1コマを抜き出して色情報を取り除くと、実は上に示したような縦縞模様になっている。ここではビットが立っているピクセルを白、そうでないピクセルを黒で表示しているが、VDP9938 の GRAPHIC 3（SCREEN 4）では、この絵柄に対して、横8×縦1ピクセル毎にビットの立っているところと立っていないところに色を与えることができる。この色情報が絵柄とは独立した縦方向の縞模様になっていて、これが絵柄の縦縞を交わることで情景動画に見える市松模様を生み出している、という次第だ。


説明するまでもないとは思うが、地面の色情報については、横8×縦1ピクセルに対応する1バイトに色情報のうち、上位4ビットが絵柄でビットが立っているピクセル、下位4ビットが立っていないピクセルのカラーコードに対応している。上掲色パターン左において、暗い緑の行については下位4ビットがそれで上位4ビットが明るい緑になっていて、明るい緑の行はその逆になる。この色情報を前掲の縦縞模様に上被せすると、上掲動画に示したような市松模様が浮かび上がるというワケ。

これが技術的に簡単に実現できることは･･････下拵えが面倒臭いことはともかくとして･･････わかっていて着手したことだから、何も問題はなかったのだが、それでも実際にやってみないとわからないこともあって、VRAM総容量との兼ね合いから、絵柄12パターン、色4パターンが使えるのだが、最初に試作時点では12パターンの絵柄を通常用4種、左右の高速移動用（上掲の縦縞が反った柄）に各4種としていた。ところが、いざこれを動かしてみると縦横ともに4パターンのアニメーションとなることから、縞の遷移が見事に同期してしまって、前後左右どちらに進んでいるようにも見える摩訶不思議なモザイク模様が現出してしまった。

それぞれの速度を調整してみたりしたのだが、パターン周期一致による同期はこれでは如何ともし難いようで、やむなく、ROMイメージのページ0に圧縮収蔵済みだったこの全パターンを作り直す羽目になった。結果、配分は通常用8種、左右高速移動に各2種となった。今度は高速移動分2種がそれっぽく見えなくなるのではないか、との危惧があったのだが、これは案ずるより何とやらで、少なくともボク自身は満足のいく感じ。最終的にはこの背景の上でキャラクタが背景の流れに応じて挙動するので、このパターンの少なさはより気にならなくなる計算である。

ちなみに。

単純に考えると、『スペースハリアー』（セガ・1985年）だとか、MSXで言えば『フィードバック』（テクノソフト・1988年）のようなゲームになることが想定されると思うが、実はちょっと違う。まぁ、それについては追々。

大した進捗でもないのだけれど。

無印MSX用のゲームだと、ブート直後の初期化では多くても14〜15KBくらいをVRAMに流し込むだけなのでこういうことは考えないのだが、流石に今回はこの8倍のデータを一気にVRAMに流し込むので、ゲーム開始を待たされる、ほどのものではないが、やはり初期化終了にはそれなりに時間がかかる。

で、この間、画面が真っ黒というのは味気ないし、ユーザー側から見れば「ホントに動いてるのか？」と不安に感じる一瞬なので、ページ0に若干残った余裕を使ってプログレスバーもどきを実装しておくことにした。


上掲動画はopenMSXで録ったものだが、本作が晴れてROMカートリッジ化された暁には……流石に自分でやる気はないので、その筋の連中が釣れれば、の他力本願の話なのだが…カートリッジを挿してMSXをブートすると、一瞬このプログレスバーが表示された後、タイトル画面へと遷移することになる。今のところ、その先の実装がまだないので、そのままサービスメニューに遷移している。

ついでに上掲動画には、現時点で完成しているBGM3曲のさわりを収録しておいた。拙Weblogの熱心な読者ならばお気づきかも知れないが、一時期取り憑かれたように作っていたFSX動画のBGMからの流用になる。もっとも、原曲は事実上同時発音数に制約のないソフトウェアシンセサイザー向けに書いたモノで、かたやこちらはPSG2チャンネル＋ノイズ1チャンネルだから、かなりテイストは異なる。自分ではよく出来た、と自惚れているのだが、こればかりは好みもあろう。

元はページ0にグラフィックデータと合わせてこれらのBGMデータを収蔵するつもりだったのだが、それほどの隙間は残らなかったこと、加えて、ちょっと欲が出て必要以上にBGMデータに凝ってしまったことにより、容量の消費が想定よりもやや早い。とは言え、それを理由にBGMを削るつもりはさらさらない……余人に理解も納得もされないと思うが、ボクのゲーム開発において最も重要な要素はBGMなのである……ので、長くペンディングしてきたBGM/SEドライバへの（限定的な）区間リピート機能を実装した。音楽的に汎用性の高いものでは決してないのだが、結果的に1,200バイトほどBGMデータを節約できた。

そろそろ見た目にわかりやすい、つまり、動作するゲームの動画的な開発進捗もお見せできようかと思うが、容量節約の目処が立ったので気分でBGMの増備に進むかも知れない。