ゲームの開発が大変になったと良く聞きます。ハードの性能が上がってより高い
クオリティのものが作れるようになったし、同時にユーザーが求める内容も
あがります。
その分だけ物量も必要で開発人数も増えて規模が大きくなりました。

ますます分業化が進んで個々の作業はさらに専門化し、作る人と考える人の距離が
遠ざかります。作り方を理解し作業工程まで工夫した設計がなかなかできず、
物量に頼る機会がますます増えてしまいます。

ハードの進化についていけずに、力技の対応で食いつないできたつけが回ってきたの
かもしれません。

開発がついていけないからといってハードの進化を否定するのは少々強引な気が
します。既存の環境やハードウエアなら使いこなしているから開発の負担が減る
だろうという考えも少々短絡的ではないでしょうか。

使っていればやっぱり不満点や足りない点が出てくるものです。あと少し、もう少し
だけここが改良されていればここまでできたのに、あともうちょっとメモリがあれば、
もうちょっと CPU が速ければ、クオリティがあがるのに、などなど。

進化しなければその同じ制限に再び悩まされることになります。世の中では、
例えば PC では当たり前に解決されていることであっても、進化を止めてしまったら
古い手法を使い続けなければなりません。

PC のスペックはものすごい速さで進化しています。10年前と比較すると 40倍の
CPU 速度に 20～30倍のメモリ量に、10倍の HDD 容量などなど。だからとって
プログラマの作業が極端に大変になったかといえばそうでもありません。

ハードが進化した分制限が無くなり、メモリや CPU速度に余裕が生まれて新しい開発
手法も使えるようになっています。class ライブラリが整備され、デバッガも高機能
になって、スクリプト言語による開発も幅広く用いられるようになりました。

メモリやディスクを大量に消費する重いアルゴリズムでも以前と比べると気楽に
使えます。

もちろん新しいことを覚え続けなければならないのは当然だけど、むしろ制限は
減ってきています。

前の世代でぎりぎりまで使い切って、限界が見えていればいるほどハードの進化は
歓迎すべきものでしょう。もしかしたら使いこなせていないときは、ハードの進化
が重くのしかかってくるのかもしれません。

同じように、データの作成手法でもさまざまな変化が必要でしょう。性能があがった
ことでいくらでもデータの作りこみができるようになりました。

2D 時代に例えれば色数に制限が無くなったようなもので、描こうと思えばどんな
絵でも出ます。パレットやチップが足りないといった言い訳はできなくなったし、
本当に力を入れるべき表現のポイントを絞らなければならないでしょう。

また不要な手間はできるだけ省き、人間が手でやる必要が無い部分は徹底的に
ツール化していく必要があるでしょう。

リアルタイム 3D CG の進化はまだまだこれからです。始まったばかりです。

Playstation3 で動く Linux について以前公式にニュースになっていましたが、
すでに動作するものが入手できるようです。

Impress の YDL の記事 2006/10/17

http://www.fixstars.com/
http://cell.fixstars.com/ps3linux/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8

Linux PC としても実用的なのかどうか、
またはリビングに置いた安価な PC として使えるのかどうか、
などといった実用面はさておき・・

一般ユーザーレベルにも Cell プログラミングの機会が与えられた点はかなり
興味深いところです。

ゲーム機などの専用ハードを、一般向けにもプログラミング用途で開放することは
これまでもありました。でも魅力的なものはそれほど多くはありませんでした。

(1) 発売後かなり期間がたってから、すでにハードとして枯れた状態で公開
(2) 専用のツールや言語を通した限定的なものでハードは直接見えない

発売直後は価格的にも性能的にも PC をはるかに凌いでいても、何年も経ってから
では PC に追い抜かれています。PC 以外をわざわざ使う意義はかなり薄くなって
しまいます。

ところが Playstation3 の場合は発売したばかりです。非常にスペックも高くて
まだまだ本業の開発メーカーもハードを完全に使いこなしていません。そんな中で
ハードに触れるようにするのだから、誰もが平等に Cell プログラミングのスタート
ラインに立てるということです。

面白そうだし、Cell 普及のためとはいえこの流れを作った SONY もみごと。
優秀なプログラマが育ってくれるとうれしいですね。

Xbox360 のゲームソフト Gears of War のグラフィックがすごすぎます。
http://www.xbox.com/en-US/games/g/gearsofwar/
Unreal Engine 3 の本家 Epic Games 開発なので、もちろんエンジンそのものが
最初からすごいんだけど…。

とにかくその Engine 性能を限界まで引き出すすばらしいデータの数々。
キャラもマップも今まで見たことが無いくらい、緻密で作りこんであって、
それでいてプログラムの性能を活かしきる。
エフェクトやシェーダーの効果もさりげなくて実に効果的です。

