作りかけの物(といっても当初考えていた機能はほとんど入ってます) を ここにおいておきます (zip形式, 約2.7MB)。おまけで吉里吉里3 レンダリング済みフォントファイル作成ツールも入ってます。

ちなみにアーカイブファイルを作成できても、それを使うアプリケーションがまだないです。

Windows 版しかまだ作ってないけど、 Releaser 自体は wxWidgets の機能しか使ってないwxWidgetsとlibtomcryptの機能しか使ってないので UNICODE ビルドの wxWidgets が存在するプラットフォームならばコンパイルにはさほど難は無いはず。

このReleaserの使い方についてはここにドキュメントのドラフトがあります。

それにしてもこのコマンドラインインターフェースは初心者にはきついような。どなたか GUI フロントエンドを作ってくださらないかなぁ………。せっかく吉里吉里3 Releaer が wxWidgets 使ってマルチプラットフォームなのでできればフロントエンドも wxWidgets あたりでとか。

最近考えていたことのまとめ。

基本的なところから言えば、まずアーカイブファイルシステムを持つことは今日日、必須です。それと、(パッチを出すことの是非の論議はおいておいて)リリース後のパッチを考えないわけにはいきません。

アーカイブファイルシステムは信頼性の高いものでなくてはなりません。吉里吉里２/KAG3の、ファイルの自動検索パスの優先順位を利用したパッチの方法は、アーカイブへのパッチの当て方としては必要十分とはいえ、あまり信頼性が高いものではありませんでした。

なので、

• アーカイブファイルシステムをもちろん持つ
• アーカイブファイルシステムのレイヤーでパッチを当てる機能を提供する
• 複数の、しかも数百個のパッチを受け付けても破綻しないような構造

最後の数百個のパッチ、というのは、開発途中ではデバッガーさんに修正分を送るために日々の差分を送ると聞き及んだので、そのパッチが数百個にもなりうるんじゃないかということからです。実際の運用ではあり得ないと思います。うーん、でもそれってアーカイブにしなくても個々のファイル単位で送ってもいいような。まあでも安易に仕様用途を想定してしまうと後が怖いし足回りの部分なのでrobustであるに超したことはないですね。

既存の吉里吉里２のアーカイブファイルシステムから引き継ぐ特性は以下の通りです。

• 2GBを超えるアーカイブのサポート
• UTFなファイル名インデックス(ただし吉里吉里２のUTF-16に対して吉里吉里３ではUTF-8)
• セグメントのサポート(一つのファイルを複数の領域に分割して格納する)
• 内容の全く同じファイルをまとめる機能(同じ内容のファイルがいくつあっても一つ分のファイルの容量しか食わない)
• 圧縮メタデータのサポート
• 拡張可能なメタデータ形式
• ファイルのZLIB圧縮のサポート

既存の吉里吉里２のアーカイブファイルシステムについているOggVorbisのコードブック共有はがんばって機能をつけるほどの効果がない (ヴォイス100MBに対して5MBとか) のでつけない方向で。もっともこれはセグメントをサポートしてるから実現できている機能なので、吉里吉里３でもやろうと思えばアーカイブファイルの形式を変えずにサポートできる範囲ではあります。

吉里吉里３のアーカイブファイルシステムは、アーカイブファイルシステムのレイヤーでファイル分割をサポートします。630MB付近で分割するとかそんなのです。

アーカイブファイルのファイル名は、拡張子は xp4 で、分割やパッチに対しては連番がつくと思います。

たとえば、data.xp4 がベースのファイル名だとすれば、分割されている場合は data.001.xp4 data.002.xp4 … のように、data.nnn.xp4 が後に続きます。パッチは data.pYYYYMMDDhhmmss.xp4 のような感じで。パッチが分割される場合は data.pYYYYMMDDhhmmss.nnn.xp4 。実際には data.xp4 が読み込まれた後、data.*.xp4 が ASCII 文字順にソートされて、その順番にてパッチや分割ファイルが適用されます。そのためファイル名は完全にこの規則である必要はありませんが、一応規定としては。この処理からもわかるように、パッチの機構と分割ファイルの機構は(xp4を使用する側としては)全く同じ機構です。

アーカイブファイル名がこんなんなので CD-ROM にそのまま放り込む場合は Joliet を使うか、Solaris を相手にする? ならば RockRidge 拡張込みで。

アーカイブファイルを作成するツールは、当面コマンドラインツールにします。パッチの作成も、既存のアーカイブと、リファレンスとなっているディレクトリを自動的に比較して作成するようにします。

コマンドラインツールにする利点は、もちろんその機能を他のツールの中に簡単に組み入れられるからですね。makeでアーカイブ作成まで一発とか。GUIじゃないとイヤだって人もいるかもしれませんが、それは追々GUIフロントエンドを(私あるいはどなたかが)作ると言うことで。

