データ構造 - セプテントリオン/SOS攻略wiki

データ構造

メモリ一覧では詳細を説明しきれないデータ構造について個別に整理します。

キャラクター管理データ

同行者やイベントで現れるキャラクターに関する管理データに対しては、キャラ管理データA,B,Cの3種類が最大16人分用意されています。
※例外的に、管理データAの主人公の1つ前の領域は、類似データがマーカー用に保持されています。
主人公および同行者は先頭12人分、先頭が主人公、後から加入した同行者が低位アドレスに、そしてイベント時に一時的に加入するキャラは最大4人分が末尾に格納されます。( 低位アドレス優先 )
※この一時的に加入しているキャラは、救出イベント時に同行者に組み込まれるキャラも兼ねています。

管理データA

0x7e04b0から保存されている、キャラあたり32バイトのデータです。キャラの見た目や位置に関する情報が主に格納されています。キャラのIDもこの領域に保存されています。
他の管理データと異なり、先頭はマーカー用のデータです。そのため一部使われない要素もあります。
コード内では、あくまで先頭は主人公分(0x7e04d0)として扱い、マーカー部分は-1番目の負の要素という体でアクセスします。

オフセット	サイズ	データ概要	データ詳細	備考
0x00,2	2x2	画面上x/y座標	表示位置のx/y座標(ピクセル値)です。 x座標では左端が0で右端が255、y座標では上端が16で下端が176です。 主人公は一部状況を除き、中央部分にほぼ固定されます。 ※x座標が128、y座標が128±最大4(船の揺れ分) なお、基準点(通常体の軸の足元)の数値なので、上端～下端の範囲に 収まらない数値の場合も一部が表示されるケースがあります。
0x04	2	姿勢情報	キャラの表示に影響します。 通常のキャラの場合、上位バイトはOAMの調整用データ、 下位バイトはキャラの表示順(1～7)です。 上位バイトの0x80のビットは上下反転表示フラグ 0x40のビットは左右反転表示フラグ 0x30の2ビット分は優先順位の調整用です。 下位4ビットは操作しません。	マーカーの場合、 0x2001が赤、 0x2a01が黄を表します
0x06	2	姿勢ID	キャラのポーズを決定する数値です。	マーカーでは不使用です。
0x08	2	キャラID	キャラクターのID(0～63)です。
0x0a,c	2x2	キャラ状態 サブパラメータ	キャラ状態の遷移を管理するサブパラメータ	マーカーでは、0x0cのみ、マーカー更新用カウンタに使用します
0x0e	2	キャラ状態	地上、ジャンプ中等の状態を示す数値	マーカーでは同一画面フラグです。 同一画面なら0、 異なる場合は0x800です。
0x10,12,14,16	(2x2)x2	マップ上x/y座標	回転の影響を除いた、1/1,048,576px単位のx/y座標です。 x座標では船尾側が、y座標では上層側が小さい数値となります。 4バイトの数値ですが、一括では扱えないので、 前後半(下位・上位)のワードにわけて扱います。 前半が端数で、後半が1/16px単位数値相当です。	マーカーではオフセット0x14(y座標下位)は常にゼロです
0x18,1a,1c,1e	(2x2)x2	マップ上x/y速度	マップを基準にした空中での1/1,048,576px単位符号あり移動速度です。 座標が小さくなる向き(船尾方向、上層方向)に正となります。 4バイトを前後半に分けて扱うのは前出x/y座標と同様です	マーカーでは不使用です。

管理データB

0x7e14f2から保存されている、キャラあたり16バイトのデータです。体力等、誘導操作に関するデータが格納されています。

オフセット	サイズ	データ概要	データ詳細	備考
0x0	2	地形データの値	そのキャラのいる場所の地形	何もない場所(地形値0～0xf)が対象
0x2,4	2x2	前の人との距離	一つ前の順の人とのx,y座標差(絶対値)	px未満の端数切捨て 先頭の人のみ、マーカーとの座標差
0x6	2	前の人との距離目標	前項の目標値	通常は56px(0x380)
0x8,a	2	体力値	最大および現在の体力	(本wiki掲載の値-64)×256
0xc,d	1x2	目的地	矢印のマップ上x,y座標の上位バイト y座標はMSB除く?	16ピクセルで1変化 ロスト時は代表キャラ(隊列の最後尾)のみ ランデブーポイント位置を反映
0xe,f	1x2	現在地	マップ上x,y座標の上位バイト

