http://pc3.2ch.net/test/read.cgi/tech/1014718263/

勉強の参考になるかどうかは別として，一般的にどのような受け取られ方をしているのか調べるには，都合いい媒体かもしれない。良くも悪くも，現場の人間の思考が率直に反映されているのではないかな，と思う。

それにしても， XML の引き合いとしてＳ式が担ぎ出されているのには，驚きを禁じ得なかった。この界隈の住民におけるマニア率が相当に高いのか，あるいは，実はＳ式の存在が僕の考える以上に一般的なものであったのか……果たしてそのどちらなのかは分からないけれど，少なくとも僕の中では， XML と対抗する要素としてＳ式を挙げる，というようなアイデアは，今までまったく存在しなかった。

検索を使ってみると，それっぽいものをいくつか見つけることができる。

http://www.google.co.jp/search?q=lisp+%EF%BC%B3%E5%BC%8F&hl=...

Lisp は以前から勉強してみたいと思っていたんだけれど，いまだに手を付けることなく時が過ぎている。「本質的にはＳ式と lambda でしかない」という Lisp (Scheme) の特徴は，言語仕様としてとてもユニークかつエレガントなものであり，それが故に勉強する価値があるのではないかと思っている。

http://www.mew.org/~kazu/doc/elisp/symbol.html

しかし，それだけのモチベーションではなかなか始めることができない。そうする必要性があまりにも低すぎるからだ。何の得にもならないと知っていることを敢えて行うということは，とても勇気の要ることだと思う。

そういう事情だから， Scheme インタラプタ "Gauche" なんかは，なかなか都合のいい存在なのかもしれない。

http://www.shiro.dreamhost.com/scheme/gauche/index-j.html

Gauche は「日常業務の中で手軽に使う」というコンセプトの元に開発されている。 Scheme の処理系としては GNU の "Guile" なんかが有名だけれど，あちらはアプリケーションへの組み込みを意識したものだから，なかなかこういったユーティリティ的な使い方には向いていないようだ。

http://www.gnu.org/software/guile/guile.html

アプリケーション（主にゲーム）への組み込みスクリプト言語として Scehme を使うという案も，以前考えていたことがあった。 Lisp の処理系には非常にコンパクトな実装が多く，組み込み言語として良い適正を持っているように思える。シンプルな言語仕様のなせる技なのかもしれない。

http://tinyscheme.sourceforge.net/

http://www.iro.umontreal.ca/~dube/

しかしこの案は， Lua が組み込み言語として有力になってきたことから，却下することになった。それに， Lisp を関係者の方々（もちろん，僕自身も含めて）に習得してもらうのは，余計にコストが高くついてしまうという懸念もあった。 Lua は比較的オーソドックスな手続き型言語だから，習得に伴うコストはかなり少なく見積もることができる。その差を埋めるほどの優位性を Scheme に見つけることができなかった……と，それだけのことだ。

permalink

http://pub111.ezboard.com/fgamingageforumsfrm17.showMessage?...

DOOM III と言えば，多くの注目を集めているわりには公開されている情報が少ないという印象がある。そういう状況も手伝っているのか，この流出事件にはどこも騒然となっている模様だ。 E3 公開バージョンが流出した，との噂もあるけれど，時期的なことを考えるとそれも少し不自然だと思う。パブリッシャーやハードウェアメーカーに向けて内々に公開したバージョンが漏れ出してしまったのかもしれない。ともかく， id software にとっては，これは非常に由々しき事態だろうと思う。

id software も決して素人ではないから，内部公開バージョンにはドングルを噛ませる等のプロテクト処置を施しておくはずだ。犯人は，それをわざわざクラックした上で流したんだろうか……。もし id software が十分に注意深ければ，プログラムもしくはデータに固有 ID などを埋め込んであるかもしれない。流出バージョンからそいつを引き出すことができれば，流出元の特定ぐらいは可能になるわけで……一体どうなることやら。

流出事件についてはひとまず置いておくとして……掲示板等にポストされているスクリーンショットからは，最新バージョンの状況を垣間見ることができる。

http://slay.www2.dotnetplayground.com/doom3/

まず気になるのは，陰影表現に残る微妙な違和感だ。シェーディングやバンプマッピングによる柔らかい陰表現と，ステンシルシャドウによる硬い影の表現が，微妙なミスマッチングを引き起こしているように感じる。かなりの部分の形状表現をバンプマッピングに頼っているようで（例えばゾンビの筋肉や鎖骨の凹凸はほとんどがバンプマッピングだと思う），これらの表現があまりにも柔らかい陰を作り出しているために，かえって影の硬さを強調してしまっているように見える。

全体的にアンビエント光が極力抑えられているのも，違和感を強調するのに一役買ってしまっているようだ。 id らしいハードな表現ではあるんだけれど，光の当たっていない側がまったくの暗闇ってのも，ちょっと無理があるのかもしれない。

シャドウボリューム生成の負荷を考慮したためか，モデル自体は思ったよりもローポリ化が進められているようだ。そういえばどこかで，ハイポリで作成したモデルの細かな凹凸をバンプマップ化し，見た目のディテールを保持しながらポリゴンのリダクションを行うツールを作ったとかなんとか，そんな噂を聞いたような気がする。ゾンビの指など良く見たら立方体だし，下手すると昨今のゲームよりもローポリな所があるかもしれない。

ローポリかつバンプマッピング使いまくりとなると，ステンシルとの競合はもはや不可避のように思えるんだけれど，実際にはどうやってこの問題を回避しているんだろう。何はともあれ，実際に動いている所を見てみたいものだ。できれば 30fps 以上で……。

permalink

http://www.konamityo.com/CV01/contents.html

よくよく考えてみれば， GBA 買ったくせに nanoloop 以外のソフトを持っていない。ていうか nanoloop って GB 用ソフトだしさ……。

やはり，電源を付ければすぐにゲームが始まる感覚ってのは悪くないな，と思った。暇潰しの道具としては最適なスタイルかもしれない。これで液晶がもうちょっと見やすければ言うことは無いんだけれど。

肝心のゲームの内容は，なんかいい感じ。このシリーズにしてはアクションとしての難易度がだいぶ低い気がするけれど，手軽に楽しむって意味では，こんぐらいサクサク進むやつの方がいいのかもしれない。

アートワークの凝り具合に老舗の底力が感じられる。久々にドット絵が炸裂しているゲームを見たような気がする。ボスキャラの関節がぐりぐりと回転したりするのは，なんか楽しげ。ラスタースクロールとか，半透明とか，回転多関節とか，そういう些細なエフェクトが妙に新鮮に感じる。こういう感覚が楽しめるプラットフォームって，最近じゃ GBA ぐらいしかないから，ある意味羨ましい環境ではあるな，と思った。

