Geistburg

いつにも増してどうでもいい話をする。特にオチはない。


まず上掲動画について。Shoulder Blade OVERDRIVEの最終調整の中で各AREAの配色を見直したのだが、その際、次AREAへ移る際に背景色が一気に変わるのが唐突に過ぎる感があったので、グラデーション的に滑らかに色が遷移する実装を追加してみたのだが、そのデモである。念頭にあったのは往年の疑似3Dの名作“After Burner”（1987年,セガ）のステージ間遷移であることは言うまでもない。

と言っても、AREA3〜AREA7については、各AREA間の背景色が大きく変わるのでこの実装が意味をなしているが、それ以外についてはRGB各要素についての変移がないか、あっても1……のワリにはかなり色味が変わるので結局唐突感はあるのだが……この実装の効果は特にないのだが。

それはともかくとして。

この実装をしながら、何を今更「MSX2のパレット操作回りの実装って何でこうなんだろう？」という疑問が浮かんだのだが、まぁ、特に答えはないし答えがわかったら何だということもないのだが、とりあえず疑問に思ったことは忘れないように備忘しておこう、というのが本稿の主旨である。MSX2以降でパレット操作をおこなうアセンブラプログラミングをおこなう人……なんて、いまどきそんなにいないわな……以外には、本当にどうでもいい話になる。

さて。

まず前提として、MSX2……厳密に言えばV9938およびその上位VDP……にはパレットの概念があって、512色中から任意に選んだ16色を同時に利用することができる。より正しく言えば、そういうモードもある。それ以上の色数を同時発色するモードについては本稿とは関係ないので割愛する。

512＝8³だから、これは要するにRGBの各要素について3ビットの情報量がある、ということだ。より直感的に表現すれば、MSX2の色は、赤8段階、緑8段階、青8段階の組み合わせによって決定される、ということになる。例えば、本作AREA1の敵機は以下の2色＋影1色で表現されている。


光の3原色で赤と緑を均等に混ぜると黄色になるから、上設定は、この色を使って表現される敵機が、かなり強く黄色味がかった緑であることを意味している。実際のキャラクタの表示例は以下の通りになる。


以上を前提として、ここからが本題……例によって例の如く、ボクの話に本題なんてものはそもそもないのだが……になる。

飽きもせず秋季大会準々決勝。


第一試合は京都福知山成美高校と、今年度春夏連覇の大阪桐蔭を府大会で破って優勝してきた履正社高校の一戦。履正社は今大会の優勝候補と目される一校になるが、その下馬評は伊達ではなかった。


清水くんの力投もさることながら、14安打を蒙りながらも連続失点を許さなかった成美の小橋くんも凄かった。やはり、投手戦は面白い。


それはともかくとして、今日も明石商業の宮口くんが凄かったのである。

以下はShoulder Blade OVERDRIVEの開発中に遭遇した……まぁ、そもそもは自分自身が無自覚なまま仕込むものだから遭遇もへったくれもないのだが……いわゆるバグ、についての備忘録である。

これらは既に解決済だが、きっと今後も似たようなことをしでかすに違いないので、こうして書き遺しておけば何かの役に立つだろう。

1. ランダムに発生する（ように見える）ウォームリスタート

現象としては、ゲーム動作中に何の前触れもなく突然MSXがリブートし、起動ロゴが表示されて何事もなかったようにオープニングデモが動き出す、というもの。アセンブラプログラミングをある程度知っている人なら、これだけで概ね原因は想定できると思うが、スタックを扱うループからの離脱に際しての考慮漏れが真因。


上に示したのは、この問題を単純化したサンプルコードになる。この構造は、特にシューティングゲームに頻出するもので、一般化すれば「Bレジスタの回数だけ内部でループするサブルーチン」ということになるが、例えば本作では弾との当たり判定がこれに該当する。

自弾にせよ敵弾にせよ、これは画面内に複数個存在している。それらとの当たり判定をおこなうオブジェクト主観から見ると、画面内に存在し得る弾の数＝ループ回数の当たり判定となり、上に示したサンプルコードの形になる。そして、その途中で実際に当りが発生した場合、大抵それ以上当たり判定のループを続けることに意味はないから、その時点でループを途中で抜ける処理が発生する。ここに落とし穴がある。

Z80にかぎらず現代的なそれも含め、アセンブラレベルにおけるサブルーチンコールとは、呼び出し元のプログラムアドレスを一旦スタックに記録し、サブルーチン終了時にプログラムカウンタをスタックに記録していた呼び出し元アドレスへ戻す、という動作になる。問題になるのは、Z80を含む多くのCPUにおいては、このときメモリ上のアドレス記録に使われるスタックと、レジスタ等数値の退避に使われるスタックは同一のものである点。CPUは自分がスタックから引き出した値がメモリ上のアドレスなのか、データとしての値なのかを知る術を持っていないので、少なくともアセンブラレベルにおいてはプログラマがこれを意識して扱わないと、ここで触れているようなバグの温床となる。

上掲＜駄目な例＞のサンプルコードでは、サブルーチン内ループ処理の先頭でBCレジスタの値をスタックに積んでおきながら、これを引き出すことなくループから抜けようとしてretをおこなっている。すると、retによるプログラムカウンタの遷移は、サブルーチン呼び出し元のアドレスではなく直前にスタックに積まれたBCレジスタの値になる。どちらも16ビットの数値であることに違いはないが、一方は1丁目23番地、といった意味合いであるのに対し、他方は456という数値だ。後者を4丁目56番地と読んで実際にその住所を尋ねても無意味であるのと同様に、これは事実上ランダムなアドレスにいきなりジャンプするのと同じことになり、多くの場合CPUは暴走し、その結果としてしばしばウォームリスタートがかかる。

原理は概ね以上の通りだが、もちろんそんなことは百も承知で＜良い例＞の原則……こういう構造のループから抜けるときは、一見無駄だが別のアドレス（上例ではラベルEXIT）へジャンプし、スタックを一段抜いてからretするコーディングをやっているのだ。では、どういうときにこのバグを仕込んでしまうかと言うと、言い訳がましい話ではあるが、一旦できあがって動作テストも済んだこのサブルーチンに、3日後くらいに何らかの機能追加を思いついたときが一番ヤバい。

なにせ、実際のコードは（処理・条件判定）の部分が上に示したサンプルコードよりももっと長く複雑で、テキストエディタ上で全体のロジック構造が目視しにくくなっている。ましてや本作のソースコードは既に1.7万行に達しようとしているのだから何をか言わんや。いや、ボクが野放図なプログラマだ、ってだけの話ではあるんだけども。