管理データC

0x7e06f0から保存されている、キャラあたり16バイトのデータです。
詳細は不明ですが、イベントの進行に関わるデータを管理していると考えられます。

オフセット	サイズ	データ概要	データ詳細	備考
0x0	2	キャラ状態?	非同室時は0x800のbitが1になる
0x2	2	不明	調査中
0x4～0x7	4	不使用?	おそらく使用されない
0x8	2	実行中コマンド	当該キャラが対象となるコマンド1～4に応じて、0,8,10,18の値が設定、 0x8000を加算する場合もある
0xa	2	次チャンクID補正値	Xで話しかけた時に処理されるチャンクID $0424をベースとした補正値	Yで話が進む際のIDは別途管理
0xc,0xe	2x2	落下距離基準座標	落下距離を計算する際のマップ上x,y座標(1/16px単位)

イベントデータ

概要

イベントデータは一部無効なものを含み0～254のIDで管理される不定長のデータで、0x9e9c20をベースとする配列にID毎の先頭アドレス(バンクを除く下位ワード)が格納されています。
イベントデータは、ID0～90がバンク0x9fに、91～254がバンク0x9eに格納されています。
※ただしID90は無効データです。

イベントデータは非圧縮・圧縮形式が混在し、前者は直に、後者はRAMの0x7fe800～に伸長した上でアクセスして使用されます。

圧縮方式

イベントデータのうち、表エリアに割り当てられた一般のイベント以外は全て圧縮形式で保存されています。
圧縮データは一口に形式を説明をすることはできず、伸長するためのアルゴリズムに沿って解釈する必要があります。

• 基本的な考え方
  • データの圧縮は、繰り返し現れる同一パターンを、より小容量のデータ表現に置き換えることで実現します。
  • そのため、圧縮前のデータに対して、「新規出現データ」と「既出パターンデータ」に分けて考えます。
  • 例えば最小のイベントデータ(空イベント) である48バイトデータ(16進)
    "0000 0000 ffff ffff 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000"
    に関しては、次のような内訳で考えます。
    • 最初の1バイト"00"は新規出現データとします
    • 次の"00 0000"は、前項の"00"の既出パターンの3バイト分繰り返しと見ます
    • 次の"ff","ff ffff"は、1バイトの新規出現データ"ff"と、その3バイト分繰り返しと見ます
    • 次の"0000 0000"は、先頭の"0000 0000"の既出パターンの4バイト分と見ます
    • 残りは、既存の"00"の36バイト分繰り返しと見ます
  • 既出パターンについて、これまで現れたデータの末尾に関しては特別扱いができます。
    例えば X,Y,Z という3バイトが末尾になっている場合、これを10文字分と指定すると X,Y,Z,X,Y,Z,X という繰り返しとして扱えます。
