2017/10/23 | 投稿者: ghost

前々作前作は、画面がスクロールするゲームではあるものの、単純な垂直/水平スクロールで画面の動きにダイナミズムはなかった。

で、今回はちょっと変わった効果を有する背景スクロールをやってみよう、と試作してみたのだが、やたらと手間がかかったわりには微妙な仕上がりである。


画面の上下それぞれに、水平方向のスクロール速度が三段階に異なる帯を設け、この帯の幅を切り替えることで擬似的に奥行きを見せようと試みたものである。上掲デモでは背景のみを表示しているが、主人公キャラクタの垂直方向の移動に応じて背景も変化し、カメラ位置もまた上下に動いているような効果……のつもり……になる予定だ。こればかりは実際にキャラクタを重ねて動かしてみないと、作っている本人も含めて、そういう風に見えるかどうか、まだよくわからない。


<再掲:主人公キャラクタのモックアップ>

この背景スクロールの基本的な原理は、こちらの拙稿で解説したものと同じだが、ドラコニックスロウンではスクロールする領域が限定的だったこともあって、ゲーム中にVRAM上のパターンを逐次書き換えていた。が今回は、前述のスクロールする帯幅の変化の都合上、結局画面のほぼ全体の表示パターンを書き換えることになるので、ゲーム中の処理負荷を下げるべく、事前に最小1ピクセルずつズレたパターンを定義しておいて、これを画面上で次々に置き換えることでスクロールを実現している。

このパターンの置き換えはPCGで表現される敵キャラクタを含むフレームバッファのVRAMへの転送を兼ねており、1フレーム(PALで3/50秒)毎に640バイトの書き込みを生じさせることになる。MSXとしては決して安いコストではないが、さりとて無理のあるものでもない。最終的にはここにVSYNC毎のスプライトローテータが加わって、768バイト/フレームがVRAMに対する書き込みの最大値になるのだが、スクロールする領域を画面内に縦型にとっていたがためにVRAMへの書き込みが細かく分割されていたゼビモドキに比較すれば、直線的なアクセスが最大4回あるのみに最適化してあるので、パフォーマンス的な問題は起こらない……はずである。

ちなみに、上掲デモ動画ではスクロールする背景画像にチラつきが見えると思うが、これは現時点ではVBLANKに対する考慮を何もおこなっていないからである。VBLANKというのは、VDPがVRAMを読み出して画面を描画する処理の隙間の時間ことで、絶対にそうでなければならないということはないが、VRAMへの一定量以上のデータ転送は、VBLANKの間におこなった方がよい、ということになっている。これを無視して勝手なタイミングにこれをおこなうと(上掲動画がそれ)VDPが画面を描画すべくVRAMを読んでいる最中にプログラムがその部分にデータを次々と書き込む、ということが起こり、結果的に上に例示したような不規則なチラつきが発生する。まぁ、これは今後いろんな処理を追加していく過程で自然に収束していく予定になっている。

ここに至るまでは、結構面倒臭いことがたくさんあった。やることは単純なのだが、それを実現するロジックは必ずしも単純ではないのだ。いや、ロジック自体は単純なことの積み重ねでしかないのだが、その積み重ねの段数がやたらと多い。で、そういう意味で労が多かったわりには、動かしてみると存外地味なのである。ま、とりあえず今日のところはそんな感じ。
タグ: MSX Z80




AutoPage最新お知らせ