Sage's YU-NO for SS Page

SS版 YU-NO解析編

　1997年12月 4日。本来ならばこの日の PM6:00 からは SS版 YU-NO をプレイする予定であった。一応、SS 本体にゲーム CD を挿入する前に、まず PC に挿入してどのようなファイルが存在するのかだけを確認して、解析作業は一応異世界編をクリアしてからにする予定であった。どのようなファイルが存在するかというのは、 CG は SS版「下級生」と同じく、ELFPAK形式なのか、 95版「同級生２」と同じ 95GP8 なのか。音声ファイルはやっぱり ACM なのか。ムービーファイルはシネパックなのか。などを調べて、もし、CG が ELFPAK や 95GP8 なら MLIST の対応表にすかさず YU-NO for SS を書き加えてからのんびりゲームを開始するというもくろみであった……。

意外な再会

しかし、やはり予定は未定で決定ではなかった。ゲームをすること以上に解析の誘惑にかられてしまったというのはありそうな話だ。これによって予定が狂ってしまったというのならどんなに良かったことであろうか。しかし実際はそうではない。そもそもゲームそのものが購入できなかったのである。これには本人、かなりショックだった。ブルーになりながら「エロゲーを語る」の方に「YU-NO 購入編」を書きはじめた。ゲームを買わずして「語る」の方を書くというのは初めてのことだった。ある程度文章を入力し、ため息をつきながら視線を何気なくディスプレイの横に向ける。そこにはいつものように CD ケースが山積みになっていた。その山の頂点には 4枚入りの CD ケースにがあり、背には「Sega Saturn」の文字が。はあ、「下級生」の CD だな。そう思いつつ視線をディスプレイに戻す。しかし、その CD の山には何か違和感のようなものが感じられた。そう午前中までは「下級生」の CD ケースは山の一番下にあったはずだ。誰かがわざわざ「下級生」の CD を山の一番下から取りだし、一番上に置いたのだろうか？いや、違う。そもそも山の高さが午前中より少し高くなっていたような気がする。そう思ってもう一度視線をディスプレイの横に向ける。山の頂上の CD の背には「Sega Saturn」の文字が見える。がそこにあるタイトルは「下級生」ではなく、何か大量のアルファベットで埋め尽くされていた。しかも、背の色が白ではなく、緑色。これは「下級生」の CD ではない。な、なんだこの CD は？そう思ってその CD を山の一番上から取り出してみると、そこには確かに午前中にも手にしたことのある CD。そう、まさしく SS版 YU-NO の CD がそこにあったのである。

時空を越えてやってきた CD

な、なぜ、ここに YU-NO の CD が…。いかにもこの私に

「どうぞ、料理(解析)してください。」

とでもいわんばかりに置いてある CD。そ、そうか、これはきっと N 君の仕業に違いない。私が YU-NO 買えなかったことを知っていてかつ「解析したそうだから置いておいた」なんてことをやりそうなのか彼くらいなものだ。そんなときにちょうど N 君が現れたので聞いてみた。

「これ君のでしょ？」
「いや違うよ。」

へ？ということはこれは一体誰の CD なのだ？この時点で私が YU-NO を買えなかったことを知っている人物は今私のまわりに全員揃っている。しかも、その誰もが自分のではないという。ま、まさか。この CD はリフレクターを使って時間と空間を飛び越え、わざわざ私のもとまでやってきたというのか！？

とりあえず CD の中見を確認

　わざわざ時空を越えてきてまで解析されにきた CD。(勝手に決めつけている。) これを解析しなくては CD に失礼だ。というわけでとりあえず CD の中にどのようなファイルがあるか確認。予想では *.ARC というアーカイブファイルがあると思っていたのだが、実際にそこにあったのは *.ABL という初めて見る拡張子を持つファイルであった。ファイルの先頭を見てみると、ABLINK という文字が。なるほど、だから拡張子が ABL なのか。この時点で少し不安になった。もしかすると画像形式も変わったかもしれない。案の上、SS版 YU-NO に使われている画像形式は ELFPAK でも 95GP8 でもなかった。

ライブラリの使い方を間違えていた

　SS版 YU-NO の画像形式はどうも ABG という形式のようだ。通常、画像ファイルの先頭にはパレット情報があるので少なくともパレット情報くらいはわかるものだが、なぜかパレット情報がないようにみえた。じーっと眺めているとなんとなく周期的に特定の符号が見えてくるので、もしかすると今回はランレングス符号化なのかもしれないな。と思いながらもう少しじーっと眺めていると、よくよくみると ELFPAK と同じエンコーディングされているような気がした。そう思って注意深くみてみると、実はパレット情報もちゃんと存在しているようだ。なんだ、ELFPAK と同じじゃないか。と安心してとりあえずファイルを展開するプログラムを作成してみた。嬉しいことに ABG には ELFPAK と違って展開後のファイルサイズも記録されているので確認が容易だ。作ったばかりのプログラムにかけてファイルを展開してみるとファイル中に記録されている展開後のファイルサイズと実際に展開されたファイルのサイズが異なっていることに気がつく。うーん、なんでだろう、と思いつつも展開したファイルの中見を眺めてみるとどうも画像データのような気がしない。おかしい。そもそも展開後のサイズが異なっているのだからおかしいのも当然かもしれない。もしかすると、ELFPAK と似ているけど展開に使用するパラメータが実は異なっているのかもしれない。そう思って、パラメータを変えながら何回もファイルを展開してみるがなかなか同じサイズにならない。メッセージファイルを展開してみて、なんとなく正しい結果になるようパラメータを調整していくと、どうも最初のパラメータが一番正しいようだ。２時間位パラメータをいじったあげくついに展開後のファイルサイズが一致した。実は単に ELFPAK の展開ライブラリの使い方を間違っていただけだった。