• 圧縮データの伸長方法
  • 圧縮データは、次の3種類の混在と見て伸長処理を行います。
    • 新規/既出区分フラグバイト
      前者1バイトをビット1、後者1まとまりをビット0として8か所分まとめてバイトデータを構成します。上位ビットが最初の方のデータを表します。
      例えば fa(11111010) というバイトであれば、5バイトの新規出現データ、1まとまりの既出パターン、1バイトの新規出現データ、1まとまりの既出パターンの構成を表します
    • 新規出現データ
      圧縮データ内の1バイトが、そのまま新規出現データとしてのバイトを表します。
    • 既出パターン長さ・参照位置表現データ
      既出パターンに対して、その長さと、パターン先頭の解釈済みのデータの末尾に対する位置(ともにバイト単位)のペアで表します。
      こちらはバイト単位ではなくビット単位の可変長データであるため、データをワード単位で都度プールしつつ、必要分を消費していく形で解釈します。
  • 伸長アルゴリズム
    以下のアルゴリズムで伸長を行います。
    • 先頭の2ワードを既出パターン長さ・参照位置表現データ用にプールします。
    • 1バイトを新規/既出区分フラグバイトとして取得し、以降、その8か所分の解釈を行います。
    • 新規出現データの箇所の場合、1バイトをそのまま伸長データに追記します。
    • 既出パターンの場合、プールの上位1～14ビットから長さ1～255を取得します。
      ここで長さが255の場合は伸長処理を終了します。
    • 既出パターンの場合、続いてプールの上位6～14ビットから位置0～4095を取得します。
    • 長さについては前出の数値に+1して、これまでの伸長済みデータを元に既出パターンを構成し、伸長済みデータに追記します。
    • プールから長さ・位置データを取得することで、残りのプールデータが15ビット以下になった場合、圧縮データから1ワード(2バイト、リトルエンディアン)を下位に追加してプールを補充します。
    • フラグバイト分の8か所の解釈が終わったら、また次のフラグバイトを取得して伸長を続けます。
  • プールからの長さ取得
    上位ビットから探して初めて1のビットが現れる位置に応じて解釈します
    • 最上位ビットが1の場合 … 最上位ビットのみ消費し、長さ1と解釈します
    • 2ビット目が1の場合 … 上位3ビットを消費し、そのビット群の示す数値(2～3)を長さと解釈します
    • 3ビット目が1の場合 … 上位5ビットを消費し、そのビット群の示す数値(4～7)を長さと解釈します
    • 4ビット目が1の場合 … 上位7ビットを消費し、そのビット群の示す数値(8～15)を長さと解釈します
    • 5ビット目が1の場合 … 上位9ビットを消費し、そのビット群の示す数値(16～31)を長さと解釈します
    • 6ビット目が1の場合 … 上位11ビットを消費し、そのビット群の示す数値(32～63)を長さと解釈します
    • 7ビット目が1の場合 … 上位13ビットを消費し、そのビット群の示す数値(64～127)を長さと解釈します
    • 7ビット目まで全て0の場合 … 上位14ビットを消費し、そのビット群の示す数値+128(128～255)を長さと解釈します
  • プールからの位置取得
    上位ビットから探す点は同じですが、長さの取得の場合とパターンが異なります
    • 上位4ビットが0000の場合 … 上位6ビットを消費し、そのビット群が示す数値(0～3)を位置と解釈します
    • 上位5ビットが00010の場合 … 上位7ビットを消費し、そのビット群が示す数値-4(4～7)を位置と解釈します
    • 上位5ビットが00011あるいは上位4ビットが0010の場合 … 上位8ビットを消費し、そのビット群が示す数値-16(8～31)を位置と解釈します
    • 上位4ビットが0011あるいは上位3ビットが010の場合 … 上位9ビットを消費し、そのビット群が示す数値-64(32～127)を位置と解釈します
    • 上位3ビットが011の場合 … 上位10ビットを消費し、その上位3ビットを001に置き換えたビット群の示す数値(128～255)を位置と解釈します
    • 上位3ビットが100の場合 … 上位11ビットを消費し、その上位3ビットを001に置き換えたビット群の示す数値(256～511)を位置と解釈します
    • 上位3ビットが101の場合 … 上位12ビットを消費し、その上位3ビットを001に置き換えたビット群の示す数値(512～1023)を位置と解釈します
    • 上位3ビットが110の場合 … 上位13ビットを消費し、その上位3ビットを001に置き換えたビット群の示す数値(1024～2047)を位置と解釈します
    • 上位3ビットが111の場合 … 上位14ビットを消費し、その上位3ビットを001に置き換えたビット群の示す数値(2048～4095)を位置と解釈します
• 伸長例
  前述の空イベントデータを示す11バイト圧縮データ(16進)"2040 a000 b018 ff00 46e0 0f"を伸長する例を以下に示します。
  • 先頭1ワード 4020 (リトルエンディアンのためバイト順が逆) から、01000000_00100000 の16ビットをプールします
  • 次のバイト a0 (10100000)から、1文字新規、1か所既出、1文字新規、5か所既出の構成と判断します
  • 次のバイト 00 は、新規として伸長データに追記します
  • プールの先頭3ビットから長さ2、+1して3、次の先頭6ビットから位置0を取得します
  • 伸長データの末尾 00 3バイト分繰り返し 000000 を伸長データに追記します
  • プールが16ビットを切ったため、次のワード 18b0 を末尾に追加し、プールを 0100000_00011000_10110000 の23ビットに増やします
  • 次のバイト ff は、新規として伸長データに追記します
  • プールの先頭3ビットから長さ2、+1して3、次の先頭6ビットから位置0を取得します
  • 伸長データの末尾 ff 3バイト分繰り返し ffffff を伸長データに追記します
  • プールが16ビットを切ったため、次のワード 4600 を末尾に追加し、プールを 011000_10110000_01000110_00000000 の30ビットに増やします
  • プールの先頭3ビットから長さ3、+1して4、次の先頭7ビットから位置7を取得します
  • 伸長データの末尾から7バイト前、つまり先頭から、4バイト分の 00000000 を伸長データに追記します
  • プールの先頭11ビットから長さ35、+1して36、次の先頭6ビットから位置0を取得します
  • 伸長データの末尾 00 の36バイト分繰り返し 0000…を伸長データに追記します
  • 途中でプールが16ビットを切るため、次のワード 0fe0 を末尾に追加し、プールを 000_00001111_11100000 の19ビットに増やします
  • プールの先頭14ビットから長さ255を得ます。255のため、これで伸長処理を終了します。