あと、(パッチや分割とは別に)複数のアーカイブファイルシステムは使えるようにしますが、それはどちらかというとアーカイブファイルシステムのレイヤーの話ではなくて吉里吉里３のファイルシステムのレイヤーの話です。

相当前の話ですが吉里吉里開発サイトの trac を 0.9 にしました。

0.9 では データベースバックエンドを SQLite ではなくて PostgreSQL にもできるようになっています。自分にとっては PostgreSQL の方が管理経験が長いからと、どうも解決ができなかった #4 が解決できるのではないかという期待から、trac のデータベースバックエンドを PostgreSQL に変えてみました。

trac の PostgreSQLバックエンドサポートができたのが最近だからかとは思いますが、一部の機能が制限される(ホットコピーが完全でなかったり)ので不安は少しあります。

で、SQLite バックエンドからデータを保ったまま PostgreSQL バックエンドに移行する方法は見つけられなかったのですが、自分の行った方法を下記に示します。参考になれば。

1. trac環境を、PostgreSQLバックエンドを使って構築する (これが移行先となる)
2. そうして作られた PostgreSQL データベースからスキーマだけを pg_dump -s trac-kirikiri > /tmp/schema などとして取り出す
3. 現在のSQLiteデータベースの内容を sqlite trac.db '.dump' > /tmp/dump などとしてダンプする
4. SQLiteからのダンプのうち、CREATE TABLE 文と CREATE INDEX 文を削除する
5. SQLiteのダンプの前に、PostgreSQL からのダンプの内容をくっつける
6. シーケンスを補正するために、SELECT setval('report_id_seq', (SELECT max(id) FROM report)); と SELECT setval('ticket_id_seq', (SELECT max(id) FROM ticket)); をダンプに追加する (SQLiteとPostgreSQLではシーケンスの扱いが違うのでこれが必要)
7. PostgreSQL にその内容を取り込む (いったん移行先のDBをdropdbで消してcreatedbで作り直してからpsqlの-fオプションなどで取り込む)

さて、#4 が直ったのかどうかは何かコミットする物ができてから確かめるということで。

以前の日記でファイル名に関して少し触れたのですが、それからいろいろ考えていくうちに、吉里吉里３では POSIX ファイルシステムと似たような方法で管理するのがよいのではないかと思うようになりました。

つまり、すべてのフルパスは / (ルート) から始まり、その下にファイルシステムのすべての階層が構築されています。起動直後は / (ルート) しか存在しませんが、初期化中に OSネイティブのファイルシステムは /os 下に、あるいはアーカイブファイルは /data に、と言った具合に、任意のマウントポイントにほかのファイルシステムをマウントできるようにします。

これの利点は、自由に任意の場所に任意のファイルシステムをマッピングできるため、ファイルの置き場所を固定ししてプログラミングしてもよくなるということですかね。たとえば画像は必ず /image にあるとか。

自動検索パスの実装はどうしたものかと思いますが、同じマウントポイントに複数の他のファイルシステムをマウントすることで実装しようかと思います。つまり、たとえば /data にアーカイブ a と b がマウントされていれば、a と b にあるファイルを両方参照できるけれども、同じファイル名がある場合は b にあるファイルが優先されて参照される、といった具合です。

吉里吉里３のアーカイブファイル形式は、吉里吉里２で使用している xp3 ではなくて、別の形式になると思います。

たとえば、xp3 はパッチの機構をそれ自体では持っていなくて、KAG3 が提供している「パッチ」(修正パッチ)の機構は吉里吉里の自動検索パスの優先順位を応用したものです。吉里吉里３ではアーカイブファイルを扱うレイヤでパッチの機構を提供するようになると思います。ただ、KAG3 のパッチの形式も、複数の元アーカイブファイルに対するパッチが一つのファイルで済む、といった利点もありますので、一概にどちらがよいとはいえないかもしれません。

DEPはマイクロソフトのデータ実行防止機能だそうです。某所で気になる報告を見かけたし、Athlon64 になったので試してみました。

吉里吉里も一部でアセンブリソースのセクションの指定を忘れてコードがデータ領域上におかれてしまっていたので修正です。

…そういえばいままで平気でデータ領域だろうがなんだろうがそこにコードがおかれてそこにジャンプすればコードを実行できたんだなぁ。

Opteron 180 はどこに売ってるのかよくわからなかったし時間もなかったので Athlon64 x2 4800+ と A8N-SLI Premium と 1GB DDR400 × 2 買ってきました。あとSATAの250GBのHDD。電源。

WindowsXPはせっかくなのでクリーンインストール(←おまえほんとに時間がないのか)

とりあえず、速いです。BCBでのコンパイル速度は、前のマシン(Intel Pentium4 2.53GHz) に比べて 体感で２倍ぐらい速いです。しかもBCBは並列コンパイルをやらないのでCPUは1コア分しか使ってないのに。

早くgmakeに-j3 とかオプションをつけて並列コンパイルとかやってみたいのですが、なにせクリーンインストールをしたので環境を取り戻すのが大変です。