2003-03-01
何やら，どんどん話が脇道へと逸れてしまっているような気がする。しかし，普段はなかなか足を踏み入れることの無い世界に目を向けることができたのだから，それはそれで良いだろうってことにしておきたい……。
浮動小数点演算の基礎的な知識については， Chris Hecker 氏の gdmag 記事 "Let's Get to the Floating Point" 辺りが参考になるかと思う。
http://www.d6.com/users/checker/pdfs/gdmfp.pdf
Michael Herf 氏は，もうちょっと x86 的な視点（ていうか「x87 的な視点」かなあ）から，浮動小数点演算の使いこなしテクニックを紹介している。
http://www.stereopsis.com/FPU.html
マニュアルなどからは伝わってきにくい実践的な情報が多く含まれており，参考となるのではないかと思う。特に float -> int 変換の遅さには気をつけねばならないようだ。
float -> int 変換については，件の記事にある "direct conversions" の方法が良いかもしれない。浮動小数点値を 23 bit 固定小数点値に変換するというルーチンだ。
ただし，引数 x の値域は [0.0, 1.0) の範囲に限られる。限定的なテクニックだけれど，応用を利かせば様々な場面に適用することが可能だ。どうせこんな凝った技を使いたくなるのは内部ループの中に限定されるんだから，いろいろと前提を設けることができるのではないかと思う。
この技のように，ビットを直接いじって操作することができるのも， IEEE 754 のおかげ……なのかなあ。ちょっと悪ノリのような気もしなくない。いつかの "Fast Math Routines" (NVIDIA) も，そんなひねくれたテクニックのてんこもり状態だ。
http://developer.nvidia.com/docs/IO/1220/ATT/fastmath.cpp
例えば， mitsuman さんも話題に上げていた exp 関数の近似など，いい例かもしれない。ちょっと読みやすくなるように書き換えてみたところ，以下のようになった。
なんでこれが exp 関数の近似式になるのか……考えてみると面白いと思う。ヒントは 1.44269504 = log2(e) であることだ。特に，一見ゴミと思われる部分が，実は線形補間式になっているところなど，意外性を伴った美しさを醸しているのではないかと思う（言い過ぎか……）。ともかく，このおかげで，相対誤差値は考えるよりもずっと低く保たれているようだ。
2003-03-02
FPU に関してもう少し詳しい資料を求めるならば， David Goldberg 氏の "What Every Computer Scientist Should Know about Floating-Point Arithmetic" や， William Kahan 氏の "Lecture Notes on the Status of IEEE Standard 754 for Binary Floating-Point Arithmetic" などが挙げられる。
http://www.validlab.com/goldberg/paper.ps
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
ただ，これらの資料はもともと研究者向けに書かれたものなので，現場の実践的な知識として役に立つものかどうかは分からない。何しろ量がたっぷりあるものだから，僕も手を出しかねている。このくらい，さらっと読めるようになりたいね……。
例えば交差判定ルーチンなどを書いていると，演算手順によって誤差の出かたが変わってくることに気付いたりするわけで，その辺りを数値的に正しくまとめるには，やはりこういった知識が必要になるのだろうと思う。
うう，まあいいや……。また込み入った知識が欲しくなったら，その時に引っ張り出してくることにしようと思う。
最後に，雑学的なネタとして面白かったのが "The Table Maker's Dilemma" だ。
http://www.ens-lyon.fr/~jmmuller/Intro-to-TMD.htm
例えば，あるドメインにおいて完全に正確な値を返す超越関数（sin, cos, exp 等）を設計するには，逆に最悪のケースを探索しておく必要がある。最悪のケースが見つかったならば，それをカバーすることのできる精度を基準として設計を行えば良いからだ。
それじゃあ，その最悪のケースってやつをしらみ潰しに探してみようか……というのがこの研究の意図であるらしい。要するに，特定の超越関数において，最も誤差の大きくなるケースを探してみよう，というチャレンジ企画だ（そんな軽いノリかなあ）。例えば， log 関数における最悪のケースとして挙げられているのが，以下の式だ。
"1^{60}" の部分は， 1 のビットが 60 個連なっていることを表している。これはつまり，倍精度小数点における最下位ビット（53 桁目）の状態が， 2 の -111 乗という僅差で決定されるケースがあることを示しており，結果的に 115 桁以上の精度を保証しなければ正しい丸め値を求めることができない……という結果を導き出すものとなっている。
まあ，なんて言うか……素人目には pi の桁競争みたいな感じにも見えるんだけれど，より高い演算精度を得るための研究として，そこそこ重要な意味を持っているようだ。
http://www.google.com/search?q="Table%20Maker's%20Dilemma"
2003-03-03
色々なことが平行して進んでいる。しかし，その内容について書き留めておくだけの余裕が無い。記憶が風化する前に，なんとか文書に直しておきたいんだけれど……。
ある件で調べ物をしている最中に，次のような記事を偶然に見つけた。
http://www.toshiba.co.jp/about/press/2001_09/pr_j2701.htm
ああ，そう言えば，そんな話もあったような気がしないでもない。東芝の TX79 コア……つまり， MIPS R5900 "Emotion Engine" の汎用向け製品だ。
http://www.semicon.toshiba.co.jp/prd/risc/79family/7901/7901...
EE と比較してみると，いろんな所がちょこちょこと変更されているように見える。特に，あの悪名高き SPRAM (Scratch Pad RAM) が削られて，替わりに 32kB の 2-way データキャッシュが追加されている所など，かなりいい感じだ。確かに，あのメモリ周辺に見られるアクの強さを排除して，更にコプロセサ類なんかも外してしまえば，それなりに無難な CPU として扱えてしまうかもしれない。むしろそれこそが本来の R5900 像のようにも思える。
なにげに FPU が IEEE 754 準拠へと改良されているようだ。倍精度への対応が追加されている辺りなども，汎用向けを意識した所ではないかと思う。元は単精度しか扱えなかった上に，微妙に IEEE 754 非準拠，しかも例外処理など皆無なものだから，汎用的なプログラムを動かす際に障害となることが多かった。例えば， PS2 Linux 上で浮動小数点を使ったアプリを動かす場合などがそれに当たる。
同サイトから TX79 のデータシートをダウンロードすることもできる。
http://www.semicon.toshiba.co.jp/prd/micon/td/index_td.html
詳細について見回してみると，わりと EE の面影が残されているようにも思えてくる。ベクターユニット類が取り払われてしまったために，凝った３Ｄ演算などを行うことはできなくなってしまったものの，あの豪快な 128 bit 汎用レジスタ群や，奇妙なマルチメディア命令セットなどは健在だ。
このマルチメディア命令セットも，ちょっとした曲者かもしれない。明らかに何らかの意図をもって設計されたものと思われるんだけれども，具体的な応用方法について提示されていないものだから，いまいち解釈に戸惑うことがある。例えば PEXT5 命令（"1:5:5:5" パック形式からの展開）などは 16 bit 色からの変換を意識したものだ。こんな感じで，特定の用途にしか使いようのない命令がピンポイントで実装されており，なんとも不思議な感覚を呼び覚ましてくれる。
平行ブロードキャスト除算 (PDIVBW) とか， HI/LO レジスタを使った 32 bit 乗除算とか，いまだに一度も触ったことの無い命令が数多く存在する。前述のマルチメディア命令セットも，音声処理や画像処理には便利そうだけれど，そういうのは DSP に任せるのが MIPS 的な解決方法なのでは……と思うことがある。実際，ゲームなんて作る限りでは，そう滅多にお世話になるもんじゃないと思う。そんなことに手を出している余裕が，この CPU には残されていないのだ。
基本的に 64 bit CPU をうたっているものの，仮想アドレス空間は 32 bit に制限されている。汎用レジスタは 128 bit もあるけれど，普段利用するのは下位 64 bit だけだ。他にも突っ込みどころがそこいらに散在している。とにかく……なんて言うか， MIPS らしからぬ雑然さを備えた，奇妙な CPU ではないかと思う。
2003-03-04
んん，なぜだか生活に余裕が無い。そんなに忙しいわけでも無いんだけどなあ。
今日は泊まり。
Gamespot に掲載されている "Grand Prix Challenge" (Melbourne House) のインタビュー記事が面白い。
http://gamespot.com/gamespot/stories/previews/0,10869,291202...
ゲーム自体は普通の F1 モノらしいんだけど，プロデューサーである Andrew Carter 氏の押しの強さがいい感じに出ている。なんでも， PS2 の性能を約２倍に引き上げる新手のテクニックを発見したんだとか……。
まあ，なんて言うか，いわゆるセールストークの一種なんだろうけども，ここまでさも自信ありげに話されると，かえってなんだか面白い。信じてみるのも面白いかも，という気にさせてくれる。夢があっていい話じゃないか。
その後にも，やけに景気のいい話ばかりが続いている。総計５０万ポリゴンほどで構成された背景の上に，１台あたり２万ポリゴンの車が２２台同時に動いて，その１台毎に千個以上のパーティクル・エフェクトが付いて……とか，そんな感じ。
http://www.infogrames.com.au/screenshots1.htm
事の真偽はともかくとしても，これだけの数の車体が同時に処理されているのは，なかなか高度な技術力なのではないかと思う。ドライビングゲームのベストセラーとして君臨する "GT" シリーズも，初代から最新作に至るまでずっと同時走車数が６台に制限されており，その数の少なさを責められることが多いようだ。特に F1 やル・マンのように実在のレースを題材として採用するとなると，そういった点がより重要な意味を帯びてくるのだろうと思う。
このゲーム "Grand Prix Challenge" を制作したのは，オーストラリアの老舗ゲームデベロッパである "Melbourne House" という集団だ。その発祥は Sinclair ZX Spectrum や Commodore 64 の時代までさかのぼるというのだから，相当な歴史を持ったデベロッパであることが分かる。
http://www.lysator.liu.se/tolkien-games/entry/hobbit.html
なんとなく聞いたことのある名前だなと思っていたら，あの有名な "Test Drive Le Mans" を制作したデベロッパであったようだ。
http://dreamcast.ign.com/articles/164/164869p1.html
海外での "Test Drive Le Mans" の存在は， Dreamcast 向けレースゲームの最高傑作として扱われているようだ（国内では発売されたかどうかも分からない……）。当時はちょうど PS2 のローンチが完了した頃で，周囲の PS2 に対する幻想が徐々に冷めつつある時期にあったと記憶している。そんな状況にあって， Dreamcast 上で２３台の車体を同時に動かすという高度な処理をやってのけたことは，同マシンのファンを大いに賑わせることになった。 CPU 処理だけでなくグラフィック的にも非常に高いレベルをキープしているこの作品は，同社の技術力を大いにアピールするものとなっていると思う。
そんなわけだから，今回の虚勢じみたセールストークにしてみたって，ちょっとは信じてみようって気になるわけだ。
2003-03-05
今日は，昨日からの泊まり。
ふとした思い付きから，自分の机ではなく，空いている席の下で寝てみることにした。僕の席は窓から少し離れた所にあるものの，やはり夜になると冷気が入り込んでくる。つい最近，とある事情でフロア中央の席が空いたので，そこで寝るようにすれば，夜中に寝袋の中で寒い思いをすることも無くなるかもしれない。
さっそく，エアパッチと寝袋と，読み古しのジャンプ（枕のつもりだ）を持ってフロア中央の席へ移動する。最近，寝袋にファブリーズをかけまくっていたものだから，すっかりファブリーズ臭くなってしまった。
結果は上々。やはり僕の席は予想以上に外気の影響を受けていたようだ。窓際の席はあまり良いことが無いものだと思う。見晴らしの良さについてはともかくとして，直射日光の影響でモニタが見え難かったり，本の表紙が煤けてしまったり，外気の影響をもろに受けたり……意外と悪いことばかりが目に付く。特に職場へ長く身を置く場合には，だ。
2003-03-06
いろいろ地味に忙しい。今日は泊まり。それにしても，恐ろしい事件が起きてしまったものだと思う。
http://www.zdnet.co.jp/games/gsnews/0303/05/news03.html
正味な話，僕にはさっぱり事情が分からないのだけれど……とにかく，ひどくややこしい事態に発展してしまっているのだろうということは，想像に難くない。
GDAlgorithms で "Judy Array" なるものが，一瞬だけ話題に挙げられていた。すぐ流れてしまったけどね……。
なんだか知らないけど，高速に動作する連想配列ライブラリらしい。処理速度やメモリ効率の点で高機能をうたっているものの，実際にどういったアルゴリズムを利用しているのかという点については，これといった解説が与えられていない。一応， "A 10-minute description of how judy arrays work and why they are so fast" なる文献が用意されているんだけども……うむむ，やはりよく分からない。
http://judy.sourceforge.net/downloads/10minutes.htm
なんとなく，キャッシュメモリの構造に適した構造や処理を盛り込むことによって高速化を図っているような雰囲気だ。まだ詳細については掴みかねている。こういうのは，地味だけども興味を惹かれる。もうちょっと時間を使って，ゆっくりと調べてみようと思う。
2003-03-07
金曜の夜は電車が混むから，できるだけ早く帰りたい。いや単に混むだけならともかく，色々と問題があるんだよなあ。酔っ払いとか多いからさあ……。
とかそんな焦りを感じつつ，帰りがけにサーバの電源を落としまくる。休日中に停電があるらしいので，シャットダウンしておかなきゃならないのだ。 USB キーボードやモニタケーブルを挿してはシャットダウン・コマンドを打ち込む作業を繰り返す。意外と面倒くさいなあ，これ。
Gaming-Age Forum への投稿情報によると， "Grand Theft Auto" シリーズで有名な Rockstar Games が，初代 "GTA" の無料配布を始めているようだ。
http://www.rockstargames.com/classics/
これは "Rockstar Classics" と銘打たれた企画の第一弾であり，今後も同社の過去の作品群を無料配布していく予定のようだ。とは言っても，僕は "GTA" シリーズ以外の同社のタイトルをまったく知らないんだけれど……。
アジア地域を除く全世界において総計８５０万本もの売り上げを記録した化け物タイトル "GTA3" は，同社にとっての稼ぎ頭となっただけではなく，世界規模でのビデオゲーム産業にとっても重要な意味を占める存在となりつつある。もし，去年のクリスマスシーズンに "GTA3: Vice City" が発売されていなかったら，去年度における業界全体の売り上げを大きく引き下げる結果となっていたかもしれない。それは即ち，北米ゲーム産業の大幅な転落を意味することになる。
http://www.dfcint.com/game_article/jan03article.html
「もし去年末にポケモンルビー・サファイアが出てなかったら，年末商戦は死滅していたかもしれない」というような話と同じノリを感じる。ええと，それはともかくとして…… "GTA3" および "Vice City" の記録的な売り上げは，パブリッシャである Take-Two 社の業績を大いに潤わす結果となったようだ。
http://news.bbc.co.uk/1/hi/technology/2807759.stm
http://www.gamasutra.com/php-bin/industry_news_display.php?s...
また付随する要素としては，北米における攻略本売り上げの新記録を達成したことも挙げられる。
http://ps2.gamezone.com/news/01_02_03_09_18AM.htm
ＦＦの攻略本が１００万冊売れるような国内の状況と比較すると，大したことのない数字のようにも思えるけれど，攻略本という文化がそれほど一般的でない北米地域においては，興味深い記録を残す結果となったようだ。
ところで， Rockstar Games のウェブサイトをよく見てみると，あの "Max Payne" も同社のタイトルとしてラインナップされている。むむ，あれって Remedy と 3DRealms 社の共同開発じゃなかったっけ。
http://www.maxpayne.com/faq_main.html
どうやら，家庭用バージョンについては Rockstar と Take-Two が販売を担当することになっていたようだ。ううむ，なんだか複雑だなあ……。
また， "State of Emergency" というタイトルがあったことも思い出した。これも Rockstar Games の開発だったようだ。
http://gamespot.com/gamespot/filters/products/0,11114,478094...
GTA3 と同時期にメディア展開を行っていたソフトで，個人的にはむしろ "State of Emergency" の方に注目していた。結果的に，こちらはあまり話題にならなかったものだから，存在自体をすっかり忘れてしまっていた。ゲーム内容は都市における民衆の暴動をテーマとしたもので，雰囲気的には「北米的解釈における『三国無双』」って感じではないかと予想している。
一度プレイしてみたいんだけれど，個人輸入するってほどでもないんだよなあ。ううむ……。
2003-03-08
様々な理由から，ゲームプログラムに XML パーサを組み込んで利用するというシチュエーションを考えてみている。
現行の家庭用ゲーム機に存在する種々の制約を考慮すると，実行時に XML のパースを行うことは，ちょっと「富豪的」過ぎるような感じがする。方法論としては恐ろしくスマートなのだけれど，タグ構造をパースする手間や，テキスト表現をバイナリ値に変換する手間を考えると，これまでの基準からすれば非常識なまでに無駄な処理が必要とされてしまうからだ。
それでも，次世代ではある程度の贅沢が許されるようになるだろうし，小さなデータぐらいだったら現状だってそれほど問題にはならないのではないかと思う。
その，「ではないかと思う」の部分を確信へと変えるべく，地味に暗躍を続けているこの頃だ。
まず最初に行うべきは，できるだけ軽量で高速な XML パーサを入手することだ。ここでは敢えて，自分で作るという方法は考えないことにする……。
「軽量な XML パーサ」ときて，とりあえず思い当たるのが， Lee Thomason 氏の "TinyXML" だ。
http://www.grinninglizard.com/tinyxml/
ちなみに， Java 向け軽量 XML パーサとして同名のライブラリが存在するけれど，これとは全く別物だ。
このライブラリは shinichiro.h さんが「白い弾幕くん」などで利用している所から知った。
http://user.ecc.u-tokyo.ac.jp/~g940455/wp/sdmkun/
C++ をベースとした XML パーサで，規模はかなり小さい。リンク時のサイズで 70kB 程度になる。基礎的なライブラリとしては好ましいサイズだと思う。ここで数百 kB も食ってしまうと，肩身の狭い思いをすることになるからね……。
気がかりなのは， DOM (Document Object Model) を利用していることから，フットプリントがどうしても大きくなってしまうのではないかと思われる所だ。この辺りは，実際に計測してみないことには分からないと思う。
実際に，適当な XML ファイルを使って計測を行ってみることにした。テスト対象は，と…… ATI RenderMonkey に付属の water.xml (54kB: 964 elements) がちょうど良い具合だったので，これを使ってみることにした。余談だけど， RenderMonkey のファイル形式は標準で XML を使用するようになっている。なにげにこういうのが XML ベースになっていると，転用が楽で便利だ。
手順は簡単…… "operator new" をオーバーライドして，確保されたメモリサイズを記録するだけだ。結果は以下のようになった。
ううむ。結構膨らむなあ……。
それよりも気になったのは， TinyXML のパース速度の遅さだ。試しに，このプログラムを１０回実行するのにかかった時間を計測してみたところ，以下のような結果が得られた。
0.8 秒って，字面ではそれほど重く感じられないかもしれないけれど，実際に待ち時間として体感してみると，かなりもったりした感触がある。これは PC だからまだ良い方で， CPU パワーの貧弱なゲーム機で同じことをやったら，もっと重くなるに違いない。フットプリント云々よりも，むしろこちらの方が問題になるのではないかと思われる。うむむ……。
2003-03-09
TinyXML は速度面で問題が発生しそうだなあ，という香りがそこはかとなく漂ってきた。負荷の原因を探るべくプロファイリングを行ってみたところ，文字列クラスの周辺にボトルネックがあるような雰囲気が感じられる。それなりに気合を入れれば改善が可能かもしれない。こういった場合にソースが短いのは助けになる。
速度面を追及するならば，まず候補として挙げられるのが expat だ。
さすがに James Clark 先生が鍛え込んだパーサと言うだけあって，速度は驚くほどに速い。 SAX 形式の API を採用しているので，フットプリントは極力小さくて済む。限定的な用途への利用には非常に適していると言える。 PC 上で XML 処理を行う場合には，強力な選択肢の一つとなる得る存在だ。
ただ expat にも難点が無いわけではない。特にゲーム用途への応用の際に問題になると思われるのが，そのコードサイズの大きさだ。例えば cygwin に付属の libexpat.a だけで 353kB もある。どうやら，高速化のためにパース処理のコードをマクロ展開しまくっているようで，ソース自体はそれほど大きくもないのに，実行コードは無闇に太ってしまっている。
そういった事情もあって，今回の場合は，当初から expat を選択肢から外すことにしていた。パーサだけで 300kB オーバーってのは，ちょっとね……。覚悟を決めれば無理でもない量だけれど，もう少しなんとかならないものだろうかと思う。
そんなわけで，悶々としながら google を叩いていると，次のようなライブラリに出くわした。 "Parsifal" だ。
http://www.saunalahti.fi/~samiuus/toni/xmlproc/
"Parsifal" は SAX2 API を部分的に実装した C 言語ベースの XML パーサだ。フィンランドの Toni Uusitalo 氏が開発を行っている。比較的新しいライブラリのようで，最初のリリースが去年の１１月となっている。本当に生まれたてのライブラリだ。
昨日と同様のテストプログラムを作成して計測を行ってみたところ，興味深い結果を得ることができた。
うん……そこそこ速い。これでコードサイズは約 40kB ほどだ。悪くない。
これもプロファイリングを行ってみたところ，ストリーミングでだいぶ処理を持ってかれてしまっているような感じがある。ゲーム用途に限定する場合は，ストリームと直結させることはまず無いだろうから，この部分を改造してしまえば更なる高速化を得ることが可能かもしれない。
ソースもそれほど長くないので，改造は難しくないと思う。それにしても……，こういうこと言っちゃいけないのかもしれないけど，ソース汚いなあ……。ちょっと萎えた。うへえ。
2003-03-10
寒い。もう三月も中旬に入ろうというのに，寒すぎる。冷たい北風が顔面に吹き当たると，一瞬息ができなくなってしまう。ふがふが……。
出社すると，席の辺りがやけに静かだった。そう言えば，昨日あった電気工事の関係で，マシン群をすべてシャットダウンして帰ったんだった。マシンが回っていないと，意外に静かなんだ，この席。
手始めとばかりに，マシン群に火を入れていくと，またいつものように騒々しいマシンノイズが聞こえてきた。うう，どうにかならんものかなあ。しかもよく見てみると，ちゃんと復帰していないマシンが数台あるみたいだ……。うげえ。
いつもよりちょっと多めのミーティングや，厄介な復帰作業をこなしていると，次第に体調が悪くなってきた。うう，喉が痛い。なんかもうダメかも。
結局，帰宅するのは普段より遅くなってしまったんだけれど，大事をとって早めに寝ることにした。久しぶりだなあ，こんなに早く寝るのは……。
2003-03-11
体調はほぼ回復。大したことなかったみたいだ。今日も寒いけど……。
何気なく SCEA R&D のページを覗いてみると， GDC 2003 の講演に使用されたプレゼン資料がアップされていた。
公開された資料は "Faster Math Functions" と "Spherical Harmonic Lighting: The Gritty Details" の２つ。両者とも SCEA R&D の Robin Green 氏が担当している。
前者の資料は，昨年公開されたものとほぼ同内容のものだ。もう定番ネタってことなのかなあ。ともかく，例の paper に目を通した人にとっては，ことさら重要なものではないかもしれない。できれば， paper を読む前にちらっと目を通しておくと，なんとなく内容を掴んでおくことができて良いと思う。雑学的な話題や余談が所々に混ぜられており，読み物としては面白いものになっているのではないかと思う。実際の講演も，ちょっと見てみたかったかもね……。
後者の資料は今年の新ネタだ。「ＳＨライティング」と言う題名が付いているけれど，内容的には Sloan の "Precomputed Radiance Transfer" を主に扱ったものとなっているようだ。
http://research.microsoft.com/~ppsloan/
要素的に新しいものはほぼ無く，既存の理論の解説に終始している。また，実践の際に必要となるテクニックについて具体的に触れているわけでもなく，どちらかと言えば教科書的な内容にとどまっている向きが強い。それでも，この資料自体が決して無価値なわけではなくて，参考書として非常に役に立つ内容なのではないかと思う。 Sloan の論文で言えばペラ数枚に圧縮されているような内容が，５０ページの資料の中に広く展開されている感じだ。現行の一般的なリアルタイムＣＧを扱っている技術者にとって不足しているであろう知識を丁寧に補い，数学的な理論よりも直感的な理解を助けるような表現を多く用いることで，より広い層への解説を行おうとしている。
特に，球面プロットを使って視覚的な解説を行っているのは面白いな……。やはり Mathematica は必要だと思う。
氏のことだから，恐らく実装は PS2 上で行っているんだろうと思う。 Audi Roadster のレンダリングが無難にいい感じだ。拡散反射まではＳＨライティングを利用し，鏡面反射には普通の環境マッピングを利用するというテクニックの例になっている。そうそう，車のモデルとかって可動部分が少ないから，ＳＨライティングの例題としては適しているんじゃないかと思っていたんだ。よく見てみるとポリゴンのエッジが見分けられることから，それほど無茶に密なメッシュでもないことが察せられる。この程度のメッシュと単色相互反射だったら，近い将来に実用レベルまで落としこめるかもな……。
この paper の内容は，拡散面の相互反射を扱う所までで終了しているんだけれど，いずれこれを光沢面の相互反射まで拡張する予定とのことだ。ともかく，氏の方針としては，もう少しこの方面に突っ込んでいくことになるようだ。ゲーム向けの R&D としては「実用と非実用の境界すれすれ」って感じの内容ではあるんだけど，むしろその位がちょうど良い加減のようにも思える。
今更ながら，今年の GDC は行っておけば良かったかもしれないと，ちょっと後悔している。来年になったら行けるかどうか分からないんだから，行けるうちに行っておくのが正解だったんだろうと思う。しかし，海外旅行の経験なんてまったく無いから，いろいろと面倒でね……。
これだから出不精はだめなんだ。うへえ。
2003-03-12
昨日の続きで， "Faster Math Functions" のプレゼンテーション資料に軽く目を通してみた。
http://www.research.scea.com/gdc2003/fast-math-functions.htm...
内容については，去年の資料とほとんど変わりないようだ。ただ，ちょっとした違いは何点か見られる。例えば，この前の exp 関数高速近似ネタが "Fast Float Exponent" として新たに追加されている。ふむふむ……。あとは，対数関数の項に載っている "A Mathematical Oddity" こと "Bitlog" 関数の解説がちょっと面白いかな。整数値に対する log2 の近似関数だ。
ここで登場する関数 lzc は， "leading zero count" ……つまり，上位に連続する０ビットの数（最も上位にある非０ビットの位置）を返す関数だ。これは，例えば TX79/R5900 なら PLZCW 命令を用いることによって求めることができる。
http://www.semicon.toshiba.co.jp/eng/prd/risc/79family/pdf/t...
また，同様の命令が PS one の GTE (Geometry Transfer Engine) にも存在していたようだ。
http://www.google.com/search?q=lzcs+lzcr+gte
このことから，この "Bitlog" 関数は，前世代環境においてそれなりに有効な手段であったことが予想できる。今でも，近似精度の悪さや値域の制限などが気にならないシチュエーションであれば，使うこともできなくないだろうと思う。なんとなく log っぽい挙動を得たい場合には，そこそこ使えるテクニックかもしれない。
ところで，この Bitlog 関数の初出文献を調べてみようと思ったんだけれど，ちょっと調べてみた限りでは突きとめることができなかった。ただ， Jack Crenshaw の "Math Toolkit for Real-Time Programming" の中で詳細な解説がなされているとの情報が存在した。
http://www.amazon.com/exec/obidos/ASIN/1929629095
ううむ，ちょっと面白そうな本だなあ。値段も高くないし，良さげな本だ。レビュアーの評価が異様に高いのが，いろんな意味で気になる。試しに google.co.jp で検索してみると，げーはなさんのページがヒットした。あー，そういえばそんなことも。
滅多に使う機会の無い命令が多々存在することで有名（？）な TX79/R5900 だけれど，ここで用いた "leading zero count" 命令こと PLZCW も，今ひとつ用途の不明な命令の一つだった。なんとなく log2 の近似に使えそうかなあ，ってことは分かるのだけれど，それだけのために用意されているとは考えにくいからだ。
ちょろっと検索にかけてみると（僕は立派な google 依存症患者だと思う），そこそこヒットする。それほどマイナーなオペレーションってわけでも無さそうだ。
http://www.google.com/search?q=%22leading+zero+count%22
ええと，算術演算のロジックを組み立てる上で利用することがあるのかな。それから，ビット列処理などに用いることもあるようだ。いずれにしろ，頻繁に利用するものでは無いと思うのだけれど……。
まあ，これも何かの縁なので，せっかくだから Bitlog 関数でも実装して my_math.h に突っ込んでおこうかと思う。
2003-03-13
今日は終日ミーティング。会議室の固い椅子の上に長時間腰をおろしていると，肩が凝ってしまってしょうがない。普段は肩凝りに悩むことの無い体質なんだけれど，長くミーティングに出席していると，いつの間にか肩が張ってしまっているのだから不思議だ。椅子の上でじっと大人しくしているというのは，予想以上の負担を身体に与えているようだ。
最近，あまりプログラミングに集中できていないような気がする。むむ……。
このところ，暇を見つけては Judy Array 関連のドキュメントに目を通してみている。しかし，なかなか結論まで至ることができなくて，少し焦れったい思いをしている。
http://judy.sourceforge.net/application/shop_interm.pdf
Judy Array は，オペレーションの速さとメモリ効率の良さを兼ね備え持つ，高性能な連想配列ライブラリだ。従来のハッシュ法を上回るアクセス速度を持ち，かつ，単純な二分木などにも匹敵するメモリ効率の良さを保持していると言う。ううむ，耳にする限りでは，何やら非常に都合の良いもののように思える。本当かな……。
ここで興味の対象となるのが，その非常に優れた性能を実現するために利用されたテクノロジーの詳細についてだ。しかしこれが困ったことに……いまいち不明瞭なのだ。
上の文献 "Judy IV Shop Manual" は，これだけでかなりの長さを持っており（約８０ページ），いきなり手を出すことはためらわれるかもしれない。これとは別途に「１０分で分かる Judy Array」なる文献も提供されている。僕の場合は，まず手始めにこちらから手にとってみることにした。
http://judy.sourceforge.net/downloads/10minutes.htm
しかし実際には，最初にこの文献を目にしたところで，いきなり要領を得ることは難しいのではないかと思う。どちらかと言えば，新規に Judy Array に触れる人よりも，すでに概要を得てから細部に疑問を持っている人に向けているようなきらいがあるからだ。順序としては，前者の文献に一旦目を通し，なんだか腑に落ちない感覚に陥ってから，後者の文献を読んで無理やり納得する，というのが正しいのかもしれない。
Judy Array が，従来の古典的なデータ構造と比較した場合に最も異なっている点は，「非キャッシュメモリアクセスの低速性」を考慮に入れているという点にある。データ構造の設計を行う上で，メモリキャッシュの特性が十分に考慮されているのだ。具体的には，単位データ構造をキャッシュラインに適合するような形にしていること，あるいは，同一のキャッシュラインに乗っているデータの走査であれば高速に処理することができるという点を活かしていること，等々の工夫が挙げられる。これらの要素を組み込むことによって，省メモリ性と高いアクセス速度を同時に得ることが可能となっている。
しかし， Judy Array の設計において最も重要な点は，設計に対する複雑性の混入を許容しているという所にあるように思える。つまり，「汚い仕事に手を染める」ことを敢えて行っているわけだ。
Judy Array には，ノードへ格納されるキーの個数 (population) に合わせてデータ構造を使い分ける，という処理が組み込まれている。初期段階においては単純なソート配列を利用し，キーが増えるにつれ "bitmap branch" 等の疎な構造を導入していき，最終的には一様な trie 構造に落ち着くようになっている。このようなデータ構造の使い分けを行うことにより，格納されるキー列の性質に関わらず，安定した性能を提供することが可能となっている……ということのようだ。
そういった意味で言えば， Juddy Array は「原理」ではなく，あくまでも「応用」なのかもしれないと思う。その仕組みを理解したところで実装することは難しい。むしろ，その実装を行ったことこそが，製作者諸氏らの功績なのだろうと思う。
2003-03-14
今日も終日ミーティング。このところ，ずっとミーティング漬け状態だ。
他にも色々あって，今月は最も進捗の少ない月になりそうな気がする。
Judy Array では，データ構造の一つとして "trie" 構造を利用している。
http://www.everything2.com/index.pl?node=trie
http://www.cs.princeton.edu/courses/archive/spring03/cs226/l...
trie 構造は，要するに木構造の一種で，特に枝の数が比較的多いものを指してそう呼ぶようだ（k-ary tree とも呼ばれる）。 "trie" という名前の由来は，「取得」を表す語 "retrieve" から来ている（ただし発音は「トライ」）。
trie 構造の利点は，その検索速度の速さにある。特に，膨大な量のデータに対しても O(n) のオーダー（n はキーの長さ）を忠実に保持できることが特徴として挙げられる。
逆に欠点としては，なんと言ってもメモリ効率の悪さが目立つ。例として英単語帳を実装するには，ノード毎に 26 の枝を持つ trie 構造を利用することになる。ベタな実装で行くと，ノード毎に最低でも 26 * 4 = 104 バイト消費することになるのだから，なかなかのメモリ食いのように思える。
ただ，メモリ効率については，キーの長さに対して制限を与えたり，基数（枝数）を絞ることができれば，それほど深刻な問題にはならないだろうと思う。それに，キー列が十分に増えて中身が充填されるにつれ，無駄な領域は減少していくことになり，むしろ他の構造よりもメモリ効率が良くなるケースも存在するのではないかと思う。
このような特性を持っているためか，電子辞書のようなアプリケーションでは比較的多く用いられているものの，通常のアプリケーションではなかなかお目にかかれない存在となっているようだ。
ちなみに， Judy Array において trie 構造が登場するのは，枝の数が十分に増えた場合のみであり，通常はもう少しコンパクトなデータ構造が利用されるようになっている。この辺りの複雑性が Judy Array の速さの秘訣となっているようだ。
Judy Array の解説書 "Judy IV Shop Manual" は，比較的軽いノリで書かれており，難しい専門用語が登場することもなく，比較的楽に読み進めることができる。例えば，ハッシュ法の欠点について列挙している部分があったので，それを引用してみると……こんな感じだ。
ただ，読みやすいからと言って，内容が把握しやすいというわけではなさそうだ。結局，ここで扱われている内容を完全に理解したとしても，同等のものを実装するには，やはり苦労することになるだろうと思う。
2003-03-15
今日は普通の休日。いつものように，飯ついでに本屋に寄ってみると， "UNIX Super Text" の改訂版が平積みされていた。ああ，なんかちょっと懐かしいなあ，これ。
http://www.gihyo.co.jp/books/syoseki.php/4-7741-1682-3
初版の発行からすでに１０年が経過している。その間，おもだった改訂は一度も行われなかったようだ。僕も学生の頃によく参照していた記憶があるのだけれど，その頃でさえ，すでに時代とのずれを生じている個所が目立っていたように思える。 Linux 等の PC UNIX がメジャーになる以前の時代が背景となっているわけで，ワークステーションの操作方法やら JUNET に関する記述やらを見かける辺りに，この本の古臭さを感じることがあった。
最近は仕事の関係で Linux を利用していることから， UNIX 関連の参考書について尋ねられることがまれにある。 "UNIX Super Text" は，本来の用途からすれば最も要望に適しているはずの参考書なのだけれど，「内容が時代に即していない」という点から，強く推すことがためらわれていた。しかし，今回の改訂のおかげで，また気軽に薦められるものになったかと思う。
とりあえず，これさえ読んでおけば TeX でレポートを書く程度のことは出来るようになるわけで，学生さんなどには特に重宝されることだろうと思う。あ，でも，今どきはレポートの類も Word で書くのかもなあ……。
以前から目を付けていた「省メモリプログラミング」を，またもや立ち読みした。いまいち買う気にはなれないでいる。
http://www.pearsoned.co.jp/washo/software/wa_soft10-j.html
この本は，メモリ空間に制限のある環境を対象として扱った，いわゆるデザインパターン・カタログの一種だ。題名からすると，特に組み込み用途を想定した内容のように思えるんだけれど，よくよく読んでみると，そうとも限らなさそうな気がしてきた。例えば，一時退避領域を利用するようなパターンや，不特定多数のモジュール間でメモリをシェアするようなパターンなど，だいぶ一般的なアプリケーション環境を対象としているような雰囲気が感じられる。小規模な組み込み機器というよりかは，もう少し規模の大きな……例えば PDA や携帯電話など，その辺りを対象としているのだろうと思う。
ていうか，オーバービューにそう書いてあるよね……。
そんなわけだから，ゲーム開発者にとっては，それほど興味を惹かれる内容ではないかもしれないと思う。ゲームソフトにおいて消費されるメモリ容量は年々増加し続けているものの，「基本的にシングルプロセス環境である」という前提が存続する限りは，比較的単純なメモリ管理で事足りるだろうからだ。今でもほとんどの場合において，コンテンツの内容から必要とされるメモリ容量を正確に推定することができる。そこでメモリが足りていなければ，コンテンツの方を削ってもらうように要請するまでだ（本当はいろいろと節約しなきゃならんのだけど）。
それよりも，お皿の上に載ったデータを，いかに「柔らかく」使うか，という問題の方がよほど難しくなりそうだ。非同期ローディングとキツキツのメモリ管理だけをとってみても，十分に頭を悩ませられる問題なのだけれど，最近では比較的複雑なデータ構造が増えてきたことから，初期化処理における負荷も気になるようになってきた。例えば "Jak and Daxter" のように，本当にシームレスなゲーム進行を保つためには，データ展開と初期化処理に十ミリ秒も費やすことができないわけで……。そこまで来ると，初期化処理さえも非同期化する必要性が出てくるのかもなあ，と思う。
2003-03-16
本屋で実物を目にして初めて気が付いたのだけれど， CG World 別冊 "Making Of Game Graphics" の Vol.3 が，いつの間にか出ていたようだ。ウェブには情報が載っていないんだけどなあ。
http://www.wgn.co.jp/cgw/issue/extra-number/
"Making Of Game Graphics" は，過去の CG World 誌に掲載されたゲーム関連の記事を抜粋してまとめた本だ。中にはちょっと消化不良気味の記事も見受けられるものの，よそ様の雰囲気を知るための媒体としては，なかなか面白いものなのではないかと思う。結局，今回は購入を見送ったものの， Anubis の制作記事などのように，興味を惹かれる話題もいくつか存在した。やはり，プログラマの端くれとしては，プリレンダムービー関連の話よりも，「アーティストの要求を実機上でいかに再現するか」という部分でのせめぎ合いに面白さを感じるのだと思う。
CG World と言えば，同誌の有名連載記事「必殺！テクスチャイリュージョン」の単行本を買ってみようかと思っている。
http://www.wgn.co.jp/texture/index.html
「モデリングよりもテクスチャ，造形よりも質感」という，実にユニークな視点から表現の追求を行っている連載記事だ。アーティストが実際にどのような過程を経て独特の質感表現を作り出しているのか，という思考を巡る際に，参考になるものがあるのではないかと思う。この記事において中心的に扱われているテクスチャやシェーダ，コンポジット等のテクニックは，実機上の処理と大いに関連してくる部分だ。その点において，「ただメッシュがあれば良い」だけのモデリングとは違っており，プログラマとのコラボレーションが欠かせない部分となるのだろうと思う。
何故か唐突に，自分の中の YMO 魂に火がついて（！），そのままの勢いで "VisualYMO: the Best" を購入してしまった。
http://www.amazon.co.jp/exec/obidos/ASIN/B00007KKZ0
YMO の「数々の貴重な映像資料」を寄せ集めた DVD だ。ワールドツアーライブ，「君に胸キュン」ビデオクリップ，散開ライブ等々の「基本」を押さえつつ，フジカセットＣＭスポットやら， "CUE" でドラムを叩く坂本龍一やらと，他では滅多にお目にかかることのできない映像まで，様々なバリエーションの資料を取り揃えている。
本編の映像もさることながら，副音声に入っている高橋幸宏の解説もいい感じだ。「この曲， MC-8 と同期してないですね」とか，アナログメカ好きにはたまらない発言もアリで，もう大満足。やっぱサンプラ以前がいいなあ……。
http://www.anz123.com/VSM/rolands/mc8.htm
も，もう，こうなったら "Giga Live", "Giga Clips" も買うしか。
http://www.amazon.co.jp/exec/obidos/ASIN/B00005G02W
http://www.amazon.co.jp/exec/obidos/ASIN/B00005G02X
まんまとコレクター商法にはめられてしまっているような気がする。こうやって儲けるわけか……。
2003-03-17
うう。また喉が痛くなってきた。このところ，どうも調子が良くない。精神的に緩むと体調を崩しやすいんだよなあ。もう少し気合を入れて行かないと，季節の変わり目でまた風邪を食らってしまうことになりそうだ。
少し前の flipcode に Jaap Suter 氏の "Geometric Algebra Primer" の情報が載せられていた。これが，なかなか良さげな感じだ。
Suter 氏はこの paper の中で， Geometric Algebra の基礎と簡単な応用について触れている。氏自身がゲーム業界の人ということで（Electronic Arts Canada に勤務しているそうだ），ＣＧ分野への応用を念頭に置いて解説を行っているようだ。
正直なところ，難しいことは何も分からないので，そもそも Geometric Algebra が何の役に立つものなのか説明することは難しいし，僕自身もよく把握できていない。それでも敢えて説明するならば， everything2.com の "Clifford Algebra" の項にある解説を引用するのがいいかもしれない。
http://www.everything2.com/index.pl?node=clifford%20algebra
いわく，
ところで，件の Suter 氏のページをよく見てみると，メタプログラミングを利用したＧＡライブラリ "Clifford" を２２日にリリースする予定とある。ううむ，むしろこちらの方が要注目だな……。同時に paper も公開する予定とのことなので，これを楽しみに待ってみたいと思う。
ゲーム技術者にとって Geometric Algebra が実用性のあるものかどうか，という点について評価することは難しい（なんせ，まともな応用例をほとんど知らないわけだし）。ただ，話によれば，ＧＡ自体は物理学等の分野で応用が進められているようであり，その辺りのノウハウが降りてくることもあり得ると考えている。上の解説にもあるようにに，なんとなくＧＡが便利そうである雰囲気は感じ取れるものの，単純に勘定すると演算量が増える一方であることから，実用的であるかどうかという点については難しい気がする。
少し前に GDAlgorithms の方で，似たような話題として「quaternion が普及した理由って何だろうか」というような内容のスレッドが建てられていた。その返答として最も多かったのは「演算量が少なくて済むからじゃん」という意見だった。これはおおむね事実であるものの，実際には，一概に決め付けられるものでも無いようだ。 Magic Software でお馴染みの David Eberly 氏が，その辺りについての考察を行っている。
http://www.magic-software.com/Documentation/RotationIssues.p...
こうして見てみると，回転の合成と補間については明らかに安くつくわけだから，「quaternion は軽いから有利」という主張も，決して的外れではないだろうと思う。しかし，やはり最大の理由は，直交正規化等の操作が手軽に行えること，直感的な回転制御が素早く行えること，等々にあるのだろうと思う。
http://sourceforge.net/mailarchive/message.php?msg_id=401367...
http://sourceforge.net/mailarchive/message.php?msg_id=401372...
そんなわけで， Geometric Algebra にも，いまだ知りえぬ何らかの利点が潜んでいるのではなかろうかと，根拠も無く期待してみてしまうわけだ。
2003-03-18
昨日の風邪をまだ引きずっている。薬を飲んでからしばらくの間は調子が良いんだけれど，今度は薬の効果で眠くなってしまう。
ちょっと故あって，付け焼き刃で ZODB (Z Object Database) の勉強をしている。
http://www.zope.org/Wikis/ZODB/FrontPage
ZODB は Zope の中核を成すオブジェクト永続化機構だ。 Python オブジェクトの自動永続化に加え，複数のスレッド間におけるトランザクションや，標準でサポートされているアンドゥ処理など，ドキュメント配信用途に特化した数々の機能を備えている。元は Zope の一部として開発されていたものなんだけれど，単体でも利用価値があることを見出した A.M. Kuchling 氏の手によってモジュールの分離が行われた。そういった経緯もあり，今では Zope から独立した形で開発が進められているようだ。
http://www.amk.ca/zodb/zodb-zeo.html
このように，概要を聞く分には便利そうな感じがするのだけれど，本当に使いこなすためには，相当の勉強と経験が必要となりそうだ。 Zope 自体がかなり規模の大きなアプリケーションであり，全体像を把握するのにどうしても時間がかかってしまう。本腰を入れて習得するつもりならまだしも，脇道程度にしか考えていないものだから，ちょっと辛いものがある。
Zope の利点の一つに，既存のリソースが多く存在する，というものがある。つまり，既存のプロダクトに頼る限りにおいては，内部的な知識を習得する必要は無いのではないかということだ。しかし，これは少し甘い考え方であったようだ。いかに出来合いのアプリケーションであっても，適切な管理を行い，トラブルに正しく対処するためには，内部構造をそれなりに把握しておく必要があるからだ。
そういった場合に，独自の方式に基づいたオブジェクト永続化機構は，命取りとなってしまうかもしれない。データとコードが密接に結合してしまっているが故に，データ側での独立した復帰が難しくなってしまうからだ。データを復帰させるにはコードが正しく動かなくてはならない。しかし，そのコードがそもそも狂ってしまっているとしたら……どうだろう。
オブジェクト永続化機構は，コードを組む側にとっては本当に便利な機能なんだけれど，なんでもかんでもシリアライズ可能にしておけばいい，ってわけでもないようだ。安全かつ効率良く管理を行うには，データを保持するオブジェクトと，機能を提供するオブジェクトを，うまく分離しておく必要があるだろうと思う。それと，願わくば XML を使ってほしいな……。
同じような理由で，安直に RDBMS を導入することにも違和感を覚えることがある。欧米などでは比較的気軽に RDBMS を用いる傾向があるように思えるんだけれど（特に MySQL を好んで使うようだ），これはあまり良い傾向とは思えない。このアプリがテキストベースだったら喜んで使うだろうに……ってことがよくある。まあ，それでも，安直なオブジェクト永続化と比べれば，よほど安全かもしれない。
そんなこんなで，一応当初の目的を達成することができた。ふう……。これでもう，しばらくの間は Zope/ZODB を触る機会も無いだろうと思う。やはり，規模に応じた道具というものが存在する。もう少し単純なものを検討してみようと思う。
2003-03-19
風邪がなかなか治らない。ミーティングが長くて，夕飯を食べ損ねてしまった。
中途半端な時間に帰宅。ちぐはぐな一日だった。
海外のメーリングリストを購読していると，普段触れる機会の少ない口語表現や，スラング，略語の類が出てきて戸惑うことがある。特に略語などは，たとえそれが何の略であるか分かったとしても，その元となった語の意味が分からなければどうにもならないわけで，二重に苦労させられることがある。例えば， "BTW" は "by the way" の略だけれど，そもそも "by the way" ってどんな意味だったっけ……。
http://www.google.com/search?q=IIRC+BTW+ASAP
IIRC, IMO, LOL など，掲示板やメールで頻出する。また，オンラインゲーム等では，打鍵数をできるだけ減らす目的から，一つの単語さえも短縮して記述することが多い。
http://gamespy.hp.infoseek.co.jp/words.htm
"plz" = "please" などはともかく， "l8r" = "later" なんて，知らなきゃ分からないだろうし，そもそも余計に打ち難くなっているような気がするんだけど……。
昔から，意味が分からなくて気になっていたのが "DOH!" という表現だ。なんとなく感嘆詞の一種であることは想像できるんだけれど，はっきりした意味が分からないことには，なかなか安心できないものがある。
この機会にと，少し調べてみたところ，どうやら "The Simpsons" が元ネタであるらしいことが分かってきた。
http://www.everything2.com/index.pl?node_id=27807
シンプソンズに登場する親父さん……オーナー・シンプソンズの持ちネタらしい。驚き，あるいはずっこけの感嘆詞が "D'oh!" なわけだ。ううむ，そもそもシンプソンズを知っていれば済む問題だったのか。一般教養が足りていないってことかなあ。
更に元ネタをたぐると "Laurel and Hardy" という古典アニメに行き着くらしいんだけど……これはまた別の話。シンプソンズによって有名となった "doh" という表現は，今ではオクスフォード英辞典にも掲載されるほどポピュラーな単語となっているらしい。
http://www.oed.com/public/news/0106b.htm#doh
同じような疑問で， "my two cents" という表現も気になっていた。これは，発言の冒頭や締めなどでよく用いられる表現で，例えば "This is my two cents." などというように使われる。正しい意味は分からないのだけれど，恐らく，「これは私のつまらない意見ですが」というようなニュアンスの表現だろうと思う。
たまに気が向いては調べてみているのだけれど，いまだに真相ははっきりしていない。ただなんとなく言えるのは，「２セント」という表現自体に「つまらないものだけれど，完全に意味が無いわけではない」というニュアンスが含まれているらしい，ということだ。そして "my two cents" は，自分の意見などを卑下した表現として用いられるようだ。
http://www.google.com/search?q=%22my+two+cents%22&lr=lang_ja
試しに "my two pennies" で検索してみても大してヒットしないことから，比較的新しい（少なくとも米ドル通貨が登場して以来の！）表現なのだろうと思う。ありがちなのは，著名人の発言とか，流行歌の歌詞とか，そういうのなんだけれど……どうだろう。あまりにも一般的な表現なので，単純な検索で突きとめることはできなかった。ううむ……。
2003-03-20
うう，風邪治りかけ。ミーティングが半分くらいと，コーディングが半分ぐらいの日。
ちょっと今週は消化不良気味。三連休は無難に休もうと思う。
GDC のウェブサイトにおいて， GDC 2003 の講演スライド資料集が公開されている。
http://www.gdconf.com/archives/2003/
今後も徐々に増やされる予定とのことなので，定期的にチェックしておくと良いかもしれない。
ざっとリストを見回してみて，まず興味を惹かれたのが， Maxis 社の Will Wright 氏による講演 "Dynamics for Designers" だ。
http://www.gdconf.com/archives/2003/Wright_Will.ppt
Will Wright 氏と言えば，あの "Sim City" シリーズの生みの親として知られるゲームデザイナーだ。氏は，世界で最も著名なゲームデザイナーの一人として， Sid Mayer 氏や Peter Molyneux 氏，宮本茂氏などと並んで挙げられる人物だ。最近では "The Sims" における成功が記憶に新しい。
http://abcnews.go.com/sections/tech/DailyNews/sims000322.htm...
件の講演では，氏のゲームデザイン手法……特に，ダイナミクスやマクロ的なデザインから生み出される偶然性，に焦点を当てて解説を行っているようなんだけれど，スライドに文字情報がほとんど含まれていないため，公開された資料のみから内容を推定することはほとんど不可能となってしまっている。ああ，もったい無いなあ……。
spin の情報によれば， Gamasutra の方で mp3 化された講演録音集を購入可能とのことなんだけれど，なにしろ凝った内容の講演だけに，ヒアリングで解読できる自信がまったく無い。文章であれば，なんとか読解することが可能だと思うんだけれど……。
EA のウェブサイト内に用意された氏のスペースでは， GDC 2001 における講演の資料も公開されている。
http://thesims.ea.com/us/will/gdc.html
日本庭園の話題などが解説に登場してくる辺りの突拍子の無さが，いかにも Will Wright 氏っぽくて面白いと思う。どうやら，建築方面の話題に興味を持っていた時期が過去にあったようだ。
http://www.watch.impress.co.jp/game/docs/20020302/ww.htm
話によれば， Will Wright 氏は，何か一つの物事に熱中し始めると止まらなくなってしまうタイプの人物であるらしい。過去にも，いきなり飛行機の免許を取得してしまったり，カーレースに出場して優勝してしまったり，手品のためにピッキング器具を自作してしまったり（！），というような，華麗な遍歴を持ち合わせているようだ。こういった話を聞いていると，偉人伝なんかによく登場するような，「天才と奇人が同居しているタイプ」の人物像が浮かび上がってくる。
http://www.wired.com/news/games/0,2101,50020,00.html
最近では，もっぱらロボットの制作に情熱を注いでいるようだ。
http://www.gamespot.com/features/maxis/page14.html
たしか，ログイン誌の鹿野氏のコラムにも，そのことが紹介されていたような気がする。そしてまた近い将来，氏の制作するゲームに，その辺りでの経験や考察が反映されることになるのだろうと思う。
2003-03-21
三連休。特に野望があるわけでもなく，家の中でダラダラと惰眠をむさぼる。
何気なく，久しぶりに，安西史孝氏のページを読みまわしていた。 YMO 熱の余韻からかもしれない。
シンセサイザーの専門家として活躍する氏だけあって，ビンテージシンセに関する知識の量は半端でない。ウェブ版だけでもお腹いっぱいだ……。
http://www.anz123.com/VSM/s_frame.htm
ああ，やっぱアナログシンセはいいなあ……。 CV/Gate 最高， MIDI 要らん，みたいな。
氏のアカデミックな雰囲気の漂う楽曲群は，それだけでも素晴らしいものなのだけれど，それに加えて，アナログシンセに対するこだわりが滲み出ており，そこに共鳴できる人にとっては堪らない内容となっている。また，氏のページには，その辺りの裏話が豊富に含まれており，これもまた非常に興味を誘うものとなっている。
http://www.anz123.com/Solo/solo1.html
普通，今時メロトロンなんて使わないだろうに……。やはり，アナログ・ガジェットに対する愛情なのだろうと思う。
http://www.yamaha.co.jp/product/syndtm/read/fm/03.html
そんなわけで，アナログシンセ関連のワードを google に突っ込んでみてはリンクをクリックしまくるという，非常に有意義な（！）ひと時を過ごしてみた。最近では，ウェブサーフィンと言えば即ち google を使った探索を意味しているような気がする。
とりあえず， "Vintage Synth Explorer" のページをポータルとして飛び回るだけで，数時間は暇潰しができそうだ。
往年の名機から，最近のアナログモデリング音源まで，様々な種類のシンセサイザーを取り揃えている。
最近のマシンでちょっと魅力を感じたのは， KORG の "MicroKorg" だ。
http://www.vintagesynth.org/korg/microkorg.shtml
「移動式１人ＹＭＯ」として ZDNet でも紹介されていた。
http://www.zdnet.co.jp/news/0210/09/njbt_04.html
いや本当にそんな感じだ……。電池で動くところや，持ち運びに適度なサイズなど，所々に作為的なデザインを感じる。実用性はどうだか知らないけれど，遊び心が感じられるマシンであることには違いないと思う。
KORG のビンテージマシン "VC-10 Vocoder" などに，そのルーツを感じ取ることができる。
http://www.vintagesynth.org/korg/vc10.shtml
ぬおっ……ご，ゴツい。無意味にデカい前面パネルと，その上面からニュルっと突き出たマイクが不気味でいい感じだ。パネルに取り付けられたレベルメーターがシブくて良い。これ，あんま意味無いと思うんだよなあ……。
ところで，「ヴォコーダー」とは，本来情報通信分野で研究されたいたものらしく，人間の音声波形をフォルマント解析して発音成分を云々……とか，そういうものらしいんだけれど，よく分からないので省略。それがいつの間にか「マシンボイス生成器」になっているんだから不思議なものだと思う。
KORG のウェブサイトにある「コルグ・ミュージアム」のページでは， VC-10 を含めた過去の独創的な製品群についての解説を読むことができる。
http://www.korg.co.jp/SoundMakeup/Museum/index.html
ああ，このページも面白いなあ。やはりシンセサイザーは良い。特にサンプラー以外が，ね……。
今でも KORG は，デジタル・アナログの垣根に捕らわれない自由な発想のシンセサイザーを数多く送り出している。例えば， "Analog Modeling Synthesizer" と銘打たれた製品 "MS-2000" など，とても興味深い。
http://www.korg.co.jp/Product/Synthesizer/MS2000/index.html
KORG のお家芸であるモデリング音源でのノウハウを駆使し，多彩な音作りを可能とするアナログ風味のシンセサイザーを作り上げている。しかし，いかに「アナログ風味」とは言え，実際にはデジタル技術の結晶なんだけどね……。「アナログを再現するためのデジタル」ってのも，僕にとっては萌え所なので（うげっ），良しとしたい。
あとは…… "KARMA" も面白そうだ。
http://www.korg.co.jp/Product/Synthesizer/Karma/index.html
"KARMA" とは "Kay Algorithmic Realtime Music Architecture" の略で，演奏者によって適当に入力されたフレーズから，曲のアレンジをリアルタイムに自動生成してしまうというシステムらしい。 Karma Lab に置いてあるサンプル曲を聴いてみれば，その完成度の高さを感じ取ることができるだろうと思う。
http://www.karma-lab.com/Audio/KARMA_GE_Intro.mp3
http://www.karma-lab.com/KARMA/KARMA_Demos.html
こんな感じで， google さえあれば，無限に暇を潰すことができる。知識欲に対する充足行為と呼べば聞こえはいいかもしれないけれど，やっていることは単なるカウチポテト族とさほど変わりないようにも思える。どうしたものだか……。
2003-03-22
しかし，最新鋭のアナログシンセサイザーと言えば，何はさておきまず "Doepfer" システムを挙げるべきかもしれない。
http://www.vintagesynth.org/misc/a100.shtml
この迫力，この重厚感……下腹部が圧迫されるような威圧感（図書館に行くとトイレに行きたくなるの法則）に，思わず興奮を覚えてしまう。だって，こんなの，すべてデジタル化してしまえば，ちょっとした大きさの筐体と液晶ディスプレイで済ますことができてしまうようなもののはずだ。それなのに，無理を承知の上で，敢えてこのようなものを作り上げてしまうとは……。いろいろと言い訳は思いつくものの，やはり究極的には，「ガジェットの放つ魅力」に充たされたいという想いが，このような製品を作り上げるのだろうと思う。
それはともかくとして…… "Doepfer Analog Modular System" は，独 Doepfer （ドープファー）社によって製作された，「本物の」アナログモジュラー方式のシンセサイザー・システムだ。
http://www.doepfer.de/home_e.htm
基本的に， VCO (Voltage Controlled Oscillator), VCF (Voltage Controlled Filter), シーケンサ，等々の各種モジュールをバラで購入し，自分の手でラックにマウントしてシステムを構築する仕組みとなっている。各モジュール間の接続はパッチケーブルによって行われ，パラメータの操作は前面のノブを手で回すことによって行われる。同じ音は二度と出ることの無い，まさに本物のアナログシンセサイザーと呼べるシステムだ。
例えば， Deopfer システムの最も基本的な VCO モジュールである "A-110" のマニュアルには，次のような記述がある。
http://www.doepfer.de/a100_man/a110_man.htm
回路を安定さすのに２０分待てと！ この，近代デジタル機器には絶対にあり得ない「スローフード感覚」が，ガジェット好きの心をたまらなく刺激する。この銀色のシャーシの向こうに存在するのは，イミテーションの DSP ではなく，本物の LCR 回路だ。その秘められたる存在感が，僕らテクノキッズを，あの確かに存在した８０年代の未来都市へといざなうのだ（何のフレーズだ，これは……）。ともかく，実際にはあまり使いたくないような気もする。さすがに２０分は，ちょっと……。
こう見ていくと，いかにも金持ち向けの嗜好品のように思えるかもしれないけれど，実際には価格もそれほど高くなく（基本システム一式が中古で１７万円程度のようだ），意外とまともな製品であることがうかがえる。実際に，アリカの細江氏などが音ネタの作成に利用していると聞いたことがある。
それにしても，ギャラリー等に掲示されている写真の中で，楽しそうに Doepfer をいじるドイツ人の姿を見ていると，ああ，やっぱドイツ人って，こうなんだなあ（？）という奇妙な安心感が湧いてくる。勝手なステロタイプだろうか。いやいや……。
http://www.doepfer.de/gallery.htm
"A-198 Ribbon Controller" や "A-178 Theremin Control Voltage Source" など，相当にマニアックなモジュールも用意されている。
http://www.doepfer.de/a178.htm
http://www.doepfer.de/a198.htm
これさえあれば， Doepfer が即席テルミン，あるいは，即席トラウトリニムになるわけだけれど……実際にどの程度需要があるものだか，僕にはまったく予想もつかない。
http://www.google.co.jp/search?q=%83g%83%89%83E%83g%83j%83E%...
2003-03-23
先日，いい加減な方法で各種 XML パーサのサイズ比較をやっていたら，案の定，こうのさんからツッコミを頂いてしまったので，もうちょっとまともに計測してみることにした。いやでもツッコミは有り難いことです……。
まずは， expat を普通にコンパイルしてみる。 autotools を介すと色々と複雑になってしまうので，手書きの Makefile を使ってビルドを行うことにした。
こうして得られたバイナリの正確なコードサイズを得るには objdump を使う。
こんな感じでセクション毎のサイズが得られるので，その総計を取ればいい。余談だけれど，たまに objdump の結果とにらめっこしてみるのも有益なことだろうと思う。普段見落としがちな「穴」を発見する手助けとなるかもしれないからだ。気を抜くと，不用意に bss セクションを占有しているソースがあったりして，ね……。
そんなこんなで，ノーマル状態での expat は 100kB ほどのサイズになることが分かった。
ここで， XML.com における Clark Cooper 氏の記事 "Using Expat" を参照してみると，次のような記述が見受けられる。
http://www.xml.com/lpt/a/1999/09/expat/index.html
ほほう……。マニュアルには記述が無かったので，気付くことができなかったのだけれど，どうやら expat にはコードサイズを節約するためのオプションが存在しているようだ。早速これを使って再ビルドしてみよう。
と，その前に……ついでなので XML_DTD と XML_NS も外してみることにした。 DTD 記述のパース可否と，名前空間のサポート可否に関するオプションだ。両方とも expat_config.h に記述がある。ただし，最新版の expat 1.95.6 には XML_DTD に関するバグが混入しており，正常にコンパイルを通すにはソースに変更を加える必要がある。リポジトリ上では既に修正済みなので，それをそのまま持ってくるのが早いようだ。
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/expat/expat/l...
こうして得られたバイナリを計測してみたところ， 65kB まで縮んでいることが分かった。ふむ……，このサイズだったら許容できるかな。 expat に備わった性能を考慮すれば，十分に満足できる結果であると思う。
ちなみに，以前ネタにした Parsifal がバージョンアップしているようだ。
http://www.saunalahti.fi/~samiuus/toni/xmlproc/
いくつかバグ修正をしていただけたようで……。あと，なにげにパフォーマンス比較とか行っているようだ。しかし，さすがに expat が相手じゃなあ。
同じく Parsifal でもコードサイズの測定を行ってみたところ， 25kB 程度であることが分かった。 expat と比較して十分に意味のある小ささであるものの，その他の要素を色々と考慮すると，結局 expat に軍配が上がると言わざるを得ないと思う。やはり，あの驚異的なパース速度と，既に市場によって十分に鍛えられているという信頼感は，なかなか他には変え難いものとなっているのだ。
2003-03-24
昨晩から軽い頭痛が続いている。生まれてこのかた頭痛など味わったことがないものだから，たとえ軽い頭痛とは言え，気になってしまってしょうがない。最近，わけのわからない新手の病症にばかり悩まされているような気がする。決して無理をしているわけではないんだけれど……。
GDC 2003 の各種講演資料を，現時点で公開されているものについて軽くさらってみた。
http://www.gdconf.com/archives/2003/
http://www.gamasutra.com/gdc2002/index.shtml
最新鋭のＣＧ技術の解説から，企画職の手なずけ方の指南まで（！），ゲームに関することならとにかく何でも，と言った感じの取り合わせになっている。人によってそれぞれ興味の対象は異なるだろうけど，やはり Game Developers Conference と言うからには，ゲーム固有の制作手法や，市場の動向などについて触れた話題をチェックしておきたいところだ。例えば， Electronic Arts は Neil Young 氏の "FilmGame: Adapting Lord of the Rings" などは，多くの注目を集めたところなのではないかと思う。
http://www.gamasutra.com/gdc2003/features/20030307/kane_02.h...
僕にとって，第一四半期最大の衝撃がこのゲームだったように思える。こんな……ここまで映画そのものを使ってしまっていいんだ，という驚きが，このゲームの第一印象だった。ＤＶＤの「ロード・オブ・ザ・リング」を観た直後だったので，余計にそう感じたのかもしれない。ともかく，映画本編のオリジナル映像をそのまま持ってきてしまったゲームというのも，いまだかつて無かったものではないかと思う。
一方，講演の内容はそれほど鮮烈なものでもなく，ただ，原作の雰囲気を崩さないように気を遣いつつ，ゲームへと「翻訳」すればいいんですよ，というようなアドバイスとなっている。裏を返せば，余計なモノを付け加えるから売れなくなるのだ！ という警告にもなっている。
現にこのゲームは世界中で優れた売り上げを記録している。前作 "The Fellowship of the Ring" はもっぱら凡作だったとのことだけれど，今作 "The Two Towers" では，コアユーザからカジュアルユーザ，それから原作のファンまでをも含む幅広い支持を得て，結果的にミリオンセラーの座を獲得することに成功している。
このような華々しい成功もある一方で，惜しくも失敗作を生み出してしまう例もある。 Treyarch/Activision の "Minority Report" などは，その最たるものと言えるのではないかと思う。
http://ps2.ign.com/articles/377/377895p1.html
http://www.gamespy.com/reviews/december02/mrps2/
http://mrgame.activision.com/main.html
パッケージに描かれた見慣れぬ男の姿が，何とも言えない怪しさを醸している。背景は写真素材っぽいのに，男だけ手描き風味なのも泣けるなあ……。真相は定かでないものの，とにかく，何らかの理由でトム・クルーズの肖像権を得ることに失敗してしまったようだ。最も重要とも言える部分でいきなりつまづいてしまったこの作品は，他にもゲーム的な詰めに若干の問題を残していたようで，挙句の果てには各誌レビューに「凡作」のレッテルを貼られる始末となってしまった。いや，実際には，それほど酷いものでもないらしいんだけれど……。
まあ，「マイノリティー・リポート」については，映画自体もあまり芳しくなかったようなので，当初からどうにもならなかったのだと言えば，それまでなのかもしれない。それにしても，上手くいかないこともあるものだというのが，率直な感想だ。
2003-03-25
次に，ぱっと見て興味を誘われたのが， Ion Storm は Harvey Smith 氏の講演 "Orthogonal Unit Differentiation" だ。
http://www.gdconf.com/archives/2003/Smith_Harvey.ppt
直訳するならば，「直交型ユニット分化術」ってとこかな……。名前は多少仰々しいきらいが感じられるものの，考え方自体は極めてシンプルなものだ。要約すると，ゲームを構成する各要素の特性を決定する際に，ここでは「直交性」と呼ばれている概念を意識することによって，よりシンプルな構成から，より広いプレイの幅を作り出すことが可能になる，というようなものだ。
このような考え方自体は，さほど目新しいものでもないと思う。ゲームのデザインを行う際に，ごく普通に意識されているであろう概念だ。例えば，同じような武器に，同じような敵，同じようなステージに，同じようなアイテム……一見バリエーションが多いように見えて，実は一つの直線状に並んでしまった要素群……そういったものを，デザイナは生理的に避けて通ろうとする。それが「不味い」デザインであることを経験的に知っているからだ。このような経験則を理屈として整理すると，件の「直交性」のような概念に行き着くのだろうと思う。
余談だけど，この講演資料の PowerPoint ファイルには，ノート部分にちょっとした「おまけ」が埋め込まれている。氏がよく利用している独自の「専門用語」に関する解説集だ。これ自体が特に深い意味を持っているわけではないんだけれど，なんて言うか……こういった感じで細かく理屈付けをしながら理論を組み立てていくのが好きなんだろうなあ，と思われる。氏の人柄が伝わってくる一幕だ。
氏のように，自らの持つメソッドを体系付け，人々に広めようという努力をしているデザイナは，かなり珍しい存在のように思える。何が氏をそのような行動に駆り立てているのか定かではないものの，制作者自身の思考を垣間見る機会というものは，そう滅多に存在するものでもないはずだ。その内容の良し悪しはともかくとして，一見の価値があるのではないかと思う。
http://www.planetdeusex.com/witchboy/
次は……同じく Ion Storm から Alex Duran 氏の "Building Object Systems" が面白そうだ。
http://www.gdconf.com/archives/2003/Duran_Alex.ppt
で，とりあえず読んでみたんだけれど……最後の方に， Jeremy Chatelaine 氏の "Enabling Data Driven Design Tuning via Existing Tools" の紹介が入っていて，むしろこちらの方に興味を誘われてしまった。
http://www.kamron.net/gdc/JeremyChatelaine_GDC_2003.zip
この講演の論調は，こんな感じだ……ゲームの構築ツールを制作するにあたって，３つの選択肢が考えられる。それはすなわち，専用のツールを用意する方法，ゲーム上にツールを組み込む方法，既存のツールを活用する方法，の３つだ。この三者には三様に利点と欠点が存在する。では，自分はどの方法を選ぶべきなのだろうか。それに対する氏の解答は極めて明快なものだ。「時間を節約しよう！」「利用者に親切であろう！」「複雑化を避けよう！」……そこで氏は，比較的安価なツール群を有効活用し，これをゲームの構築手段へと転用する方法を模索している。
とまあ，こんな感じで，なんとなく目を通してみているものの，このプレゼンテーションもやたらとノート部分に註釈が添えられており，取り扱いに苦労している。この， PowerPoint のノート部分をうまく印刷する方法ってのが，僕にはよくわからないんだよな……。家には PowerPointViewer しか無いから，ノート部分を覗き見ることさえままならない。うう，職場で読むしかないか……。
2003-03-26
セミナーに出席のため，赤坂はホテルニューオータニへと直行した。
http://www.newotani.co.jp/tokyo/
メールに添付された地図を一目見て，１０分も前に到着すれば余裕かと思っていたのだけど，この考えが甘かったようだ。ホテルニューオータニのデカさってったら，もう，とんでもないものだ。しかも内部構造が複雑で把握し難い。建物の中で道を聞いたのなんて，久しぶりの経験だったかもしれない。
結局，会場へ辿り着くまでに１０分以上費やしてしまった。うう，ダメダメだあ。
その後も小さなハプニングなどあって，散々な一日となった。疲れたよ，もう……。
帰社してから即ミーティング。軽く夕食をとった後に，メールを数件処理。それからしばらくして帰宅すると，ほとんど何もしないまま，すぐに寝に就いてしまった。
2003-03-27
先日から引き続き， Jeremy Chatelaine 氏の講演 "Enabling Data Driven Tuning Via Existing Tools" の資料を読んでみている。
http://www.kamron.net/gdc/JeremyChatelaine_GDC_2003.zip
この PowerPoint ファイルには，いわゆる「ノート」部分に非常に多くの註釈が埋め込まれている。先日は，この部分がうまく印刷できない（あまりにも量が多くてページからはみ出てしまう）とわめいていたのだけれど， PowerPoint のヘルプ（イルカのカイルくん……）と数分戯れた結果，なんとかうまく印刷することができるようになった。ノート形式のページ設定を変更するには「マスタ」を使えばいいわけね……。それでもおかしくなってしまうページについては，個別に手動で対応した。
この講演の内容には，革新的な要素はほとんど存在しないものの，現実的な開発手法を見据えるという点では，かなりうまくまとめられているように思える。特に，資料の前半部分にまとめられた，各種手法についての考察は，なかなか良い指摘となっているのではないかと思う。独自ツールを用意する方法，ゲーム内にツールを埋め込む方法，既存のツールを利用する方法……これらの手法のそれぞれに利点と欠点が存在し，その優劣を一概に決め付けることは不可能だ。
例えば，コミュニティ重視のＰＣゲームなどでは，完成度の高い独自ツールを用意しておくことが後に付加価値となるかもしれない。また，家庭用ゲーム機などの場合には，エンジン部分をゲーム本編と共有することに多くのメリットが存在するように思える。最後の既存ツールを利用する方法は，総合的にみて開発期間の短縮に貢献するところが大きい。これは非常に重要な要素であるから，もうそうすることにデメリットが伴わないのであれば，できるだけ既存ツールを用いるべきだと思う。
この講演では，実践例として Microsoft Excel を使ったデータ管理手法について述べている。具体的には， Excel の VBA スクリプトを利用して，データの整形出力と，それに対応するソースの自動生成を行うというものだ。データ（特に各種パラメータ）の管理を Excel で行うのは，かなり一般的な手法のように思えるけれど， VBA を使ってデータの出力を行ったり，ソースの生成を行ったり，というのはかなり珍しい例のように思える。
個人的には，データ側でソースの生成を行うという方向性に，少し違和感を覚える。プログラムを再コンパイルする手間や，コードとデータの不整合を解決する手間を考えると，あまり上手い方法のように思えないからだ。ただこれについては，各担当者の端末上に，プログラムのビルドが可能な環境と，ゲームアセットの複製が存在するような方式であれば，それほど問題にはならないかもしれない。中央集権方式の環境だと難しいものがあるではないか，ということだ。
講演の後半部分では，各種ツールについて個別の考察を行っている。まず最初に挙げられているのは，お馴染み MS Excel と MS Access だ。これらのツールが XML に本格対応してきたことは，即席ツール職人にとって多くのメリットをもたらす結果となったのではないかと思う。特に XML SpreadSheet の登場は，僕にとって非常に嬉しい知らせだった。これのおかげで，データの管理方法や変換工程を数段シンプルなものへと変更することが可能となったからだ。
http://msdn.microsoft.com/library/default.asp?url=/library/e...
手堅くやるには Access もいい方法だ。しかし，よりアドホックな手段という意味では， Excel も捨てがたい魅力を持っている。
次に Chatelaine 氏は，非常にユニークな事例として， Microsoft Visio を画面進行管理に利用するという手法を挙げている。
http://www.microsoft.com/japan/Office/visio/
Visio は，もともとフロー図やスキーム図を作成するためのツールだ。ある日 Chatelaine 氏は，ゲームデザイナが持ってきた画面進行のフロー図を手に取りながら，そのフローをできるだけ少ない手間で実装するにはどうしたらよいのだろうかと思案していたそうだ。そしてしばらくの後に，その事実に気付いてしまったというわけだ……それを生成するために必要なデータが，既に自分の目の前に存在しているという事実を。
僕は Visio を一度も触ったことが無いので，このツールがどの程度のことをできるものなのか，まったく分かったものでない。 Chatelaine 氏の話によれば，各パーツに独自の属性を追加する機能があるため，ある程度の設定をこのツール上で行うことが可能であるとのことだ。ただ，元の用途がまったく異なるツールであることや，ファイル共有の機能が存在しないことなどから，それほど強く薦めることはできない様子だ。まあ，ちょっと変な実践例の一つ，程度に受け取っておくのが良いかと思う。
最後に， Macromedia Flash を利用した事例について軽く触れている。これについてはかなり興味があるのだけれど， Flash についての予備知識がほとんど無いことから，今回はスキップしておこうと思う。いつか本腰を入れて調べてみたい用件の一つだ。
講演の最後では，注目すべき将来のツールとして Microsoft の "XDocs" について言及している。これは， Microsoft の次世代 XML ツールスイートのコード名であり，現在では "InfoPath" という正式名称が割り当てられている。
http://www.microsoft.com/office/preview/infopath/default.asp
http://www.atmarkit.co.jp/fdotnet/special/infopath/infopath_...
うーむ……，要するに XML Spy みたいなもんかな。ただ， Microsoft が本気で作っている製品のようだから，最終的にはかなり本格的なものになるんだろうと思う。今後の展開に注目したいところだ。
2003-03-28
ゲームのデザインフローにおいて，データをどういった形で扱うか，という選択は，非常に難しい問題のように思える。旧き良き時代ならば，実行時の効率のみを優先して設計を行うことが可能だった。しかし，コンテンツ量の加速度的な増加や，制作者間におけるコラボレーションの必要性が深まるにつれ，次第に開発時の効率をも考慮しなければならない状況へとなってきた。
データを完全にバイナリイメージの形で持つことは，プログラム側から見れば非常に都合の良い状態なのだけれど，開発過程においてはトラブルのもととなりやすい。再設計に対してあまりにも耐性が低過ぎるからだ。そこで，データ側に対してある種の機能性を与えることによって，トラブルの回避を狙うことになる。例えば，シンボルによる参照を可能とする，とか，構造の定義をデータ側で行えるようにする，等々の工夫だ。これをコードの再生成によって実現する方法が，前の Jeremy Chatelaine 氏の挙げた例に相当する。
データの汎用的な表現方法を突き詰めて行くと， XML のような形式に辿り着くことになるだろうと思う。ただ，実行時における XML の利用は，パフォーマンス的に見て不安材料が多い。冗長性が高いため容量が膨らみがちだし，パース処理もかなりの重荷となる。高性能なライブラリやツールが存在することは心強い要素だけれど，それで問題の解決が可能かというと，微妙なところであるように思える。
この件に関して，某氏より，スクリプト言語をデータのコンテナおよびインタフェースとして用いるのはどうか，というアイデアをうかがったことがある。これは，小・中規模のデータに対しては，なかなか良い解決法のように思える。
例えば，次のような形式のデータがあるとする（以下は RELAX NG による記述）。
この形式のデータを，スクリプト言語 Lua を用いて表現すると，以下のような形になる。
ついでにアクセスメソッドもいくつか持たせてみる。
このようにして実装されたデータに対してホスト（Ｃ言語）側からアクセスを行うには，以下のような処理を用いる。
ちょっとややこしく見えるけれど， Lua のスタック操作に慣れればそれほど難しい話でもない。 Lua で表現するならば，
というような一文に相当する。
こうしてスクリプト言語 Lua によって構築されたデータ表現には，いくつかのアドバンテージが存在する。まず，これは当たり前のことだけれど，データの変更に対してコード側が一切関与しない，という点が挙げられる。データの内容が変化しても，対応する lua ファイルを読み直すだけで，新しいデータを適用することができる。
次に，インタフェースの挙動さえ保たれていれば，データ構造の変更に対してもコード側は関与しない，という点が挙げられる。これはかなり重要なアドバンテージだ。要素の追加によって挙動の乱れることが無いのはもちろん，要素の削除に対しても，ダミーのアクセスメソッドを用意することによって耐性を与えることができる。例えば，何らかの理由によって name 要素を削除することになってしまったとしても，
というようなダミーメソッドを用意しておくことで，コードへの依存性を隠すことが可能となる。このことは，よりフレキシブルなデータ運用を実現する可能性を秘めているように思える。
また，スクリプト言語として Lua を用いることは，パフォーマンス面においても比較的良い結果をもたらしてくれるのではないかと考えている。各所での評価が示しているように， Lua インタラプタの実行効率の良さは折り紙付きだ。 luac （バイナリコードを生成する lua コンパイラ）を用いれば，事前のパース処理も可能であることから，初期化時の負荷量に関しても楽観的な見通しを立てることができる。まあ，この辺りはいずれ詳しく調べてみようと思っている。
2003-03-29
このように，スクリプト言語の利用がアドホックな解決法を導き出すという展開が，実際の開発場面においてまれに存在する。特に Lua は，フットプリントの小ささや，処理の軽さ，メンテナンス性の高さなどから，気軽に利用することのできる存在となっている。比較的親しみやすい文法や（ここで Lisp などを持ち出すには，相当の説得材料が必要となる），連想配列を基本としたシンプルな言語仕様など，運用面での障害も極力少なくなっており，そのことがまさに理想的な条件を作り出していると言える。
ゲームへの組み込み用途には理想的な設計である Lua も，他の一般的な用途には，標準ライブラリの機能不足から，あまり受け入れられないのではないかと考えていた。しかし，ニッチであることが逆に幸いしたのか， Lua はその人気を地道に高めつつあるようで，プロジェクト自体も急成長を遂げている。その辺りの事情については Mitchell Charity 氏のレポート "The Year In Scripting Languages" にまとめられている。
http://www.vendian.org/language_year/
Lua は本来，ブラジルはリオデジャネイロ・カトリック大学の Tecgraf 研究室によって進められているプロジェクトだ。
この Tecgraf をホストとした開発体制が確立されているため，今後の開発に関しても，ある程度安心して見届けることができるのではないかと思う。少なくとも，近日中にプロジェクトが消滅してしまうような事態にはならないはずだ。
現時点における正式な最新リリースは 4.0.1 となっている。更に，新バージョンである 5.0 のベータ版の配布が既に開始されている。
http://www.lua.org/download.html
Lua 5.0 では，基本的に旧バージョンとの互換性を保ちつつ，いくつかの重要な改良が加えられている。最も大きな改良点としては，処理の更なる高速化や，マルチスレッディングへの対応等が挙げられる。これらの改良は，新たに開発されたレジスタベースの仮想マシンへ移行したことによって得られたものであるようだ。
特にマルチスレッディングへの対応に関しては，以前から懸念していた要素だけに，吉報でもある。この Lua 5.0 におけるマルチスレッディングは，いわゆる完全協調式のスレッドであり， "coroutine" と呼ばれる機構によって実現されている。
coroutine とは，要約すれば，「スレッド化されたルーチン」と表すことができる。もう少し簡単に言うと，ある関数の実行中に，その関数をコールした元へと復帰するというフローを可能とするものだ。
例えば，以下のような Lua コードがあったとする。
これを実行すると以下のような結果が得られる。
coroutine として起動された test 関数は， "hello" という文字列を表示した後， yield 関数によって制御をコール元へと返却している。コール元では， "!! boing !!" という文字列を表示した後， resume 関数によって再び制御を coroutine へと戻している。このように， coroutine ライブラリを用いることによって，自由に処理の流れを制御することが可能となっている。
その他にも Lua 5.0 では，標準ライブラリの整理や，タグメソッドの廃止，コア部分から stdio を排除，等々，よりコンパクトな機能性を実現すべく，数々の改良が加えられている。実のところ