GBA には SFC ばりの回転拡縮機能がついている。 BG だけでなくスプライト毎の変形も可能だから，解像度を別にすれば SFC の性能は超えていると言っても過言ではない。ただ，画面解像度が 240x160 という珍しい値になっているので，他機種からの移植などは，ちょっとやり難そうな感じがある。

http://vsync.org/agb/index.html

スプライトの限界数が少ないのが気になる。ラスタ割り込みによるスプライト増幅技は使えるかな……。

GBA の液晶画面を見ていたら，こんなのを思い出した。

http://grc.com/ctwhat.htm

LCD ディスプレイの特性を活かして，横方向の解像度を擬似的に増幅させるテクニックだ。

GBA の液晶画面を目を凝らして見てみると，青いドットは右に，赤いドットは左に寄っているように見える（"Castlevania" の場合はマップ画面を見てみると分かりやすい）。恐らく R-G-B の順で画素が並んでいるんだろうと思う。これを元に sub-pixel レンダリングを行えば，擬似的に３倍の解像度を得ることが可能かもしれない。

これで，夢の横 80 文字表示が現実のものに……。

permalink

http://www.geocities.co.jp/SiliconValley-SanJose/8700/P/GXSC...

本当に MIDI ファイルを突っ込むだけで chiptune になっちゃうんだから，大したものだと思う。着眼点が良かったんだなあ……。うちの PC に付属の "SoundMAX" の貧弱な MIDI ドライバで鳴らすぐらいだったら， GXSCC の方がよっぽどいいんじゃないかと思うぐらいだ。

http://www.soundmax.com/products/information/codecs.html

以前使っていた YAMAHA YMF734 に付属の XG 互換 MIDI ドライバとか，かなりいい感じだった。しかし最近では YMF の名もほとんど聞かなくなってしまったような気がする。いわゆる "on-board" なサウンドチップの分野では， SoundMAX の製造元である AnalogDevices 社のシェアが断然で高くなっているようだ。

AnalogDevices 社では SoundMAX の関連商品として "SoundMAX SPX" と呼ばれるゲーム向けサウンドエンジンを開発している。

http://www.audioforgames.com/

これがちょっと面白い扱いになっていて，ゲームへの組み込みに関しては完全にロイヤリティーフリーとなっている。

http://www.audioforgames.com/support/index.html

これには，同社のメインは PC 向けデバイスの開発・製造にあり， SoundMAX SPX に関しては同社の技術力の宣伝のために用いたいという意思が働いているようだ。そのため，スプラッシュやロゴの表示は義務付けられるものの，金銭に関しては何も求められないということになっている。

SoundMAX SPX は Intrinsic 社のゲーム向けミドルウェア "Alchemy" のサウンドエンジンとしても採用されている。

http://www.intrinsic.com/

ただ SoundMAX SPX も Intricsic Alchemy も実際に使用しているソフトを見たことがないので，その品質がいかなるものなのかは定かでない。いちおうデモを落としてみたんだけれど，いまいちうまく動かないんだよね，これ……。

ゲームのミドルウェアなんて言うと，ちょっと地味な印象があるかもしれないけれど，昨今のゲーム産業におけるハードウェアおよびソフトウェアの複雑化は，ミドルウェアの重要性を急速に増幅してきている。特に PS2 登場以降における市場の成長は凄まじく， 2006 年には４億ドル規模に達するのではないかという見通しもある。

http://www.renderware.com/press_clippings/september/gamesana...

特に売れているのが Criterion 社の RenderWare だ。同社の売上に関する資料を見つけることができなかったものの，あの怪物商品 "GTA3" が RenderWare だってことだけでも，そうとう稼いでいることが推測できる……。

permalink

今日は調子がいいので泊まり。泊まる基準は，いつだってだいたいそんなものかもしれない。

DOOM III の件について jiro さんから色々と御教授を賜った。有難いことです。

「ハイポリモデルをリダクションしつつ法線マッピング化」については，現在進行形で各所に導入が進みつつあるテクニックであったようだ。いつものことながら，流行から取り残されている感が否めない……。

有名なところでは， ATI の "NormalMapper" ツールや， Game Programming Gems 3 の Oscara Blasco 氏の記事 "Curvature Simulation Using Normal Maps" などが挙げられる。

http://www.ati.com/developer/mojo.html

特に ATI の NormalMapper デモは，なかなか興味深い内容だ。そうそう，せっかく RADEON 持ってるんだから，たまにはデモも動かさないとね。

http://mirror.ati.com/developer/normalmapper.zip

上の画像がその実行画面だ。左がハイポリモデル。中央がその 1/10 リダクションモデル。そして右端が，中央のリダクションモデルに NormalMapper の出力する法線マップを貼り付けた結果だ。やはり完全とまでは行かないものの，かなりのディテールが再現されている様子をうかがえる。本来なら中央のように表示されるモデルが，右の画像の見た目に化けちゃうってんだから，これはかなりおいしい話ではないかと思う。

ディスプレースメント・マッピングとは違い，実質的には曲率を補正する程度のものでしかないため，元の形状と大きく異なる部分については，どうしても再現度が低くなりがちであるようだ。例えば車体前面に掘られている溝の部分など，見えないはずの陰の側が黒いスジとなって現れてしまっている。

全体として見渡すと……やはりポリゴンの切れ目に沿ってうっすらとムラが見えているのが，ちょっと気になる。これはジオメトリが大きく削られている以上，どうしようもない問題なのかもしれない。細かい所をつつけばそんなものだけれど，コスト対効果で言えば，目覚しいほどの効果があげられていることは確かだと思う。

ローポリモデルを使用する上で，どうしても目立ってしまうのが，シルエットに表れるエッジの荒さだ。これについてイメージベース的に解決しようというのが， Sander/Hoppe の "Silhouette Clipping" だ。

http://people.deas.harvard.edu/~pvs/research/silclip/

Hoppe と聞くだけで腰が引けてしまう性分なので，どうにも中身は読んでいない。だいたいのノリとしては，

……と言った感じのようだ。仕組みは明快だけれど，ちょっと手間がかかり過ぎのような気もする。

この他にも参考文献をたどって行くと，結構な数の法線マッピング関連の論文を見つけることができる。このことからも分かるように，「ローポリ＋法線マッピング」で見た目の品質を保持つつジオメトリ量を減少させる，という手法はかなり一般的なものとして認知されているようだ。

実のところ，バンプマッピングや法線マッピングの類は，これまで一度もまともにやったことが無い。苦手意識があるので克服したいなと思いつつも，手を出さないまま時が過ぎ去ってしまっている。ううむ，どうにも，どうにも……。

ともかく，このテクニックは非常に利用価値がありそうだ。バンプマッピングの類はオーサリングが困難なために，ちょっとしたマテリアル表現にしか使えないと思っていたんだけれど，この方法ならば，簡単かつ有効に運用することが可能ではないかと思う。

permalink

permalink

