2002-04-01
結局今日も泊まり。まあ，覚悟はしていたし，しょうがないけどね。
AABB Tree は意外と妥当な解決法なのかもしれないなあ，とおもう。ツリーの構築も楽だし，交差判定も難しくない。 Sphere Tree は一見単純そうに見えて，実は構築が意外とめんどくさいし（外接球を求めるよりも AABB の導出の方が簡単なことに注目），フィット率も相当に悪い。唯一交差判定だけは最も速いのだけれど，それも前述の短点で十分にスポイルされる程度のものだろう。
AABB の交差判定は RTR に載っていた "Woo's method" で問題無し。 RTR では同時に "slab" 法も紹介しているけれど， Woo の手法の方が SIMD 命令と相性が良いとおもう。
いちおう realtimerendering.com の方も見てみると， Terdman 氏が（corder corner の管理者だ）が Woo の手法の最適化バージョンを作成していた。
http://www.codercorner.com/RayAABB.cpp
このプログラムの下のほうにある関数がそれなんだけど，ちょっとハッキーだなあ。 SIMD 命令を使える環境ならば，オリジナルのアルゴリズムでも十分に効率良く動かすことができるだろう。
2002-04-02
昨日のじりじりした雰囲気とはうって変わって，今日は異様に平穏な感じだ。やたらに天気もいいし，なんだか知らんけど平和なもんだねえ。まあでも，また明日辺りにリトライが発令されるかもしれない。用心用心……。
このまえ落とした "Homomorphic Factorization of BRDFs" を読んでみているんだけれど，なかなか内容が難しくて苦労している。 Kautz 氏の方法とは違って代数的なアプローチがとられているんだけど，代数学なんてぜんぜん知らないもんだから，文章を読んでもなんのことやらさっぱり伝わってこない。だいたい "Homomorphic" の意味がわかっていない時点で詰みなんだよね，きっと。
結局やっていることは，４次元関数である BRDF を２つの２次元関数（これは最終的にテクスチャマップに落とし込まれる）の合成で近似するというもの。このとき，元の BRDF と近似関数の関係をうまいことやって
という線形システムに落とし込んでいる。ここで A はとてつもなく大きな行列になるんだけれど，十分に疎な行列（いわゆるスパース行列）なので，一般的な数値解析の手法を用いてこれを解くことができる，ってことなんだとかなんとか。
実際にこの論文では NIST の "SparseLib++" と "IML++" というライブラリを使用して近似マップを求めている。 "SparseLib++" はスパース行列を扱うためのライブラリで， "IML++" は反復法を使って線形システムを解くためのテンプレートライブラリだ。
http://math.nist.gov/sparselib++/
うーむ。世の中にはこういう便利な技法もあったんだなあ，っていまさら感心。もっとも，こういうのを勉強するために学校に行っていたはずなんだけどさ……。
2002-04-03
なにはともあれ，まずは数値解析について調べてみることにしよう。
"Numerical Recipes" は，計算機による数値解析の基礎から応用までを取り揃えた教科書。ケンブリッジ大出版部の著作なんだけど，Ｃ言語版や FORTRAN 版は同サイトからフリーで入手することができる。 PDF や PS で配布されているので，印刷にも適しているのが嬉しい（コピーは一人一部までって約束だ）。おそらくウェブ上で参照できる計算機数学の教科書としてはもっとも優れているのではないかとおもう。
今回のネタこと "Homomorphic Factorizations of BRDFs" は線形代数の応用になっていて，特に Singular Value Decomposition （特異値分解）の手法をベースとしているそうだ。なので，とりあえず第２章の "Solution of Linear Algebraic Equations" を読んでみるんだけど……うーん，難しい。やっぱ最初から読もうかなあ。
なんとなくメモ。
プログラミングもできるＣＧアーティストこと Jason Nairn 氏のページ。 Blender マスターとして密かに注目していたんだけど（チュートリアルも何篇か書いている），肝心の Blender が潰れてしまったが惜しまれるところ。その一方で氏は "Clay Modelar" というモデリングツールの開発に勤しんでいるようだ。正直それほど興味は無いんだけど……なんとなくキレイなページなので，なんとなく気に留めておこうとおもっただけ。
2002-04-04
Q3A の common ライブラリの内容をなんとなく覗いてみると， MD4 がデータチェックサムの方式として利用されているのが見受けられる。 MD4 は RSA 社が提案したメッセージダイジェストアルゴリズム，つまりハッシュ関数の一種で， RFC1320 として登録もされている。
http://www.faqs.org/rfcs/rfc1320.html
MD4 は，任意長の文字列を 128bit のハッシュ値に変換する。このアルゴリズムの数学的な意味はわからないけど，かなり対衝突性に優れているらしい。つまり，あらゆるデータを流し込んでも，そこから生成されたハッシュ値が衝突することはめったにないということだ。
この特性は単純にチェックサムの役割として役に立つんだけれど，セキュリティ屋さん的にも重要な意味を持っている。ハッシュ値から元の文書を特定することは不可能だし，同じハッシュ値を持つ文書を生成することも難しいから，このハッシュ値を文書の代替として使用することで，機密性に優れた認証システムへと応用することができる，ということだ。つまり，ハッシュ値をデータ本体の「指紋」として使おう，ってこと。
具体的な利用方法については，下の記事に詳しい。こういう話題は IBM Developer Works が役に立つねえ。
http://www-6.ibm.com/jp/developerworks/security/001117/j_has...
ゲームのセーブデータに対しての改竄チェックとして利用するのも面白いかもしれない。単にデータのハッシュ値を末尾に加えるだけでもそれなりのチェックになるし，何パターンかのダミーデータを末尾に加えた上でハッシュ値をとるようにすれば，わりと強力なガードになるのではないかとおもう。まあ，コードを解析されたら一発だけど……。
MD4 アルゴリズムは，最近では十分な信頼性を持っているとは言えなくなってきているらしく，さらに対衝突性を高めた MD5 アルゴリズムが主に使用されているそうだ。しかし MD5 は MD4 に比べて冗長な実装なので，速度を求める場面ではいぜん MD4 を使用することが勧められている。 MD4 は 32bit マシンでの実装を前提にしたアルゴリズムなので，たいていの計算機では高速に動作させることが可能なのだ。
RFC1320 の巻末には MD4 の実装例が添付されている。この実装はフリーで使用することが可能で， Q3A もこのソースをコピペして使っている。ライセンス文の解釈にはちょっと自信が無いんだけれど，場面によっては著作の表示が必要とされるみたいな雰囲気…… Q3A には見当たらないけど。
2002-04-05
ちょっと睡眠が足りない。外はとても暖かい。眠い……。
昔書いたコードをちくちくと高速化してみる。試しにパフォーマンスの測定をしてみると，苦労したほどの効果が得られていないことが判明する。こんなのとっとと切り上げて次の仕事に移りたいところなんだけれど，なかなか作業に区切りがつかなくて，徐々に焦りを感じてくる。危険だなあ。本当は忙しいのに。
最近ではボトルネックのほとんどがメモリアクセスの遅延にあるので，アルゴリズムとデータ構造にさえ気を遣っていれば，たいていの場合はどうにかなるはず，というスタンスをとっているのだけど，それでもやはり地道な高速化作業が功をなす場合もある。今日やっていたことがまさにそれなんだけど，こまめにコードをアセンブラ化したり， SIMD コード化するだけで，処理時間が万単位のクロック数で切り詰められていく。ほんとうはこんな小手先のごまかしに頼るのはあまり良くないとおもうんだけど，それでも効果が出てしまうんだからしょうがない。嬉しいやら悲しいやら……。
メモリが重いからって，たまにプリフェッチ命令 (pref) とか使ってみることがあるんだけど，これがほとんど効いた試しが無い。例えばリストをたぐる場合なんかに，
なんて感じで pref を挿入してみる。 update() を実行している間に次のノードをキャッシュに入れといてくれ，ってノリ。でもこれは，実際にはほとんど速度に影響しないようだ。確認のためにパフォーマンスの測定をしてみると，確かにデータキャッシュミスは減っているみたいなんだけど……うーむ。
ちなみに，
ってのをプリフェッチの代わりとして使うこともできるらしい。でも pref 命令の方にはアドレス例外を無視してくれるという特殊機能があるので，わざわざ "ld $0" を使う意味は無いだろうとおもう。例えば前の例で "ld $0" を使うと，終端で null アドレスを参照して例外を投げてしまうだろう。
Beltorchicca をなんとなく閲覧。 Rudy Rucker の "Freeware" の邦訳版がいつのまにか出ているそうだ。
http://www.amazon.co.jp/exec/obidos/ASIN/4150113939/ref=pd_s...
ていうか原書と雰囲気違い過ぎ……。
http://images.amazon.com/images/P/038078159X.01.LZZZZZZZ.jpg
まあとりあえず，ファンとしては押さえておかねばなるまい。と，その下には，ディックの「あなたをつくります」の復刻版が。
http://www.amazon.co.jp/exec/obidos/ASIN/4488696163/ref=pd_s...
これもファンとしては押さえておかねばなるまい。
「軌道上に謎の構造体が出現した記念」として「ヴァリス」に再挑戦してみるのもいいかなあ，とかおもってみる。ちなみに「ヴァリス」は，宇宙からの電波を受信できるようになっちゃった危ないひとが，狂ったり徘徊したりヤク打ったり秘密経典を書いてみたりするマッド小説なんだけど，あまりの混沌っぷりに途中で読むのを諦めてしまった経験がある。
ディックの小説は適度に狂いつつも人間性に対する尊敬の気持ちが込められているところで救われるのが良かったりするんだけど，「ヴァリス」だけは，ほんとうにただ狂ってるだけだったなあ，とおもう。
2002-04-06
たまに気まぐれで GDAlgorithms-ML を覗いてみる。最近ではあまり頻繁にはチェックしていないんだけど，たまに覗いてみると面白いことを議論していることもある。例えば今日のなら，こんな話題。
http://www.geocrawler.com/mail/msg.php3?msg_id=8268240&list=...
元はここら辺から流れてきた話題らしい。
http://www.flipcode.com/tutorials/tut_fastmath.shtml
うーむ，これが generic programming ってやつか……。テンプレートだの演算子オーバーライドだのなんて言い始めると，どうもコードが重くなってしまうような印象があるんだけど，これはその逆。むしろテンプレートをヘビーに使ったメタプログラミング的な手法によって一時オブジェクトの生成などを回避することができる，っていう主張。
しかしそれも賢いコンパイラがあってはじめて成立するものだ。どんなに頑張って inline や const を付けまくったとしても，コンパイラにそれを応用する力が無ければ，やはりベタなコードが生成されてしまうだろう。 VC++ では， VC++6 にサービスパックを当てた状態でなんとかなるらしいんだけど，僕は gcc 専門だから， gcc でそれがどうなるのかを見極めてみないと。
しかしまた複雑なテンプレートだなあとおもう。足し算するだけで一苦労だ。コンパイル速度もかなり落ちそうだけど，果たして大丈夫だろうか。 gcc の内部エラーに苦しめられることはないだろうか。 gdb でデバッグできるだろうか……などなど，検証してみなければならないことはたくさんある。いきなり業務に持ち込んだりするのはかなり危険かもしれない。だからこそ，趣味の範疇で検証を行おうとしているんだけど。
ここらへんの多くのレポートは x86 系の CPU と VC++ を前提にしている。上の flipcode の記事でも x86 のレジスタの少なさに対して気を遣っている記述が見受けられる。しかし x86 以外のほとんどの現行 CPU は多くのレジスタを持っているわけだから，高速化の理屈が細部で異なってくることもあるだろうとおもう。 EE ならディランの gcc パッチによって VU0 の SIMD を使った実装なども可能になるだろう。ていうかあの場合，一時オブジェクトもレジスタに乗ってくれるはずだから，こういう変態テンプレートに頼る必要も無いのかも……。
なにげに yan 氏のページをチェックしてみると，新曲がアップされていた。
http://www.muzie.co.jp/cgi-bin/artist.cgi?id=a001262
ああ，いいねえ。ほのぼのとするよ。僕は，本当はこういう曲がいちばん好きなんだ。
もう桜もすっかり散ってしまったけど，どこか空気の澄んだところに行ってのんびりしたいね（都内は却下）。んで，屋外プログラミングなんかに挑戦してみたい今日この頃。やはりビルの空調ってのは肌に合わないよ。ありゃあ，しまいには精神を病みかねん。いやほんとうに……。
2002-04-07
今日は夜から出動。それで，家を出る前に，久しぶりに「サイヴァリア」をプレイしてみた。ローリングがボタンに割り当てられることを知ってから，ずいぶん楽にプレイできるようになったものだ。ちょっと邪道かもしれないけど，このゲームばかりはパッドじゃどうにもならないって。
「斑鳩」の PS2 移植の噂もあることだし，にわかにシューティング流行が来ようとしているのかもしれない。あくまでも僕自身に向けて，だけど。
カエルカフェのＴシャツブランド "GbM" ２００２年版のオーダー受付が開始されたことを，風の噂に知る。
http://www.kaerucafe.com/GbM/02colec/index.html
今年のもなかなかいい味出てるけど，ちょっと迫力不足かなあ。０１コレクションの破壊力の高さは，そりゃもう伝説級だったのだけども。
http://www.kaerucafe.com/GbM/01colec/index.html
こういうのを平然と着れる大人になりたいかもしれない（thnikgeek のＴシャツとかは平気で着れるよ！）
昨晩，煮詰り切ったところで放棄してしまった高速化作業の続きを始める。 XVNC はデスクトップの状態がサーバに保持されるから，作業のレジュームがとても楽だ。前日にシャットダウンした瞬間の状態が，すっかりそのまま画面上に再現される。しかしそのときのメンタリティまで再現されてしまうのは，ある種の弊害であるのかもしれないけれども。
かくして作業は行き詰まりを極め，いよいよ埒が空かなくなってきている。もし休日中にこの問題が解決されなかったときは，このブランチリビジョン自体を無かったことにしてしまおうとおもっていた。
２時，３時……刻々と朝が近づいてきて，いよいよこれまでかとおもった瞬間，ある１つのアイデアをおもい付く。ううむ，これはいけるかも。
正直，すごくインチキな方法なんだけれど，実行速度は確実に速くなる。実際に計測してみると，以前のコードの３倍ぐらいの速度は出ているようだ。うーむ，むしろ今までおもいつかなかったのがおかしいぐらい基本的な解決法なんだけれど……すっかり煮詰まっていたんだなあ。
まあそんなわけで，高速化の件については遂に見切りができそうだ。これでやっと本来の仕事のリファインに入ることができる。もちろん，ここからが本当の本番なのだ。
2002-04-08
とりあえず昨日の作業の続きにカタを付ける。今朝は簡単な検証を行った時点で寝に入ってしまったから，ちゃんとした実装はまだ済んでいないのだ。地道にカリカリとコードを組み上げる。既に結論は出ているわけだから，気は楽だ。
内部ループについてはだいぶアセンブラ化を進めている，とは言っても，その主な成分は SIMD 操作であって，基本的なフローについてはほとんどＣのままで通すのが普通のやり方だ。あとは，いかにコンパイラが理解しやすいコードを書くかって点にも気を配ってみたりする。狂ったように const を付けまくってみたり，ならべく参照を減らしてみたり，とか，そんなノリ。 RISC CPU はレジスタが多いから，ならべく値がレジスタに乗りやすくなるような書き方を心がけみようってわけ。
とか書いてて，自分でもわけがわからなくなってくる。 const ってどこに付けるとどうなるんだっけ？ ていうか "void **" なんて使ってる時点で致命的にダメダメだ。こんな調子でほんとに C++ に移行できるのかなあ……。
Gaming-Age Forum より "GBA Web Server Development Diary"
http://www.fivemouse.com/gba/diary.html
GBA 上でウェブサーバを実装してしまおうというプロジェクトだ。うーむ，久しぶりに GBA 触りたくなってきたなあ。
この GBA ウェブサーバプロジェクトを進めている Adrian O'Grady 氏は， Shrikumar 氏の PIC ウェブサーバに触発されて，このプロジェクトを立ち上げるに至ったようだ。
http://www-ccs.cs.umass.edu/~shri/iPic.html
GBA で TCP/IP スタックなんてけっこうしんどそうに聞こえるけど， PIC でさえそれを実現してしまっているのだから， GBA で不可能ということは無いのかもしれない。デバイス的には，対戦用ケーブル端子を UART （いわゆる「パラレルポート」）に変換するケーブルを自作し（これは Dark Fader 氏のアイデアだ），それを経由して Linux ホストと PPP で接続する，という方法をとっている。
実用性の評価については難しいところだけれど，その精神には共鳴できるものが確かに存在する。氏は Linux for DC プロジェクトの貢献者としても有名な人物らしく，その手のハックはお手の物なんだろう。こういうのいいね。
会社のひと情報で MGS2 のメイキング本。
http://www.amazon.co.jp/exec/obidos/ASIN/4789718433
ううむ。これは買わなければ，とおもって早速 amazon.co.jp に行ってみると，早速売り切れていた。くはあ，出遅れた。 amazon.co.jp の「取り寄せ」は正直信用ならないんだけどなあ……ここで手をこまねいていても埒が空かないので取り寄せ注文クエリー発行。ついでに途中で読みかけの「虹色のトロツキー」も注文しておく。本屋に行く暇がないんだ。どうにも。
2002-04-09
MD4 について調べたついでに，暗号化処理についても少し嗅ぎ回ってみることにした。とはいっても，数学的な理論についてはほとんど無視して，手段と応用について調べてみただけ。結局，僕が興味あるのはそこだけだから……。
基本的な知識については，ここでおさらい。
http://www-6.ibm.com/jp/developerworks/java/000915/j_jw-0428...
とりあえずここは，最もメジャーでありふれたアルゴリズムの１つである DES 暗号化アルゴリズムについて注目してみることにする。
DES 暗号化アルゴリズムの発祥をたどると，７０年代前半にまでさかのぼることになる。 DES はそれほどまでに歴史のあるアルゴリズムで，マイナーな変更を繰り返しつつ今日まで使われ続けてきた。 UNIX で標準的に使われている暗号化システムコールである crypt 関数も DES をベースとしたものだ。 POSIX crypt と DES の関連性，およびその危険性については下の記事に詳しい。
http://www-6.ibm.com/jp/developerworks/security/001208/j_pas...
DES は既に時代遅れの手段となりつつあるけど，それほど深刻でない問題（例えば，ありがちだけどゲームのセーブデータの暗号化とか）に対してはこれで十分な場合もあるはずだ。
次に DES の実装について漁り回ってみたのだけど，なかなかよさげな実装が見つからない。しばらく調べてみると libdes というライブラリが良さそうだということが分かった。 libdes は OpenSSL や glibc などにもインポートされているライブラリで， DES の実装としてはかなりメジャーな存在であるらしい。
ftp://ftp.psy.uq.oz.au/pub/Crypto/DES/
libdes では標準的なコードブックモード (ECB) に加え，チェインモード (CBC) ，フィードバックモード (CFB) やトリプル DES などの強化アルゴリズムにも対応している。とりあえず DES の類ならなんでもできるってことのようだ。
libdes は商用・非商用を問わず自由な使用が認められている。ただし，何らかの場面で， DES 暗号を使用している，もしくは libdes を使用していることについて触れる場合は，明確な著作者表示が必要となるらしい。その著作表示文でサーチをかけてみると，結構な件数がヒットした。
http://www.google.co.jp/search?q=%22This+product+includes+so...
まあおおかた BSD っぽいライセンスだと理解しておけばいいとおもう。
2002-04-10
DES を調べたついでに，暗号化処理について更にもうちょっと押し進めてみることにしたい。次の標的は Rijndael 暗号化アルゴリズムだ。
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/
Rijndael （「ラインダール」と読む）は２０００年末に AES - "Advanced Encryption Standard" として選定されたアルゴリズムで，これからの世代の標準的な暗号化アルゴリズムとして注目されているものらしい。そこらへんの事情については下の記事に詳しい。
http://www-6.ibm.com/jp/developerworks/security/010316/j_s-r...
AES としての Rijndael アルゴリズムの仕様は一般に公表されており，仕様書やリファレンス実装を NIST のサイトからダウンロードすることが可能だ。
http://csrc.nist.gov/encryption/aes/rijndael/
また，作者のひとりである Vincent Rijmen 氏のページからオリジナルのソースコードをダウンロードすることもできる。
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/
Rijndael では鍵の長さとして 128bit, 192bit, 256bit を選択できるようになっている。コードブロック長もこの３つの長さのうちのいずれかになる。任意の長さのデータを暗号化するには，元データをブロック長でスライスし，それぞれのブロックに対して個別に暗号化処理を適用することになる。
Rijmen 氏のページを見てみると，さまざまな Rijndael 実装のページへのリンクが張られている。その中にはモトローラ 6805 用のアセンブラ実装なんてのも存在する。
http://members.ozemail.com.au/~geoffk/aes-6805/
ちょっと脱線だけど 6805 ってのはこんな CPU （モトローラ風に言うなら MPU ）だ。
http://www.st.rim.or.jp/~nkomatsu/mc680x/MC6805.html
ああ，なんてシンプルな CPU なんだ……この頃のモトローラ製 CPU アーキテクチャに見られる潔さは，ある種の美しさをも連想させるものがある。かの有名な 6502 だってレジスタ２つしかないもんね。ちなみに 6805 は「ギャラクシアン」や「ディグダグ」とか，ナムコの初期タイトルなんかでよく使われていた CPU らしい。そんぐらい古い歴史があるってこと。
んで，すっかり脱線してしまったけど，本題に戻すと， Rijmen 氏のページに張られているリンクのなかから Mike Scott 氏の実装を選んでテストに使用してみることにした。
ftp://ftp.compapp.dcu.ie/pub/crypto/rijndael.c
この実装を選択した理由は，１つのファイルにまとめられていてコンパクトそうだったから，ってだけのことだ。速度面を重視するならばもっと優れた実装も存在するようだから，まずはそちらを試してみた方がいいだろう。
とりあえず単純に 128bit 鍵を使用して 128bit ブロックを暗号化する処理を 1000 * 1000 回繰り返し，その所要時間を測定してみた。
まったく問題無い速度が出ているようだ。これならちょっとくらい速度を要求されるような場面にも耐えられるかもしれない。
2002-04-11
最近の読み物は "Homomorphic Factorization of BRDFs" と，その全編となる論文 "Iterative Rendering with Arbitrary BRDFs" あと教科書代わりの "Mathematical Recipes" の３つの印刷物。これらを行ったり来たりしながら，頭が痛くなってみたり，眠くなって船を漕いでみたり，まあとにかく読むだけ読んでみている。どうせ電車の中は暇なわけだし。
"Iterative Rendering with ..." で使っているのは Singular Value Decomposition (SVD) による近似法だ。 SVD は線形システムの解法としてよく使われる手法で， singular （特異）な系に対しても近似解を求めることができるなど，いろいろと便利な特徴を持っている。ここでは SVD から係数を減らす手法を使って近似式を求めている。
この SVD を使用した方法はかなり精度の良い近似が取れるんだけど，実数演算が必要なためにハードウェアで実装しにくいという欠点がある（忘れがちなことだけど，一般的なラスタライザでは負数の扱いにいろいろと制限が付きまとう）。あと，４次元グリッド化しなきゃいけないんで容量が足りなくなりがちだとか，まあ様々な問題が発生するらしい。それで，前の論文では Normalized Decomposition (ND) を使用した近似法を使おう，って結論に落ち着いているんだけど，これはあまり優れた解決法ではないようだ。
"Homomorphic Factorization of ..." では，４次元 BRDF を複数の２次元関数の積によって近似するという考えをベースにしている。ここで，近似式を求める前に，値の log を取ることによって積算から加算への写像を取っている。この変換により，複雑な非線形式の解法を線形システムの問題へと持ち込むことができる。また，この手法ならば正数ベースのオペレーションへと限定できるためにハードウェアでの実装も楽になるってことらしい。ちなみにこの写像がいわゆる「準同型写像」であるので "Homomorphic Factorization" って言ってるわけ。
http://www.everything2.com/index.pl?node=homomorphism
http://www.graco.c.u-tokyo.ac.jp/~kashiwa/sysI/2001/homo/nod...
こんな数学全然知らないから，単語を読むだけでもとても苦労する。とほー。
で，結論から言うと，まだここらへんの手法も無理があるかなあ，とおもう。ぬぉっ，これはっ，みたいな感動はいまだ無く，なんだか試行錯誤の中間報告を受けているような印象だ（失礼だなあ）。いまのところ，こういった手法で自由な BRDF を扱おうとするよりも，注意深く数式化された反射モデルを扱った方が処理も軽いしオペレーションも楽だし，総合的にみて有利だとおもう。レンダリングエンジンの設計面から考えると，なんでもかんでもサンプリング BRDF っていうのは，簡潔で魅力的な方向性ではあるんだけどね。
ところで BRDF とか異方性反射とか散々言っておきながら，面のタンジェントベクトルを定義する方法を全然考えていないような気がする。モデリング時に明示的な指定をするのはかったるいので，曲面形状から自動抽出するような方式がいいとおもうんだけど，どこかにそういう手法は転がってないだろうか。
「本当の」デザイナは法線さえも手でモデリングするらしいんだけどね。うへ。
2002-04-12
とりあえずシメとして SparseLib++, IML++ の使い方でも調べておこうかとおもったんだけど……
http://wwwcsif.cs.ucdavis.edu/~wiley/mathematicians.htm
http://bullard.esc.cam.ac.uk/~trinks/solutions.html
うーむ，たしかに SparseLib++ の方はビルドさえもままならないようだ。おとなしく NumericalPython でも使っておけってことだろうか。ほうほう……。
以前から読もうとおもっていて読まずじまいの文書に手を付けてみる。
http://www.flipcode.com/misc/SamuelRanta-Eskola_BSPTrees.pdf
Samuel Ranta 氏による Quake 式 BSP-Tree 応用法の研究。どうやら卒業研究として取り組んだもののようだ。正直この手法には限界が来ているとおもうんだけど，まあそれでも調べてみようって言うんなら，この文書が何らかの手助けになることもあるかもしれない……ってことで結論。
DAKINI さんの SIGGRAPH 2002 paper 集が徐々に充実してきた模様。
http://www.geocities.co.jp/SiliconValley/8072/NewFiles/SIG20...
ちょろちょろっと覗いてみてはいるんだけど，まだ公開されているものはごく少数のようだ。公開済みのもので最も興味があるのは Microsoft Research は Peter-Pike Sloan 氏の "Precomputed Radiance Transfer for Real-Time Rendering in Dynamic, Low-Frequency Lighting Environments" だ（題名長ぇ）。
http://research.microsoft.com/~ppsloan/
SH （球面調和）関数を基底として低周波成分だけを扱うって手法は例の Ramamoothi の手法と同じ。今回のネタではもうちょっと大域照明っぽい処理を盛り込んで，環境照明だけでなくセルフシャドウや照りかえしも焼き込んでしまおうというものらしい。あと SH 関数ベースで比較的鈍いスペキュラを扱う手法についても触れているようだ。ちょっとこれは面白そう。とにかく読んでみる価値はありそうだ。
2002-04-13
今週はスケジュールの都合上金曜の夜に帰ることができたので，土曜の夜に出社するというまれなパターン。土曜に泊まるのってなんか不毛よねえ。でも，土曜の夜のオフィスの静けさは，なかなか気持ちのいいものかもしれない。そのために出社したとおもえば，まあそれでいいや。
出かけしな，久しぶりに Reason なぞを走らせてみる。定期的に使わないと勘を失ってしまうんで，本当はちょくちょくいじりたいところなんだけど，最近は忙しくてなかなかそうもいかないのが悲しい。
最近のゲームもそうなんだけど，もっとこう，電源付けて１０秒後には遊びの真っただなかにいるようなコンセプトのものを提供してくれないものかねえ，とおもうことがある。そういう用途ではファミコンの方がよっぽど優れているかもしれない。 PS2 を起動させてシャーンとか言ってる間に，スーマリだったらクリボー踏んづけてますよ，ってこと。
そんな感じだから， PC 起動して Reason のアイコンをポチポチっとダブルクリックして……とかそういう面倒くさい手順を踏むよりも，こういうハードウェアの方が優れている面もあるよなあ，とかぼんやりと物欲を働かせてみたり。いかんいかん。
http://www.korg.co.jp/Product/Dance/ElectribeAR/index.html
Electribe は Roland の MC303 みたいなやつで，要するに KORG 版ビンテージシンセのリバイバルだ。アナログシンセを彷彿とさせる風体だけど，中身は完全にデジタル。この Electribe の場合は，内蔵の DSP による FM モデリング音源がベースとなっているみたいだ。フィルタ部もたぶん DSP ベースなわけだし，昔だったら C とか R とか必死に並べて作っていたはずの回路が全部 DSP で実現できちゃうんだから，こりゃあ凄いことなんだぜ，って回路嫌いな学生を諭したい感じ＞数年前の自分
とかおもっていたら，めがてんさんが Electribe の分解をやってた。
http://www16.big.or.jp/~hosoe/sound/bunkai/electribe/
案外素っ気ない中身だ。どうりで安いわけで……。
んで肝心の Reason の方はと言うと，相変わらず USK 氏の曲がいい感じ。
http://www.reason-why.net/cgibin/detail.cgi?mode=userdetail&...
ひとつひとつの音にハリを感じられるのが非常に気持ちいい。もともと楽曲のレベルも高いし，渋めの曲調も良しで， Reason 曲の中では最も好き。
ついでに virt 氏のサイトを訪問。新曲は "Discontinued Soup" 。ていうかいつの間にか vgamix.com ドメインに移ってた。
http://virt.vgmix.com/music.html#mp3
スティービーワンダー風味，とのこと。いいんでないの。
2002-04-14
最近，地味ながらも密かに C++ への移行を考えている。それで，まずは基本となるベクトル・マトリクス演算のクラスライブラリを見繕っておきたい。自作は最後の手段として残しておくとして，とりあえず平鍋氏の vecmath-c++ などに注目してみている。
http://objectclub.esm.co.jp/vecmath/index-j.html
他にも何か面白いものはないものかと sourceforge でべロっと検索してみると，なんだか良さげなものを見つけることができた。
tvmet (Tiny Vector Matrix library using Expression Templates) は， "Meta Template" と "Expression Template" を軸とするテンプレートベースのベクトル・マトリクス演算ライブラリだ。要するにこの前言っていた「メタプログラミング的手法による最適コードの生成」をまさに具現したもののようだ。うーむ，これは面白いかもしれない。
さっそくダウンロードして configure && make 。僕の使っている cygwin (gcc 2.95.3) では '-finline-limit=5000' って表記でエラーが出てしまったけど，これは '-finline-limit-5000' って感じでイコールをハイフンに直せば通るようになる。
それでいくつかサンプルプログラムのコンパイルを試してみたんだけど，どうやら gcc 2.95 ベースではテンプレートとインラインの展開があまりうまく行かないようだ。 Linux マシンに入れてある gcc 2.96 ではかなり最適化されたコードが吐かれていたようだから，単に gcc のバージョンが古過ぎるってことなんだろう。
cygwin (gcc 2.95) の生成したコードをリスティングしてみると，
以下略，って感じ。いきなし最初にスタックポインタから 492 も引いているのは，膨大な量の一時オブジェクトを保持するためにフレームを確保しているわけ。うへえ。
マニュアルを参照してみると，以下のような記述があった。やはり正式な対応は gcc 2.96 以降に限定されるらしい。
http://tvmet.sourceforge.net/_compiler.html
かくなる上は cygwin が早く gcc3.0 ベースになることを祈るのみ，って感じだけど，まあ当分そういうことはなさそうだ。うーむ，どうしたものだろうか。
それにしても x86 のコードリスティングは，その，なんていうか，率直に言って読みにくい。特に FPU 命令の読みにくさといったら，もはや暗号レベルと言っても過言ではないほどだ。いまどきスタック式のレジスタってどうよ，って感じの。
とかそんなことばかり言っているとアンチ Intel 野郎の烙印を押されかねないのでやめておくけど，本気で MIPS マシンの導入を考えたりする瞬間を否定できない今日この頃，どうやって自制心を保ったものだろうか。
2002-04-15
夜中，ちょっと疲れて眠げな頭で，何気なく学生時代の後輩のページを覗いてみる。彼はたしか去年度に卒業だったはず。いまごろ新生社会人として頑張っているんだろう。
トップページに飾ってある，作りかけのスクリーンショットが痛ましい。学生時代最後の作品か。社会人になってからも，これを作り上げるつもりなんだろうか。僕もそういう経験はあったけれども，結局それを作り上げることはできなかったし，そうできなかったからこそ，今もこうして醜態を晒し足掻き続けている。
僕の学生時代のおもいでは，とても地味で決して華々しいものじゃなかったけれど，それはそれで今やかげがえのないものとなりつつある。学生の頃はそれこそ，自分の目の前に無限の可能性が広がっていたはずなのに，今無性に感じるこの閉塞感は一体何なんだろう。
学生から社会人へと変化する過程で，確実に僕の中の何かが失われ，そして何かを得た。それは決して間違ったことでは無いし，今の自分を否定する気もさらさら無いけども，今その変化をまさに迎えようとしている若者が目の前に存在するとおもうと，言い知れようのない喪失感が胸から込み上げてきて，無性に切なくなってくる。
http://www.jwz.org/gruntle/nscpdorm.html
僕は jwz ほど感傷的でもないし，ましてや他人の幸せを願うほど思いやりのある人間でもない。けれども願わくば，どうか，その真っ直ぐに前を見据えた瞳が，つまらない日常の繰り返しのなかに紛れて濁ってしまうことのないように，と，祈らずにはいられないんだ。
2002-04-16
先日 cygwin (gcc 2.95) で撃沈してしまった tvmet ライブラリを， Linux マシンに入れてある gcc 2.96 で試してみる。テスト用に用意したソースはだいたいこんな感じのものだ。
３つのベクトルを加算するだけの簡単な関数だ。ちなみに vector3d は int 型の３次元ベクトルとして定義してある。本来は float か double で使うもんなんだろうけど， x87 の FPU コードはたいそう読みにくいので，無難に整数型を使うようにしてみたってわけ。
で，アセンブラのリスティングはだいたいこんな感じになる。
うーむ，まさに理想通りのコードだ。一時オブジェクトを生成することもなく，要素毎に一気に演算を済ますような処理が組まれている。ちなみに，比較のために vecmath-c++ でもリスティングを取ってみたんだけど，こんな感じ。
しょっぱなの subl が全てを物語っていると言えるだろう。うーむ，テンプレート・メタプログラミング恐るべし……。
ここでちょっと気になったのが，テンプレート使用時のコンパイル時間の長さだ。よく「メタプログラミングはコンパイル時間と引き換えに実行時速度を得る」とか言われているみたいだけど，少なくとも gcc に限って言えばまさにその通りで，そのコンパイル時間の増大っぷりってったら，目も当てられないくらいのものだ。
ここで挙げたような，単にベクトルの加算を行うだけのコードでも，コンパイルに５秒近くの時間が費やされてしまっている。これは vecmath の場合の約５倍に相当する。むむむ……。
仕事の方ではコンパイル速度をならべく向上させるような工夫を凝らしていて，これは実にうまく働いているんだけど，それでも長大なビルド時間に不満を感じる瞬間は日常的に存在する。そんな，まるっきし C ボケの状態だから，いきなしヘビーテンプレート路線に転向しようってのには無理があるだろう。うーむ，どうしたもんだろうか。
2002-04-17
今日は帰るべきなのかどうか，よくわからない。最近，日単位での見通しがますます効かなくなってきた。大局的には比較的安定したペースが保たれているとおもうんだけど……。
GBA の ARM (ARM7DTMI) には除算命令が存在しない。だから GBA で除算を行うには，ソフトウェアでの実装を用いるか，もしくは除算以外の方法で代替するしかない。乗算やビットシフトによる代替が可能ならば，もちろんそれを使うに越したことはない。
Ｃ言語上では普通に除算演算子を使うことができるものの，これは汎用的なソフトウェア実装なので速度の面でやや劣る。より高速に除算を行うには，最適化された GBA BIOS の除算ルーチンを使用することが推奨されている。
http://www.devrs.com/gba/files/biosdiv.txt
まあ CPU の除算なんて，たいていどこでも遅いものなのだけど，ソフトウェアベースとなると法外に遅くなるし，Ｃの除算演算子を下手に使えないというのも心理的圧迫になるかもしれない。
例の "Precomputed Radiance Transfer for ..." を，ゆっくりながらも徐々に読んでみている。相変わらず読むのは遅いんだ。今回の論文はちゃんと SH （球面調和）の解説が付いているのが親切だ。 Ramamoorthi のはこれが無かったから，最初は何のことだかさっぱりわからなかったんだよなあ。ともかく，SH ベースの手法は色々と応用が効きそうな気がする。もうちょっとよく調べてみたほうがいいかもしれない。
2002-04-18
結局昨日は帰らなくて，泊まり作業で夜を過ごすことになった。そして，ちょっとしたスケジュールの変動により今日も夜半から忙しくなりそうな雰囲気になってきた。それでも僕はさほど切羽詰っているわけでもないので，午後に一旦抜け出して，帰宅して風呂入ってまた出社。ともかく，この会社にはシャワー室が必要だ。
"Spyro the Dragon" で有名な Insomniac Games の新作 "Ratchet & Clank" が公開されたようだ。
http://uk.playstation.com/news/newsStory.jhtml?storyId=10203...
http://gamespot.com/gamespot/stories/news/0,10870,2861838,00...
SCEA といえば，ちょっと前までは「クラッシュ」と「スパイロ」が看板キャラだったはずなんだけど，それらの版権を押さえている Universal 社がコナミと提携してしまったことにより，また別のキャラクタを生み出さざるを得なくなってしまったようだ。そうして生まれたのが，昨年末の "Jax & Daxter" と，この "Ratchet & Clank" なんだろう。とりあえず "Jax & Daxter" については，そこそこうまい具合にグローバル受けしそうなキャラクタにまとまっていたような気がするんだけど，一方この "Ratchet & Clank" はといえば，うーむ，眉毛が……。
Insomniac Games も非常に技術力の高い会社なのでゲーム内容には期待したいところなのだけど，どうもこのキャラクタデザインから察するに，日本での売り込みはあまりうまくいかなそうな気がする。
2002-04-19
いつものように flipcode をチェックしてみると，おもしろそうなトピックが上がっていた。 The Code Project より "How a C++ compiler implements exception handling"
http://www.codeproject.com/cpp/Exceptionhandler.asp
Windows 上，特に VC++ において例外処理がどのように扱われているのかを解説する記事だ。 Windows の構造化例外処理 (SEH) の説明から始まり， C++ がどのようにして例外の発生個所を特定するのか，とか，どうやってスタック上のオブジェクトを廃棄しているのか，など，分かりやすく順序立てて説明している。
例外処理と言うと，漠然と「重くなる」ってイメージを植え付けられているんだけれど，具体的にどこがどう重くなるのか調べたことはなかった。この記事から知る限りでは，例外処理を入れた場合のペナルティとは，
の３つに限定されるようだ。
(1) は，実際に例外に関連する処理の分のコード量が増加するに加えて，関数の拡張情報などを保持するテーブル類が付加されるために，余計にオブジェクトファイルの容量が増加する，というものだ。この影響は try-catch を使用している関数に限定され，例外処理に絡んでいない関数については発生しない。
(2) は，例外処理をトラップするためのハンドラを登録する処理で， try-catch を使用している関数に突入する度に行われる。これは実際に例外が発生しなくても強いられる処理なので，絶対的にコードを遅くする要因として考えられそうだ。
(3) は，例外発生時にその個所を特定したり，スタックの廃棄を行ったりするために要される処理で，かなり複雑な処理が行われることになる。この３つのなかで最も重い部分だろう。
超高級言語の類などでは例外処理をフロー制御の一種として扱う傾向が見られることもあるけど，少なくとも C++ に限定して言うならば，フロー制御としての例外の使用は避けたほうがよさそうだ。そうすれば (3) の影響は考慮しなくとも済むようになる。
難しいのは (1) と (2) の扱いだとおもう。特に (2) の影響は，ただ try を通過するだけで発生するものなので，例外を使用している以上は避けられないものとなる。だから，処理の末端部分で try を使用するのはならべく避けたほうが良さそうだ。ただ必然的に言って try を使用するのは通過回数の少ない根幹部分に当たる傾向があるので，この影響を危ぶむ必要は，実はそれほどないのかもしれない。通過回数が少ないのであれば，まあ関数のプロローグ処理が多少長引いたもの，程度に考えることができるからだ。
とにかく (1) の影響も考慮するならば，例外処理，特に try-catch ブロックについては，ならべく抑えて使うように越したことはないようだ。逆に throw のコストはそれほど考慮しなくてもいいかもしれない。
ところで，この辺りの例外処理の実装方法は， OS によって大きく異なることがあるようだ。 Linux と Windows でアセンブラリスティングを比較してみると，その内容がほとんど異っていることがわかる。特に Linux の方にはセットアップ処理がまったく存在しないところが印象的だ。
もうちょっと深く調べてみる必要があるかもしれない。
2002-04-20
急に忙しくなってきた。隙あらば日曜に一度帰宅するとして，基本的には２泊覚悟で出勤。ボスはもっと忙しい（ある種無謀な）スケジュールを課せられているわけで，僕はまだ楽な方であることには間違いない。
なんとなく SVG とか。ネタ元は mitsuman さんの所。
http://www7.lunartecs.ne.jp/~mamesite/svg/
CGI との組み合わせなんかで面白いことができそうだ。標準化やアプリ側の対応がまだそれほど進んでいないようだけど，まあそこは Adobe の SVG Viewer が事実上の標準となって普及が進むのではないかと。
今のところ CGI で画像を扱う際には ImageMagick なんかが大活躍。
でもなにぶんラスタベースだけにあまり効率がよろしくないので，今後は SVG も視野に入れていきたい所存。
2002-04-21
まあ結局今日も泊まり。きっとマスターアップ時期よりも，今のほうが忙しくなっているに違いない。
結局のところ，最も重要なのはロバスト性というかなんというか…… 1e^-10 や 1e^-20 が入ってきても正常な動作がなされることを常に保証しなければならないのだけど，そういった値は実地ではまず滅多に入ってこないわけで，それで現象が確認できないからって油断していると，ふいにとんだ冷や水を浴びせられることになる。
ああ，もう，いまさら言うまでもなく当然のこと。いくらゲームだからってったって，モジュールの単体テストぐらいやっときゃいいのに。
ところでゲーム向けのテスト手法って無いもんだろうか。もっとも，一般的なそれを適用すればいいんだろうけど。
2002-04-22
隙を見て一時帰宅。風呂入って出勤。さすがに２泊はキツい。主に匂いが。
SIGGRAPH の paper 集で有名な Tim Rowley 氏のページが更新されているようだ。内容はもちろん SIGGRAPH 2002 の paper 集で，いくつかの論文はすでにダウンロードできるようになっている。
http://www.cs.brown.edu/~tor/sig2002.html
やはり "Lighting and Appearance" 辺りが最も気になる。例の "Precomputed Radiance Transfer" とか， Ramamoorthi の "Frequency Space Environment Map" とか，そこらへん。インタラクティブＧＩとか，リアルタイムレイトレとかも面白そうだけど，これらの技術がローエンドに降りてくるのはもうちょっと先の話になりそうだな……。あとは DAKINI さんも注目の "Geometry Images" とか。たまにはメッシュ関連も触ってみないと。
2002-04-23
ここまで来ると，本気で昼夜２交代制の導入を考慮せざるを得ない。
ヴィド・フランスの制服はとても質素なデザインで，大抵の店員はまったく似合っていないんだけど，たまに似合うひともいるものだ，とおもう。もっとも，こんなひどいものでも似合うってことは，何を着たって似合うってこと。
しかしこの制服は，似合わない場合は，なぜかとてもドメスティックな雰囲気になる。
2002-04-24
連日の作業にさすがに息切れを隠し得ない。まだ終わることはできないのだけど，とりあえず，今夜は束の間の休息になりそうだ。
Xbox の「本物の」 VGA Box 製品。ドイツ製だ。
http://www.digital-x.de/knowhow/xbox/xbox_dx_vga_box/xbox_dx...
ビデオ信号をアップスキャンして VGA Box の名を騙る粗悪品も見受けられるけど，これは正真正銘の VGA Box だ。プログレッシブ SDTV モードに対応したゲームならなんでも VGA 出力できるらしい。ただし，ダッシュボードは対応していない模様。 DVD プレーヤも恐らく対応していないだろう。
ていうか，俗に言う HDTV ってのは，インターレス 1080 ラインのことを指すんだなあ。プログレッシブ 480 ラインはあくまでも SDTV だ。
個人的には GC の VGA 接続手段が欲しいとおもう。 GC はいわゆる「Ｄ端子」の D1 (480i) と D2 (480p) に対応しているそうで，このうち D2 出力を VGA に変換するケーブルを自作する方法もあるらしいけど，とてもそこまではやってられなさそうだ。
2002-04-25
なかなか決着がつかない。恐らく今日も泊まりだろう。世間様が連休に入るまでには何とかしなければいけないんだけど……
へんてこ技術系ニュースとして有名な ZZZ online が，いつのまにか復活していた。
半年ぐらい前から zzz.ru でアクセスできなくなったので，すっかり潰れたものだとおもっていたんだけど，地道に続いていたのね。相変わらずどこから見つけてくるんだか見当もつかないトピックがたくさんで，実に喜ばしい限りだ。また毎週チェックしよう，これは。
VORC 情報より，ロシアのＰＣメーカー PETERS PLUS のページ。
PETERS PLUS は ZX Spectrum （ Sinclair 社の 8bit マシンの名機）の互換機などを製作していることで有名な企業なんだそうで，今でも "Sprinter" と呼ばれる Spectrum 互換モードを持った Z80 マシンを生産している。
Sprinter はザイログ社の Z84C15 を搭載したマシンで，前述の通り ZX Spectrum との互換性を持っている。 Altera 社の PLD を搭載しており，これにより単一のハードウェアで２つのアーキテクチャを切り替えることが可能になっているそうだ。ちなみに PLD は Programmable Logic Device の略で，ソフトウェアにより変更可能なロジック回路のことを指すんだとか。ふーむ……。
さすがに Z80 まで戻りたいとはおもわないけど， 21MHz 駆動する Z80 とかちょっと恐ろしいかもしれない。それに 4MB ものメモリ空間をどうやってアクセスするんだろう。全部バンク切り換えかなあ。うへぇ。
2002-04-26
うーむ。さらに忙しくなるんだろうか……
結局のところ， C++ の例外処理には少々ながらも確実にコストが費やされるので，使用する側は常にそれを意識するようにしなけらばならない。もっともそれ以前に「 C++ の例外をフロー制御として使用してはいけない」というのは定説にあたるようで，文字通り例外的なケースを扱うものに限定するのが一般的な使用法とされているようだ。
この「どこからが例外で，どこまでが例外でないか」という線引きはなかなか難しいところがあるかとおもう。例えば指定されたファイルを読み取り専用で開く際に，そのファイルが存在しなかった場合に例外となるかと言うと，それは状況によって異なってくるものだとおもう。その程度で例外を投げるのは大げさだし，「ファイルオープンに失敗した」という値を返すのが仕様であるべきだろう，とすることもできるし，本来ファイルの存在可否は access 関数で調べることができるのだから，それを無理やり open するのは紛れもなく例外だとすることもできるかもしれない。
まあおおむね， C では assert や error を設置していたようなところに throw を置くような感じにすればいいとおもう。そうすれば，例外的な状況が発生した場合に，闇雲に処理を止めてしまうのではなくて，より上位のブロックに復帰の判断を委ねることができるようになる。
ところがこれで全ての例外が C++ の例外処理に置換されるということでもなくて，依然として旧来の assert 文などを使用する個所も残ることになるとおもう。 C++ 例外では，下位ブロックにおいて例外を「無かったことにする」のが困難だからだ。
商用アプリケーションの開発手法のひとつに "Writing Solid Code" の Maguire が述べているところの「防衛的プログラミング」というものが存在する。例外的な状況が発生した場合に，より安全な「仮の」処理を流すことにより状況の安定を図るというものだ。
上の例は name に関連付けられた mime_obj ポインタを返す簡単な関数だ。ここで dic_search が「オブジェクトが見つからなかった場合に NULL を返す関数」だったとすると， get_mesh が検索に失敗した場合はそのまま NULL を返すことになる。これを仕様としてしまうこともできるけど，もし検索に失敗するケースが稀で，大部分のコードが「 get_mesh は常に成功する」ことを前提として組まれているのならば，この状況は例外として扱うのがより適切な実装と言えるかもしれない。
get_mesh はこれで精一杯のことをしているのだけれども，より上位のブロックがこの例外を正しく扱う可能性は低いだろう。検索に失敗する可能性が低いからこそ例外にしたのであって，そのような場合の復帰コードを上位ブロックが用意しているとは考えにくいからだ。
このようなケースを「防衛的プログラミング」では次のように扱う。
error 関数で一応のエラー処理を行った後に，ダミーのオブジェクトを返すようにしている。デバッキングバージョンではエラーメッセージと共に実行が中断されるんだけど，リリースバージョンではエラー処理は無視され（例外は無かったことにされ） get_mesh を呼んだ上位ブロックではダミーのオブジェクトを受け取ることになる。上位ブロックではこのオブジェクトをダミーと知らずに使い続けることになるんだけど，とりあえず処理が中断されるような事態は避けられるはずだ。
このように「バグを隠すためのコード」を入れ込む行為に一抹の不安も感じないわけではないけれども，品質管理の観点から見るならば，こういったコードが非常に重要な意味を持つこともある。こういった些細なバグでいきなり実行が中断されてしまうよりも，ちょっとおかしくなりながらもひとつの区切り（例えばセーブポイントとか）まで続行できる可能性を残しておいた方が，ユーザ的に見てメリットが大きいからだ。
また，デバッグ時にもこういった「防衛的プログラミング」が役に立つこともある。上の例で言えば error 関数を強制停止関数にしてしまうのではなく，
とかそんな感じのダイアログを表示するようにして，テスターに処理の続行の判断を委ねるようにすれば，一部のつまらないバグによってテスト作業が中断されてしまうようなことも起こりにくくなる。コンシューマゲーム機のように ROM メディアに焼いてみなければテストできない場合や，そもそもテスト業務が外注だったりする場合には，このような処置がコスト的に良い結果を生み出す可能性はかなり大きいだろう。
2002-04-27
いつものごとくの休日夜出勤パターン。ただ，今日はいつもよりちょっと遅めのペースで，家を出たのは夜９時ぐらいのことだった。職場に着いたのは１０時頃。この時間じゃもうマックも閉まってるよね。まあいいや。結局，食事は適当にカップ麺でごまかすことにした。
アマゾンに注文していたメタルギア本がやっと届く。これがなかなか面白くて夜中に大いに読みふけった。技術的な事はさておくとして，大規模プロジェクトにおける制作進行の雰囲気がリアルに伝わってくるのがいいとおもう。僕が就職して最初に加わったプロジェクトがちょうどこれくらいの規模の大所帯だったんだけれど，どちらかと言えばそのときの雰囲気に近いものを感じた。
意外と面白かったのが，巻末にある小島秀雄自身の開発日記だ。あまり飾り気の無い文体で書かれたごく普通の手記なので，読み物としては面白みに欠けるところがあるかもしれないけれど，大規模プロジェクトのリーダーという立場から見た現場の景色を知るための資料としては，それなりの価値があるかもしれない。
日記を通して読んでいると，意外と多くの要素が削られた結果として，あの「製品版」 MGS2 があるんだということを思い知らされる。変態的なこだわりや，局所的なネタが盛りだくさんにみえるこのゲームも，実は削りに削りまくってこの姿なんだという事実は，作業する側の人間にしてみればなんとも恐ろしい話だ。
ゲームをやっている最中は，中後半の無線機デモの多さに辟易しかけたものだけど，これはコスト面の問題から多くのリアルタイムデモが無線機デモに移行させられた影響だったようだ。んまあでも，これはスクリプト作成段階での見積りミスだよね……。
あまり脈略の無い些細なネタ。
http://www.muckyfoot.com/downloads/tomsspec.html
PC のストラテジーゲーム "StarTopia" に組み込まれている裏技で，画面を ZX Spectrum 調のローレゾ＆ローアトリビュート風味にしてしまうというグラフィックエフェクトだ。しかも実装方法がちょっと変わっていて， DXT テクスチャ圧縮を利用してブロック化されたローアトリビュートへの変換を行うというものらしい。
エフェクト自体もなかなか味があるし，テクニックも面白いとおもう。最近のちょいヒットネタ，って感じ。
2002-04-28
前からやろうとおもっていた Maya の PLE (Personal Learning Edition) のダウンロードを決行。 130MB もあるので，とても家の回線じゃ落としてらんないのだ（うちはいまだに ISDN なのだ……）。コンビニで CD-R を購入して，ダウンロードしたファイルを焼き込む。今の時代コンビニでＲが買えちゃうんだよね。恐ろしいことだ。
ちょろっと触ってみた感じ，とても洗練されたインタフェースでよろしい限り。これがいまや LightWave 並の価格で入手できちゃうってんだから，エイリアスも思い切ったことをやるもんだと思う。ただし Maya Complete では NURBS モデリングの機能が限定されているようだ。ひとえに NURBS パッチと言えども Maya のモデリング機能の要をなす存在なので，必然的にデザイナは Maya Unlimited を買わざるを得ないってわけ。うーむ，微妙にせこいな……
Maya PLE では，上の画面のように常に画面にウォーターマークが入る。たぶんスクリーンショットを利用した素材利用を防ぐための防護策なんだろう。ファイルの保存・読み込みについては，本来の Maya とは互換性のない PLE の独自形式のみ対応。ちなみに PLE 形式の解析および対応ソフトの開発は契約条項により禁じられている。どんなかたちであれ，習得と評価以外の手段には使うなってこと。
そのかわり，本来の Maya が持つほとんどの機能を使うことができるのは喜ばしいことだ。もちろん MEL (Maya Embedded Language) の使用も可能で，ファイル入出力系の関数以外はすべて呼び出せるようになっている。
さっそく評判の高い MEL を試してみたいんだけど……時間あるかな。
Hoppe の "Geometry Images" がダウンロード可能になっていたので，ちょっと覗いてみた。
http://research.microsoft.com/~hoppe/
しかし，トポロジーとか出てきた辺りであえなくダウン。こういうのはどうにも難しいや。でもきっとそのうち，メッシュの王様ことミキタさんがサルでもわかるように怪訳してくれるに違いない……ので，この件は無かったことに。
代わりに Marc Alexa の "Linear Combination of Transformations" をダウンロード。
http://www.igd.fhg.de/~alexa/paper/
なんかいまいち怪しい内容だけど，もしかしたら役に立つかもしれない匂いがしたので，読んでみることにする。全然だめかもしれんけど。
2002-04-29
結局，最も忙しい時期と連休とが見事に重なってしまった。しかし，たぶんこの調子なら夏には楽になることができるだろうし，その代わりに今が忙しいだけのことだと思えばそれでいい……ということにしておこうと思う。
flipcode によれば "FreeSpace2" のフルソースコードが公開されたそうだ。
http://www.descent-network.com/cgi-bin/download.cgi?file=/dd...
FreeSpace のコミュニティサイト "Volition Watch" にはなぜか繋がらないので Decent-Network に置かれているミラーからダウンロードすることにした。
"FreeSpace2" は１９９９年に Volition 社から発売されたスペースオペラものの３Ｄシューティングゲームだ。
僕の中ではなぜか Digital Anvil の "Starlancer" とごっちゃになっちゃってるんだけど，それはどちらも Origin の "WingCommander" をベースにしているせいかもしれない。個人的に "WingCommander" には強い思い入れがあるのだ。
ソースの方は，まあそれほど変わったものでもなくて，わりと普通の作りをしているようだ。拡張子は cpp だけれど，中身はすべてＣファッションで組まれている。ただし，ツール類だけはＣ＋＋で書いているようだ。
そういえば Windows ネイティブなゲームのソースが公開されるのは珍しいかもしれない。せっかくだから色々見てみると面白いだろうと思う。
2002-04-30
スケジュールによれば，明日の夜にまたピークを迎える予定なので，とりあえず今夜は帰った方がいい気もするんだけれど，なんとなくノリで泊まり。どうせ勤務時間帯なんてめちゃくちゃになりつつあるんだから，ノリのいいうちに作業しておいた方が得に違いない。
ミキタさんが Hoppe の paper を怪訳してくれた上に要約してくれた！ さすがはミキタさんだ。有難いことこの上無い……これで堂々とこの論文を読み飛ばすことができる（えー）。
そして "Linear Combination of Transformations" の方は，あまり役に立ちそうにないことがわかってきた。なんとなくそんな気はしてたんだけど，まあ，この件はこれで終了ってこと。
なにげに Tim Rowley の paper コレクションをチェックしてみると， Ramamoorthi の "Frequency Based Environment Map" がアップロードされていることが判明した。
http://www-graphics.stanford.edu/papers/freqenv/
早速ダウンロードしてチェック。ふーむ，これはどうやら，おなじみの SH ベースの手法を使用して BRDF を近似しようというもののようだ。ちょっと見栄えしない内容かな。地味だ。
ともかく，もう少しちゃんと読んでみることにしようと思う。