目次 | 前の話題 | 次の話題

パッチ作成への長い道(その1)

1997年10月19日

嬉しいニュースだ。日本初のバーチャル・エアラインパシフィック・ジャパン航空グループ がマスコミに取り上げられることになった。10/25(土)付けの日経新聞夕刊 「らららパソコン」という欄に掲載される。みんな買いに行こう。


今回からはシーナリパッチ作成の話をしようと思う。私がこれまでに作成したシー ナリパッチは「名古屋周辺修正シーナリ」と「東京湾改造シーナリ」だ。これらは Microsoft Japan シーナリの不具合を修正するためのものだ。またちょっとマニアッ クな話になってしまうが、ご容赦いただきたい。


Japan シーナリの問題

Japan シーナリは良く出来たシーナリだと思う。日本人ならやはり日本の空を飛び たいと思うのは人情で、それを叶えてくれる。しかし一つ重大な問題がある。それ はシーナリ中に含まれている様々なオブジェクト(物体)の位置が実際の位置から かなりずれている、ということだ。さすがに空港や無線施設はほぼ位置はあってい るがそれ以外はめちゃめちゃである。

これによって、もちろんリアリティが下がってしまうのだが、それよりもっと大き な問題がある。それは、自作シーナリを追加したいと思ったときに、位置合わせが うまく行かないという点だ。通常、自作シーナリを作るときは電子地図などを使っ て正確な位置にオブジェクトを置く。でも肝腎の Japan シーナリが不正確なため、 例えば川にかかるべき橋が海のど真ん中にできてしまったりするわけだ。

名古屋シーナリを作成するときにこれがかなり大きな問題となった。 最大の問題は名古屋城の位置である。名古屋市街を作成すると、名古屋城との相対位置が 全くおかしくなってしまうのである。また、名古屋港近辺のオブジェクトを置くと きに海岸線の位置が変なため、うまくオブジェクトが配置できないという問題もあっ た。

これを回避するには2つ方法がある。ひとつは、Japan シーナリに合わせてオブジェ クトを配置するという方法。これはそこそこうまくいくが、オブジェクトの数が多 いと位置の調整が非常に大変である。名古屋の場合、名古屋城の位置に合わせて全 てのビルの位置をずらしたりすることが必要で、これは非現実的だった。

そしてもう一つの方法は Japan シーナリを直接修正してしまうという方法だ。 これなら、全ての問題は解決できるはずである。 具体的には以下の手順で行えばいいはずだ。

  1. 逆コンパイラを使ってシーナリファイルを解析し、ソースファイルを得る。
  2. ソースファイルを修正
  3. コンパイラを使って再びシーナリファイルを再構成する。
  4. 元のシーナリファイルとの差分を取ってパッチとする。
最終的に得られたパッチを配布すれば良い。(直接シーナリファイルを配布するの は著作権の問題で×)

しかしこの作業には相当な苦労を要したのである。


逆コンパイラの問題

まずは逆コンパイラの選定である。といっても、当時は bgl2bgs しか選択 肢はなかった。また、コンパイラは bglcomp を使うことになった。bgl2bgs の出力するソースをコンパイルできるのは bglcomp だけだからだ。困ったことに両方とも若干バグが含まれていたり、機能不足だった りして、回避方法を見つけるのに一苦労である。(なお、この問題については名古 屋修正シーナリのドキュメントにちょっと書いてある。)

特に bgl2bgs はいくつかのレコードを解析できなかったため、やむなく即席の逆 コンパイラを作るしかなかった。FS5STRUCT.TXT を見ながら、少しずつ作っていく のである。結構根気のいる作業である。

この即席コンパイラをちゃんと作りなおして、SCASM 形式のコードを出力できるよ うにしたのが SCDIS である。だから、今ならパッチ作成は結構楽であるが、 名古屋修正シーナリの開発当初は bgl2bgs を使わざるを得なかったのである。


ビューワの作成

実は逆コンパイラの問題はさほど大した問題ではなく、他にもっと大きな問題があっ た。それはシーナリの視覚化の問題である。

bgl2bgs が生成したファイルはテキストファイルである。このファイルにはシーナ リの全ての情報が詰まっている。が、ファイルのどの部分が実際のどの部分(名古 屋城とか、川とか、空港とか、、、)に対応するかはそう簡単にはわからない。何 等かの視覚化ツールが必要であった。

最初に行った対応は比較的シンプルな方法である。ソースコードを PostScript 形 式に変換して、GhostView などで見るのである。変換ツールは Perl で書いた。 表示されるオブジェクトがソースのどの行に対応するのか調べるため、行番号も PostScript の中に埋めこむ方法をとった。

この方法はそこそこうまく行き、必要なオブジェクトの位置を特定することが出来 た。でも使い勝手は最悪であった。最大の問題は、変換にかなり時間がかかり、かつ GhostView の速度も遅いため、ビューワで見るだけでかなりいらいらさせれらるという点 だ。特にズームが上手くいかないので、ズーム率を変更する度に変換ツールの起動 とGhostView の起動をしなおさなければならない。

何とかしなければいかんな、、、とは思ったのだが、最初は我慢して使いつづけた。 他にいい方法がなかったのだから仕方が無い。唯一の方法は専用のビューワを Windows プログラムとして作ることであったが、この時はそこまで余裕がなかった。


根気のいる修正作業

修正作業で一番時間がかかったのは海岸線の修正である。そこで、この修正方法に ついてちょっと説明しよう。

MS JAPAN の海岸線は細かく分割されて描画されている。この1つ1つをセグメン トと呼ぶことにしよう。まず先程のビューワを使って修正するセグメントを一つ選 ぶ。そして、このセグメントと実際の地図を見比べてただしい位置を計算する。 そして、対応するソースをエディタで修正するのである。

地図は電子地図(私は MapFan というのを使った)を使う。電子地図でないと、緯度・ 経度を得るだけで大変である。

MapFan にはルート機能というのがある。これは本来、特定の経路の距離を測った りするための機能なのだが、この機能をうまく使うことにした。MapFan ではルー ト情報をファイルに保存することができる。このファイルにはルート上の 各ポイントの位置が納められているはずだから、それをうまく引き出すことができ れば作業を楽に行うことができるはずだ。

具体的にいうと、さきほど選んだセグメントと同じものを MapFan の地図上でルー ト機能を使ってトレースするのである。それをファイルに保存し、このファイルか ら緯度・経度情報を引き出してやればいい。

もちろん、このためには MapFan のルート情報ファイルの形式を知らないといけな いのだが、幸いこのファイルはテキストファイルで、内容の解析にはさほど時間は かからなかった。

それとルート情報ファイルから緯度・経度情報を引き出し、bglcomp のソースファ イルで使用する座標変換を行うための変換ツールも作った。これも Perl で書いた。 Perl は便利である。Perl がなかったら、パッチは存在しなかったであろう。

あとは全部のセグメントを手作業で1つ1つ修 正していくだけである。かなり単調でかつ集中力を必要とする作業で、ツールの使い にくさとあいまって脳味噌が爆発しそうであった、、、

続く、、、


今回の内容についてアンケートにお答えください。
とても面白い まあまあ面白い 普通 あまり面白くない 全然駄目


目次 | 前の話題 | 次の話題