http://www.python.org/doc/current/lib/module-ConfigParser.ht...

もうこっちの世界に戻る気はしない。簡単な設定ファイル等については ConfigParser で十分なこともあるけれど，それでも，将来的に複雑度が増したときのことを考えて，あらかじめ拡張性の高い形式にしておくのは良い考えだと思う。

Python 2.0 以降では，標準ライブラリとして "xml.dom", "xml.dom.minidom", "xml.sax" 等が使えるようになっている。 SAX はエレメント毎にコールバックが呼ばれる方式で， DOM は XML のツリーをオブジェクト化する方式だ。なんとなく DOM の方が扱いやすそうに思えるかもしれないけれど，いざツリーをたどる段になると，結局 SAX と同じような処理を組んでしまっていることが多い。

ツリーの一部分を書き換えて，それをまた XML 文書に戻すような場合には， DOM が確かに役に立つ。しかし，一方的に読み出しを行う作業においては， SAX と比較してそれほどの利点も無いように思える。それだったら，処理速度とメモリ・フットポイントの小ささを重視して SAX を選択した方が良いのではないかと思う。

SAX と言えば，やはり expat だ。

http://expat.sourceforge.net/

http://www.python.org/doc/current/lib/module-xml.parsers.exp...

他にも SAX ベースのパーサはいくつか存在する。 expat はその中でも古参の部類に入るものだけれど，処理速度について言えば，今でも最も秀でた存在であるようだ。機能面では多少不安な要素が残る。しかし，例えば３Ｄモデルのように巨大なデータを扱う場合には，やはり expat の出番になるのだろうと思う。

Relaxer みたいなツールが使えれば，もうちょっと楽になれたんだけどな……。さすがに，今から Java を本格的に導入する気にはなれない。

http://www.asahi-net.or.jp/~dp8t-asm/java/tools/Relaxer/inde...

今の所，スキーマの類は何も使っていない。本格稼動時には書式をかっちり定めて，バリデーションの機構を差し込むことになるだろうと思う。

http://www.oasis-open.org/committees/relax-ng/

書式のバリデーションを外部のツールに任せられるのは，そこそこ重要な要素かもしれない。ツールの方で，書式が完全に正しいことを前提に処理することができるようになるからだ。

permalink

http://www.atmarkit.co.jp/fxml/tanpatsu/08officexp/officexp0...

これで，何か特殊なテクニックに頼らなくとも， Excel や Acces のデータに対してストレートにアクセスできるようになる。特に， Windows 以外のプラットフォームからこれらのデータにアクセスする際には必須の機能となるだろうと思う。

また，最近では，こんなツールも登場しているようだ。

http://public.kitware.com/GCC_XML/HTML/Index.html

"GCC-XML" は， C++ の構文を XML に変換するツールだ。

例えばこんなソースファイルが，

http://public.kitware.com/GCC_XML/HTML/example1in.html

こんな感じの XML 文書に変換される。

http://public.kitware.com/GCC_XML/HTML/example1out.html

現在の C++ の仕様は十分に複雑なもので，自前で構文の解析を行おうものなら，多大な労力を要求されることになる。例えば C++ のソースに対して自動でドキュメンテーションを行うツールを作ろうなどと思っても，なかなか簡単に実現できるものではない（その点 Doxygen は大したものだと思う）。こういった場合に， GCC-XML を使って事前に XML 化しておくようにすれば，構文解析の手間を完全に省くことが可能だ。コード分析やコード生成など， C++ の構文の複雑さゆえに諦めていた処理が，これで可能になるかもしれない。

GCC-XML は， GCC のソースに対してのパッチとして開発されている。 GCC がバイナリを吐くかわりに，独自の XML 出力を通すような仕組みになっているようだ。

http://public.kitware.com/GCC_XML/HTML/Patching_GCC.html

インストールの手順がちょっと複雑なので，まだ試してみていない。しかし，自動でコードを云々ってのはわりと好きな方法なので，じきに必要になる時が来るのではないかと思っている。

permalink

http://artists.mp3s.com/artists/3/sketch.html

いつの間にか，随分とレパートリーが増えているみたいだ。アコースティック・ギターのソロ演奏によるカバー曲がメインとなっている。昔置いてあったオリジナル曲がほとんど無くなってしまっているのは，ちょっと寂しい。

いつのまにかサイトも立てられていた。

http://www7.ocn.ne.jp/~sketch/

たまには，こんな静かな音楽を聴きながらプログラムを打ちたくなることもある。それにしても，アコギのソロ演奏ってのも，面白いものだなと思う。たった五本の弦から，ここまで豊かな和音を作り出すことができるんだから，驚きに値する。

ギターの音が持つ独特の素朴さと暖かみが，冬の冷えた夜にはとても心地よく感じる。

permalink

随分と長い間ほったらかしにしてあった photon mapping のコードに手を入れた。数ヶ月前に交差判定の部分を書き換え始めてから，ビルドできないぐらいにぐちゃぐちゃな状態が続いていた。今はオーバーホールも完了して，そこそこ完結したプログラムになっているつもりだ。

このプログラムについて，やるべき事はまだまだ沢山あるんだけれど，ここで一区切り打っておかないと，他に何も手を付けれなくなりそうな気がしてきたので，無理やり完結させてみることにした。ほったらかしにしたまま他の事に手を付けてしまうと，またこの作業へ戻ってきた時に，何をやっていたのか思い出せなくなってしまう危険性がある。

http://www.radiumsoftware.com/files/photonmap.021110.tar.gz

ビルドには boost, tvmet, DevIL が必要。ただし，最新版の DevIL を使うには，ちょっとした工夫が必要になるかもしれない。

http://www.radiumsoftware.com/wiki/moin.cgi?DevIl

DevIL プロジェクトは，相変わらず停滞したままのようだ。そろそろ他のライブラリを探さないとだめかな……。

今年の春ぐらいに仕事が忙しくなってからと言うもの，リアルタイム関連からずっと遠ざかっていた。せっかく RADEON を導入したのに腐らせておくのはもったいないので，また GL と戯れてみようかなあ，と思っている。

そう言えば， Blender のことをすっかり忘れていた。これも随分とご無沙汰になっている。

http://www.blender.org/

先月，待望のソースコードも公開され，オープンソース Blender としての新たなステージが始まろうとしている。まだ，ビルドできただのできないだので騒いでいるような状態だけれど，コミュニティの機能も徐々に始動しつつあり，そこそこ明るいスタートが切れているのではないかと思う。

開発者向けの内部資料が公開されたのが，そこそこ大きな動きだと思う。

http://www.blender.org/modules/documentation/intranet/index....

わりとマメにドキュメンテーションされているようだ。外部に出す資料としては不十分かもしれないけれど，閉じた環境で開発されていたプロジェクトで，ここまでドキュメンテーションされていれば大したものなのではないかと思う。それとも，僕の意識が低すぎるのか。うう。

