先日「こちら」で，ジョン・カーマックがParheliaについて語ったNewsをお届けしたが，今回のNewsはその第二弾となる。前回同様，彼のplan.fileの全文を翻訳したのが以下の文章である。（Okutani）

　Matroxには謝らなければなりません。あの会社のハードウェアがサポートするディスプレイスメント・マッピングは，関数quadベースじゃなかったね。ほかの会社が計画している仕様と混同してしまっていた。Matroxの仕様は，実は結構良く感じられる。だから，ジオメトリ増幅化の問題でDOOMIIIにはMatroxの手法を使わないのであって，あの意見は関数quadでの取り組みを撤廃してもらいたいという意見に基づいているんだ。

　先週3D LabsのP10チップ（完全OpenGL 2.0サポートの次期VPU）をもらって，昨日ずっと遊んでいた。ボクの時間のほとんどは，ゲーム制作に注ぎ込んでいるから，たいていの場合，そのチップの第1印象でどこまでゲームを最適化していくかを決定するようにしてる。例えばATIとは，去年Radeon 8500をもらったあとは数か月に渡って話すことはなかったんだ。ドライバが使い物にならなくて，コンソールも正しくレンダリングされなかったからね。

　P10は，すごくいい感じだ。fallback_ARBの拡張パス（スペキュラーハイライティングを除く）にも，NV10 NVIVIAレジスター・混合パスも両方サポートしていて，入れた途端にフル稼働していたからね。実は二つほど問題があったけど，一つは我々のデータ側の問題だったし，もう一つは"問題"とさえ呼べないかもしれない。3D Labsは，NV_vertex_support_program_1_1をサポートするつもりはないらしいんだ。ボクは，これをNV20のパスで使っているけど，テスト用に1.0に戻してみたら不都合が起こった。でも，NVIDIAの新カード以外で一番良い手応えを見せているのは確かだね。

　まだこのチップが，どれだけのパフォーマンスを出すのかを語るのには早すぎる。なぜなら，まだバーテックス・オブジェクトのエクステンションがサポートされていない段階から，CPUが頂点データ全部を手でエサを与えているような状態なんだ。こんな状態でも，ボクが思っていたよりも速かったんだけどね。

　第1印象が良かったんで，シングルパスでDOOMIIIのインタラクションレンダリング全部をこなせるように，新しいコードベースを気分良くプログラムしたんだ。中でも一番好都合なオプションは，NVIDIAのエクステンションを利用していることだね。NV_vertex_programとNV_register_combinerの二つで，GF3とGF4が四つのテクスチャユニットがないのに対して，七つのテクスチャユニットをサポートしている。その代わり，一緒に送ってくれたプロトタイプのOpenGL 2.0エクステンションを試してみた。

　作業は非常にスムースにいったんだけど，すべての機能セットを入れ込む前にプロトタイプのコンパイラの上限にぶつかってしまった。でも凄く良かったよ。コンパイラができてきたら，このプログラミングモデルのリサーチをするのが楽しみだ。シェーディング言語は一番大切なアスペクトで，現行のOpenGLのエクステンションに小分けしていくことはできるけど，OpenGL 2.0の計画書で提議されていることの中には，小さいけれど重要なことがいっぱいある。

　今は，DOOMIIIを改良していくどの段階ででも，OpenGL 2.0のレンダラーをサポートするつもりだ。ひょっとしたら，この（OpenGL 2.0のフルサポートという）問題をハードウェアメーカーに提案するのを怠ってきたのかもしれないなあ。そろそろ，ゲーム制作のプログラミング環境についてを決定していくべき重要な時間になってきている。ここで決められることは，今後10年に渡ってボクらに関わってくるんだから。

　OpenGL 2.0のドライバは，現在七つ以上のテクスチャユニットをサポートしている現行チップに，何らかの理論的なアドバンテージを与えるものではない。だけど，今後のリサーチによっては，必ず低次レベルでのコーディングという慣習から移行していくし，もしハードウェアメーカーが新しいチップを開発する予定でいるなら，ライセンスで縛られているエクステンションよりもOpenGL 2.0を使ってもらいたい。

　まだCgとの具体的な比較はやってない。C言語のようなグラフィックス言語は数種類も存在しているけど，正直に言って，使いこなすということでは，構文レベルでの大きな違いはない。今ボクらが使っているものよりはずっと良いし，構文の言い逃れが神格化されないこと願っているよ。こういうチップで作業する日は近いはずだし，そのうち，今ボクらがアセンブラ言語でアプリケーションを作る人に対する印象と同じものを，低次レベルでのコーディングを書く人に受けるようになるはずさ（アセンブラ系の開発者には驚かされるけど，ぜんぜん効率的な仕事じゃないよね）。

　今後出てくる高次レベルのグラフィックス言語の持つポテンシャルを最大限にするために，なぜ固定化されたリソースじゃあダメなのかってことを，お立ち台に立ってでも説き回わらなければならないと思っている。チャンスがあればもっと詳しいことを話したいんだけど，ドライバは小さな限度のハードウェアに対して，独断的に複雑なインプットを行うマルチパスを担う権利と責任を持っているに違いないよ。分かるよね，みんな。