2次圧縮

　やっと正しく展開できたところで、もう一度ファイルの中見を確認してみる。しかし、やっぱり画像データのような気がしない。そもそもファイル中に記録されている画像サイズらしき部分が同じ２つのファイルの展開後のファイルサイズが異なっているではないか。これはまさか2次圧縮がかかっているのか？ファイルの中を見てみるとなんとなく定期的に符号らしきものが見えてくる。おそらくランレングス符号化であろうとは思ったのだが、それにしては使われている符号の数が多過ぎる。さすがにこれを解析するのは無理か。しかし、なんとかしてこれを解析しなくては次の elf さんの新作「臭作」の画像も見れないことになってしまう。なんとしてもこれを解析しなくては。そうは思ったが、今日は午前中にゲーム屋を回ったために疲れているので椅子に座ったままその場で寝てしまった。

夢

　気がつくと時計の針は 12時を回っていた。 SS版 YU-NO が発売されてから 1日目に突入したようだ。なんとか今回も SS版「下級生」のときのようにゲーム発売日の次の日には画像ローダを作成したいものだと思った。下級生の時は寝ている間に夢を見て、その夢の中で画像形式がわかったのだが、今回はまったく夢を見なかった。そのかわり、目を開けて目の前にあるディスプレイに移っているファイル中のデータの列びを見ていると数時間の内には画像形式が判明しているようなそんな気がした。

ついに完成

　そうこうしている内に時計の針が朝の 4時を指すころには画像形式が判明。昼の 12時には MLIST に組み込んだのでした。やっぱり疲れているときは寝るに限るようです。

技術的に語る

　elf さんが独自の 256色画像フォーマットを採用したのは私が知る限りでは SS版「下級生」をリリースしたときがはじめです。(SS版野々村は知りません。) このとき、次回作の 95版「同級生２」はこれと同じ画像形式になるだろうからなんとしても、ここで下級生のローダを作成しておきたいなと思いました。ですが、SH の逆アセンブラなど持ちあわせていなかったのですから画像データそのものから画像形式を解析するしかありません。これはもう、雲を掴むようなもので、まあどんなものかなと思ってデータを眺めるだけ眺めてみました。その結果、奇跡的にしかもなんと一日で画像形式を解析することができました。

95版「同級生２」のために解析したというのに、その 95版「同級生２」といえば、実は SS版「下級生」とは画像形式が異なっていたというすごいオチが待っていました。しかし、基本的に下級生と同様のエンコーディング形式だったので、これも何とか一日でローダを作成することができました。

次にでたのは 95版「河原崎家の一族」でしたが、これはゲームを買っていないので画像形式は不明です。

その次は今回の SS版 YU-NO となるわけですが、困ったことにまたもや画像形式が異なっているということになりました。これも何とかして解析しなくては次回作「臭作」の画像が見れないと思い、なんとかして今回も奇跡的に画像ファイルを見ただけで (しかも、ゲームしていないからどんな絵かもわからない) ローダを一日で作成できたのでよかったです。しかも、プログラムを逆アセンブルして解析したわけではないので SS版「下級生」、95版「同級生２」、SS版「YU-NO」に関してはリバースエンジニアリングに引っかからない。

で、問題は「臭作」。これだけ画像形式をかえてきているのでもしかすると次回も画像形式が変わる可能性があります。しかし、次回もデータを見ただけで一日で解析できるとは限らない。私としては非常に不安です。でも、そろそろ画像形式も落ち着いてくるころではないかと思います。というのも、いままで elf さんとこの画像形式が頻繁に変わってきたのは実は画像の圧縮率が非常に悪かったからだと思えるからです。実際にどのくらい圧縮率が悪いかというと、 AliceSoft さんとこの PMS と F & C さんとこの IPF と比べてみると一目瞭然です。以下に最大圧縮率を示します。

各画像形式と最大圧縮率(1)
ソフトハウス	画像形式	最大圧縮率
elf	`GP8`	1/8
AliceSoft	`PMS`	1/130
F & C	`IPF`	1/340

上表を見るとわかるように GP8 は他の 2つの画像形式に比べ圧倒的に最大圧縮率が悪いです。理由は簡単で、PMS と IPFは画像に特化された圧縮形式なのに対し、GP8 は汎用な圧縮形式だからです。 elf さんのゲームに使われている画像以外のデータ(例えば、シナリオデータなど) も実は GP8と同じ方法で圧縮されています。そのため、最大圧縮率は確かに悪いのですが、複雑な絵に関していえば GP8の方が圧縮率が高くなることもあります。

さて、では今回の ABG の圧縮率はどうでしょう。 ABG でもやはり GP8 と同じ圧縮方法を採用しています。 (この圧縮の形式を ABZ、無圧縮形式は ABSというようです) しかし、実際、ABG では汎用の圧縮方法である ABZ をかける前に画像に特化した圧縮方法で画像を圧縮します。したがって、ABG の最大圧縮率は GP8 に比べはるかに向上しています。

各画像形式と最大圧縮率(2)
ソフトハウス	画像形式	最大圧縮率
elf	`GP8`	1/8
elf	`ABG`	1/512
AliceSoft	`PMS`	1/130
F & C	`IPF`	1/340

上表を見ればわかるように、ABG の最大圧縮率は上の中では最高になっています。しかも、最終的には汎用の圧縮方式である ABZ で圧縮されているため、複雑な絵でもそこそこの圧縮率を実現できます。

というわけで、ABG の圧縮率はかなりのものなので、今後画像形式を変えてくることはそうないのではないかと思います。というより、変えないで欲しい。

Return