第-32760回吉里吉里オフ会を今回も開催致します。詳しくは第八回吉里吉里オフ会inコミケ69 参加者募集のお知らせ こちらをご覧ください。

そういえば GDB: The GNU Project Debugger って wchar_t 文字列をちゃんと表示してくれないよなーと思ってたのですが、GDB をハックして表示するようにしてしまいました(GDB6.3へのパッチ)。

insightではこんな感じ (ここではwxCharはwchar_tのtypedefです)

実際は 2バイト幅の整数へのポインタを UTF-16 として、4バイト幅の整数へのポインタを UTF-32 と無理矢理解釈して表示します。wchar_t が違うエンコーディングだった場合は知りません。

また、natural 形式の表示では整数型だと10進数しか表示されなかったところを、「16進数」「それをUTF16またはUTF32文字として解釈した場合の文字」も表示もするようになっています。

ただ本来は UI 側の文字コードに会わせてエンコーディングを適切に変換して表示してやる必要があるのですが、現在は UTF-8 固定です。insight は内部的に UTF-8 が使われているようなので表示できていますが、Eclipse CDT とかではダメのようです。

あと、MinGW の右側にある Proposed: Insight/gdb からダウンロードできる gdb (6.3 + Insight 6.1) が、なぜか関数にステップ・インするとセグメンテーション違反を起こしていたのも修正。

しばらくの間、自分が使う分には良さそうです。

動画形式はいろいろあるのですが、それなりにいろいろ問題があります。

• MPEG I はもうそろそろ時代遅れかなぁ
• MPEG I でさえたとえばLayer3(MP3のこと)を使ったコンテンツの配布はMP3ライセンスに引っかかるかも
• MPEG4系 (XviD、DivX、MSMPEG4など) は特許関連が不詳
• コーデック配布それ自体がライセンスや特許に引っかかる場合がある
• XviD とかはライセンスが GPL (LGPLではなく) だったりしてちょっと使いにくい(これを組み込んでゲームを出したらしいあそこは大丈夫なんだろうか)
• OS付属のコーデックはあまり信用ならない

吉里吉里３はマルチプラットフォームを目指す手前、特定のOSに特定のコーデックが入ってることを期待することができないため、自前でコーデックを持たざるを得なくなります。

で、Theoraを標準に でも触れたように、特許の問題がとりあえず無くて、フリーで使いやすいコーデックというと現状やっぱり Theora になるなぁ、と。

ビデオ再生は割とパフォーマンスにシビアな場合が多く、たとえばハードウェアサポートがある場合はハードウェアサポートを利用するなどの最適化に考慮を払うべきだったり、安定して再生するためにバッファリングを内部で行わないとならない状況があったりと、わりと厄介な代物です。

このような状況下で、ゲームなどのアプリケーションへ動画再生機能を組み込みたいときに、安心して使える、使いやすいライブラリがあると便利かな、というわけです。

で、楓 softwareさんの所で開発中の動画再生ライブラリを吉里吉里３では使わせていただこうと考えています (経緯はこちら)。

ちなみに吉里吉里２は前のバージョンではOS(というかDirectShow)にコーデックを選ばせていたので、環境によっては変なサードパーティ製のコーデックが使われたりして再生不具合が生じる、と言ったことが良くありました。しかし、最近のバージョンではたとえサードパーティ製のコーデックが入っていたとしても、OS標準のコーデックを強制的に使うようになったので、コーデックがらみの問題はほとんど聞かなくなりました(こちらも楓 Softwareの井元氏のありがたいご尽力による)。

寒い！

for(;;);

吉里吉里3 ファイルシステムの設計と実装に入りました。

といってもまだまだ初期段階ですが ... 先は長い。

とりあえず考えていることをば。もちろんこれらは案であって最終的には違う物になっているかもしれません。

前にもここで書いたとおり、POSIX風味のファイル名規則を持ったファイルシステムを導入します。

'/' (ルート) を基底とし、'/' (スラッシュ) を区切りとしたツリー構造で管理します。

ツリーの任意の場所に「ファイルシステム」を「マウント」することができます。マウントを行うと、その場所がそのファイルシステムの中身を参照する形になります。たとえば /data に data.xp4 をマウントすれば、/data/image/imo.tlg は data.xp4 の /image/imo.tlg を参照することになります。

ファイルシステムの種類はとりあえず4つぐらい考えていて、

• osfs - OS のファイルシステムを参照するファイルシステム
• tmpfs - メモリ上ののファイルシステム
• xp4fs - XP4 アーカイブ
• pathfs - 自動検索用ファイルシステム

となっています (たぶん最終的にはプラグインで拡張可能にします)。

OS のファイルシステムには osfs をマウントすることでアクセスできます。

たぶん、起動直後は '/' (ルート) に tmpfs がマウントされている状態で起動すると思います。起動時にどこにどのファイルシステムをマウントするかはいろいろ考えるべき所ですが ...

tmpfs はすべてがメモリ上に作成されるファイルシステムです。高速なアクセスが可能で書き込みも可能ですが、揮発性(プログラムが終了すると消えてしまう性質) です。でもそれだけだとちょっとつまらないので save や load のようなメソッドを用意して、内容をシリアライズして保存、あるいは読み込みができるようにしたいと思います。なにかのセーブデータが複数のファイルで構成されるような場合、いったん tmpfs を新規にマウントして中にファイルを書いて、それを save メソッドで osfs 上のどこかに保存してアンマウント、のようなことをするとセーブデータが一つにまとまる、といった感じです。

xp4fs は Releaser で作成した XP4 アーカイブを扱うファイルシステムです。

pathfs は、吉里吉里２で言うところの自動検索パスを実現するファイルシステムで、複数箇所のディレクトリの中身を、あたかも一つのディレクトリの中にファイルが全部あるかのように見せることができるファイルシステムです。

マウントの方法は

// OS のカレントディレクトリを '/os' にマウント
Files.mount("/os", new Files.fs.OS("."));
// '/os/data.xp4' (OSのカレントディレクトリ下のdata.xp4)を '/data' にマウント
Files.mount("/data", new Files.fs.XP4("/os/data.xp4"));
// '/data' 以下のファイルをすべて一つのディレクトリにまとめて '/all' から
// アクセスできるようにする
Files.mount("/all", new Files.fs.Path("/data", true));

のように、new で作成したファイルシステムオブジェクトを Files.mount にマウントする形になると思います。ファイルシステムオブジェクトはファイルシステムそれぞれ独自のメソッドやプロパティを持つことができます (たとえば上述の tmpfs の save や load メソッドのようなもの等)。

気が向いたら wxWidgets のファイルシステムをそのまま参照するファイルシステムを作るかもしれません。wxWidgets はそれ自身で独自のファイルシステム (wxFileSystem) を持っているので、それはそれで便利だろうということです。HTTPとかFTPとかzipアーカイブとかをマウントできるようですが、読み込み専用です。

なんか複雑だなーと思われるかもしれませんが、吉里吉里２みたいに OS のファイル名規則と独自のファイル名規則の両方を処理できるように苦心していたり XP3 アーカイブファイルの中身をその仕組みの中で透過的に扱おうとあがいているのに比べれば、実は内部構造的にはすっきりする予定。いったんマウントポイントとそこにマウントするファイルシステムを決めてしまえば、アプリケーション側ではそれが実際にどういうファイルシステム上にあるかを考慮しなくても同じ名前、同じ規則でファイルにアクセスできるので、そっちの面でもすっきり楽になるんじゃないかと思っています。