"Famous development quotes" の項は，ちょっと面白いなと思った。

http://www.blender.org/modules/documentation/intranet/docs/d...

これは真似してみてもいいかもしれない。むしろ，このくらいの冗談が通じる雰囲気の職場でないと，ちょっと困る気もする。

あと，これを見て， Blender がオランダ製だということを久しぶりに認識した。ちゃんと英語でドキュメンテーションしているのは偉いと思う。

permalink

http://www.radiumsoftware.com/wiki/moin.cgi

とりあえず，デフォルトでは閲覧のみとしてみた。管理者だけが編集系の操作を使えるような仕組みになっている。ちょっとした Blog システムみたいなノリかな……。

MoinMoin 1.0 では， WikiPage に対してファイルの貼り付けを行うプラグインが，標準で装備されている。

http://twistedmatrix.com/users/jh.twistd/moin/moin.cgi/HelpO...

これがなかなか便利そうなので使ってみることにした。こんな感じ。

http://www.radiumsoftware.com/wiki/moin.cgi/PhotonMapping

お気楽な感じで良いのではないかと思う。

ただ，最近の MoinMoin は Python 2.0 をベースに開発されているような風があって， Python 1.5.2 では動かない個所がいくつか存在するようだ。最も多かったのは， cgi モジュールの FieldStorage に対して getvalue を発行している個所。 FieldStorage の getvalue は Python 2.0 以降のサポートなので， 1.5.2 では has_key でキーの確認をしてから form[key].value とか，そんな感じに変更する必要がある。

このレンタルサーバに Python 2.2 が入っていれば，話は早いんだけどな……。

CGI の動作確認をするのに， Python の "CGIHTTPServer" モジュールを使ってみた。

http://www.python.org/doc/current/lib/module-CGIHTTPServer.h...

Python の標準ライブラリには， HTTP サーバだの， ftp クライアントだの， XML-RPC サーバだの，ネットワーク関連の出来合いモジュールが沢山含まれている。これらはいかにもアドホックな解決手段を提供するものなんだけれど，実際のところ，そこそこ頼りになる存在だ。

使い回しの効く小さなツール群を単純なインタフェースで連結して，適当なソリューションを即興で構築するってのは， UNIX の流儀でもあったような気がする。例えば， Python では File オブジェクトが汎用的なシリアルインタフェースとして使いまわされていたりするわけで，これが UNIX の「なんでもファイルデスクリプタで解決」なノリを連想させて，なんだか可笑しい。

えーと，それはともかくとして……家の環境には適当な HTTP サーバが無かったので，これは結構役に立った。こんな感じのスクリプトで，お手軽 HTTP サーバを立ち上げることができる。

もちろん，セキュリティもへったくれも無いので，くれぐれも実稼動させてはいけない。あくまでも動作確認用だ……。

permalink

http://www.yellow5.com/pokey/

自分でも，なんでこんなページにたどり着いたんだか，わけがわからない。これを見てどうしろと。

こんなのでも， google でサーチしてみると 6,000 件もヒットする。

http://www.google.com/search?q=%22pokey+the+penguin%22

なんだかなあ……。

このテイストで笑えるかどうかは，向こうの人間にとっても難しい判断であるようだ。

http://www.rit.edu/~flf1754/pokey/pokeyfaq.html

しかし，ええと……個人的には，いいと思う。 "Penny Arcade" じゃ，ちっとも笑えないけど， "POKEY THE PENGUIN!!" には，面白いと感じさせる要素が少なからず存在する。脱力系の笑いってのは，文化を越える力があるのかもしれない。海外発の flash アニメなんかでも，下手に洗練されたものよりも，ちょっと脱力気味で気合の抜けた作品の方が面白く感じることがある。

「分かっててやってる」ってのが，ギリギリ判別できるぐらいのが面白いのかなあ……。狙いがミエミエなのは嫌だし，「分かってない」のは，やっぱりちょっと怖い。この辺りの評価基準は，「２ちゃんねる」のネタなんかにも通じるものがあると思う。

まあ，なんていうか，こういうので笑えるとか笑えないとか，真面目に語ってるあんたらの方がよっぽど面白いよ……。 6,000 のコンセンサスが，この作品に対して十分な存在意義を与えているんだと思う。

同じ脱力系では "JEFF K!!!" なんてのもあった。これも結構な脱力加減で，いい。

http://www.somethingawful.com/jeffk/

こちらは， "POKEY..." よりもいくぶん洗練されている感じかな。しかし，それでも，これひょっとすると天然なのかも，って思わせるぐらいの迫力がある。いい感じだ。

http://www.everything2.com/index.pl?node_id=516996

permalink

http://www.atmarkit.co.jp/fxml/tanpatsu/xslt/xslt00.html

この辺りの，いわゆる IT 関連の分野に関しては，日本語の資料が豊富に存在するのが有難い。素の新入社員がとりあえずの一人前になるまで，組織的に教育することができるような基盤が整っている。これは非常に優れたことだと思う。ゲームなんてのは，趣味的な要素が無ければ，とてもじゃないけどやっていけないようだ。

プログラマはまだしも，アーティストなんて，もっと悲惨かもしれない。最近は分業化が進んでいるから，アーティストなどはますますゲームについて知る機会が少なくなってしまっている。例えば，非専門の学校を出て，ぽろっと業界へ飛び込んできたような人材に対し，ポリゴン数を削ることの重要性や，パレット化されたテクスチャの価値などを正確に伝えるには，どうしたらいいのだろうかと考えることがある。ましてや，ポータルやコリジョンなんて，どうやって作ってもらったものなのやら……。

昨今のリアルタイム CG 技術は，明らかに特殊化が進行している。今後も，「数年前のオフライン CG 技術の縮小再生産」的なノリでは通用しない部分が増え続けることだろうと思う。そういった状況に対して速やかに追従していくには，コンテンツ作成者に対して技術サイドから細かなフォローを与え続けることが重要になるはずだ。

PS2 という明らかに前時代的な環境をベースメントとしていると，こういったダイナミズムから遠ざかってしまいがちだ。やはり，大・中規模の制作集団が単一のプラットフォームに縛られるってのは，あまり良くない傾向だと思う。たしか，多様性を失った集団ってのは，変革を迎えたときに滅亡しやすいんじゃなかったっけ……。

ところで， XSLT を「プログラミング」と称するのには，ちょっと抵抗感がある。基本的にはパターンマッチングとアクション定義の組み合わせなわけで，プログラミングと言うよりかは，ちょっとしたコンフィギュレーションを与えているような感覚に近い。 awk をプログラミング言語と呼ぶかどうか，みたいなレベルのものを感じる。

perl を「あんなのプログラミング言語じゃない」って言い切ったのは，たしか RMS だったと思う。とても声に出しては言えないけれど，そんな感じの心境だ。

permalink

