DQ3 K.Mix アイテムID9ビット拡張作業2

前回のエントリで領域の問題はクリアしたところまで説明しました。あとはPCのアイテム領域の操作、袋の中身の操作のプログラムを書くだけ、という話になりそうなのですが、以下の2点が問題となります。

1. 対象範囲がかなり広いため、十分なテストが必要
2. ビット単位でデータを詰めてセットしているので、アイテムの操作にまつわる処理量が10倍～に膨れ上がり、人が操作していて違和感を覚えるくらいに遅くなりかねない

1に関しては十分にテストをすればいいだけという話ではありますが、対象範囲を把握するのがかなり大変です。先日もテストプレイ中に間違った場所に情報をセットしてしまう箇所が残っていていつの間にかPCの最大MPが999になっていたりしました。一応そこそこテストをしてからテストプレイを開始したわけですが、ポロポロと問題が見つかるという始末です。PCのデータというかなりデリケートな箇所の操作なので、対処漏れがあると非常にまずいです。一通りテストしてOKだと思って別の方にテストプレイをしてもらったら対処漏れが見つかったりしたので(DQ3のアイテム操作のバリエーションは意外と多い)、rcまで出せたとしても正式版までは2ヶ月位置きたいと思っています。

2はデータ形式をこねくっている以上避けられません。各キャラクターのアイテム操作は最大12個なのであまり表面化しませんが、袋のアイテム操作は種類数が最大255(かそれ以上)になるので実装によっては処理に時間がかかり、突っかかるような感覚を覚えるケースがあります。オリジナルでは1バイトにアイテムID、個数を格納しているので、アイテムを並べ替えたり順番を1つずらしたりという操作は極めてシンプルに記述されています。以下一例。

アイテムIDを9ビット化した場合、アイテムID,個数情報が0ビットから始まるわけではなくなってしまうので単純にずらせばいいというわけにはいきません。アイテムID+個数情報をまとめて2バイトに固められたら楽ですが、その分領域を食うのでそれもできないというのが悩ましいところ。かくして空きを作らずビットの途中からアイテムIDを格納するような形態しかできないという結論に落ち着きました。次に問題となるのが「どうやってアクセスするか」です。ビットの途中から始まる情報にアクセスするためのSRはオリジナルの時点で存在しています。

なんとなく前後を見ていれば想像がつきますが、「$7E23ACの3-4ビットの値を取ってくる」のがSR: $09029Eらしいということがわかります。反対に値をセットするのがSR: $0902E9です。自分で0から実装するとなると結構面倒ですが、なかなか便利なSRです。次に中身を見てみます。

何をやっているかはともかく、ぱっと見て「クソ長い」というのはわかると思います。ちなみに値をセットするSRはこれより長いです。アイテムIDを取ってくるだけの「A=$3725+X」の1命令と同じことをするだけでもこの処理量に膨れ上がるわけです。DQ3は幸いにしてターン制RPGなのでリアルタイム性を求められるアクションゲームやATBを採用しているFF4-6と違い、複雑な処理を実装しても実害が出るケースはほとんど存在しないため、トータルのCPUのサイクル数(=処理量)というのには今まであまり気を配らずに作業をしてきましたが、流石に上記のような変更が更に256倍以上(アイテム種類分)になると目に見えて支障が出ます。当初はこのSRを使っていましたが、特定のケースで突っかかるような感じを覚えることがあったので(アイテムの種類をほぼ最大にして先頭付近にある1個しかないアイテムを袋から出すなど)、アイテム操作という移動中ユーザーが行う作業の半分以上を占めるであろう部分が快適にできないというのはよろしくないので結局専用のアクセスSRを作ることにしました。

長くなったのでまた次回。