DQ3／DQ6グラフィック改造マニュアル
2024/04/23
ぐんたいカニカマ
| パレットデータの変換フォーム | ||||||
|
◆DQ3／DQ6のパレットデータのアドレス | ||||||
|
・DQ3 オリジナル（4MBバニラ） ・DQ3 Extended 1444（6MB拡張） ・DQ6 オリジナル（4MBバニラ） ・DQ6 KTPEx 0.9.9（6MB拡張） |
$36602C- (2byte ｘ 16 ｘ 2873) $5C0000- (2byte ｘ 16 ｘ ???) $341225- (2byte ｘ 16 ｘ 2435) $5DA000- (2byte ｘ 16 ｘ ???) | |||||
|
※バイナリエディタを使って、ROMから直接パレットデータをコピペして下さい | ||||||
|
24bit入力（3byte単位） |
|
15bit出力（2byte単位） | ||||
|
せっかくなので、変換スクリプトはweb archiveに残っていたDQ32作者（中の人）さんの JavaScriptをそのまま利用できるよう、ページのトップに入力フォームを用意しました。 似たようなプログラムはネット上にいろいろあります。（大抵はオープンソース） 好きなものを選んで使うとよいでしょう。 https://orangeglo.github.io/BGR555/ BGR555 Color Tool 世の中には、16進数を見ただけで、カラーイメージが脳内に浮かぶ人もいるという…… | ||||
|
ページＴＯＰに移動▲ |
|
※当テキストでは、データの改変にバイナリエディタを多用しており、 慣例として、リトルエンディアンと呼ばれる方式を使います。 たとえば、アドレス$401B5A- を記入するなら「5A 1B 40」と書き、 ID：28Aならば「8A 02」と、1byteずつ末尾から順に書きます。 | ||||
| 前提として、知っておいた方がよいこと | ||||
|
スーパーファミコン（SNES）は、レロトゲーと呼ばれるジャンルだけあって、 今時のＰＣやスマホのように、24bitカラー（1667万7224色）の画像は扱えません。 https://snes.nesdev.org/wiki/Palettes ここ（↑）に書いてあるように、最大でも256色です。 一応、Windows規定色の256色ではなく、5bit ｘ 5bit ｘ 5bitのＲＧＢカラーなので、 32,768色の中から選んだ256色ということになります。256色の画像と聞くと、 なんだかビミョ〜に感じるかもしれませんけど、実のところ、私たちが日常接している 画像やイラストには、結構な頻度で256色（ただし1667万色の中から選択した256色）の ものが混じっています。しかし、現にスーファミの画質は、最近のゲーム機に比べて 見劣りするように感じる……。もちろん、解像度が小さいというのもあるんですが、 一番の原因は、ゲーム上の効率の問題から、256色すべて利用できる場面が ほとんどないということです。戦闘背景サイズ（256 ｘ 224pixcel）の256色画像を、 仮に「スーパーマリオワールド」に収録したとすれば……なんと、たったの８枚！ プログラム部分を含めてそれですから、およそゲームとして成立しません。 そんなわけで、常に256色使うなんて贅沢が許されるはずもなく、実際のドラクエでは、 スプライト１つにつき16色（1色は透過色なので、正味15色）というハンデが 重い足かせとなります。……15色というのはかなりキツい条件です。せめて倍の 32色使えれば、アニメキャラなんかはそこそこ奇麗に描けるんですが……。 ファミコン： ワシに謝れ（スプライト３色制限） ＭＳＸ： 背景色と文字の区別だけ…（２色制限） GameBoy： 色ついてるだけマシでしょ！（モノクロ４階調） これからグラ関係の改造に手を出す人、あるいは知り合いの絵師さんなんかに 外部協力者として素材を提供してもらう前に、 ・キャラグラは、固定15色の２系統（系統を増やすことは可能） ・モンスターは、32,768色の中から選んだ１５色のみ という縛りがあることを頭に入れておきましょう。 32,768色というのは膨大なようでいて、案外そうでもなかったり？ 「Ｒ64／Ｇ216／Ｂ152」とか、「Ｒ132／Ｇ112／Ｂ96」とか、 要は８の倍数（32段階）の組み合わせなので、絵が上手い、こだわりのある人ほど 悩みは深くなるかもしれません。（逆に創作意欲が上がる！という意見も） | ||||
|
ページＴＯＰに移動▲ |
| 色違いモンスターの追加について | ||||
|
バイナリスレにおいて、定期的にこの手の質問がありますので、 なるべく分かりやすく（？）書いた資料を残しておきます。今後、同じ質問があれば、 このテキストにリンクするなり、コピペするなりして教えてあげて下さい。 ◆DQ3／DQ6のパレット指定は二重構造 ドラクエの改造で、ここで悩んでいる人をよく見かけます。 「パレットデータも、番号も間違いないはずなのに、まっ黒のままだｙｏ！ｗｈｙ？」 「オレは逆に真っ白さ！ 驚きの白さに心まで洗われるｙｏ！」 （話の都合上、開発者向けの拡張ＲＯＭ「DQ3 Extended」を例にあげて説明します） Extended1.444のパッチのreadme、「拡張仕様_ver144.txt」に、 →２． パレットデータ移動 移動先 $5C0000- →３． パレットアクセス情報データ移動 移動先 $5E0000- (2byte ｘ 8 ｘ 1024) 通常用 $5E4000- (2byte ｘ 8 ｘ 1024) モンスター用 （注）モンスター用については、モンスターのパレットアクセス番号読み込み時に、 読み込んだ値に0x400を加算し拡張エリアに飛ばしています。 という項目がありますよね？ 実データそのものは、「２」のアドレスで合ってます。 ただし、「３」の設定も必ずやらなくてはいけません。というのも、スーファミの ハードの仕様上、パレットのコントロールは８つのモード／スプライトと背景の２系統／ それぞれ８つのパレットを一まとめにしたものを介して行われるためです。この８つ 一まとめにしたグループを、「アクセス情報」と（過去の解析人さんが）呼んでいます。 便宜上、パレットの実データには番号（ID）がふってありますが、ゲーム中の プログラムで、この番号を直接指定することは、まずありません。 呼び出されるのは、ほぼ例外なくパレットアクセスID（情報）の方です。 町のマップなんかですと、木や草に緑系、石カベなどには灰色系と、いくつかの パレットを同時に併用しているのは分かると思います。……で、モンスター画像の場合、 １つのスプライトにつき１つのパレット（15色）しか使いませんし、使えません。 要するに、ツールで指定するモンスターのパレット番号とはパレットアクセスIDのことで、 あらかじめ実データの番号を、アクセスデータ構造体（１レコード＝2byte ｘ 8）の方へ 書き込んで設定しておく必要があるのです。 ◆色違い「キースドラゴン」の追加 具体的にやってみましょう。 ドラクエの改造をやっている人は、おそらく492氏のSFCGENEditor（通称：GEN）を 使っている人が多いと思いますので、これを使った説明から…… 「DQ3 Extended1.444」の設定フォルダを使い、SFCGENEditorを立ち上げます。左側の ツリーから「パレットデータ」の項目を探し出してクリック。パレットの実データの リストがズラズラと並んでいますが……  SFCGENEditorで新しいパレットデータを追加するには、設定フォルダのRomMapを開き、 項目数を初期値から増やす必要があります。このあたりの説明は、ツール作者さんの 領分かと思われますので省略します。（カニカマはGENを使って改造していないので……） ともあれ、ここで押さえておくべき点は、パレットデータの最終項が「ID：B38」と なっていること。そして右下の、パレットの実データが「00 00 E5 44 C6 75....」と なってるので、この数値をバイナリエディタで検索してみましょう。 ……$5D6700-の行がヒットします。この32byteがパレットの実データのラストです。 当然、新しいパレットデータは、ここから下の「FF FF FF FF FF FF....」となっている 空白部分におけばよい、ということになります。 今回のケースのように、単純な色違いモンスターの追加ならば、別のハック作品から そのままデータをコピペするのが手っ取り早いでしょう。特にキースドラゴンのような 有名（？）モンスターなら、収録されている作品がたくさんありますし。とりあえず、 拙作の「ドラクエすいーつ」からデータを持ってきます。アドレスは $3E3700-です。 それを適当な空白部分に、バイナリエディタのStirlingで上書きコピペ。 最終項からスキマを空けずに貼り付けると、後で見た時に分かりづらいので……  ※アドレスの計算式は、電卓（１６進数）で 「 B80 ｘ 20 ＋ 5C0000 ＝ 5D7000 」 アドレスはキリよく $5D7000-とします。最終項の $5D6700-が「ID:B38」でしたから、 このデータの位置は「ID:B80」に相当します。私の場合、この先もバイナリエディタで やってしまうのですが、話をSFCGENEditorの方へと戻しまして……  左側のツリーから、今度は、パレットアクセスデータの項目をクリック。 幸いなことに、アクセスデータの方は余白部分まで変更できるようになっているので 「750」の行のあたりへ飛びます。ここの「$FFFF」となっている先頭のセルに、 先ほどの「ID：B80」を入力。残り７つの「$FFFF」はそのままでもかまいませんけど、 ブサイクなのでできれば全部「$0000」と変えておきましょう。……はい、これで 新しいモンスターのパレットを指定する下準備が整いました。  モンスター基本データの項目をクリックして、グラフィック（スプライト）IDと パレットアクセスIDのセルに、それぞれ「0B」と「350」を入力します。 「0B」はドラゴンのスプライトIDと同じなので、まさしく色違いモンスターですね。 ……んん？ さっき変更したのは「750」の行だったのに？？？ そう、ここでようやく、 拡張仕様_ver144.txtの注意書きにあった、「読み込んだ値に0x400を加算し〜」という 話が生きてきます。「350 ＋ 400 ＝ 750」（１６進数）というワケ。ここらへん、 分かっている人には分かりきった話ではあるのですが、慣れていない人には 確かに分かりづらいかも……。まあ、これにて一件落着ということで、 改造結果をデバッグモードで見てみましょう。 ※デバッグモードは、アドレス$1FFFE- 「00 00」を、「FF FF」と書き換えて、 コントローラーのＬボタンを押せば起動します。  うまくいきましたね。 言うまでもないことですが、他のステータスをなにも設定していないため、このままだと エンカウントして戦闘することができません。（名前もモンスター１６０のまま） いっそバイナリエディタでドラゴンのモンスターデータ（37byte）を丸ごとコピペし、 SFCGENEditorでパレットを「350」にしてから、残りの部分を書き換えると楽でしょう。 あとは分かると思うので、お好きなように調整して下さい。 ※「sample_1444.ips」は、文字通り、確認用のサンプルパッチです。 DQ3 Extended1444に、このマニュアルの改造内容をそのまま書き込んでいます。 パッチは未改造のバニラＲＯＭ（4MB）にあてて下さい。 | ||||
|
ページＴＯＰに移動▲ |
| ドラクエと関係なく画像を表示（知らなくても困らない） | ||||
|
ここから先、DQ3／DQ6の画像（スプライト）表示について解説しようと思いますが、 バイナリwikiに並んでいる解析資料を読んで理解したとしても、それはDQ3／DQ6に 限定された知識であって（DQ1+2やDQ5はまた話が違う） 他のゲームでは使えません。 DQ3／DQ6の画像表示ルーチンを、コピペで切り貼りしてマリオやＦＦ、ロマサガなどで 動かそうとしても、うまくいかないということです。 そこで前段階として、スーファミで一番オーソドックスな256色画像の表示について 説明します。オーソドックスな手法なのに、実機で目にする機会はほとんどないというｗ 「ドラクエの改造以外、興味ねーし！」という人は、次のページまで読み飛ばして もらってかまいません。なぜか最後はアミバ？の話……マジ関係ない…… ◆256色のイントロ画像 サンプルパッチをあてた人は、ＲＯＭ起動時点で左下のイントロ画像を見たと思います。 これはゲームのＲＯＭ内部のプログラムを使ったものではなく、ドラクエとは関係ない、 完全に独立した別のプログラムによって表示しています。（バンクを１つ丸ごと使用） バンクを２つ使えば、もう一ランク画質を上げられますが、さすがに非効率すぎますね。 ドラクエのＲＯＭ内部のプログラムを使っているわけではないので、当然ですが、 アドレスさえ正しければ、画像データをプログラムごと別のゲームに貼り付けても、 ちゃんと画像を表示してくれます。ちなみに右側は、「テイルズ・オブ・ファンタジア」 のオープニングの一枚絵で、これでも70色程度に抑えられた圧縮画像です。 （フルサイズの一枚絵を収録しているゲームは案外少ない）   6MBのテイルズですら圧縮画像を使っているのに、たかだか256色の画像１枚に バンク１つ割りあてるというのが、いかにバカげた容量の無駄使いか分かります。 とは言え、拡張された改造ＲＯＭは、案外内部がスカスカだったりしますから、 改造職人さんはあまり気にしなくてよいのかもしれません。 データの構造としては、画像の実データ部分、256色パレット、タイルID群、 そしてプログラム部分に分かれます。画像がタイルID（番号）で管理されている点が ミソで、プログラムが直にアドレス（＋オフセット）を読みに行くことはまずありません。 この記述形式は、ほとんどのゲームで共通しているため、未解析のゲームを 自力で調査するときに手がかりとして役立ちます。改造ツールの「yy-chr」で 画像が圧縮されていて表示できないゲームがたまにありますが、（例：DQ5など） その場合はIDを読み取るサブルーチンから逆にたどっていくと、なんとなーく プログラムが何をやっているか分かると思います。なんとなーく。 で、256色のイントロ画像は、yy-chrで見てもどんな「絵」なのか、今ひとつ 分かりづらいですよね？ これはハード上で、背景とスプライトの２つのレイヤーを 重ねて合成表示するからで、つまり描き手としては、256 ｘ 224pixcelの256色画像を 先に用意し、それをあらかじめSNES用のレイヤーに分離して、yy-chrなどのツールで ペタペタ貼り付ける、という作業が必要になります。めんどくさいンゴ。 yy-chrでＲＯＭ内部を見たとき、   （↑）せめて下のような感じの画像でないと、yy-chrで描き直すのは難しいと思います。 前者と後者でなにが違うのか……？ それはパレットの扱いです。下は16色、 上はレイヤー合成して256色です。256色画像をレイヤー分離後に再加工するのは 専用ツールを用意しないと無理でしょう。というより、どう考えても効率が悪すぎるので、 画像の加工はレイヤー分離前に別のツールでやった方がいいです。私も絵を描いたあと、 改めて分離工程を、PhotoShopのプラグイン（自作）でやってます。 そうそう、たまに勘違いする人がいますけど、yy-chrには、ＲＯＭのパレットデータを 変更する機能はありません。ＲＯＭのパレット編集は、バイナリエディタでやります。 yy-chrのパレットは、あくまでツール上で一時的に色をつけて表示しているだけです。 色がついてないと、描きづらいですからね。 yy-chrには、別途24bitのパレットデータを 保存する機能があるので、このテキストのトップにある入力フォームで変換し、 バイナリエディタで貼り付けるとよいでしょう。 ただ、正直に言えば、この手法（レイヤー２枚で256色合成）は、あまり面白くないのです。 むしろレイヤーの合成をやめて、スプライト側はＨＤＭＡのプログラム操作で あれこれ細工する方が、できることが豊富です。 実例として、同じ原画を使った別のイントロを入れておきます。（ＦＦスキンのイントロ） 試しに、$40FF9C-の「5C 00 50 E3」を、「5C 00 80 40」と書き換えてみて下さい。 ドラクエ３のＲＯＭ本体は、日本語のままなのでご安心を。  ＦＦスキンのイントロの方は、半透明のスプライトを動かしている点が目につきますが、 文字を画像ではなく、フォントデータとして扱っているので、バイナリエディタで 直接文章が編集できます。（ドラクエ改造でアイテム名を変更するような感じ） ここらへんから、だんだんゲームの仕組みに近づいていきますね。 そのうち、初歩的なゲームＲＯＭの作り方も解説しようかな？ ◆磯野ー、DisPelで逆アセしようぜー！ 続いてプログラム部分のお話。 いわゆるＨＤＭＡのメモリ操作が大半ですから、逆アセンブルしたところで それほど意味はありません。どのメモリが、どういう役割を持つか調べる方が ずっと重要だからです。興味がある人のため、資料にリンクをはっておきます。 細かく覚える必要はないです。私もプログラムを書く時以外はあらかた忘れています。 それどころか、しばらく触ってないと65816の命令もポロポロ忘れていく始末……。 一覧表を見れば、さすがに思い出せるんですけど。下（↓）は備忘録の代わりです。   話が脱線しますが、逆アセ行為そのものについて触れておきましょうか。 エミュレータのデバッガに、逆アセンブル機能がついてたりしますけど、精度的に 少々頼りないので、カニカマはいまだにDOSの逆アセンブラ「DisPel」を使っています。 プレハブ小屋「ドラクエ命」さんのところに、DisPel導入についての記事があります。 念のため、ここにも書いておきますね。「DOSなんて触ったこともない」という 今時の若い人でも、一字一句、下記の通りにすれば大丈夫！（と信じたい） １．「DisPel」をダウンロード （DisPelのソースコードは→こちら） ２．分かりやすい場所にフォルダを展開。 （例： C:\dispel） 同じフォルダにＲＯＭも一緒に入れておくとよい。（例： dq3.smc） ４．WindowsのスタートメニューからDOSコマンドプロンプトを立ち上げる ５．「dispel」のフォルダまで移動する。 cd c:\dispel とコマンド入力。 ６．コマンドプロンプト上で、dispelを実行。 C:\dispel> dispel -r 10000-12000 dq3.smc >10000.txt と入力する。 ７． exit とコマンド入力して、DOSプロンプト終了。 ※コマンドプロンプトなんて最近のＰＣでは使わないせいか、日本語のWindowsでも 「\」ではなく「 \（バックスラッシュ）」でパス表示されるみたいです。ｴｰﾝ 同じフォルダに「10000.txt」というテキストファイルが作成され、$10000-$12000の 範囲の逆アセルブル結果が書き込まれます。（もちろん逆アセ範囲は変更可能） こうしてファイルにパイプライン化しておかないと、いきなりDOSプロンプト上に ドババーッと解析結果を吐き出してしまうので…… Windowsが登場したとき、子どもでも使えそうな使用感に驚かされたものてす。 でも、生まれたときからタッチ操作のスマホがあたりまえの世代からみると、 私らロートルはどんな風に見えるんでしょうね？ 時代遅れのおっさんどころか はじめて火を見て驚愕する石器時代の人間みたいな扱いでしょうか。ﾅﾆｺﾚｱﾂｲﾜｰ ……ククク、そうやってバカにして、トラックにはねられて異世界転生して、 コブリンにくっ殺されたり、森の中で火を起こせなくて途方にくれるがよい…… う、いや、UNIXやDOSコマンドでも火は起こせませんけど、多少はね？ 魔法が使える世界なら、ワンチャンなんか出るかもしれないじゃないですか（震え声 ドラクエに関しては、すでに先人たちの解析結果がコメントつきで手に入りますから わざわざ逆アセする必要はありません。しかし、未知のプログラムに対して、逆アセは それなりに有効です。今回のケースですと、同じフォルダに「sample_1444.smc」を置き、 C:\dispel> dispel -n -r e35000-e35300 sample_1444.smc >235000.txt と入力してやれば、私の書いたプログラムが解析できます。ヘッダなしＲＯＭなので オプションとして「-n」をつけること、ＲＯＭアドレスではなく、実機（エミュレータ）の メモリアドレスであることに注意して下さい。$FFFFF-以降、$10xxxx-なら （D0/xxxx） $30xxxx-なら （F0/xxxx）、そして $226000-なら （E2/6000） と表記します。 なお、$400000- 以降はそのままです。（40/xxxx）（50/xxxx）（60/xxxx）…… 話のついでにもう一点。デバッガなどでアドレスを指定する時や、ＲＯＭ内部の サブルーチンのアドレスで、たとえば $446A4- を （C4/46A4） と表現したりします。 「頭のＣって何？ どっから来た？」と 疑問に思った人もいるかもしれません。 なんのことはない、実働状態のメモリアドレスというだけです。SNESGTのような メモリビューア機能がついたエミュレータならば、実際にドラクエ３を動かしたとき、 $C00000- に「D5 0C C1 00 03 40....」と、ＲＯＭの冒頭部分のバイナリデータが そのまま格納されているのが確認できます。まあ、SNESの「.smc」というファイルは Windowsフォーマットですから、アドレッシングが異なるのは仕方ないですね。 さて最初に言ったように、一から画像表示ルーチンを書くなら、各メモリの役割を 理解する方が重要ですが、２次改造で軽く手を加える程度であれば、逆アセンブルが 役に立ちます。たとえば $226000-から始まる画像データを（デカすぎ。すんごい邪魔） どこか別の場所へ移動させようとした場合…… | ||||
|
$23517D- $235180- $235183- $235185- |
（E3/517D） （E3/5180） （E3/5183） （E3/5185） |
: A2 00 60 : 8E 02 43 : A9 E2 : 8D 04 43 |
LDX #$6000 STX $4302 LDA #$E2 STA $4304 |
|||
|
赤字の２ヶ所を書き換えればよい、と見当がつくはずです。 まあ、この程度ならバイナリ検索でもすぐ見つけられますが、できればプログラムの 前後の流れを見ておいた方が、より確実に判断できますからね。 ……ひとまずここまで読んで、なにやら小難しい話ばかりでチンプンカンプンな人も いるでしょう。しかし、実際にはそれほど高度なことをやっているわけでも、 特別な知識が必要な話でもなかったりします。要はインターフェイスが時代相応に 素朴と言いますか、使い勝手が悪いだけで、ぶっちゃけユーザーの慣れの問題です。 とは言え、レトロゲーの逆アセンブルをスマホのアプリでお手軽に出来たりすると、 それはそれで、ものすごい違和感を感じると思いますけど。 仮に逆アセンブルを一切やらないとなると……、改造界に古くから伝わる禁断の奥義、 アミバ流改造術に手を染めることになりますね。そう、あてずっぽうで実験体の 経絡秘孔を突くがごとく、ＲＯＭの一部をバイナリエディタで適当に書き換えて、 ゲームを動かして反応を見るという、恐るべき邪法です。無論、大半が爆死するため、 ファミコン時代のゲームならまだしも、今時のギガ単位の容量のゲームにはまったく 通用しません。モヒカンどころか、空ペコの子どもとサウザーぐらい手強さが違うので、 さすがに出番はなさそうです。フフフ…この身体に北斗神拳は効かぬ！（アミバ流も） だが、改造はいいぞぅ、ケンシロうわらば。   ※こちらは「Amiga」、グラフィック関係に強かった伝説のＰＣです。ただし基本英語。 元アミガー（Amiga使い）としては、友人との会話で「昔、コモドールのAmigaで……」 「子どもおるアミバ？ アミバって嫁おったん？」とか聞き返されて憂鬱です。 | ||||
|
ページＴＯＰに移動▲ |
| DQ3／DQ6でスプライトを表示する | ||||
|
お待たせしました。チュートリアル回です。 ドラクエすいーつで言うと、自宅で母親が表示されるのも、かっ飛ぶラーミアも、 サイコロの出目も、ホイミンを消し去る落雷も、ゾーマの前でイキるバラモスも、 パンツを盗むベビーサタンも、大量に押し寄せてくるカンダタこぶんも、そして何より、 戦闘画面に登場するモンスターアニメも、すべて記述形式は同じです。 ただ、それぞれの状況において、呼び出すサブルーチンと付随する補助データが異なり、 どれか一つでもデータに不備があると、画像はうまく表示されません。 ゴチャゴチャといろんなパターンを説明すると混乱の元かと思いますので、 ここでは戦闘時のモンスター表示一本にしぼって話を進めます。 ◆必ず設定しなければいけない２つのデータ構造体 （出オチ） 【その１】 スプライトグラフィックインデックス （SFCGENEditor呼称） スプライトグラフィック情報データ （DQ3 Extended 1444 readme呼称） スプライト読み込み情報 （バイナリwiki DQ3解析テキスト呼称） テキストごとに違う呼び方をされていますが、意味は同じ。未改造のＲＯＭにおいて、 $542A6- $54E83- の範囲にある「１レコード＝14byte ｘ 217」のデータ構造体です。 内容は、描画の記述データやアニメモーションのアドレス、使用画像（タイル）数など。 DQ3 Extended 1444では $E0000- に移動し、拡張されています。 【その２】 モンスターグラフィック構成データ （SFCGENEditor呼称） モンスター画像位置情報 （バイナリwiki DQ3解析テキスト呼称） $54F80- $55180- の範囲にある「１レコード＝9byte ｘ 57」のデータ構造体です。 内容は、スプライト番号（【その１】の並び）、画像／エフェクトの位置、横幅など。 DQ3 Extended 1444では $E1000- に移動し、拡張されています。 例によってSFCGENEditorでは、項目の新規追加のために設定フォルダのRomMapを 編集しておく必要があります。モンスター基本データで、グラフィック（スプライト）ID と呼ばれるのが【その２】ですね。本体の【その１】は、わりと離れた位置にあるので ちょっと見つけづらいかも。 スプライトを構成／表示するデータを制作したあと、仕上げにこの２つの構造体に 必要な数値を書き込むことになります。まだ肝心の画像を用意してませんので、 とにかく今は、重要な記入項目が２つある、とだけ頭に入れておいて下さい。 身分証明に、住所と電話番号の２つの個人情報がいる、みたいな感じです。 ◆ まずは基本となる一枚絵の表示から。これが出来ないと、なにもできないのだ……。 yy-chrで、sample_1444.smcを開いて下さい。そして$570080- へ一気にスクロール。 ページの頭が$xxxx80- なのは、画像データ開始アドレスが$410080- だからです。 同じフォルダに sample_1444.pal（yy-chrのパレットファイル）も入れておくと、 最初から色つきエスタークを表示してくれます。  毎回寝起きドッキリ！される地獄の帝王です。……半分だけ？ ええ、半分でいいのですよ。某トナカイみたいに人見知りで隠れてるわけではありません。 では、これを使って、さっそく描画データを作っていきましょう。スプライト描画の 仕組みを理解してもらうため、バイナリエディタとyy-chr以外のツールは使いません。 当然、バイナリ直打ちです。ﾔﾙｿﾞｵﾗｧｰﾝ! モンスターアニメーションは、どういう風にスプライトを動かすかを記述する部分と 具体的にスプライトを描画する２つのデータによって構成されています。 とりあえず、今はアニメ（モーション）については触れません、これは後回しです。 描画データは、さらに２つのパートに分かれます。前半はアドレス群。そしてタイル数や タイルID、描画座標などをまとめた集合データです。この２つは自由に配置できます。 ２つのデータの間に「FF FF FF FF....」とスキマがあっても、別に問題はありません。 ひとまずアドレス群は$373018- に、集合データは$37302B- から記述します。 アドレス「群」とは言うものの、今回は一枚絵なので、後半の集合データは１つだけ。 従って、$373018-に「2B 30 F7」と 3byte記入しておわりです。簡単ですね。 一方、集合データの方は、かなりややこしい記述ルールがあります。 順を追って説明していきましょう。  $37302B- の最初の2byteですが、これは後半の座標データまでのオフセットであり、 赤線で囲った部分のサイズを１６進数で記入します。180byteあるので「B4 00」です。 次の2byteは、そのあとに続く「タイルIDの数」を記入します。IDは2byte単位なので、 水色で反転した部分のサイズを２で割り、１６進数で記入します。「58 00」です。 これはスプライトがメモリで占有する「（使用）タイル数」という意味もありますね。 仮にIDを全部「00」で埋めても、ちゃんと88マス分確保してくれます。 この水色で反転した部分のタイルIDというのは、画像データの開始アドレスから 8 ｘ 8pixcel（32byte）ずつカウントして番号をふったものです。……分かりにくい？ $410080-が「00」ページ、今、yy-chrで開いている$570080-を「B0」ページ目として、 16 ｘ 16 のマス目の位置がそのままタイルIDになると考えて下さい。マウスの矢印を マス目に合わせると、yy-chrの下部中央、緑で囲った部分に数字が表示されます。 エスタークのツノが「15」となっているのは分かりますか？ つまり、 この 8 ｘ 8 pixcelが「タイルID：B015」…… 15 B0 （2byte）というわけです。  で、このタイルID群がどうなるのかと言いますと、ドラクエでは、戦闘用に予約された メモリ領域に格納されます。今回は、88マス分（１６進数で58）確保していますので、 （↓白ベタで塗りつぶした部分以外がそれ。「00 00」の空白IDも含めて88マスある） タイルID群のデータを流し込むと、メモリ空間では  左上（↑）のように格納されることになります。（視覚的に分かりやすく再現してみた。 $572080- は説明のためにコピペしただけで、ゲームでは使ってない画像。消してもよい） エミュレータによっては、タイルビューア機能を持つものもありますから、 それを使えば実働状態で確めることもできるでしょう。……どのエミュか忘れました…… なお、記述データとしては、「00 00 00 00 00....」と00が続く部分は、「xx FF」と 2byteの省略形で書くこともできます。（今回は分かりやすさ優先で省略なしのベタ書き） 元ＲＯＭのアニメデータを移植するときに注意しましょう。 すでに改造に手を出している人ならばお分かりでしょうが、元ＲＯＭに収録された 公式のモンスター画像は、もっとスキマなくびっしりと、そしてグチャグチャに乱れて タイルが並んでいます。それこそyy-chrで開いても、パッと見ではどのモンスターが どのタイルなのか分からないほどです。私の追加画像は比較的分かりやすく並べて ありますが、実働状態のメモリ空間においては、図のような感じでタイルが並んで いるのが普通です。（つまりＲＯＭとメモリ空間でのタイルの並びは全然違う） ここで重要なのは、メモリに格納されたタイルは 2 ｘ 2 の正方形で扱うのが基本 だということです。別の言い方をするなら、集合データのタイルIDを記述する部分は、 メモリ空間で 2 ｘ 2 の正方形を保てるように並べ直すのがベターです。もちろん 今回のように、すべてのタイルを 2 ｘ 2 として扱うと無駄が大きくなりますから、 最大限 2 ｘ 2 で並べ、空白IDを減らして 1 ｘ 1 で詰めるのが理想でしょう。 元ＲＯＭの画像の並びから、タイルIDをそのまま１マスずつ書き写すのは下策で、 仮に全部のタイルを 1 ｘ 1 で扱うと、同じ面積の描画に４倍の時間がかかってしまい、 速度低下を起こします。昔からスーファミは「ＲＰＧ向きのゲームマシン」と言われ、 事実、ＲＰＧのタイトルがとても多いのですが、ここの処理を間違えて、スーファミの 性能を生かしきれていないソフトがあります。（特にシューティングで影響大） まあ、ドラクエにはほとんど関わりのない話ですが。 一度にたくさん出てくる雑魚モンスターなら、処理速度よりもメモリで確保するID数を 節約したいとか、そういうケースもあるでしょう。そのあたりは臨機応変に。 こういうパズルっぽい作業（タイルの並びの最適化）を、プログラムに任せるのは 難しいかもしれません。ああでも、最近のＡＩならやってくれそうな気もしますね。 １００年後くらいには、人間が「よきにはからえ」とだけ言えば、あとはロボットやら ＡＩやらが全部やってくれる時代がくるんでしょうか。いい時代……なのかなあ？ もう一度バイナリエディタを見ながら、説明を続けます。 タイルID群の次、青で反転した 1byte。これはこのあと続く描画座標データの数です。 描画座標は4byteで１セットなので、ピンクで反転した部分の合計サイズを４で割って １６進数で記入します。80byte ÷ ４ ＝ 20 ですから、１６進数で 14 ですね。 そして今数えた描画座標データ群。4byteのうち、前半の2byteはＸ座標／Ｙ座標です。 図で見たほうが分かりやすいと思います。こんな感じ（↓）です。  3byte目は、格納されたタイルの何番目を表示するかを意味します。バイナリwikiにある 解析情報では、ここらへんが理解しづらくて、挫折してしまった人が多いみたいですね。 ＲＯＭ上のアドレスやIDではないのです。タイルを格納したメモリ空間の位置なのです。 これも実際に自分の目で確めた方が早いでしょう。$572080- を開き、これを擬似的な タイルビューアと見なしてマウスの矢印を動かして下さい。yy-chrの下部中央の数字が そのまま答えとなります。すなわち3byte目が 28 なら、四角い白線で囲んだ部分を 指定しているというわけです。ゲーム上では、４枚のタイルがまとめて表示されます。 （剣をにぎっているエスタークの手の部分）  そして最後の4byte目。ここが 10 ならタイルを 2 ｘ 2 で扱うという意味になり、 00 なら 1 ｘ 1 で扱うことになります。基本が 2 ｘ 2 なのをお忘れなく！ さて、これで描画データ（仮）は完成しました。 描画データのほかにも、どうやってスプライトを動かすか、モーションデータが 必要なことは言いましたよね？ ひとまずモンスターの表示を優先したいので ここは深く考えず、 $373000- に「03 30 F7 00 02 00 00 FF」と記入して下さい。 詳しい意味はあとで解説します。動かないモンスターの表示はこれだけでＯＫです。 これも立派な（？）モーションデータですので。 ◆必ず設定しなければいけない２つのデータ構造体 （知ってる天丼） 話は前項へと戻ります。 描画データが用意できたので、例の２つの構造体に、必要な数値を記入していきましょう。 設定ファイルをいじってないので、SFCGENEditorからは記入できませんから、ここは バイナリエディタでやってしまいます。（もちろん、あとからGENでも設定できる） 【その１】スプライトインデックス $E0BDE- 00 30 F7 18 30 F7 00 00 00 64 00 01 00 00 ※１つ前の最終項が「ID:D8」なので、このデータは「ID:D9」となる まずは最初の 3 ＋ 3 byte。これは先ほどの２つのデータ、それそれのアドレスを 記入するだけです。モーションデータのアドレスが$373000-、描画の記述データが $373018- ですから、「00 30 F7」「18 30 F7」と書けばいいわけですね。 そして、8byte目。ここはモンスターアニメにおいて、上書きされる最大のタイル数を 入れます。今回は一枚絵なので上書きタイルはありません。従って「00」です。 残りの部分は気にせず、他のモンスターと同じ値を入力しておきましょう。 （戦闘時以外で画像を表示するために参照する数値で、今は無視してよい） 【その２】モンスターの位置と構成 $E1201- D9 00 37 E0 37 00 37 D8 70 ※１つ前の最終項が「ID:38」なので、このデータは「ID:39」となる 最初の2byteに、【その１】のIDから、「D9 00」（2byte）と記入。 続く 2 ＋ 2 ＋ 2byteは、武器などのエフェクトのＸ座標とＹ座標なので、とりあえず 「37 E0 37 00 37 D8」と記入しておきましょう。目安としては、Ｘ座標はどれも スプライトの横幅の半分くらい、呪文などのエフェクトのＹ座標だけ少し低くする感じ？ まあ、ここらへんは気に入らなければあとでいくらでも調整できます。 最後の9byte目は、モンスター横幅をそのまま入力。エスタークの横幅は 112pixcelありますから、「70」です。（１６進数） 【その２】が、いわゆるグラフィック（スプライト）IDに相当します。あとは当テキストの 「色違いモンスターの追加について」の手順に従って、エスタークを登録します。 モンスター１６４です。（パレットIDはキースドラゴンの後） さあ、デバッグモードでみてみましょう。  グゴゴゴゴ……ゴア？！ バグではありません。正常です。だって最初から半分しか描画してませんから。 ガッカリさせて申し訳ないですが、話はまだ続きます…… ◆ エスタークのような左右対称のモンスターは、タイルを反転させて描画することで、 画像データを節約することができます。実は、k-mixやDQ32の追加モンスターは、 タイルの反転描画をあまり使っておらず、画像を節約して切り詰めることで、 収録アニメ数を増やすことが可能です。（そうしないと追加スペースがないともいう）  タイルの反転は、描画座標データの4byte目を「＋40」することで可能となります。 ついでに言えば、上下反転ならば「＋80」、左右上下反転ならば「＋C0」です。 タイルの反転描画を含め、改めて描画データを書き直したものが $37323B- で、 $37302B- のデータと比べて描画座標データの数が２倍に増え、（「14」→ 28 ） 増えた座標データの4byte目は、いずれも 50 （10＋40）となっているのが 分かると思います。なお、タイルを 2 ｘ 2 の単位で扱っているため、 反転も４枚まとめて行われます。 ここで一つ、豆知識というか、小ネタの紹介を。 タイルは重ねて描画することができます。何枚まで許容範囲かはメモリの状態で 決まりますが、１枚だけならほぼ無条件で重ねて描画しても大丈夫です。また、仮に 無茶な描画でメモリを飽和させたとしても、下になったタイルが消えるだけなので あまり気にする必要はありません。画面が極端にバグったような表示になったら、 記述データにミスがないか調べましょう。（アドレスや予約タイル数の間違い、など） カニカマもよくやらかします。長時間ミスに気づかず、一歩も進めなくなることも しばしばです。カニでさえ横に動けるのに……てか横にしか歩けないが…… ……カマボコはどうしたらいいんだ…… 今回のエスタークの場合、そのまま重ねず反転描画すると、元のドット絵より １ドット（1pixcel）太めに描画されることになります。この程度ならば、見た目は ほとんど変わりませんが、どうせなら１ドット左に寄せてしまいましょうか。 ふとましいｗｗ横綱ｗｗ土俵入りｗｗｗとか、草生やされるのは可哀想です。 増えた座標データの1byte目（Ｘ座標）を、すべて -1 ずつ減らしておきます。   では、完成したデータをモンスター１６５に登録して、デバッグモードでチェック！  おー、やっと見慣れた姿となりましたね。……ピクリとも動きませんが。 ◆動け！動け！動け！動いてよ！ （死んでも動かない君） そんなわけで、モーションデータの説明です。 DQ3／DQ6のモンスターアニメは、セル画のアニメ（パラパラマンガ）と同じ原理でして、 セル画一枚に相当する画像番号とフレーム数、そしてＸ軸／Ｙ軸の移動方向とpixcel数を 指定してやれば動きます。これも１セット4byteのデータです。可変長データなので、 プログラムの頭出しで「FF」が読み出されたところで止まります。要するに、最後が 「FF xx xx xx xx....」となっていれば、そこでアニメは終了です。 今のところ、エスタークの静止画像は、$373203- に書き込んだ「00 02 00 00」 というモーションデータに従って動いています。はて？……静止画なのに動いている？ どういうことかと言いますと、（次の1byteの「FF」は終端サインなのでいいとして） この4byteのデータは、「00（1byte目）番目の画像を、２フレーム（2byte目）の時間、 Ｘ軸方向に±00（3byte目）、Ｙ軸方向に±00（4byte目）動かせ」という意味になります。 動かす方向も速度も00なので、動かないように見えるというだけ。あくまでこれは モーションデータであり、スプライトの動き方を指示するデータなのです。 実際に大きく動かしてみましょう。対象はモンスター１６５です。 $373203- の「00 02 00 00」の続きに、「00 20 00 FC」と書き足してみて下さい。 $373200- 03 32 F7 00 02 00 00 00 20 00 FC FF FF FF.... わはははは。黒ヒゲ危機一髪みたいに飛び上がりました。そして戻ってこない……。 意味としては、「20フレームＹ軸方向に−4ずつ進む」となります。 では、さらに以下のように追記。 $373200- 03 32 F7 00 02 00 00 00 20 00 FC 00 30 00 00 00 $373210- 20 00 04 FF FF FF... 意味としては、「20フレームＹ軸方向に−4ずつ進み、30フレームその場で静止し、 20フレームＹ軸方向に＋4ずつ進む」となります。ものすごい不自然な動きですけど、 どうですか？ スプライトの動かし方、お分かりいただけたでしょうか？ 記述の注意点は、１つめのモーションデータは、必ずアドレス群の直後に続けること。 「FF FF FF....」とスキマを挟んではいけません。２つ目以降は挟んでも大丈夫です。 「xx xx xx（アドレス１）」「xx xx xx（アドレス２）」「xx xx xx（アドレス３）」 ときたら、そのまま「xx xx xx xx（モーションデータ１）」を続けて書きましょう。 あとは……、スプライトのモーションは、正確に元の位置に戻して終了することかな？ そうしないと、戦闘中にそのモンスターだけ、だんだん位置がズレていきますので。 気のちっさい小動物がバレないように逃げてくみたいでちょっとﾜﾛｽｗｗｗ  参考までに、モンスター１６６のモーションを、DQ6からコピペした「ヘルクラウド」の ものに設定しておきます。（アドレス$372E00-） さっきの不自然な動きに比べれば、 よほどマシではありますが、なんか手抜きくさい……？ けど、もうこれで完成でよくね？ うーん……、ドラクエすいーつの場合、その手抜きっぽさもネタ扱いだったので、 これで十分だったんですけど、やはり普通（？）の改造ＲＯＭを作る人なら、 ちゃんとしたモーションアニメを入れたいのが心情ですよねえ…… ◆ぶるぅわあああああ！ （まとめて吸収して完全体へ） 実のところ、ここまでのお話で、アニメ制作に必要な知識はほぼ出そろっているのです。 残る話はせいぜいタイルを上書きする時の注意点ぐらいでして、あとはひたすら １０枚、２０枚と動きを変化させた画像を記述し、連続して動かすだけですから。 制作する人の根気次第ですな。めんどくさいのは確かかと。 サンプルとしてモンスター１６７に、ＦＦスキンやデラパッチに使用したエスタークを 入れておきます。DQ32のエスタークと比べて表示画像数が２倍近くあるので、単純な 差し替えはできません。DQ32の内部データを、何か大きく削らないと無理ですね。 8MBのk-mixには普通に入ると思います。差分パッチは作りませんけど。（察して下さい…） わらべさんとか、私よりずっと上手なgifアニメを作られる方もおられますし、 得意そうな人を見つけたら、いろいろアドバイスをもらうといいんじゃないかと思います。 「囲め囲め！洗いざらい吐かせるんだ！」「どういうことだ！なんであんな上手いんだ！」 私もネットでアニメーターさんのこぼれ話を拾ったりして、勉強しています。 サボテンダーのマンガ走りなんかは、そのまんま昔のアニメの手法です。 残像を最初から描くとか、絵を描く技術とはまた別方向のテクですよね。   モンスターアニメを描くのに、すごく参考になると思いますので、わらべさんの 「キラーマシン」「バーサーカー」「メドーサボール（反転を多用するタイプ）」を サンプルとして収録させてもらいました。お礼や賞賛の言葉は、わらべさんの方へ。 ついでに私のくま（大）も一緒に入れておきましょうか。気に入ったら使って下さい。 サボテンダーもオマケしちゃう……ｺﾚDQﾁｬｳ モンスター１６７の描画データは$370000- にある9,500byteほどの記述です。（デカい） モンスター１６４〜１６６のデータと比較すれば分かりますが、２枚目以降の画像は タイル上書きです。上書きの指示は、各画像の描画座標の4byte目を「＋20」することで 実行します。アニメデータを作れる職人さんは知ってて当然なんですけど、解析情報 としてネットに上がってないので、ここでつまづいた人は多いんじゃないかと思います。 私も逆アセして、描画プログラムの方から逆にたどって初めて気づいたくらいなので。 すいーつを作る前にかなり悩みました。一体、どこで指定してるのかと…… 【その１】スプライトインデックス （モンスター１６７） $E0C08- 00 00 F7 60 01 F7 00 48 00 64 00 01 00 00 タイルの上書きがあるため、【その１】スプライトインデックスの8byte目に、 表示画像のうち、タイル数が最大となるものと同値を入力しておくのも忘れずに。 （モンスター１６７なら、全25枚中「48」が最大） ただ、ここの記入を忘れても、 もともとかなりのマージンがあるため、即バグるということはありません。わんさか モンスターが出て、派手なエフェクトが入った時にコマ落ちするかなー？という程度。 それも一瞬のことなので、大抵は気づかないという。 なお、アニメを動かす際の効果音や、パレットアニメーションの説明については、 省略させてもらいます。SFCGENEditorのようなツールでも設定できますし、 チュートリアル的な事例が、492氏のブログの記事にありますので…… いかがだったでしょうか？ 数年前にバイナリスレで、「アニメの詳しい説明をして欲しいです」とお願いされ、 その時は「おっぱい描くから無理ぽ（めんどいからイヤですの！）」と答えました。 たぶんご理解いただけたのではないかと思います……。説明のめんどくささが。 一応、はじめてツールをさわるような人にも分かるように書いたつもりですけど、 どうしてもバイナリでのデータ書き換えは避けられませんし、分からない人には あちこち分からない専門用語だらけかもしれません。アミバとか。 まあ、あわてずマイペースに、ゆっくり読んでもらえればと思います。 JavaScript使用ＯＫなら、バイナリwikiの記事としてまとめてもよかったんですが このテキスト、原稿用紙で１００枚近くあるんですよね…… おっぱい１０枚は描けそうなリソース費やしたんじゃよ？ わし超がんばった。 これはもう、生で揉んでもバチはあたらんと思うんじゃが？（逮捕 | ||||
|
ページＴＯＰに移動▲ |