見たのは 2006/11/7 発売の海外版だけど、
日本語版も 2007/01/18 に発売されるようです。
http://www.xbox.com/ja-JP/games/g/gearsofwar/

今まで見たゲームの中では最高の緻密さ。圧倒的なクオリティです。
これをもっと大々的に宣伝したらもうちょっとは Xbox360 もいけるんじゃないかと
思ってしまいました。

○今日のシェーダーメモ

mul( float4x4, float4 ) と mul( float4, float4x4 ) の違い

// mul( float4x4, float4 )
mul r0, c1, v0.y
mad r0, c0, v0.x, r0
mad r0, c2, v0.z, r0
mad o0, c3, v0.w, r0

// mul( float4, float4x4 )
dp4 o0.x, v0, c0
dp4 o0.y, v0, c1
dp4 o0.z, v0, c2
dp4 o0.w, v0, c3

W-ZERO3[es]もそうですが、最近の携帯電話についているイヤホンマイク端子は
ほとんど平型です。以前はイヤホンマイクといえばミニミニジャックの丸型で、
たしか昔使ってた J-PHONE の J-SH51 も丸型でした。

平型端子には通常ステレオヘッドホンやらマイクつきのモノラルイヤホンが
つながります。だけど SHARP の携帯ではそれ以外にもさまざまな周辺機器が
ここ につながります。

例えば V905SH は

・アナログ変換ケーブル
・マイクつきイヤホン
・光デジタル変換ケーブル
・マイク付き液晶オーディオリモコン
・ビデオ力ケーブル
・TVアンテナ付きステレオイヤホンマイク

などのオプションがあるようです。
機能だけまとめてみると

・ステレオ音声出力
・ビデオ出力
・マイク入力
・音声入力
・デジタル音声入力
・液晶リモコン用信号
・TVアンテナ

…このコネクタは一体何なのだろうか。と思って少しだけ調べてみました。
「JEITA(EIAJ) RC-5240 携帯電話用角型コネクタ」という名前らしいです。

こちらの
通信用語の基礎知識 RC-5240 にピンアサインが載っています。

やはりステレオ音声出力とマイク端子しかないので、それ以外の信号は結局
SHARP 独自仕様なのかもしれません。

D3D10 でなくても OpenGL の NVIDIA 拡張ならできるということをすっかり忘れて
いました。
http://developer.nvidia.com/object/nvidia_opengl_specs.html

しかも CUDA という新しい GPU 向けプログラミングキットまで出ています。
一般的な C言語を使って GPU 向けプログラムが書けて、演算用のストリーム
プロセッサとして活用できるようです。マルチコア CPU でもせいぜい数個のスレッド
が走る程度ですが、CUDA では数千というスレッドが可能とのこと。
http://developer.nvidia.com/object/cuda.html

描画向けパイプラインを流用して演算させる手間が要らず、ハードにあわせた専用の
シェーディング言語を用いなくても良いわけです。ShaderModel4.0 の仕様になって
非常に汎用性が高く、一般の計算用途に活用できる構造になりました。
CUDA はさらにその先を行ってるわけです。

あらためて仕様を見てみると、D3D10 の ShaderModel4.0 HLSL でも演算可能な
32bit int の整数型が追加されています。整数型が追加されたことで、bit 演算や
シフト演算子も使えるようになっています。

D3D10 ではアセンブラによるシェーダープログラミングはなくなっており HLSL のみ
のサポートです。マニュアルにもアセンブラについては書かれていません。

その代わり上記リンクにある資料から OpenGL の NVIDIA 拡張命令で 4.0 相当の
アセンブラ命令を見ることができます。これまで存在しなかった AND, OR, XOR,
NOT, SHL, SHR, I2F, PK/UP～ の整数系命令が並んでいることがわかります。

int 型整数の乗算は 32bit 分の演算が必要なので、浮動小数点演算よりも負担が
高くなります。整数乗算の制度を 24bit に制限するオプションがあり、これで
浮動少数点相当の演算コストで高速に乗算できるようになっています。

また整数乗算では 64bit 相当の演算を行った後、上位 32bit のみ受け取ることも
できます。上位と下位を同時に受け取れないので結果を 64bit で受け取りたい場合
は乗算が 2命令必要になります。

比較は結果をレジスタに bool 値で代入できる専用の命令もありますが、演算や
代入と同時に結果をフラグに反映させることができます。これも汎用 CPU と同じ
ように、zero, carry, overflow, sign の４つの flag が揃っています。

フラグの更新と参照は依存関係を持つためパイプラインストールに原因になりがち
です。これを CC0 と CC1 の2セットのフラグレジスタを使い分けることで回避
しているようです。

VertexShader → GeometryShader はそのまま直接値を渡すことができますが、
VertexShader/GeometryShader → PixelShader の場合は間にラスタライザが介入
します。この場合の補間は float で行われます。補間を行わない場合は任意の型で
渡すことができるようです。