ギャプラス-変身条件の内部処理について考察(追記3月6日)

シューティングゲーム探究記
ギャプラス「アブノシップ変形完全解明」
http://d.hatena.ne.jp/replicorn/20090303

こちらの管理人のreplicornさんから
100点じゃなくても変身できることを教えていただいた。
そちらの内容への自分なりの考察だが、あんまり向こうに長々と書くと、
　他人の手柄を自分の手柄のように解説する痛々しい人
にしか見えない予感がするのでここに書いておく。

先に断っておくが、
自分は気に入ったゲームのプログラムの解読は絶対にやらない。
解読したと誤解されることも不快なくらいこだわりがある。
ここに書いていることは、見た目から逆にプログラムを想像しているだけである。
推理するのが楽しいのにいきなり解答を見てどうすんのよ、て感じ。
そこんとこよろしく。

そんではスタート

----------------

＞　十万,一万,千,百の4つの桁の並びが
＞　0001 0100 0101 はOKという法則性から
＞　0000 もいけそうなのにそれはNGなのはなぜか

(1) 当時のプログラムは、
ゲームの点数のような桁数が多い十進数は、パックドBCDという考え方を使い、
2桁ずつを1バイトにセットしてメモリ上に連続して並べるのが普通でした。

(2) 当時のプログラムは、
実行命令数(厳密には実行サイクル数)を可能な限り節約して
全体的な処理速度をいかに上げるかを追求するのが当たり前でした。
(現在でもその追求は有益ですが)

(3) この件でプログラマが求めていたものは 「0001であること」だと思います。
しかし、どうしてもこの数字でなければならない、というほど厳密である必要はありません。

これをプログラマ視点で考えると

(1) 2バイトまとめて読む命令があるからそれで4桁の情報を読もう。
(2) 2バイトの上半と下半を分けて OR命令 でくっつけると 0001 0100 0101 の3パターンが 01 になるぞ。
(3) 0100 0101 が暴発するけど、9999通りの中のたった2つだからどうってことないよ。オマケってことにしよう。
(4) 01 かどうかの判定は DEC命令 を使うと超速いぞ。

高速化のためにOR命令やAND命令を使うのはアセンブリ言語プログラマからするとセオリーってやつです。
「100点でなく10100点でも可」を読んだ瞬間に「あ、ORしてんのか？」と思った程ポピュラーなセオリーです。
ついでに
00 かどうかの判定は ANDかOR
FF かどうかの判定は INC
を使うのもセオリー。

こんな感じで 0100 0101 はたまたまオマケでOKになったんじゃないでしょうか。
0000 は始めから眼中にないわけです。

----------以下　3月6日追記

アイマスのオーディション待ち中にボーっと考えてて気づいたけど

(1)上下をORで合成
(2)合成結果をDEC
(3)0001 0100 0101 ならBEQ成立

(1)下をDEC
(2)上下をANDまたはORで合成
(3)00001 なら BEQ成立

(1)上下をORで合成
(2)合成結果をDEC
(3)0000 0001 0100 0101 ならBLE成立

どれも同一クロックで検査できるわ。
せめて30分くらいは考えてから書けばよかったか。

でも、厳密である必要はないからおまけで採用、という説は撤回しない。
当時は開発ツールも未熟で、ちょっとした間違いを発見しても
それを修正するのに結構な手間がかかったと想像できるので。