http://www.tempur-japan.co.jp/whats_tempur/whats_tempur.html

そうそう， awk でちょっと思い出したことがある。 sed についてだ。

UNIX には sed ってコマンドがある。正規表現で置換を行うフィルタの一種なんだけれど，よくよく考えてみると，それがなんで "sed" なんだか，わけが分からない。マニュアルには "Stream Editor" の略だと書いてある。しかしこれも，ちょっとしっくりこない説明だ。

http://www.opengroup.org/onlinepubs/7908799/xcu/sed.html

ストリームを「エディット」って……ううむ。英語だとそういう表現があるのかなあ。ていうか，これ，どっちかってば「フィルタ」なんだし，やっぱりなんか不自然だ。

そんな感じでしばらく考えていて，やっと理由が分かった。 UNIX の最も原始的なエディタである "ed" をストリーム方式にしたのが "sed" なんだ，と。 ed なんて，まず使うことが無いから，全然気が付かなかった。

この辺りの命名には，歴史的な因縁を含むものが多いと思う。そもそも "C" とか "UNIX" がそうだし。

ちなみに， awk という名前は，作者の三人の名前の頭文字を集めたものに由来する。

http://www.everything2.com/index.pl?node_id=33077

Aho, Weinberger, そして Kernighan 。だから "awk" と。 Aho は「エイホ」。発音に要注意。

permalink

http://www.muzie.co.jp/cgi-bin/artist.cgi?id=a003486

かなり前から存在していたようだ。懐かしい……。なんだかんだ言って CD は持っていないもんだから，こうしてまた聴くことができるのは有難いことだと思う。

未発表音源の "DANDISM" とか，いい感じだ。相変わらずネタが斬れているなあ……。それでいて，ネタや勢いに頼るわけでもなく，完成度の高いオケを繰り出してくる所が，カラテクノの素晴らしさだったと思う。

permalink

http://pocket.ign.com/articles/371/371225p1.html

やはりこの手のアクション・アドベンチャーは，海外での受けがいいらしい。アクション・アドベンチャーの金字塔である "Metroid" シリーズが，今や海外のデベロッパによって開発されているという事実は，そういった状況を反映した一つの例だろうと思う。最新作である "Metroid Prime" の国内販売スケジュールはいまだ未定だし， GBA の "Metroid Fusion" も，今のところ海外のみの販売となっている。

海外の記事を調べていて，ちょっと気になったことがある。十字架に代表されるような，宗教的な意味を持つシンボルが，海外版でもそのまま使用されていることだ。

http://www.konami.com/harmony/official/frame.html

この手の要素はローカライズ時に問答無用で削除されるのが普通だと思っていたんだけれど……。もっとも，このゲームから宗教的なモチーフをすべて取り去ってしまったら，テーマも何もあったもんじゃなくなってしまうかもしれない。伝統のあるタイトルだけに，その辺りのノウハウは既に蓄積されているのだろうと思う。

なんだかんだでグッドエンドまで到達した（エンディングは数種類あるようだ）。グッドエンド後は，タイトル画面にサウンドモードの項目が追加された。そこで楽曲を聞いていて気が付いたんだけれど，タイトル曲やエンディング曲では PCM 音源が多重に鳴っているようだ。

GBA の音源は， GB 音源に PCM ２音を付け足したような構成になっている。

http://vsync.org/agb/agb09.html

通常なら， PCM １音は効果音に割り当てたいと考えるだろうから， BGM は実質的に GB 音源と PCM １音だけで構成することになると思う。これだと，ほとんどファミコンと同程度，もしくはそれ以下の表現力でしかない（ファミコンの方が拡張が効くぶん潜在的な性能は高いとも言える）。 GBA のゲームレビューなどを見ていると，何かと音の悪さが取り沙汰されているように見えるんだけれど，これはハードウェアの制約上しょうがないことだとも言える。

GBA は CPU に ARM7 の 16.78MHz を積んでいる。それなりに演算能力を持っているので，リアルタイムに PCM 音声の波形合成を行うことも可能だ。ただし，相応の処理時間を費やすことになるので，ゲーム本編の処理が忙しくなければ，という制約は付く。例えば「キャッスルバニア」では，タイトルやエンディングなどのように， CPU パワーがそれほど必要とされていない箇所についてのみ，このような合成テクニックを利用しているようだ。

実際に聴き比べてみればわかるんだけれど，発音数の増加による表現力の差は歴然としたものがある。やはり，何と言うか……せめて PCM ４音ぐらいは欲しいところだったのかもしれない。 GBA は，これから先の数年間（下手すると十年近く）生き残るプラットフォームとなるはずだ。この中途半端な仕様は，これからもずっと，開発者に呪われ続けることになるのだろうと思う。

permalink

permalink

http://www.sunkus.co.jp/serch/shp_detail.asp?Shop_id=2020279...

こんなにまで集中して店舗を配備することに，一体何の意味があるのかと考えると，不思議でならない。もっとも，フランチャイズ方式というのは，あくまでも各店舗は独立した商店であることが基本だから，右にならえでサンクスを選んでしまったオーナーに責任があるのであって，サンクス自体に罪は無いのだろうと思う。

http://www.sunkus.co.jp/coinfo/shp/pages/kamei2_1.html

おおかた，ご近所様とコンビニ合戦になったんじゃ困るから，同じ系列店にしておけば平等に人がバラけてカドが立たないでしょ……とか，そんな日和ったやりとりがなされているに違いない。ううむ，どんどん邪推は加速する。どうにも適当な運営状態の店ばかりだから，少し恨みが募っているんだ。

コンビニというものは，オーナーが直接に運営を担当している店舗の方が，サービスの質が良くなる傾向にあるようだ。もとが酒屋などの個人経営商店だった所がコンビニ化した場合などに，そういう運営スタイルになることが多いように思える。コンビニなんて，品揃えという点ではどこも同じレベルなんだから，純粋に立地と人材の問題に帰結されるのは明白なことだと思う。

ともかく，同じコンビニなど２つまでで十分だ。３つ目以降はいつか爆破してやろうと企んでいる。

permalink

http://www.openoffice.org/

http://blow-away.net/openoffice/

OpenOffice は，オープンソースベースで開発が進められている Office スイートのプロジェクトだ。早い話が MS Office 相当のものをフリーソフトウェアで揃えてしまおうというものだと考えればいいと思う。元は StarOffice という名前のプロジェクトで，独 StarDivision 社の元で開発が進められていたものなんだけれど，同社が Sun に買収された後にオープンソース化され，そこから OpenOffice.org が分派し……といったような複雑な歴史を抱えている。

http://www.openoffice.org/about.html

作り自体は，かなりしっかりしている。ちょっと起動が遅いのを除けば，昔の MS Office を使うような感覚で利用できるはずだ。ただし，日本語のサポートに関して完璧では無い部分が少なからず存在するため，日本語環境で本格的に使うには問題があるだろうと思う。

