DQ36SFCPlugin.dllのビットマップインポート機能の問題点の考察

先週リリースしたDQ3,6SFCPlugin.dllに実装した「スプライト画像の外部ビットマップファイルからのインポート機能」ですが、自分でもゴールドマン以外のモンスター画像をインポートしたところ、いろいろ問題が見つかりました。もとより1発目から問題のないバージョンをリリースできるとは思っていませんでしたが、現時点で分かっている問題は

  1. スプライト中で使用しているSNES4BPP画像数が96を超えると画像欠けが発生する
  2. 再利用できるSNES4BPP画像の考慮漏れ
  3. インポートするSNES4BPP画像を減らす

です。1についてはSNES的な制限なのかDQ36での制限なのかよくわかりません。スプライトグラフィックインデックス($0542A6-)の7-8バイトが1スプライト中で使用するSNES4BPP画像数を規定しているのでは、と推測します。ちなみにDQ3ではゾーマの攻撃、呪文画像、DQ6ではジャミラスが最大値まで使用しているようです。この点についてはプラグインにチェックを行う関数を追加すれば防ぐことができます。

2については、これもプログラムでなんとかなる問題です。現在リリースしているバージョンでは、SNES4BPPの重複のチェックは立ち絵で同じSNES4BPP画像が使用されているかどうかしか見ていません。後発の作品からインポートする場合などは、なめらかにアニメーションさせるためにスプライトの枚数が多くなる傾向がありますが、滑らかに見せようとすればするほど1枚前の画像からの差分が少なくなる可能性が高くなるため、立ち絵との重複チェックしか行わないと、インポートするSNES4BPP画像の枚数が膨大になってしまう可能性があります。理想を言えば既にROM中に存在している画像全てと突き合わせるのがインポートする画像数を減らすベストの方法ですが、現実的に考えて、時間がかかりすぎるのとマッチする画像が存在する確率が低いことから、同じアニメーションデータ中での重複のみチェックさせる、ということを考えています。

3については、プログラムで対応することは不可能に近いですが、必須というわけではありません。ただ、インポートする画像数を少しでも減らしたい場合は考慮する必要があります。今回いろいろと問題が発覚したやつざきアニマル(from PS版DQ4)を例にとって説明します。

20100831230544.jpg

これが1枚目(立ち絵)です。8×8で分割すると下記のようになります。(4倍拡大後)

20100831225819.jpg

よく見ると、真ん中の1ピクセル(青ライン)を挟んで左右対称(赤矢印の部分)であることが分かります。従って、画像数を減らすには真ん中+1(緑で囲った範囲)までをSNES4BPPとして取り込み、画像右側については、1ピクセルずらして水平反転で配置することで必要とするSNES4BPP数を大幅に減らすことができます。しかし、単純に8×8で分割して水平反転、垂直反転して同じ画像かどうかを判定させると全部異なるため、機械的に取り込んでしまうと使用画像数が大幅に増える、ということになります。さすがにこのへんの判断をプログラムにさせるというのは難しい(というか自分が思いつかない)ので、その画像についてよく理解しているかどうかが鍵になります。他にも同様の例がいくらでもありますが(1ピクセルずらすと同じパターンになるなど)、これはまあしょうがないかなと。機能としてはいささか不十分な気がしないでもないですが、サイズを気にしなければ一応アニメーションはできるのでこだわる場合は各人の努力に任せるということにします。

スポンサーリンク

コメントを書く

メールアドレスが公開されることはありません。コメントは管理者の承認後表示されます。