monotoneの0.37、 出てたのは知ってたんだけど、またちょっと遅れてNEWS翻訳。
2007年10月25日22:35:33(UTC)
0.37をリリースしたよ。
変更点
- mtn db kill_rev_locallyがリビジョンを削除する前に、既にある
ワークスペースをチェックして削除しようとするリビジョンの変更点を
ワークスペースに反映させようとするようになりました。
これで削除した後に再度コミットするのが楽になります。
- mtn annotateの"--brief"オプションは意味がわかりづらいので
"--revs-only"に変更されました。
- mtn helpがあるグループ内のコマンド(とその別名)を一覧表示するよう
になり、コマンドの概要がいつでも簡単に見れるようになりました。
- "MTN_MERGE=diffutils"のマージ機能(std_hooks.luaに入ってるやつ)が
賢くなりました。
MTN_MERGE_DIFFUTILS環境変数に"key[=value]"形式のエントリをコンマ
で区切って入れてやると動作をいじることができます。
今のところサポートされてるエントリは、競合した時に自動で部分的な
3-wayマージを行なう"partial"、ファイルの内容に競合マークを埋め込
む"resolution"と、"diff3"とか"sdiff"コマンドに渡すオプションを指
定する"diff2opts=[...]"と"sdiffopts=[...]"エントリです。
特に"mtn merge_into_workspace"といっしょに使った時にはCVSやSVNの
スタイルの対話的でないワークスペースベースのマージができるように
なります。
- 新しいセレクタ"p:REV"が追加されました。
これはリビジョンREVの親(複数あるかも)を指します。
たとえば、あるリビジョンの親が1つだった場合、
mtn diff -r p:REV -r REV
これでそのリビジョンでの変更点が表示されます。
- Monotoneではboost::regexの替わりにPerl互換正規表現(PCRE)ライブラ
リを全ての正規表現に使用するようにしました。
これにより、Monotoneをビルドしたり使ったりするのに外部のBoostラ
イブラリは一切必要としなくなりました。
でもソースからビルドする場合はBoostのヘッダがあちこちで使われて
るので必要になります。詳しくはINSTALLを見てください。
PCREの正規表現はboost::regexの表現のスーパーセットにあたるため、
.mtn-ignoreファイルや他のところで使ってる正規表現がぶっこわれる
ことは無いと思われます。
マニュアルにはPCREから持ってきた詳しい正規表現文法のドキュメント
が含まれるようになっています。
- "mtn automate inventory"の形式がbasic_ioに変更されました。
この変更は古いフォーマットが間違った情報を返すとか厳密な出力を返
したいとか、属性の変更を認識したいとか諸々あって行われました。
新しいフォーマットの詳細についてはマニュアルの適切な節を見てくだ
さい。
バグ修正
- mtn automate stdioを介してブランチを指定する引数無しに
mtn automate headsを呼んだ時に正しくワークスペースのブランチの
headリビジョンを返すようになりました。
- mtn commitで作ったリビジョンのrosterが既に存在する時でもクラッ
シュしないようになりました。
`mtn db kill_rev_locally REV`を使った時などにこんな状況になって
いました。(savannah #18990)
ドキュメントの変更
- annotateコマンドの"--revs-only"(元"--brief")オプションのドキュ
メントが実態と全然違っていたのを修正しました。
- "ssh_agent_add"コマンドのドキュメントが無かったので追加しました。
その他
- contrib/usher.ccが削除されました。代わりに
net.venge.monotone.contrib.usherブランチを使ってください。
内部的なもの
- SQLiteを3.4.1にしました。
- Luaを5.1.2に最新のバグ修正を加えたものにしました。
- Botanを1.5.10にしました。
- 内部での正規表現の使用をほぼ取り除きました。
(正規表現自体は.mtn-ignoreとmtn diffの--show-encloser機能、Luaの
フックで依然として使用可能です。)
最近はリポジトリのフォーマット変更が無くて助かる。変更があっても大抵は簡単に済むんだが、やはり怖いよ。
今回はやっぱりマージ周りの変更ではなかろうか。今までは競合があると強制でマージ用のアプリが立ち上がってその場で手動マージ、できないならマージ失敗!と結構めんどかったんだが、CVS形式でのマージが出来るのは有り難い。All or nothingだったのがpartial付けて競合しない部分は自動でマージしてくれるし、resolutionは<<<<<<<みたいなマークをファイルに埋め込んでくれるってことだよね。
マージャとしてvimを指定してたけど、好きなオプション指定するのがすげー大変だったりするんでマージ周りはもっとなんとかして欲しいけど。あとMTN_MERGE=diffutilsとかってどうやって指定するんだっけ…環境変数かな?
正規表現がPCREになったようで。オプション解析やファイルシステムなどどんどんBoost離れが進むんだけどなんでじゃろ?
とりあえずチュートリアルがとても古いのでなんとかしたいんだが書く暇がねぇ。
miruはもうやめてViewMTNを動かそうと思ったら単体で立ち上がってくれない…。やる気があればいじって動くようにするんだが、あんまりやる気も無いんでmiruでもちょっとずついじるか。
それよりいつの頃からかmtn servがずっとリポジトリロックしっぱなし。miruとmtnサーバー同時に立ち上げられないよ! なんとかならんかなぁ。
テキスト描画がある程度整理できたのでコミット。しかしWindowsではビルドできないと思うので近いうちになんとかしたい。
あと衝突判定。Riko自体には入れてないけど、作ってるゲームの方で2Dの判定は結構ちゃんとできた。
ゲームプログラミングのためのリアルタイム衝突判定ってな本を読んで勉強してたんだが、この本、内容以前に翻訳が酷すぎて途中で投げた。せめて日本語にしてくれりゃいいんだが。MSのおもしろ日本語ドキュメントかよという程の文章炸裂してて読めたもんじゃなかった。
原書を隣に置いて読むにはいいのかもしんないけどさ。
結局いつもお世話になってるゲームプログラミングのための3Dグラフィックス数学って本を見たら簡単に分かりやすく説明されてたんでそれを2Dに落として実装。思ったより簡単だった。
でもまあRubyで書いたら重くて洒落にならなかったのでそのうちC++で書こう。Rikoには入れたくないんだけどVectorとかは共通で使いたいのが困り所。
あとサウンド。サウンドはSDLに任せっきりにするつもりだったんだがOpenALを調べてみたら結構いい感じ。
SDLの音声はかなりプリミティブすぎてミキシングすら自分でやる必要がある。SDL_mixerはいろんなフォーマットを適当に鳴らすにはいいんだが、できればボリュームだけじゃなくてピッチの変更も欲しい。
で、OpenALは使い方は簡単、ストリーミングも自前制御ながら簡単、基本は3Dサウンド、ピッチの変更も簡単に可能、ドップラー効果も標準で装備*1、サウンドのキャプチャーも可能、という素敵ライブラリ。
WindowsではCreativeのSDKとランタイムが使えて、Macでは標準でついてて、その他ではLGPLのライブラリが使える。
3Dサウンドというとめんどくさそうだが、自分の位置と向きを適当に置いて、あと音源の位置を適当に置くと適当になるらしい。3Dじゃない音源(BGMとかシステム音みたいなの)の場合は自分の位置からの相対位置にしておくと自分が移動しても追従するからOK、という形らしい。
OpenALは名前の通りOpenGLっぽいAPIではあるものの、カオスな時代のOpenGLというよりは比較的最近のまともな形の物に近いんで使いやすそう。というかそもそもオブジェクトがListenerとSourceとBufferしかないし。
で、Listenerは自分だから1個しかないでしょ。BufferはVertexBufferとかと同じようなサウンドの生データ入れておくだけのものでしょ。あとSourceは音源でこいつにBufferをくっつけてやってどっかに配置してやって再生してやると適当になるって寸法だ。これだけ。簡単じゃん!
ピッチとかボリュームとかListenerとSourceの距離による減衰はSourceの属性としててきとうに設定しておけば勝手にやってくれる。
ストリーミングはSourceにBufferをキューとして何個もくっつけて再生してあげて、適度な間隔で再生が終わったBufferを問い合わせて、そいつをもう一回リサイクルしてキューにぶち込んでやって…というのを繰り返すだけ。簡単!
これはいいなぁ。無駄に3Dサウンドとかやりたくなるね。
XNAで使ったXAudioもたぶんいろいろ出来たんだろうが、機能が多すぎてとりあえず鳴らす方法を調べるのにも一苦労だったからな。このくらいシンプルな方が把握するにも楽だわ。
問題はMIDIとか無理なのと圧縮されたファイルを直で読むのは難しいっぽいってことか。でもOgg/Vorvisなんかならライブラリで結構簡単に読めるっぽいから大丈夫かな。MIDIはまあ使わんだろ。最悪はSDL_mixerみたいにソフト音源ライブラリ使用って手もあるわな。
あー、そんなことよりシェーダ周り整理せんとな。
動作環境なるべく広くしようとCg使ってたけど、GLSLってRadeonの9600とかでも一応使えるんだねぇ。IntelさえなんとかなればGLSLでも大丈夫ってことか。
まあいっそIntelは切り捨てるってのもありなんだが…。うーん、俺はいいんだが…。
もちろんCgは今後もサポートするけど、やっぱりシェーダを書き溜めるのにCgとGLSLに変換できるシェーダを書く方がいいのかなぁ。
ああ、もう、ほんとにIntelうぜぇ。GLSLすらサポートできないなら3Dの機能なんか無けりゃいいのに!
*1 標準に入れるほど使うものなのか?
そういやCg 2.0β出てましたな。
前からNVSDKには付いてたんだけどNVSDKがWindowsしか無い以上、当然Windows版しか無かったので、やっとMac版とかも出た。
2.0はやっぱりGeometryShaderというかGeForce8系対応ですな。
ところで気になったのがcgCreateObjectとかcgCreateObjectFromFileとかいう関数。引数見るとどうも普通にシェーダを作る関数に見えるんだが、CreateProgramと何が違うんだが分からん。あと戻り値の型がCG_OBJECTとかなんとか。でもそんな戻り値受け取れる関数は無い。
ドキュメント見てもTo be written。これなんだろうねぇ?