W.Deeの2006年2月の日記

kikyou.info»日記

誠に勝手ながら、kikyou.infoは2017年12月いっぱいをもって閉鎖します。ながらくありがとうございました。

最新月 : 2008年10月
2003年 [             3    4    5    6    7    8    9   10   11   12  ] 月
2004年 [   1    2    3    4    5    6    7    8    9   10   11   12  ] 月
2005年 [   1    2    3    4    5    6    7    8    9   10   11   12  ] 月
2006年 [   1    2    3    4    5    6    7    8    9   10   11   12  ] 月
2007年 [   1    2    3    4    5    6    7    8    9   10   11   12  ] 月
2008年 [   1    2    3    4    5    6    7    8    9   10   11   12  ] 月
2009年 [   1    2    3    4    5    6    7    8    9   10   11       ] 月
前月の日記  次月の日記

2006年2月11日

AtomicFS

今のところ TmpFS(いわゆるRAMディスク)、XP4FS(XP4アーカイブファイルへのアクセス)、OSFS(OSの提供するファイルシステムへのアクセス)、PathFS(自動検索パスを実現するファイルシステム) を実装している吉里吉里3のファイルシステムですが、AtomicFS というのを新たに考えています。

たとえばゲームのセーブデータなどはサムネイルやフラグなどの複数のファイルから成り立っていることがありますが、本来同時に更新されなければならない複数のファイルのうちの、どれか一つのファイルの更新が終わったときに、不意の出来事(OSのハングアップや電源断)があると一貫性がとれなくなってしまいます。セーブデータが壊れたなんて話は実際よく聞く話だったりします。

AtomicFS はバックエンドにACIDを実現しているデータベースエンジンを使ったファイルシステムで、ファイルシステムに対してファイルの追加、削除、更新などの「変更」を行うことは出来ますが、最終的に「コミット」を行う段階までこれらは永続化されません。コミットは原子性が保証されています。コミットまでの「変更」を行ってる途中で何らかの原因でプロセスが中断しても、それらの変更はあたかも無かったかのように扱われ、整合性が保証されます。

バックエンドには SQLite を考えています。これ自体はSQLを解釈できるデータベースエンジンなので、ファイルシステムのファイル階層からクエリへのマッピングをある程度自由にカスタマイズしておけるようにすれば、既存のデータベースをファイルシステム上にファイルとしてマッピングするような用途にも使えるかもしれません (SQLFSという名前の方がいいかな)。

もっともとりあえず他の実装項目の方が優先順位が高いのでこれ自体の実装は後になりそうです。

ちなみに TmpFS は前に書いたような気がしますが、save と load という2つのメソッドを持っていて、内容を他のファイルに永続化することが出来ます。しかしACID性はありません。

RisaGL

吉里吉里2では内部的にtvpglと呼んでいる、グラフィック関連のプリミティブな操作を集めたライブラリがあります。どれぐらいプリミティブかというと、水平方向に指定ピクセル分アルファブレンドを行う、ぐらいです。ビットマップの領域と領域を重ね合わせて、というのはまた別の部分が担当しています。

吉里吉里3ではたぶんRisaGLと呼ばれるようになるそれですが、tvpglはかなり内部構造がぐちゃぐちゃしてるし、いっそのこと書き直そうかなと思ってます。

で、テンプレートを駆使して作れないかな、と思っています。

STL が char_traits で文字の特性を表しているように、たとえば blend_traits が ブレンド関数の特性を表していて、それを使って単純なブレンド関数や拡大・縮小時しながらのブレンドなどを書くと。速度的にクリティカルな部分はテンプレートを特化させて書くなどしたとしても、大幅にコーディング量を減らせるような気がします。

似たようなことは誰でも思いつくでしょうから、たぶん世の中に似たようなライブラリはあるんだと思います。吉里吉里3の要求に合うかどうかはよく見極めないとならないと思います。要求に合うのがあればわざわざ書く必要はないですね。AGGはよくできてると思いますし、描画のクオリティは高いしベクトル画像の描画も含めた総合的なライブラリで魅力的ですが、速度的にちょっと不満があります。

あと、アセンブリ言語はもう書きたくないです。書きたくないけどMMXやSSEへの対応とかどうするよ、ということになれば、コンパイラの intrinsic (コンパイラ組み込み関数) で

return  _mm_xor_ps(_mm_and_ps(_mm_and_ps(a1, C1), b1), C3);

のように書きたいです。これならば x86_64 でもソースコードに手を加えることはないし、レジスタの割り当てやプロセッサごとの命令タイミングの調整なんかはコンパイラが勝手にやってくれるし、テンプレートとして実装しても使えそうだし、と、いろいろ都合が良さそうです。等価な命令があれば他のSIMD実装への応用も簡単かもしれません。

もっとも intrinsic についてはOgg Vorbis 高速化プロジェクトの中の方の受け売りですが... (ちなみに吉里吉里3ではOgg Vorbisのデコーダとしてそのうちwuvorbis.dllではなくてこっちの成果を使わせて頂こうかと思っています)。

…ということで、割と吉里吉里本体の実装とは独立して並列して進められる部分なので、どなたかやってみませんか?(^^; (気になる方は 吉里吉里エンジン開発用MLへお願いします)。

2006年2月6日

ロギングとコンソール

サウンド関連のイベントをテストしようと思ったらイベントシステムが必要になって、イベントの発生を時系列で追おうと思ったらロギングの機構が必要になって、ログも見たいし 気軽に TJSを入力してテストできる環境も欲しいのでコンソールが必要になって、ということで今はコンソールを書いています。

吉里吉里2のコンソールはコンソールといっても、ログがだらーと表示されるログビューアと、TJS式を入力してそれをその場で評価できる入力欄が組み合わさっただけの物でした。吉里吉里3もそんな感じで作ります。

ログ機構は重要ですね。ログには様々な情報が含まれているので、ログファイルを現場から改修すれば、障害解析に非常に役に立ちます。自分も吉里吉里2では何度も助けられています。

2006年2月4日

Reverb

相当前の話になりますが、リバーブ(残響音) フィルタとして Freeverb を元にしたフィルタを実装しました

Freeverb は public domain なリバーブの実装です。本家のサイトは落ちているようですが、オリジナルのソースは osdev-jのwikiのこのページから 拾うことが出来ます。

パラメータはいろいろいじらないと難しいですね。前にsoxのリバーブが気に入らない等と書いてしまいましたがこっちも調整次第なのかも。

プリセットのパラメータとしてはZynAddSubFxの物(これも内部でFreeverbを使用しています)がよいようなので、引っ張ってくるかもしれません。