web拍手への返信 その10

> リクエストですが店以外で肉を出現させてみたところ、
> 店の設定とは関係なくシレンの肉が出現したんですが、
> 店以外でも設定通りに肉を出現させることはできますか?

肉に関しては030559以降に、5バイトずつのデータがあり、ダンジョン(01~04)、層(00~02)、オフセット下位バイト、オフセット上位バイト、肉の種類の数、の順に並んでいます。
そして、それを読み込む処理は03050C以降にあります。
ただ、この処理は店でしか読み込まれないので、落ちている肉の種類を設定するには、大幅なプログラムの改造が必要になると思われます。
[PR]
# by oyasen | 2010-08-08 22:09 | web拍手への返信

web拍手への返信 その9

> フロアの記事を参考に試しに水脈の処理を32回繰り返してみました。
> 通常と分裂が水フロアと化したのは予想通りでしたが、
> 5×3以外の地形でやったら意外な結果になりました。
> http://www1.axfc.net/uploader/Sc/so/118624/

これは興味深いものを見せて頂きました。
通路で分断されたり、水脈が2本できることもあるとは。
最近よく見かける、水脈と道具が重なるバグも起きていますね。


> デバッグモードですが、改造コードで
> C0800000
> C0800100
> を有効にしたほうが手間が少なくていいと思います。

SFCの改造コードは単純なのでわざわざ書かなかったのですが、改造コードが保存されるエミュレータならその方が手間がかからないかも知れませんね。


> いつもこのサイトの解析結果を楽しませて貰っています。
> 書き換え版でない初期のロム限定のバグを発見しましたので報告します。
> 民家の中でシレンが一時しのぎの効果を受けると出口に飛ばされますが、なぜか真っ暗な空間になっています(恐らく民家の中から見た出口だから真っ暗なのでしょう)。
> そこからどうにかして適当な民家に入ると、画面がぐちゃぐちゃな空間に飛ばされてしまいます。そうなると抜け出しにくくなる上かなりの頻度でフリーズしてしまいます。
> これってエミュ限定のバグということはないですよね・・・?

結構前に初期版と書き換え版の違いを調べていて、書き換え版の032073~032085にあるプログラムは通常版にはないことを発見したのですが、それがどんな時に呼び出されるのか、色々試したのですが分からず終いでいました。
それは確かにシレンでなおかつ屋内の時に分岐する処理でした。なるほど、書き換え版で修正されていたのは一時しのぎの処理だったのですね。
ということで、実機でも起こる筈です。
[PR]
# by oyasen | 2010-08-01 13:02 | web拍手への返信

web拍手への返信 その8

> うまく調整すれば町での泥棒の成功率が上がりそうなので、NPCの出現条件について詳しく知りたいです。

NPC毎に個別に調べるのは簡単なのですが、NPC出現スクリプトは長いので、全貌を調べるかどうかは分かりません。やるとしても完成するのは当分先でしょう。


> 武器や盾のことで質問で、変更は何とかできたんですけど、
> 新規アイテム(花とか)に追加することは可能ですか?
> オフセットを空き領域に移せば何とかなる感じでしょうか。

武器・盾のグラッフィクデータから離れた空き領域に追加したいグラフィックデータを入れて、
追加したグラフィックが読み込まれるように武器・盾のグラフィックを読み込む処理を改造することになるでしょう。
なので、デバッガを使ってそのプログラムを突き止め、改造する必要があります。


> 戦車といえばボウヤー系を含め、放たれた矢(銀の矢以外)がシレンに当たるのとその他モンスター、NPCに当たるのとではダメージが妙に違いますよね。

それは既によく知られているバグで、敵の矢がシレン以外に当たった時の攻撃力はシレンの攻撃力となります。
[PR]
# by oyasen | 2010-07-18 11:28 | web拍手への返信

特殊モンスターハウスのモンスター出現率のバグ

web拍手で指摘を頂いたのですが、特殊モンスターハウスに出現するモンスターの出現率が、開発者の意図したようにはなっていないようなので、調べてみました。
その他のROMイメージ改造で、次のように書きました。

039764以降 種族データのオフセット
03976E以降 種族データ
039792以降 種族データのサイズ

本来の設定は次の通りです。バイナリエディタで確認しながら見て下さい。

どろぼう:ガマラ,ガマラ,ガマラ,ガマラ,ぬすっトド,ぬすっトド,ぬすっトド,ぬすっトド
ドレイン:吸引幼虫,吸引幼虫,くねくねハニー,くねくねハニー,まわるポリゴン,まわるポリゴン
1ッ目:吸引幼虫,吸引幼虫,ぴーたん,ぴーたん,ゲイズ,ゲイズ,アイアンヘッド,アイアンヘッド
ゴースト:死の使い,死の使い,エーテルデビル,エーテルデビル,パコレプキン,パコレプキン,セルアーマー,セルアーマー
パワー:ナイフゲータ,アイアンヘッド,タウロス,デブータ,火炎入道,キグニ族