しかし，ドローソフトである OpenOffice Draw だけは別だ。日本語に多少の不具合があるとしても，ドローソフトとして使う分には問題の無いレベルだし，第一 MS Office には OpenOffice Draw に相当するツールが無い（Visio はちょっと用途が違うだろう）。フローやスキームを書くための機能もそこそこ充実しているし，これは本格的に使う価値のあるソフトだと思う。

http://blow-away.net/openoffice/public/draw.png

というわけで， OpenOffice Draw を使って図表をゴリゴリと描いてみている。結構ハマるなあ，これは……。出力の際には， Enhanced Postscript でエクスポートしてから Ghostscript でビットマップ化するのがコツだ。 Ghostscript がアンチエイリアスを効かせてくれるので，単純にビットマップ出力するよりも高品質な画像が得られる。

そんな感じで，結局，泊りがけで図を描ききってしまった。

permalink

http://objectclub.esm.co.jp/UMLintro/index.html

付け焼き刃で導入したって効果ないかもしれないけれど……要するに気分転換なので，それでもいいとしよう。 UML デザインツールを使って，チクチクとクラス図を描いていくのは，なかなか楽しいものがある。ツールには SourceForge で見つけた "UML Sculptor" を使ってみている。

http://umlsculptor.sourceforge.net/

KDE "Umbrello UML Modeller" や，オブジェクト倶楽部の "Jude" なんかもいい感じだ。

http://uml.sourceforge.net/index.php

http://objectclub.esm.co.jp/Jude/jude.html

ただ，これらのツールはコード生成機能を持っているんだけれど，それが逆に，使い勝手に対して制約を加えてしまっているような気がする。僕は，これらのツールの CASE 的な使い方は当てにしていないので，極端な話，コード生成機能は必要無いと思っている。だから， UML Sculptor ぐらいの手軽さと柔軟さがいいのかもしれない。

出力形式が貧弱だとか，一部に致命的なバグが残っているとか，不満点は少なからず存在するんだけれど，それなりに使えるツールではないかと思う。今後の発展に期待したい。

permalink

http://objectclub.esm.co.jp/eXtremeProgramming/xp-faq.html

XP についてはさておき，僕の今のところのスタンスでは，できるだけ簡潔にドキュメンテーションを行うことが，ドキュメントの寿命を延ばすためのコツなのではないか，と考えている。なるべく限られた文章で解説を行うようにし，意味の無くなった部分についてはどんどん削除を行う。そして，枯れた部分から順次に詳細なドキュメンテーションを行うようにすれば，累積コストを最小限にとどめることができるのではないかと思う。

どうにも，職人気質や個人のカラーが尊重されがちなゲーム開発においては， XP のような手法を導入することは難しいように思える。製品の性質から考えて，作り手の作家性みたいなものが尊重されるのは決して間違ったことではないから，これを一方的に改めればいいってものでもないと思う。

ただ，そんなのん気なことを言っていられるような時期が終わりつつあるのも，一つの事実だと思う。大量の人員を投入し，多彩なコンテンツを大量かつ計画的に生産できるような体制を確立することが求められている。そうなった場合に，従業員個人の作家性やらなんやらってものを尊重している余裕があるのかというと，それは難しいことだと思う。作家性は一部のブレーンにのみ在ればいいのであって，部下は良き歯車であることを要求される，そんな時代かもしれない。

大企業の大規模プロジェクトを「工場」と揶揄することがある。コンベアから流れてくる部品を黙々と組み立てる工員のように，与えられた資料に従って黙々とポリゴンを構築する人たちがそこにいる。しかし，コンテンツ生産の究極の姿を求めれば，行き着くのは工場生産の世界なのかもしれない。生産性の極大点を求めて特化された環境こそが「工場」なのだから，その比喩は間違っていないだろうと思う。

ただ，最近の工場はコンベアなんて使わないらしいんだけど。

http://www.google.co.jp/search?q=%83Z%83%8B%90%B6%8EY%95%FB%...

permalink

http://www.doxygen.org/

以前にも Doxygen を使ってみたことがあるんだけれど，それほど良い結果を得られなかったことから，その後は使用を見合わせていた。一方で， Doxygen を導入するプロジェクトは着実に増えつづけており，既にかなり高い知名度を獲得しているように思える。これだけの知名度を得ているのならば，追従する意味もあるかもしれない，ということで，もう一度 Doxygen の導入に挑戦してみることにしたわけだ。

ところで，いくら「ドキュメント自動生成」ったって，何でもかんでもソースをぶち込めばいいってもんでもない。それに， C++ の場合はヘッダファイルとソースファイルって区分があるから， JavaDoc 風な使い方を単純に真似るってわけにもいかない。各ソースのプライベートな部分は無視し，外部参照される部分のみを Doxygen で文書化する，という前提において使用するならば，ヘッダファイルのみを食わせるようにするのが無難な使い方だろうと思う。

文書化の情報が与えられていないソースを Doxygen に食わせても，ほとんど意味の無い大量の HTML が吐かれるだけなので，文書化すると決めたファイルのみを Doxygen に食わせるようにした方が，リファレンスとしての機能は高くなるだろう。そういうことだから，入力ファイルは '*.hh' のようなワイルドカードで指定するのではなく， INPUT オプションで逐次指定する。加えて， HIDE_UNDOC 系のオプションを立てておいて，文書化情報の与えられていない要素は無視するように指定するのもいいかもしれない。もし十分な覚悟があるのなら，これらのオプションは OFF にして，代わりに WARN_IF_UNDOCUMENTED を立てるのもいいだろう。そして，警告が出なくなるまでひたすらに文書化するのだ。

あとは，個人の趣味で適当にカスタマイズだ。僕は JavaDoc 風のシンタクスが好みなので， JAVADOC_AUTOBRIEF を ON にしておく。また， @param 系のコマンドは，必要な場合のみ与えるのがいいかなあ，と思う。闇雲に全部付けようとすると，同じような文章をいくつも量産するハメになるし，それ以前に，ほとんどの引数は型と名前から内容を想像できるものだと思う。もし，そうとも限らないと思ったのならば，そう思ったところだけ付けるようにすればいい。

これは一部のアクセスメソッド等にも言えることだから，やはり HIDE_UNDOC 系は危険かもなあ，と思う。意固地になって意味のないコメントを付けまくっても，あとで後悔するだけだ。まあ，それ以前に，アクセスメソッドを量産する行為自体が，僕はあまり好きでないんだけれど……。

と，こんな感じで，ひとえに Doxygen と言っても考えることはいろいろある。極めれば非常に強力なツールであることは間違い無いんだけれど，自由度が高いゆえに悩みどころも多いツールのように思える。そんなこと無いだろうか。

例えば， Apache XML Project なんかがわりと上手く使いこなしているようなので，その辺りを参考にしてみるといいかもしれない。

