2005-08-01
並列プログラミングの難しさを物語る一例として "Double-Checked Locking" というパターン（"DCLP" と略される）を挙げることができる。これは Singleton パターンの実装において，インスタンスを生成する際に二重のチェックを行うことによって安全性を確保しようというものだ。しかし実際には，このパターンには破綻があることが広く知られている ... more
2005-08-02
これまでに記した以外にも，並列プログラミングを行う際に注意すべき点は多く存在する。自分も経験の浅い分野であるだけに，未だ分からない点も多い ... more
2005-08-03
今週一杯は夏休み。今回の夏休みは有給を使っての長期のリフレッシュ休暇を目論んでいたのだけれど，仕事の方が中途半端に入ってしまい（多忙ではないが休めない程度），結局，会社の規定通りの夏休みに収まりそうな展開となっている。
夏休みの前半は，忙しくてなかなか手のつけられなかった部屋の掃除や買い物などに費やした。捨てられずに部屋の片隅に放置されていた PC や家電をまとめて処理したおかげで，部屋が少し広くなったような気がする。あとは，洗濯機が軽く水漏れを起こしているようなので，今のうちになんとかしておかないといけない……。
PC の DVD/CD ドライブが CD だけ認識しなくなってしまった。 DVD は何の問題も無く読むことができるのだけれど， CD を入れるとちょっと反応しただけで諦めてしまう。これでは CD を買っても iPod へのインポートができなくなってしまうし，せっかく買った Battlefield 2 をプレイすることもできなくなってしまう……。
これを機会に PC の買い替えも検討してみたものの，今の時期に買い換えるメリットがあまり見当たらなかったので止めておいた。唯一食指が動いたのは IBM の ThinkCentre ultra small で，これが DVI 出力に対応していれば思わず買ってしまっていたかもしれない。やはりアナログでの LCD 接続にはどうにも抵抗感がある。
結局，ドライブの換装だけで済ますことにした。最寄の電器屋で売れ残っていた適当なドライブを購入して換装作業を行う。こういう場合は換装のついでにグレードアップを行うものなのだけれど，今回は何のグレードアップもしていない（もしかしたらグレードダウンさえしているかもしれない）ので，単に面倒な作業を強いられただけのように感じられる。
サーバの移転作業は未だ完了していない。今は，ようやくドメインレジストラの情報が書き換わったところのようだ。これから DNS を切り替えて，それが浸透した後に前サーバの契約を打ち切れば移転終了となる。今回，最も時間がかかったのはレジストラの移行作業だった。結局，ホスティング業者が行っているのはドメインの再販であり，実際の管理は国外のレジストラが行っているため，そこでのやりとりに時間をかけられてしまうと，どうしても遅延が発生してしまうということのようだ。
2005-08-06
夏休みの中盤は帰省して実家で過ごしていた。帰省となると新幹線やら飛行機やらの手配で大変な人もいるけれど，自分は電車１時間で済む距離なので，なんてことはない。ふらりと帰って，ふらりと戻ってきた。
帰省している間に，とうとう日本でも iTunes Music Store が開始された。さっそくアカウントを作成してサービスを体験してみた。
残念ながら自分のお気に入りのミュージシャンはことごとく取り扱い対象外になっているようだったので，ちょっと古めのところからオリジナル・ラヴの曲を幾つか選んでみた。 iTunes のブラウザを使って曲をサーチし，見つかった曲を試聴してみて，ＯＫそうならばボタンクリックで即購入。そうしたら，もうすぐに iPod で聴けるようになっている。これはいい感じだ……。特に，どんな曲でもとりあえず試聴することができるのは有難い。そのおかげで，今まで知らなかったようなミュージシャンにも気軽に挑戦してみることができる。このような利便性は，店頭に足を運んで CD を購入するよりも明らかに優れていると感じられる点だ。
あとは曲数の充実を願うのみだ。対応レーベルの拡大が望まれるのはもちろんのこと，現状で対応しているレーベルにしてみても一部分の曲しか扱うことができていないようなので，この中でも更なる充実が望まれるのではないかと思う。
今年の始め頃から，忙しさを紛らわすために，わりと頻繁に CD を購入していた時期があった。最近よく聴いているのは，キリンジ， capsule, HARCO, テイトウワ，月刊プロボーラー，等々……選択に脈絡はあまり無い。あとは，最近，電気グルーヴが何気に復活していたので，これも早速購入してみた。まあ，何と言うか，いろんな意味で期待通りで良かったと思う……。
新サーバへの切り替えも帰省中に完了していた模様だ。今はもう既に，ほぼ全域から新サーバが見えるようになっているのではないかと思う。あとは旧サーバの解約を残すのみだ。
2005-08-07
「アナログでの LCD 接続にはどうにも抵抗感がある」云々と書いていて思い出したのだけれど，以前 LCD の動作の仕組みに関して調べた際に，特許流通促進事業 (NCIPI) の特許流通支援チャートの中にあった「アクティブマトリクス液晶駆動技術」が簡潔で分かりやすく，参考になったという記憶がある。
まず興味深かったのが「線順次駆動方式」の存在だ。アクティブマトリクス液晶の駆動方式には， CRT のように「点」で画素を更新していく「点順次駆動方式」と，走査線毎に画素の一斉更新を行う「線順次駆動方式」の２種類が存在する。そして現在は，各画素への書き込み時間を長く設定することができるという理由から，線順次駆動方式の方が広く用いられているということだ。
この「点」と「線」の差は微小ではあるものの，表示装置としての性質を変えうる要素であるだけに，非常に興味深く感じられた。例えばレンダリングレイテンシの問題などは，この方式の如何によって異なってくると考えられる。
もうひとつ興味深かったのは，焼き付きやフリッカーを防止するために用いられている「フレーム反転技術」の存在だ。
液晶表示装置においては，長時間の直流電圧の印加から生じる「焼き付き」や，スイッチング回路の特性から生じるフリッカーなどを防ぐために，一定時間ごとに電圧を反転させるという「フレーム反転技術」が一般的に用いられている。ただし，画面中の全画素に対して一斉に反転を行ってしまうとかえってフリッカーが目立ってしまうため，ライン毎に反転を行う方式（ライン反転駆動）や，格子状に反転を行う方式（ドット反転駆動）が用いられている。
ドット反転駆動方式を用いることによって，通常は十分にフリッカーを緩和することが可能であるものの，反転に用いられている格子のパターンと全く同じ画像を画面上に表示させると，その効果が打ち消され，本来生じているフリッカーが見えてきてしまう。この様子は William Andrew Steer 氏の "LCD monitor technology and tests" のページで確認することができる。
自分が自宅で使用している LCD (Sharp LL-T1620) では "Line-paired RGB sub-pixel dot-inversio (offset)" で最も激しいフリッカーを確認することができた。本当はこんなにチラついているのか……と軽いショックを覚えるほどのフリッカーだ。ちなみに，このパターンは各メーカーが保有する特許と関連があるものと思われる。メーカー毎に固有のパターンが反応するのではないかと思う。
また，上記のテストページにおいては，フリッカーの他にクロストーク現象も確認することができる。例えば右クリックでポップアップメニューなどを呼び出してみると，その縦ないしは横方向に帯状の「ムラ」が発生する。これも普段はフレーム反転技術のおかげで緩和されているだけで，実際には常に生じている現象であるということだ。
もうひとつ，これは先述の文書には載っていない技術なのだけれど，最近の LCD では残像を緩和するために，通常のフレームの間に特殊なフレームを挿入することがある。これらの技術に関しては，ソウル国立大学・半導体装置研究所のレクチャー資料が簡潔にまとめられていて参考になる。
ここで重要なのは， LCD 特有の「残像ボケ」は，液晶の応答速度の問題であると共に，画素が常時点灯していることも要因になっているということだ。 CRT 等の表示装置では，人間の視覚に備わっているローパスフィルタ的な特性を利用して，瞬間的な点灯（インパルス）を連続した映像に見せるという技術を実現している。ところが通常の LCD は各画素が常時点灯（ホールド）しているため，フレームの間ずっと静止映像が維持されることになる。これを人間の視覚に通すと，残像として感じられるようなボケを生じてしまうということだ。
この現象を緩和するために，最近の LCD にはフレーム間に黒画面を挿入するものがある（擬似インパルス方式）。更に最近になると，この考え方をもう一歩前進させて，黒画面ではなく動きを補間したフレームを生成・挿入することによって，ホールド効果を解消しようというものもあるようだ。単なる黒画面の挿入はフリッカーを生じると考えられるため，補間フレームの挿入の方が理想的な解決法ではあると思う。しかしその実現には，かなりのプロセッサ能力が必要とされるはずだ。何とも大胆な解決法だけれど，既に高級機には搭載されているとのことで驚かされる。
このように表示装置側で各種のフィルタリングがなされるようになると，映像を生成する側では最終的な出力の様子が予測しにくくなるという事情がある。ブラウン管の時代にもカラーフィルタリング程度の技術が搭載されることはあったものの，動きの補間などというレベルの処理が入ることは無かった。もはや「点が走査線上を左上から右下に向かって移動して，水平帰線と垂直帰線があって……」というような古来の単純なメカニズムでは量ることのできない世界が広がりつつある。
先日，画像の「チラつき」を意図的に表現する目的で点滅効果を作成したところ，これを LCD 上に表示させた際に，表示装置側のフィルタリングと点滅効果が相殺されてしまい，単なる半透明効果になってしまうという事態があった。このように，一般に表示装置側で行われている各種のフィルタリングは自然画像を前提としたものであるために，リアルタイム CG のように離散的な映像には適さない物も少なからず存在する。その影響を事前に察知するためにも，様々な表示装置を揃えたテスト環境を構築しておくことが望まれる。
2005-08-09
僕と同じくらいの世代の人たちならば，フロンガスにはオゾン層を破壊する効果があることを誰もが知っているはずだ。フロンの使用は全廃されて久しい1から，もしかしたら若い世代の人たちにとっては印象が薄いかもしれない。それでも，古いエアコンなんかの廃棄の際にはフロンの回収が義務付けられているし，オゾンホールの問題などは今もなお人々に影響を与え続けているわけだから，なんとなく話ぐらいは聞いたことがあるんじゃないかと思う。
このフロンによるオゾン層の破壊は有名な話だけれど，その対策が大幅に遅れた理由のひとつとして，あるソフトウェアの欠陥があったということは，案外知られていないかもしれない。
フロンの代表格であるクロロフルオロカーボン (Chlorofluorocarbons: CFC) は， 1928 年にアメリカの技術者 Thomas Midgley によって開発された2 3。この CFC は，それまで冷媒として使われていたアンモニアや二酸化硫黄の代替物として開発されたものだった。これらの冷媒は人体に有害であるのに対して， CFC は無害であり，なおかつ化学的に安定しており，しかも沸点が低いという，極めて良好な性質を備えている。余談だけれど， Midgley はこれらの性質を誇示するために， CFC を自ら吸って，その吐く息でロウソクの炎を消すという芸当をやってのけたそうだ。
それから 60 年もの間， CFC を始めとするハロン類 ― いわゆる「フロン」は，冷却装置の冷媒やスプレーの噴射剤，溶剤や発泡剤など，実に様々な用途に使われていくことになる。
最初にフロンの持つ欠点に目を向けられたのは 1970 年代の初めのことだった。とは言っても，まだこの頃はフロンの持つオゾンの分解効果には気付かれておらず，まずはフロンの持つ強力な温室効果が槍玉に上げられた。その効率は二酸化炭素の数百倍から数千倍にも及ぶ4と言うから，それなりに注目を集めたことだろうと思う。でもこの頃はまだ，規制をかけてまでどうにかしようという動きにはならなかったようだ。
フロンの持つオゾンの分解効果を最初に指摘したのは，カリフォルニア大学の２人の研究者 ― Frank Sherwood Rowland と Mario J. Molina だった。この２人は 1974 年に Nature 誌にある論文を発表する。その内容とは，フロンにはオゾン分子を効率的に分解する触媒としての働きがあるということを指摘するものだった5。ちなみに氏らは後の 1995 年に，その発見の功績によってノーベル化学賞を受賞することになる。
この論文は世間の注目を十分に集めたようで，まもなくフロンの使用を規制しようという動きが欧米において活発になってくる6。しかしまだこの段階においては，この理論はあくまでも仮説に過ぎなかったので，産業界からの反発もだいぶあったようだ。そこで 1975 年には，アメリカの議会から NASA に対して，上層大気中で発生している現象を観察するための計画の立案が要請されている。そして，それから少し経った 1978 年に，オゾン層の状態を観察するための装置 "TOMS" (Total Ozone Mapping Spectrometer) を搭載した人工衛星 Nimbus-7 が打ち上げられることになる7。
わざわざ人工衛星まで打ち上げているんだから相当な気合の入れようだと思うのだけれど，なぜかその後もオゾン層破壊の事実は見過ごされ続けることになる。一方でその頃の科学者の予想と言えば，まあ数十年後にはオゾン層の数パーセントが破壊されちゃうかもしれないね……なんていう気楽なものだったらしい。
しかしそんなお気楽ムードも，ある論文をきっかけとして一気に打ち破られることになる。 1985 年に英国南極観測局の Joseph Farman, Brian Gardiner, Jonathan Shanklin の３人が Nature 誌に発表した論文は，南極は Halley Bay の観測地点において 1975 年から 1985 年の間にオゾン量が半分近くにまで低下していたという驚くべき観測結果を明らかにしたものだった8 9 10。それまでは数十年かけてせいぜい数パーセントの減少と予測されていたものが，実際にはたった 10 年の間に半分も削られていたというんだから，これは相当にショッキングな出来事であったに違いない。
この発表は世間に強烈な衝撃を与えたようで，それまでは緩やかな規制で済まそうとされていたものが，全先進国において 2000 年までにフロンの使用を全廃するという非常に厳しい規制（モントリオール議定書1）へと切り替えられることになる。それからのフロンの末路や，オゾンホールの存在が世間に知れ渡る過程などは，僕らに馴染の深いところだ。
ここで不思議に思うのが， Farman らの発表よりも 7 年も前に調査用の人工衛星が打ち上げられていたにも係わらず，なぜ地上の観測所が指摘するまでオゾンホールの存在が見過ごされていたのかということだ。各種の記事11を参照してみると， TOMS から得られた観測結果を処理するためのソフトウェアは，予想値を大幅に外れたデータをエラーとして無視するように設計されていたと解説されている。つまり，装置自体はオゾンホールを確かに検出していたにも係わらず，ソフトウェア側の誤った設計が，その事実を覆い隠してしまっていたということだ。
過去にもソフトウェアの誤った設計が悲劇を引き起こしてしまった例は数多く存在するものの，オゾン層の破壊を数年間も見過ごすというような，地球規模の影響を人々に与えてしまった例は，他に聞いたことがない。
僕らが普段ソフトウェアを開発する際に扱っている問題は，オゾン層の破壊ほど重大ではないかもしれないし， TOMS や Nimbus-7 ほど高価なものでもないかもしれない。でも，想定外のデータを単に除外するというような無思慮な設計が，地球規模の失態を引き起こしてしまったことがあるという事実は，ひとつの戒めとして覚えておいても損は無いだろうと思う。
2005-08-10
少し前に EDIROL の USB オーディオインタフェース UA-20X を購入した。概ね機能には満足しているのだけれど，ひとつだけ気になる点がある。 USB の接続状態を表すインジケーターに裸の青色 LED が使用されているのだ。眩しくてしょうがない！
ここ数年の間，電気製品における青色 LED の使用率は増加する一方のように感じられる。僕が自宅で使用している PC の電源ランプも青色 LED だった。これもやはり常にやたらと眩しいし，しかもサスペンド中は点滅するものだから，寝るときなど気になってしょうがない。
Design Continuum 社の記事によれば，青色 LED の放つ光が眩しく感じられるのには幾つかの理由がある。まず最初に挙げられるのは，そもそも青色 LED は古典的な赤・緑色 LED と比較して非常に輝度が高いという点だ。これは比較する LED の種類にもよるだろうけども，記事によればおよそ 20 倍の差があるとされている。
次に挙げられるのは，人間の眼の性質によるものだ。人間の眼のレンズは赤色や緑色の光点に対しては正確に焦点が合うものの，青色の光点に対しては網膜よりも少し前に焦点が合ってしまう。さらに，青色光は波長が短いために眼球内で散乱現象を起こしやすい。このような性質のために，青色光は目障りな暈（ハロー）を生じやすくなっている。
また，人間の眼は，暗がりの中では青色に反応しやすくなるという性質がある（プルキンエ効果）。そのために，例えば薄暗い部屋の中でビデオを観るときとか，あるいは部屋を暗くして寝るときなど，青色 LED の光が余計目障りに感じられるということだ。さらにタチの悪いことに，いくつかの研究によれば，たとえ弱い光であっても青色光は網膜内の受容器官を刺激し，メラトニン（睡眠に関連のあるホルモン）の分泌を抑制してしまう効果があると報告されている。
青色 LED の放つ光は，たしかにクールでかっこいいけれど，最近の濫用ぶりにはさすがに安直な印象を禁じえない。また，今でこそ青色 LED は新鮮さを保っているものの，もうしばらくすれば皆慣れてしまい，ただ眩しいだけの存在になってしまうかもしれない。何にせよ，控え目かつ効果的な使用を心掛けて欲しいものだと思う。
2005-08-15
先日は Battlefield 2 をひたすらにやりこんでいた。巷の評判に偽りは無く，やはり非常に面白い。もはや昼夜を問わずプレイし続けるような状態だったのだけれど，さすがにそろそろハマり具合がヤバくなってきたと感じられたので，先程思い切って PC からアンインストールしてしまった。この手のゲームはいつもそうなのだけれど，飽きるまでプレイすると相当な時間を吸い取られてしまうので，惰性になりそうなところで自主的にアンインストールするようにしている。 BF2 に関しては，今がそのタイミングであると感じられたわけだ。
BF2 をプレイしていてまず感じられたのは，初期のバージョンから既に調整の行き届いた状態にあるということだ。初代 BF や前作 BFV においては，兵科による性能の優劣や，勢力による装備の優劣，特定の兵器が持つ圧倒的な強さや，マップによる展開の定型化など，各種の調整に関して腑に落ちない点が少なからず見受けられた。ところが今作 BF2 においては，それらの問題が初期バージョンにおいて既に解決されていると感じられる。各兵科には明確な役割の違いがあり，勢力による装備の優劣はほぼ無く，各兵器には単独では補うことのできない弱点が存在する。特に，実世界の設定を正確に反映するならば格段の差が生じるであろう勢力（アメリカ／中東）による兵器性能の違いを，バランスを保つために敢えて平均化してある辺りには，前作 BFV の反省があるのではないかと感じられる（前作 BFV では勢力毎の特色を強調するあまりにバランスが破綻してしまっている感があった）。
もうひとつの注目すべき点は，大人数の組織的な行動を可能とする「部隊」と「司令官」のシステムだ。
これまでの BF シリーズにおいては各プレイヤーの単独行動が基本とされていたのに対して，今作では「部隊」 (squad) と呼ばれる集団行動のための仕組みが導入されている。各プレイヤーは任意の部隊に参加することができ（参加しないことも可能），部隊に参加した場合は部隊長の指示に従って集団行動をとることになる。部隊内ではボイスチャットを使った綿密な連携が可能であるほか，死んでしまった場合にも部隊長の傍から復活することができるようになっている。これを利用した波状攻撃を仕掛けることが，今作における基本戦略のひとつとなっている。
もうひとつのシステム「司令官」 (commander) は，全部隊を統括する役割を担う存在だ。偵察衛星や UAV （無人偵察機）を駆使して敵の様子を探りつつ，各部隊に指令を出すことによって戦闘を有利な方向に運ばなくてはならない。砲撃や物資投下などによって味方の行動を直接に応援することも可能だ。これら司令官の特殊機能は非常に強力なものであり，これらを如何に活用するかという戦略の中に勝利の鍵があると言っても過言ではない。ただし，これらの機能は拠点に存在する施設類を破壊されてしまうと使えなくなってしまうため，味方拠点の防衛および敵拠点への攻撃を行うことが非常に重要な役割を帯びることになる。これまでの BF の基本戦略に加えて，この「司令官」の存在と拠点を巡る攻防とが，今までに無かった戦略的要素を生み出す結果となっている。
これらの組織行動を補助するシステムは，今までの BF シリーズにあった「自由奔放なプレイ感」を薄めてしまっているという視点から観ると，必ずしもプラスばかりではないかもしれない。無能な部隊長や司令官は当然の如く批判の対象となるから，それを担うこと自体が相当なプレッシャーになることは間違い無い（司令官は投票でクビにすることもできる）。しかし，最大 64 人という大人数のプレイヤーが組織的な戦略によって攻防を繰り広げるという新たなプレイ感は，その欠点を十分に補うほど魅力的なものであると感じられる。
最後に，グラフィックに関しては，自分では評価することができない。自宅のマシンではグラフィック関連のオプションを最低レベルにまで下げなければまともに動作してくれないためだ。ただ，概して戦闘の迫力は増していると感じられる。特に，砲撃や爆撃によって生じる凄まじい轟音と爆煙は，その絶大な効果に相応しいほどの迫力を持っており，食らった側としてみれば絶望感すら覚える。それで，砲弾の音が聞こえた途端に，みんな反射的に屋根のあるところに向かって走り出すのだけれど，傍から観るとその様は滑稽ですらある……。
2005-08-16
ここ数年の間，グラフィック関連のハードウェアに触れる機会が極端に少なくなっている。そのためか，久しぶりに最新事情を調べてみると，その性能の向上に新鮮な驚きを覚えることがある。最近それを切に感じたのが， Fábio Policarpo 氏の Relief Mapping だった。
Relief Mapping （以下「レリーフマッピング」）は，バンプマッピングや法線マッピングのような凹凸表現の手法を更に進化させたものだ。これら従来の手法では，フラグメントのシェーディングを行う際に，画像化された凹凸情報を基に輝度を変化させることによって，擬似的な立体感を作り出していた。ただし，これはあくまでも擬似的な表現なので，面を水平に近い角度から覗いた場合などに顕著な違和感が生じてしまう。これに対してレリーフマッピングでは，フラグメントのシェーディングを行う際に，ハイトマップに対するレイキャスティングを行うことによって，正確な立体感の表現を可能としている。
動作原理の詳細については，氏のノート "Relief Mapping in a Pixel Shader using Binary Search" が非常に分かりやすくて参考になる。
実際のレリーフマッピングの処理は，従来の手法と比較すると相当に複雑なものとなる。上の模式図にある面上の点 A のシェーディングを行う際に，視線とハイトマップとの交差判定を行い，凹凸面上の対応する交点 P を求める。このときの交差判定には，なんと二分検索（バイナリサーチ）を用いているというから驚きだ。たしかに，点 A, B 間を段階的に分割していけば，点 P を近似的に求めることができるはずだ。しかし，このような処理はピクセルシェーダーとしては非常に重い部類のものであり，現に氏の組んだシェーダーでは 1 フラグメントあたり約 200 命令を消費すると解説されている。
また，上の模式図にもある通り，光源からも同様の処理を行うようにすれば，光源からの光が当たっているかどうかの判定を行うことができる。つまり，セルフシャドウを表現することができるわけだ。もちろん，これを行えば処理量が倍に増えるわけで， 1 フラグメントあたり約 400 命令という超重量級シェーダーが出来上がってしまう……が，それでもリアルタイムに動かすことは可能であるというのだから驚かされる。
更に印象的なことに，氏はこのレリーフマッピングを Doom3 の Mod として組み込むというデモンストレーションを行っている。その映像を覗いてみると，低解像度ながらもそこそこの速度で動いていることが分かる。立体感の違いについても実感することができるはずだ。
結局のところ，このレリーフマッピングの手法は，現段階においてはあまり実用的ではないと評価することができると思う。 HD 映像フォーマットへの移行が盛んに叫ばれている今，重いフラグメント処理は全体のボトルネックになる危険性を秘めているためだ。 Doom3 エンジンのような特殊な事情（ジオメトリ処理のコストが他よりも高い）が無い限りは，ある程度の凹凸はジオメトリで処理してしまった方が懸命だろう。ともかく，このレリーフマッピングの手法は，ピクセルシェーダーの機能性の高さを誇示するデモとしては，非常に面白いものであると思う。
2005-08-17
Banner & Witcoff 社の弁護士 Ross Dannenberg 氏の運営するサイト "The Patent Arcade" は，ビデオゲームの知財保護に関連する話題を取り扱っているサイトだ。今のところコンテンツは過去の判例の紹介記事を中心にまとめられており，ビデオゲームの知財保護の歴史を知るうえで参考になる。
ちなみに，国内の事例に関しては夏井高人氏のページや井上雅人氏のページなどが充実しており参考になる。いずれのページも基本的にはコンピュータ・ソフトウェアに関連する様々な事例を扱っており，その中にはかなりの割合でビデオゲームに関連する事例が含まれている。
これらの事例は大雑把に言って，特許の侵害に対する訴えと，著作権の侵害に対する訴えから構成されている。ただし，ビデオゲームの場合はその両面から知財の保護が行われていることが多く，それらを単純に二分することはできない。例えば，ビデオゲームのプラットフォームにおけるライセンス供与の仕組みなどは，ライセンス品の判定に特定の特許技術や著作物を用いるという複合的な手法によって保護されており，それを掻い潜ろうとすれば複雑な話に発展する恐れがある。
これらの事例の中には，明らかな侵害を行っている事例や，言いがかりに近い事例なども含まれるものの，やはり最も多いのは，各々の微妙な利害の衝突から生じる訴えの事例だ。このような事例は自分のような素人には判断が難しく，最終的に下された判決が現状における結論であると受け入れるほか無い。
ともかく，それらを総じて言えるのは，今日各々が得ている利益は，これらの判例を作り上げてきた先人たちの努力の上に成り立っているということだ。判例の内容から伝わってくるのは，難しい法律の話ばかりではなく，各々の利益のバランスを取るべく行われた数々の葛藤の歴史だ。その歴史を知ることは，自分たちの日々の活動を成立させている「根拠」の理解へと繋がるのではないかと思う。
2005-08-21
このところ，忙しい間には出来なかったことに色々と手を出してみている。 Battlefield 2 はそれなりに満足するまでプレイすることができたので，次は DSI Evolver を飽きるまで触ってみようと思っている。
Evolver は Dave Smith Instruments 社が開発・販売を行っているシンセサイザーだ。同社の創立者である Dave Smith 氏は 70 年代から数々のシンセサイザーの開発に係わっている「超」ベテランであり，名機 SCI Prophet-5 や KORG Wavestation 等の開発を手掛けたことで知られている。
この Evolver には，その Dave Smith 氏の設計思想が色濃く反映されている。様々な面で「いまどきのシンセサイザー」とはちょっと違うユニークな設計だ。そのような所に惹かれて，仕事が終わった気晴らしも兼ねて，思い切って購入してみた次第だ。
Evolver の仕様の中でも最も目を引くのは，アナログ＋デジタルの２方式から構成されたオシレーター群だ。オーソドックスなアナログオシレーター（恐らく DCO）を２基，自由度の高いデジタルオシレーターを２基，計４基のオシレーターを搭載している。 Dave Smith 氏曰く，アナログとデジタルにはそれぞれ長点があり，どちらが優れているということは無い ― とのことだ。だから両方とも積んじゃえということなのだろうけども……他にデジ・アナ２方式のオシレーターを同時に搭載したシンセサイザーというのは聞いたことが無い。少なくとも 2000 年代に発売されたシンセサイザーの中にそのようなものは，この Evolver 以外に存在しないだろうと思う。
この２方式のオシレーターには，それぞれ異なった機能が与えられている。アナログの方はごく基本的な機能のみで構成されているため，音色の基礎となる部分を任せるのが無難な使い方だ。デジタルの方は変調系の機能が充実しているため，音色に変化を与えるのに都合が良い。有り体に言えば，アナログは普通の音を出すのに使えて，デジタルはクセのある音を出すのに使える感じだ。
オシレーター以外の仕様に関しては，比較的無難な構成でありながらも，音を変調させるための機能が充実していると感じられる。例えば，音にクセを与えるフィードバック回路や，空間を表現する３基のディレイ回路，音に歪みを与えるディストーション回路や，謎の "Hack" パラメータ，等々……。昨今の DSP シンセならともかくとして，この手の半アナログ・モノフォニックシンセにしては少し珍しいと感じられるほど変調機能が充実している（ちなみに "Hack" パラメータは D/A 変換時の精度を劣化させる機能であると思われる）。
Evolver はモノフォニック（単音）シンセなので，これ１台で音楽制作を完結させることはできない。自分の場合は KORG Electribe MX との組み合わせで遊んでみている。なんだかんだ言って Electribe MX は気に入っていて，未だに飽きることなく使っている。とても使い勝手が良いのだけれど，基本的に薄っぺらい音しか出ないのが弱点だ。そこで，音を厚くしたい所に Evolver を投入するというような使い方を試してみている。
個人的に気に入っているのはベースラインに Evolver を使用するというスタイルだ。さすがに４基もオシレーターがあるおかげで味のある音が出てくれる。まだ練習中だけれど，徐々に使い方が分かってきたような気がする。
これはもう暫くの間遊べそうだ。でも，今度はサンプラーが欲しくなってきてしまった。どうしよう……。
ベースラインと言えば，映像作家 Nate Harrison 氏のビデオ作品 "Bassline Baseline" が面白かった。これは，ベースラインシンセの元祖である Roland TB-303 の歴史を解説したエッセイ作品だ。発売当初の 80 年代から，後のエレクトロニック・ミュージックのスタンダードになるまでの変遷を，その時々の代表的な作品を交えつつ解説している。発売当初と現在との間で，これほどまでに使用法が変化したシンセサイザーも珍しいだろうと思う。
ちなみに，同氏の別の作品 "Can I get Amen?" も面白い。こちらはドラムループのサンプリング素材として有名な "Amen Break" を扱った作品だ。前半部分では，単なるＢ面曲の間奏に過ぎなかった Amen Break が，ヒップホップやブレイクビーツ，果てはドラムンベースの基本素材にまで発展していく過程を解説している。そして後半部分では，この素材の著作権のあり方について氏の考察を展開している。ただし残念ながら，後半部分は厳密な部分が聞き取れなくてよく分からなかった。せめてトランスクリプトがあれば……。
2005-08-22
"The Patent Arcade" を読んでいて特に興味を引かれた話題がひとつある。 Nintendo of America 社と Atari Games Corp. (Tengen) 社との間で繰り広げられた "10NES" プログラムのコピーに関する係争だ(Fed. Cir. 1992/N.D. Cal. 1993)。
この件に関して調べるまで知らなかったのだけれど，日本国内で販売されていた「ファミコン」には海賊版対策が施されていなかった。これは，ファミコン向けの非ライセンス品（いわゆる「海賊版」）を製造するのに技術的障壁がほぼ存在しないことを意味する。このような状況は NES (Nintendo Entertainment System) として北米へと進出する際に対策が試みられることになる。 "10NES" とはこの時に組み込まれた海賊版対策の機構を総称したものだ。
資料によれば， 10NES とはハッシュ関数を利用した認証システムの一種であったようだ。ゲーム機本体が起動されると，本体側に内蔵されている「マスター」チップとカートリッジ側に搭載されている「スレーブ」チップとの間で数列の交換が行われる。その検証に失敗すると，本体に対してリセット信号が送られソフトウェアの起動が阻止されるようになっている。そのため，ソフトウェアパブリッシャーは 10NES チップの供給を受けなければプラットフォーム上で正常に動作するカートリッジを製造することができない。このような機構を用意することによって，技術的な側面からライセンス供与の仕組みを保護することが可能となる。
しかし，こうした技術的障壁を乗り越えようとする人々は常に存在するもので，この 10NES も攻撃の対象として晒されることになる。当時，最も手軽な手法として広く用いられていたのは， 10NES チップに対して逆電圧パルスを与えることによって誤動作を引き起こさせるというものであったようだ。
当時の Tengen 社（Atari 社の NES 向けブランド）は，もう少し巧妙な手法を利用してこの 10NES を破ろうとする。その手法とは，「著作権侵害の訴訟のため」と偽って 10NES の資料を著作権事務局 (U.S. Copyright Office) から不正に入手するというものだった。こうして 10NES の全容を把握することのできた Tengen 社は， 10NES と完全な互換性を持つデバイスである "Rabbit" チップを開発することに成功する。
当然のごとく， Rabbit チップの一件は民事訴訟へと発展することになる。この裁判で焦点となったのは， 10NES に関連する著作権の侵害と，同じく 10NES 関連する特許の侵害の二点だ。
まず原告側が主張したのは， 10NES チップ間で交換されるデータに認められるべき著作権の侵害だった。原告側の主張によれば，ここで交換されるデータ（"data songs" と表されている）は著作権によって保護される「表現」の一種であるとされている。しかし，地裁はこの訴えを退けている。データを扱うプログラムに著作権は認められても，そこで扱われるデータには著作権は存在しない ― 加えて，ゲームが起動するまでの「沈黙の期間」においてやり取りされるデータを著作権によって保護することはできないという判断だった。
次に焦点となったのは， 10NES プログラム自体に認められるべき著作権の侵害だった。被告側は，著作権では保護されない要素である「機能性」のみを模倣したものであり，著作権侵害には相当しないとの抗弁を展開している。しかしその後の審査により Rabbit プログラムは本来の目的である「互換性の維持」に必要とされる以上の要素を模倣していることが判明する。これは，機能の模倣ではなくプログラム自体の模倣を行っていることを意味しており，現状の互換性だけでなく将来的な互換性までもが保証されてしまうことを意味する。地裁は，このような模倣は原告側の優位性を失わせてしまうものであるとし，被告側の抗弁を退けている。
しかしここで重要なのは，現状での互換性を維持するために必要とされる模倣に関しては否定されていないということだ。 Tengen 社は資料の不正入手を行っていたためにフェア・ユースの主張が困難となっていたものの，純粋なリバースエンジニアリングによって現状での互換性を実現したものであれば合法的に受け入れられる可能性が残されていた。この辺りが 10NES のような初期のライセンス保護機構に見られる弱点であり，後のプラットフォームにおいては別のアプローチからこの弱点が補われることになる。
最後に焦点となったのは， 10NES に関連する特許の侵害だった。原告側は U.S. Patent No. 4,799,635 （「635 特許」）を主軸として訴えを展開することになる。これに対し被告側は， 635 特許の持つ自明性と， U.S. Patent No. 4,736,419 との二重特許を指摘することにより 635 特許の無効性を主張した。被告側の主張は，一旦は地裁において認められたものの，後に陪審によって棄却されてしまった。結果的に特許侵害の訴えは受け入れられることになったものの，原告側にしてみれば非常に危うい展開であったと推察することができる。
2005-08-24
Jeff Atwood 氏のブログ "Coding Horror" は，最近よく読んでいる Microsoft 開発者ブログのひとつだ。ソフトウェア開発に関連する日々の考察や雑談などを随筆的に綴っている。世代的に似通ったものを感じさせられることが多いのも面白いところだと思う。
「ハック」 (hack) という単語には様々な意味が含まれる。特に工学的な話題においては，「普通ではない方法で物事を解決する行為」という意味で用いられることが多いのではないかと思う。例えば Microsoft が Windows の下位互換性を保つために数多くのハックを行っていることはよく知られている。また，時には Windows のバグを補うために Intel がハックをやってのけることもある。先日 Jeff Atwood 氏が触れていた CPUID のハックなどは，まさにその一例として挙げることのできる話だ。
CPUID とは Pentium 以降のプロセッサに実装されている命令の一種であり，ソフトウェア側からプロセッサの判別を行うために用いられる。 CPUID 命令を通して取得することのできる情報としては，プロセッサのファミリー番号，モデル番号，ベンダー名，拡張機能の有無，等々が用意されている。
件の記事において問題とされているのは， CPUID 命令によって得られる「ファミリー番号」の値についてだ。この値には Pentium ファミリーであれば "5" が， Pentium Pro ファミリーであれば "6" が設定されるようになっている。そのまま順当に行けば Pentium 4 には "7" が与えられそうなものなのだけれど，その前に開発中の Itanium ファミリーが "7" を予約していたため，後発の Pentium 4 には "8" が与えられることになった。
ところが，ここで思わぬ問題が発生する。詳しい理由はよく分からないのだけれど，何故か Windows NT 4.0 が「ファミリー番号」を下位 3 ビットしか見ていないことが判明する。これは， Pentium Pro までは上限が "6" であったために問題にならなかったものの，ファミリー番号 "8" のプロセッサが登場した途端に破綻を引き起こしてしまうことになる。なにしろ下位 3 ビットしか見えないため，ファミリー番号が "0" であると誤認識されてしまうわけだ。
Pentium 4 が完成を迎えた 2000 年当時， Windows NT 4.0 は主流の一端を担っていた（まだ Windows 2000 は登場したばかりだ）。 Intel にしてみれば，この問題を残したまま Pentium 4 を市場に送り出すことは得策でない。そこで Intel が採った行動とは， Pentium 4 のファミリー番号を，一気に "15" まで引き上げてしまうことだった。
ファミリー番号を "15" にしてしまえば，下位 3 ビットしか見ていない Windows NT 4.0 においても，ファミリー番号 "7" のプロセッサとして認識させることが可能となる。根本的な解決にはなってないうえに，ひどく不自然なナンバリングになってしまうものの，最も穏便な形で問題を解決することができる。まさに「ハック」的解決法だ。
こうした「ハック」は，通常の感覚からすれば汚らしいものではあるものの，実用的な見地に立てば必要とされる行為のひとつであると感じられる。現場においては時として審美的な感覚よりも実践的な思考を求められることがある。やむを得ず手を汚すことになってしまったとしても，悩み抜いた末の結論であれば，それを悔いたり恥じたりする必要は無いと思う。そうした行為には職人的な気高さすら感じられることがある。
2005-08-25
もうひとつ， Microsoft 開発者のブログと言えば， Larry Osterman 氏のブログをよく読んでいる。 Osterman 氏は Windows Media チームのエンジニアであると同時に， Microsoft 勤務歴 20 年を誇るベテラン開発者としても知られている。ブログの内容としては， Windows プログラミングないしは一般的なソフトウェア開発に関連した技術的な話題が多いように感じられる。
ソフトウェア・コンポーネント間の相互関係を管理する際に重要となる考え方のひとつとして，「循環依存は避けなければならない」という決まり事がある（「非循環依存原則」 ― Acyclic Dependancies Principle: ADP として知られる）。しかし，コンポーネント群から循環依存を排除した状態を保ち続けるというのは意外と難しいもので，比較的小規模なプロジェクトにおいても，往々にして循環依存は発生してしまうものであると感じられる。
ましてや Windows のような超大規模プロジェクトともなれば，少しでも気を抜いた途端に循環依存が発生してしまうだろうし，それが深刻な問題へと発展してしまう危険性も非常に高いとみることができる。それが故に Windows 開発チーム内においては，コンポーネント同士が循環依存を持つことは原則として許されていない（ただし一部の例外を除く）。開発者達もその原則を忠実に守り続けている。それには特殊な技術が存在するわけではない。 Osterman 氏は不断の努力こそが重要であると説いている。
ただし，努力を払っているのは開発当事者だけではない。アーキテクチャ階層化チーム (architectural layering team) が常に監視の目を光らせているからこそ，循環依存を排除することができているのだろうと思う。
Osterman 氏の説明によれば， Windows の開発工程には幾つかの "quality gate" が用意されている。「アーキテクチャ階層化」は，それらの quality gate のひとつとして存在しているものだ。開発対象のコンポーネント内に階層化違反 (layering violation) が存在する限り，「アーキテクチャ階層化」の quality gate を通過することはできない。他にも quality gate は幾つか存在しており，それら全てを問題無く通過しないことには，コンポーネントを Windows の正式なブランチとしてチェックインすることは許されていないということだ。
件の記事において Osterman 氏は，最近新たに発生してしまった循環依存についての検討を行うために「階層化裁判所」 (layer court) へと赴いたことを話している。大抵の循環依存はメールのやりとりによって解決することが可能であるものの，稀に発生する難しい問題に関しては，階層化チームのオフィスを直接に訪ね，会話とホワイトボードによって密な打ち合わせを行わなくてはならない。
個人的には，こうしたソフトウェアの構造面の品質を守るために専門のチームが存在していることに感銘を受けた。また，そうした監視の下に開発を行っているからこそ，明快なアーキテクチャを保つことができているのだという事実は，ひとつの重要な事例として参考になるものであると思う。
2005-08-28
Yahoo! Movies で映画版 Doom の予告編の最新版が公開されている。
凶悪な敵モンスター，唸りを上げる銃器，不必要なまでに筋肉質な主人公（ロック様！），どこか垢抜けない古典的な SF 設定，等々……これでもかという程にメリケン臭の漂う「分かりやすい映画」なのだけれど，それはともかくとして，最も衝撃的なのは，劇中に一人称視点のシーンが存在するということだ。映画のカメラワークは三人称視点が普通なので，ここにいきなり一人称視点が持ち込まれると予想以上の新鮮さがある。あるいは違和感なのかもしれないが……。
向こうの人々にはどのように受け入れられているのだろう。 Joystiq 読者の反応は案外落ち着いているようだ。予告編の内容からも伝わってくるように，「ゲームの映画である」という点が強調されているのは面白い。中途半端に「普通の映画」を目指すよりも，原作のファンを確実に取り込もうという判断だろうかと思う。
[via Joystiq]
Andreas Muller 氏の "For All Seasons" は，インタラクティブ要素を備えたタイポグラフィー作品だ。東京 TDC の 2005 年 TDC 賞グランプリを受賞している。
四季にまつわる幼少の記憶を綴った文章が，ユーザーのクリックと同時にインタラクティブな要素へと変容していく。文字の配置だけでは表現することのできないことをインタラクティブ性によって補うというコンセプトが面白い。
Muller 氏の他の作品は www.hahakid.net から辿ることができる。
[via we make money not art]
頭の中で勝手に繰り返され耳から離れなくなってしまう音楽のことを英語で "earworm" と言う。語源はシンシナティ大学の James Kellaris 助教授がドイツ語の "Ohwurm" を直訳して用いたことに始まるとされている。日本語では「耳虫」という訳語が当てられているものの，実際にはあまり用いられていないようだ。語呂がよろしくないので今後も広まることは無いだろうと思う。
ここで「耳虫」の発生する仕組みが分かると面白かったのだけれど，あまりはっきりとしたことは判明していないようだ。それほど単純な仕組みではないのだろうと思う。一応 Google Answers の情報が参考になる。これを基に少し調べてみたのだけれど，結局のところ，あまり面白い方向には発展しない話題だった……。
[via collision detection]
2005-08-29
お馴染み Tim Rowley 氏の SIGGRAPH 2005 論文リンク集から辿ることのできる論文の中で，個人的に最も面白かったのは，アイオワ大学は Chris Wyman 助教授の論文 "An Approximate Image-Space Approach for Interactive Refraction" だった。
上記のページからは Windows 上で動くデモや動画をダウンロードすることができる。まずはこれを覗いてみるのが早いだろうと思う。
この論文は，フラグメントシェーダーを利用して屈折のシミュレートを行うというものだ。屈折によって光線の変化する量をイメージベース的手法によって求めている。そのアルゴリズムは非常にシンプルかつ直感的であり面白い。プログラムの知識が無い人にも説明することができるのではないかと思う。
光線が透明な物体によって屈折する様子は，次のような順序で追うことができる。まず，光線が物体の前面で屈折する。次に，屈折した光線が物体の中を進む。最後に，物体の背面に突き当たった光線が再び屈折する。あとは，屈折後の光線ベクトルを基に環境マッピングを行えばよい。
物体前面の屈折を扱うには，光線ベクトルと入射面の法線ベクトルが分かればよい。スネルの法則によって屈折角を求めることができる。屈折光が物体の中を進む量については，屈折光に沿った物体の厚さが分かればよい。物体背面の屈折を扱うには，やはり背面の法線ベクトルが分かればよい。
ここで最も難しいのは，「屈折光に沿った物体の厚み」を求めることだ。これを正確に求めるにはレイトレーシング処理をまともに行わなくてはならない。そこで件の論文においては，これを「視線に沿った物体の厚み」で近似してしまっている。この厚みを求める方法は至極簡単で，オブジェクトの前面と背面のレンダリングを行い，それぞれのデプス情報を画像として得ておくだけでよい。あとは，これらの単純な差分から「物体の厚み」を求めることができる。
「視線に沿った物体の厚み」による近似は，入射角と屈折角の差が大きくなるほど誤差を生み出す。ただし実際に試してみると，この誤差は見た目にさほど大きな影響を及ぼさないことが分かる。むしろこれを無理に補正しようとした方が，かえってアラが目立ってしまうという結論であるようだ。
個人的にこのアルゴリズムが面白いと感じたのは，比較的高等な処理 ― 前世代のハードウェアでは実現の難しい類の処理 ― を行っているにも係わらず，プログラムを組む人以外にも理解できるような分かりやすさを備えていることだった。
ハードウェアの進化は様々な可能性を広げていっている。しかし「それで何が出来るのか」ということを技術者以外の人に分かりやすく説明することは難しい（当の技術者だって分かっていないことがあるのに！）。単純に「数」の上限が向上するという「縦軸の進化」は説明が簡単だが，それ以外にも出来ることの「幅」が広がっているということ ― つまり「横軸の進化」は，説明が難しい。これまでとは異なる新たな発想を身に付ける必要があるためだ。
そのような「横軸の進化」を知ってもらう際に，例えばこのアルゴリズムのような分かりやすい例を挙げることは，理解の一助となりうるのではないかと考えている。デプス情報を上手く使えば「物体の厚み」が分かるんだから，あとは物体の表裏の法線情報さえあれば，今までに無いようなリアルな屈折が表現できるよ……と，それじゃあ，○○と××を使えば□□な△△ができないかだろうか……そんな発想のやりとりができるようになれば理想的だと思う。なかなか難しいけどね。
2005-08-30
"The Daily WTF" は，皆が日常で見かけた「タコなコード」を紹介するサイトだ。よくもまあこんな……と思うようなものから，タコながらも同情を誘うようなものまで，日々様々な事例が紹介されている。
以前は，ここから何らかの教訓を得ることができるかもしれないと思い，定期的に目を通していたのだけれど，それが最近では，気の向いたときに軽く覗く程度になってしまっている。結局の所，ここに挙げられているような事例は極端なものばかりであり，あまり一般性のある話に展開することができないという点が良くないのだろうと思う。
個人的に好きだったネタは "The Best-est Version Control" だ。ファイルの内容を更新する際に，古いファイルの名前に ".bak" を付けて保存しておくなどということは，誰もがよくやることではないかと思う。しかし，同じファイルを再び更新して，ここでも同様に古いファイルを保存しておきたいと思った場合は，一体どのようにしたらいいのだろうか？ そこで投稿者の知人が編み出した方法とは，以下のようなものだった。
最上級 "-est" の更に上は "-est-est" だ。覚えておこう。
自らのソースを出力するプログラムのことを "Quine" と呼ぶ。日本語では「自己出力プログラム」と呼ばれることもある。この "Quine" という名前は現代哲学者ウィラード・クワインに由来している。自己言及性の研究で知られることから，その名前を借用したということであるらしい。
自己出力プログラムの定義は非常に簡単であるものの，実装するとなると途端に複雑な問題となる。 Wikipedia の "Quine" の項や， Gary Thompson 氏の "The Quine Page" には様々な言語における自己出力プログラムの実装例が紹介されているのだけれど，これらに目を通せば複雑なコードが多いことに気付くと思う。例えば C 言語における自己出力プログラムの例は以下のようになる。
面白いのが HQ9+ 言語の例だ。 HQ9+ 言語における自己出力プログラムは以下のようなものになる。
やけにシンプルなコード（？）だけれど，それもそのはずで， HQ9+ 言語は自己出力プログラムを始めとする「よくあるサンプルプログラム」を簡単に実装するために作られたジョーク言語であるためだ。 HQ9+ 言語にはたった４つのコマンドしか存在しない。 "H" は "Hello, World!" を出力し， "Q" は自己出力を行い， "9" は "99 Bottles of Beer" の歌詞を出力し， "+" はアキュムレータをインクリメントする（アキュムレータに他の用途は無い）。 HQ9+ 言語はチューリング完全ではなく，機能面からも実用的な言語であるとは言い難いのだけれど，特定の用途には驚くべき生産性を発揮することができる！ 特に，プログラミングの授業の講師が任意の言語で自己出力プログラムを実装してみろなどという課題を出してきた場合には……。