しかし、データを読み込むプログラム(03973B以降)にバグがあります。これは書き換え版でも修正されていません(書き換え版ではアドレスがずれています)。
種族データのオフセットが2バイトずつなので、それを読み込む為に引数である$00(特殊モンスターハウスの種類)を2倍にして"X"に入れ、LDA $039764+"X"としてオフセットを読み込みます。
この後、0~7の乱数を発生させて$039792+"X"と比較して、前者が後者以上だと乱数生成をやり直すようになっているのですが、2倍にされた"X"を1/2倍する処理を忘れています。その結果、種族データのサイズとして読み込まれるデータは1バイトずつ飛び、次のプログラム(039797以降)にまではみ出してしまいます。
更に、種族データのサイズは1バイトずつなのにも拘わらず、比較する時点で2バイトモードを1バイトモードにするのを忘れています。その結果、この比較処理は意味がなくなり、本来6バイト分しか用意されていないドレイン、パワーハウスのデータは2バイトはみ出してしまいます。
それでも、不幸中の幸いと言うか、偶然にもドレインハウスの次の2バイトは1ッ目ハウスの吸引幼虫*2、パワーハウスの次の2バイトは種族データのサイズである08 06(種族データと見なすと火炎入道、デブータ)なので、意図しないモンスターが出たりはしません。だから気付かれなかったのしょう。
ということで、実際は次の表から等確率で選択ということになり、出現する種族に偏りが出ます。それにしても、あまりにも初歩的なミスの連続なのですが、よく大した不具合が起こりませんでしたね。

どろぼう:ガマラ,ガマラ,ガマラ,ガマラ,ぬすっトド,ぬすっトド,ぬすっトド,ぬすっトド
ドレイン:吸引幼虫,吸引幼虫,くねくねハニー,くねくねハニー,まわるポリゴン,まわるポリゴン,吸引幼虫,吸引幼虫
1ッ目:吸引幼虫,吸引幼虫,ぴーたん,ぴーたん,ゲイズ,ゲイズ,アイアンヘッド,アイアンヘッド
ゴースト:死の使い,死の使い,エーテルデビル,エーテルデビル,パコレプキン,パコレプキン,セルアーマー,セルアーマー
パワー:ナイフゲータ,アイアンヘッド,タウロス,デブータ,火炎入道,キグニ族,火炎入道,デブータ
[PR]
# by oyasen | 2010-07-04 14:51 | 改造・解析

スプライトの圧縮

リクエストがあったので武器・盾のグラフィックデータのフォーマットを調べてみました。
それから、報告だけしておいてまだ解説できていなかったキャラのグラフィックデータのフォーマットも序でに解説します(武器・盾と殆ど同じです)。
古印体のフォーマットの応用なので、先そちらを理解した方が良いです。
1つのデータのフォーマットは以下の通りです。

・ブロック1~4のタイプ(1バイト)
・ブロック1(0~32バイト)
・ブロック2(0~32バイト)
・ブロック3(0~32バイト)
・ブロック4(0~32バイト)
・ブロック5~8のタイプ(1バイト)
・ブロック5(0~32バイト)
・ブロック6(0~32バイト)
・ブロック7(0~32バイト)
・ブロック8(0~32バイト)
……

1つのブロックは8*8ピクセルで、左から右へ16ブロック並べると次の行へ下ります。1つのデータにつき16*4ブロック、128*32ピクセルです(盾は16*2ブロック、128*16ピクセルです)。
古印体と同様に、ブロックn~n+3のタイプは、bit0,1がブロックnの、bit2,3がブロックn+1の、bit4,5がブロックn+2の、bit6,7がブロックn+3のタイプを示します。
そして、やはりタイプ0は非圧縮、タイプ1は全て透明なブロック、タイプ2は省略行は透明なブロック、タイプ3は省略行は上の行と同じブロックです。

タイプ0はそのまんま、
1行目のbit0、1行目のbit1、2行目のbit0、2行目のbit1、……、8行目のbit0、8行目のbit1、
1行目のbit2、1行目のbit3、2行目のbit2、2行目のbit3、……、8行目のbit2、8行目のbit3、
で32バイトです。それぞれのバイトは、最上位ビットが一番左のドット、最下位ビットが一番右のドットに対応します。bit0~bit3を組み合わせて1ピクセルにつき4ビットになります。

タイプ1は0バイトなので解説不要として、タイプ2,3はまず省略されたバイトを示す2バイトを入れます。bit0が1~2バイト目、bit15が31~32バイト目に対応し、0で省略、1で省略していないことを示します。
そして、タイプ2は0のビットに対応する2バイトを00 00で、タイプ3は0のビットに対応する2バイトを直前と同じ2バイト(先頭の行が省略されている場合は00 00)で埋めて、32バイトのデータを作ります。
但し、タイプ2で展開したデータはタイプ0,3とは違って、
1行目のbit0、1行目のbit1、1行目のbit2、1行目のbit3、……、8行目のbit0、8行目のbit1、8行目のbit2、8行目のbit3、
で32バイトとなります。

これを組み合わせて1つのグラフィックデータの完成です。
パレットは、0は透明、1~4は3BC5D7~3BC5DE、5~9は武器によって変わる5色、A~Fは盾によって変わる6色です。
これで展開していくと、次のようなグラフィックが出て来ます。
http://oyasen20.tripod.com/image/sprite1.png

キャラのグラフィックデータも圧縮の仕組みは同じですが、最初に横幅等を示すバイトがあり、左から右へではなく上から下へブロックを並べていく所が違います。
でも、古印体なら手作業でも展開できないことはないですが、グラフィックデータは自分で圧縮・展開ツールを作ってやらないと大変だと思います。
因みに私はまともなプログラムの開発環境がなく、グラフィックの表示はいつもJavaScriptにやらせている(非常に遅い)ので、私に展開ツールは求めないで下さい。

上の解説が分かりにくいという人は次の例を見てみると分かるかも知れません。
http://oyasen20.tripod.com/image/sprite2.png
http://oyasen20.tripod.com/image/sprite3.png
[PR]
# by oyasen | 2010-06-20 14:19 | 改造・解析