イベントデータ構造

非圧縮、または伸長されたイベントデータの構造は、以下の図のように、ヘッダ部分とコマンド群とに分かれます。
※最小のイベントデータ(空イベント)はヘッダ情報のみとなります。(ただしゲーム上で使用されてはいません)

以下、内訳です。

• ヘッダ情報
  • メッセージIDベース値(オフセット0、ワード値)
    コマンド群での、メッセージに対応するコマンドを判断するときの、IDのベース値です。$0410に転記されて使用されます。
    基本的に、イベント内で現れるメッセージのIDの最小値-2の値が設定されます。
  • キャラ数情報(オフセット2、ワード値)
    イベントに登場するキャラ数(～4)および、救助可能人数をパックした値です。先頭バイトが登場キャラ数、次のバイトが救助可能人数となっています。
    このワード値は、$0412に転記されて使用されます。
  • キャラIDリスト(オフセット4、バイト配列)
    イベントに登場するキャラのキャラID一覧です。登場するキャラ数を超える分は、0xffで埋められます。
    また、死亡状態で登場するキャラの場合、キャラIDの上位ビットが1になる(+0x80される)形で設定されます。
  • キャラ座標リスト(オフセット8,0x10,0x18,0x20、4×2バイト配列)
    傾きのカテゴリに応じた、登場キャラ人数分の座標のリストです。
    座標の数値は、16ピクセル単位のx座標・y座標の値をペアにしたものですが、登場しないキャラの分や、また傾きによってイベントが発生しないケースでは無効な値が設定されます。
    なお、傾きのカテゴリは次のように分類されます。
    • カテゴリ0
      水平状態から反時計+135°～180°、-180°～-157.5°で、基本的に転覆前が該当します。
      ただし、ボイラー爆発後も、後半の+135°の傾きはこのカテゴリになります。
      ※ジャックやユーサーが+135°で現れないのは、このカテゴリで有効な座標の設定がないためです。
    • カテゴリ1
      水平状態から反時計+45°～112.5°で、基本的にボイラー爆発後が該当します。
    • カテゴリ2
      水平状態から反時計-45°～+22.5°で、基本的にボイラー爆発前が該当します。
    • カテゴリ3
      水平状態から反時計-135°～-67.5°で、通常のプレイではまず現れない傾きです。
  • キャラ別初期チャンクオフセットリスト
    各キャラにXボタンで話しかけた時に発動するチャンクのIDの初期値リストです。ただ、バイトデータだと収まらない場合があるため、ベース値からの差分を格納します。
    チャンクの発動が設定されない場合は0が格納されます。
  • 開始チャンクID(オフセット0x2cのワード値)
    イベント開始時、あるいはキーとなるキャラに近づいた時に自動で話しかけられる場合のチャンクIDを保存します。これは$0416に転記されて使用されます。
    なお、最上位ビットだけは扱いが別で、このイベントがプロローグでの共通メッセージによるものかどうかを示すフラグとなっています。( 共通ならビット1、キャラ個別ならビット0 )
  • チャンクIDベース値(オフセット0x2eのワード値)
    イベント内で発現するチャンクIDの差分計算のもととなるベース値です。
• コマンド群
  イベントの進行を制御するための4バイトの指示データ(コマンド)を4個単位でまとめた16バイトずつのデータです。
  • 初期設定用(オフセット0x30)
    イベント開始時に発動するコマンドを保存しています。
  • メッセージ用(オフセット0x40～)
    チャンク内のメッセージが発現したときに実行されるコマンド群を、メッセージ単位でまとめたものです。