http://xml.apache.org/xerces-c/apiDocs/index.html

スタイルシートやヘッダ／フッタの指定を上手く行えば，それなりに見栄えのするドキュメントを生成することも可能だ。

permalink

http://members.tripod.co.jp/townsemu/

それで結局， Doxygen を導入することにしたのはいいんだけれど，どうしても煮え切らないことが，いくつか残っている。

Doxygen は当然のごとく，英語を扱うことを前提として設計されている。文字コードに関する些細な問題は EUC の利用によりほとんど解決することができるんだけれど，各言語の文法に関わる問題となると，解決はなかなか難しくなる。

例えば， Doxygen では改行がスペースへと変換されるようになっているんだけれど，これは日本語にとってあまり有難くない機能だ。意味の無い位置にスペースが挿入されてしまい，何となく間の抜けたドキュメントが生成されてしまう。他にも，簡易コメントの文末へ勝手にピリオドが挿入されてしまう，など，些細な問題がいくつか存在する。どうしてもダメ，ってほどの問題ではないところが，余計に悩ましいと思う。

せっかくのオープンソースなんだから，ソースにパッチを当てて修正するのがスジなんだろうけど，ちょっとそれは大げさな気もする。とりあえず改行問題についてはプレフィルタリングをかますことによって解決できそうだから，それを試してみようと思う。 INPUT_FILTER オプションを使うわけだ。

僕は JavaDoc シンタクスで Doxygen を使うつもりなので，その線で仕様をまとめてみる。つまり……

この３つを満たす場合に，２つの行を連結するようなフィルタを用意すればよさそうだ。昔は，全角文字処理なんてのは鬼門だったので，できるだけ手を出さないようにしていたものだけれど，今は perl も Python も Unicode に対応しているおかげで，手軽に処理できるようになった。このフィルタも，一旦 Unicode に変換してしまえば，あとは至極簡単なものだ。ざっくりと Python で作成。あとは実地で運用しながらバグフィクスしよう……。

permalink

http://lxr.linux.no/

ううむ，これはどうだろう。 LAN 上で動かして，そこそこのレスポンスが得られるのであれば，なんとなく使えそうな気もする。ただ，これだったら， SlickEdit の "Context Tagging" 機能や， VisualStudio のインテリセンス機能などの方が，よっぽど役に立つのではないかと思う。

http://www.slickedit.com/products/pr_products.php

ただし，開発環境の前提条件として，特定の商用アプリケーションに頼るというのは，できれば最後の手段に回しておきたいと思う。オープンソースであることが，比較的優先される事項として存在するのだ。

もちろん，導入のための費用などは会社がいくらでも（？）出してくれるのだから，その点を心配しているわけではない。ただ，そうやって導入したインフラは，いつまでも自分の手元に残っているわけではない。それはあくまでも会社のものであって，組織が無くなってしまったり，あるいは自分が組織から外れてしまえば，たちまち手元から消え去ってしまうものだ。一介の契約社員でしかない僕にとって，それはとても儚いもののように思える。

それが，オープンソース・プロダクトならば，また違った可能性が見えてくる。導入に要されるコストは限り無くゼロに近いのだから，いつ・どこでも再導入を試みることができるだろうし，それまでに培ったノウハウを再び活用することも自由自在だ。それに，コミュニティに対しての貢献は，それを使用する自分の身にそのまま帰ってくる。一見利他的な行動に見えて，実は私利に走っているという図式だ。

http://www.nagaitosiya.com/lecture/0110.htm

会社にお金を出させることこそが，会社を都合良く利用するための方法だと思ったら，それは極めて一面的な観点なのではないかと思う。本当に私利を求め，私欲を発揮する人ならば，会社にオープンソース・ソリューションを活用することを積極的に薦めるだろうと思う。

permalink

http://www.e-lets.co.jp/news/r_kiri_potter2.htm

稚拙な UML 図と戯れながら，いつか購入した GoF 本などを読み返してみている。 UML もデザインパターンも，表向きは設計手法の一つなんだけれど，その本質は，開発者間の意思疎通を効率化することにある，というような話をよく聞く。設計を助けると共に，設計を理解する助けにもなるということだ。

今，僕の目の前には，貧弱な語彙と稚拙な文章力をもって無駄に書き連ねられた文書の数々がある。こんな，自分でも読むのが辛いような文書を，他の誰が好き好んで読むだろうか。これをもっと簡潔な表現で伝える方法が必要だ，ということをひしひしと感じる。

文書量の増加は，単に読み難くなるというだけではなく，メンテナンスを困難にするという問題も伴う。仕様に変更が生じれば，当然のごとく文書にも更新の必要性が生じる。文書量が無駄に大きいと，更新作業が困難になるだけではなく，更新の度に内容が劣化していくというリスクも伴う。

文書が無駄に長くなる原因の一つに，旧世代における語彙の不足という要素がある。 Kernighan や Wirth がバイブルだった僕らにとって，二分木やハッシュは当然の語彙であっても，その２つを同じインタフェースに帰着させるデザイン手法など，想像すら及びつかないものだ。それをもし文章で伝えようとするならば，逐一すべてを言葉で表現し尽くすことになる。これでは，ひどく冗長性が高まってしまう。難解な法律を小学生の語彙で記述しているようなものだ。

例えば， Singleton パターンなんてのは，やっていることは至極簡単なのに，普通に文章で伝えようとすると，ちょっとした長さの解説になってしまうものだ。これを各場面毎に繰り返していたのでは，どうしても冗長な文書になってしまうだろうし，各所で曖昧な解釈が成り立つものになってしまうかもしれない。それが，すべての技術者の間で「Singleton とはこういうものだ」という共通認識が成立していれば，たった一言で伝えきることが可能となる。これはとても重要なことだ。

http://www.hyuki.com/dp/cat_Singleton.html

UML にも似たような性質を見つけることができる。アプリケーションを構成する各要素のリレーションとシーケンスを，厳密かつ簡潔に表し，それを他人に伝えることができる。冗長な文章で表現するよりもはるかに効率がいいし，標準仕様として文法が定義されているから，人や地方によって書式に偏りが出ることもない。

http://www.omg.org/technology/documents/formal/uml.htm

permalink

http://hillside.net/patterns/

あえて挙げるならば， GoF の 23 パターンが最も基本的な概念として扱われているんだろうけど，このカタログの品揃えには，以前から微妙な疑問を抱いている。

http://home.earthlink.net/~huston2/dp/patterns.html

http://www.agcs.com/supportv2/techpapers/patterns/papers/tut...

例えば， Flyweight パターンとか， Chain of Responsibility パターンなんてのは，正直なところ，かつて一度も使用したことがないと思う。それほどまでに出現頻度の低いパターンが Factory Method なんかと同列に並べられていることには，少し違和感を禁じ得ない。

それと，各パターンの名称に関しても，ちょっとした「扱い難さ」みたいなものを感じる。例えば， Java を知っている人にとって "Bridge" なんて呼び方は，どうにもまどろっこしいものに聞こえるだろうし， C++ ユーザにとっては "Template Method" なんて名称も少し紛らわしいものと感じられるかもしれない。

と，下らないクレームはこの程度にしておいて……やはり，こういった概念を浸透させることは，開発者同士の意思疎通を円滑化させる方法として，とても重要な要素になるだろうと思う。

もちろん，設計の場面においても，イディオムの一つとしてデザインパターンは有効なはずだ。決してパターンに振り回されてはいけないんだけれど，適所でうまく使いこなすことができれば，設計作業を効率化することが可能かもしれない。

なにはともあれ，まずは自分がマスターすることだ。まだ，とてもじゃないけど，啓蒙なんてできるレベルじゃないって……。

permalink

http://boost.org/libs/function/index.html

テストプログラムをいくつか作成し，生成コードを分析してみると，初期化のコストがかなり高くなっていることが分かると思う。死ぬほど重いってわけではないんだけれど，やっていることのわりには……って印象は拭えない。

呼び出しのコストはそれほどでもないので（それでも関数ポインタの十倍は重い），よほど注意すればうまく使いこなすことも可能かもしれない。しかし，どうしても関数ポインタを使いたくなるシチュエーションというのは，そう頻繁にあることでもないはずだ。他の実装方法を検討することが優先されるべきだと思う。

boost::function はともかくとして，非常に残念なのが boost::shared_ptr だ。詳しい話は省略するけど，どうも，初期化と参照カウンタ処理が無視できないほどに膨らんでしまう傾向にあるようだ。参照処理は軽いから大丈夫……としたい所だけど，そういうわけにもいかないと思う。スマートポインタは，低レベルから高レベルまで，あらゆる個所から頻繁に利用される要素なので，最大限の注意を払う必要がある。実態を知らずに，とりあえずポインタは全部 shared_ptr にしちゃえ，なんてのは，かなり危険な考え方だ。

boost::format なんかも，もうちょっとコンパイルが速ければ使えるんだけどなあ，と思う。下のプログラムをコンパイルするのにどれだけ時間がかかるか計測してみれば，その罪深さを理解してもらえると思う。

こうして洗い出しを進めていくと，使うことのできる要素はかなり限られてくるように思える。 bind とか lambda なんてのは，最初から封じるつもりでいたし……。なんだか， array とか tuple とか地味なのばかり残ってしまった。はて……。

permalink

http://mynewsgroups.sourceforge.net/

今までニュースリーダには WinVN を利用していた。これはこれで，それなりに使えるソフトなんだけれど，オフライン状態での閲覧ができないのと，どうにもインタフェースがレガシー臭いのとで，他のソフトへの乗り換えを検討しているところだった。

ニュースリーダをウェブアプリにすることには，それなりに利点があるように思える。記事をローカルにプールすることでトラフィックを節約することができるし，任意のドキュメントからニュース記事に対してリンクを張ることも可能となる。それに，元は単なる文書なんだから，ウェブベースに移行するのは自然な流れのように思える。

"MyNewsGroups :)" （フェイスマークは必須のようだ）の "My" は，どうやら MySQL の My を意味しているらしい。この前，初めて PostgreSQL を触ったばっかだってのに，今度は MySQL か……。

http://www.mysql.com/

オープンソース RDBMS と言えば，まず真っ先に挙げられるのが PostgreSQL と MySQL だ。一般に，機能面では PostgreSQL が，速度面では MySQL が，それぞれ優れているとされている。国内ではもっぱら PostgreSQL の方がメジャーなんだけれど，海外では MySQL もそれなりに人気があるようだ。本格的な業務用途はともかくとして，小規模なインハウス用途や個人用途には，軽量な MySQL の方が向いているということなのかもしれない。

"MyNewsGroups :)" は， PHP と MySQL をベースとして動いている。僕は，基本的に PHP も MySQL も使ったことがないので，セットアップにやたら苦労することになってしまった。どうやら最新版の PHP 4.3 ではうまく動いてくれないようだ。 PHP やら Apache やら MySQL やらをダウングレードして，やっとのこと成功した。

しかし，日本語化ができていないなど，まだ問題は多数残っている。ここまで苦労するのもどうかと思うんだけれど，このインタフェースはわりと理想に近い気がするので，簡単に諦めてしまうのはちょっと惜しいのだ。ああ……。

PHP は，あまりにもウェブ用途に特化されているという印象から，習得するメリットが少なすぎると判断して，できるだけ避けて通るようにしてきた。しかし最近は， PHP を避けるがあまりに，逆に選択肢を狭めてしまっていることが多いように思える。これじゃ本末転倒かもしれない。ううむ……。

permalink

http://www.muji.com/

なんだか知らないけれど，いつの間にか，ひねくれた負け犬的思考が染み付いてしまっているようだ。ちょっとでもハイソな空気を察知すると，たちまちに疎外感を感じてしまう。どうせ僕にはドンキホーテかダイソー辺りがお似合いなんですよ，みたいな。

Pat Hanrahan の講義コース "Image Synthesis" のスライドなぞを覗いてみた。

http://www.graphics.stanford.edu/courses/cs348b-02/

これらのスライドはあくまでも講義用であって，単体で読むことのできるようには作られていない。でも，最新の CG 技術の基礎部分に関する総括的な内容になっていて，眺めているだけでもそれなりに面白いかなと思う。僕が受けたことのある CG の講義なんてのは，いまだに Foley & van Dam から何も進歩していないような内容のものだったから，こんなに刺激的な内容の講義を受けることのできる生徒さん達のことを，とても羨ましく思う。

まあ，生徒の質の違いってのもあるから，教員を一方的に責められたものでもないんだけれど……。

副読書として "Louis K.Meisel Gallery" のページが挙げられているのが面白い。

http://www.meiselgallery.com/contents.htm

この画廊は，フォトリアリズム作品のコレクションを行っている画廊として有名らしい。異様なまでにリアルな作品の数々にただ驚くばかりだ。

http://www.greatamericanpinup.com/estes/

http://www.meiselgallery.com/tb/

一般的なレベルで言うところの「写実的な描写」と，これらの「写真と見分けがつかないほどリアルな描写」の間には，一体どんな差が存在するのだろうか。それを考察することが，フォトリアル CG を追求する上で重要なポイントとなるのかもしれない。

それと，ちょっと面白かったのが "Motion Studies" の講義コースだ。

http://graphics.stanford.edu/courses/cs448b-01-fall/

手描きベースでのアニメーション制作を実際に体験することにより，「動き」の表現の原理について習得しよう，という内容のものだ。これをバリバリの工学系の生徒にやらせようってのは，ちょっと面白いなと思った。

permalink