こんなに幸せだったとは!!!
東プレ Realforce91U 買ってしまいました。
2万円近い値段のキーボードです。
値段で躊躇していたのだけれども、店頭でついつい触ってしまい、
結構うろうろしつつ悩んだ末の購入。
だけど実際に使ってみたらもう大満足。
どんなに速くキータイプしても文字がついてくるのですよ。
どんなに長くて複雑な関数名でも全部自分で最後までタイプできるのです!

http://www.topre.co.jp/products/comp/key_list.html

今までは速くタイプすると途中でキーが引っかかってしまい、無意識のうちに速度
を抑え目にしていたようです。全力疾走したいけどできなかったような感じです。

長いシンボル名では引っ掛かりを回避するために、途中までタイプしたらすぐ
テキストエディタの補完機能を使ってました。
それだけ自分のキータイプに信頼が無かったのでしょう。

Realforce ではそれが必要ありません。最後まで文字を打ち抜けます。
キーの軽さやタッチ感が高級なせいもあるのでしょうが、どうやら
「Nキーロールオーバー」おかげみたいです。

前のキーを離す前に次のキーが押されると、同時に複数のキーが押された状態に
なります。このまま次のキー入力を認識できるのは、普通のキーボードだと
3キー程度が限界だそうです。

きっとタイピング技術がもっと上手ならば、キーを離してから次の文字をしっかり
打てるのでしょう。自分は速くタイプすると4キー以上同時に押してしまっている
ようです。

Realforce は何キーでも押された順番認識できるらしいので、これが
「最後まで文字を打ち抜ける」感覚につながっているわけです。

そういえば 8bit/16bit パソコンの時代はキーボードの相性がありました。
キーボードマトリクスの関係上、直角に並んだ特定の3キーが押されるともう
1キー押されたことになってしまいます。
高速にタイプしていると知らない文字がよく混ざったりします。

マトリクスの配列に依存するので、自分のタイピングのくせとこの条件が重ならない
キーボードだと速く打てて相性がいいのです。

最近このマトリクスの話を聞かないので、特定の3キーが同時に押されるとキー入力
自体が入らないようになっているのかもしれません。
もしかしたらこれがタイピング中に感じる引っかかりの原因なのでしょうか。

とにかく東プレのおかげで幸せです。

ゲーム開発ではなぜか mipmap が嫌われることがあります。

GPU のレンダリングではカメラからの距離に応じて、参照するテクスチャの解像度
を切り替えることができます。例えば 512×512 pixel のテクスチャ画像がある場合
あらかじめ縮小した画像を次のように何パターンも用意しておきます。

256×256
128×128
64×64
32×32
:

カメラから近い場合は高い解像度のテクスチャを参照しますが、遠くの場合は
高い解像度を使う必要がありません。mipmap を用意しておけばそのため遠くに行く
ほど小さいテクスチャの参照で済みます。いわゆるテクスチャ解像度の LOD の
ことです。この mip レベルの選択は pixel のレンダリング時に行われます。

正確にはカメラからの距離というよりも、レンダリングするポリゴンの面積から
計算すると効率が良いことがわかります。画面のピクセルに対してできる限り1対1で
対応する解像度のテクスチャを参照したいたいためです。

実際の実装ではピクセル間の uv の密集度から mipmap のレベルを判断します。
ピクセル間の差分は、PixelShader でも 2.x 以降なら dsx, dsy 命令で求める
ことができます。

テクスチャの拡大と異なり、縮小時のフィルタリングにはより多くの pixel 情報を
畳み込む必要があります。例えば最大まで縮小した 1×1 pixel の点には元の
テクスチャのすべての平均値が含まれます。

この計算はリアルタイムに向かないので、前処理でフィルタリングしておける
mipmap は低負荷ながら遠くのポリゴンのちらつきをおさえて画質の向上に
つながります。

もちろんテクスチャアクセス時の負担も減るので mipmap を使った方がテクスチャ
フェッチは高速です。

mipmap はできるだけ使ったほうが良いのです。

デメリットは、あらかじめ縮小した画像を含んでいる分だけテクスチャ容量が
1.34倍程度に増えることです。

コンシューマ系のゲーム開発で mipmap があまり使われないのは、ひとつは容量の
問題でしょう。Xbox1 以降なら容量に対してアクセス負荷が高いので、使用した
場合のメリットの方が大きいと考えられます。

極端にバスアクセスが速かったり、シェーダーでピクセル演算の方が重くて
テクスチャ読み込みが負担にならない場合はこの限りではありません。

もうひとつは mipmap を使ったほうが負荷が高いという思い込みがまだ残って
いることかもしれません。

そして画像が過度にぼけすぎることです。

画質がぼけすぎるのは、最適な解像度よりも下のレベルのテクスチャが参照される
ことがあるためです。

例えばテクスチャ画像とレンダリングされるポリゴンの縦横比が極端に異なると、
短い辺では最適な解像度でも、長い辺では解像度が足りなくなってしまいます。
見た目よりも低いレベルのテクスチャが参照され、引き伸ばされるが故に余計に
ぼけているように見えます。

3D 視点で描画される地面のように、カメラに対して角度のついたポリゴンはこの
傾向が強いので非常にボケボケの画質になりがちです。せっかく書き込んだ
テクスチャの詳細も失われてしまうので、これを嫌がるデザイナーも多いのです。

こんなときは mipmap を切るのではなく異方性フィルタ(Anisotropic filtering)
を活用します。
(続く)

Nike + iPod sport kit 地道に使ってます。でも記録はさっぱり伸びてません。

ワークアウト中にセンターボタンを押すといつでも音声で現在の状況を知らせてく
れます。これがなかなか便利で、よそ見しなくていいのでペースが気になると
ついつい押しちゃう。

ボタンを押すと同時にマークをつけてくれるらしく、Nike+ サイトのグラフにも
小さな丸印で表示されます。

各ワークアウトのログデータは本体に 1000個まで保存できるようです。
少々調べてみたところ

iPod_Control\Device\Trainer\Workouts ～

こんな感じのフォルダに xml 形式で保存されていました。

記録されているのは全体のデータとボタンを押したタイミングのスナップショット、
グラフ用の一定時間ごとの距離データ (km/mile単位) などなど。

これならオンラインにつながなくても、ローカルで確認できるビューアも作れそう
ですよね。

ワークアウト中だけでなく、普段音楽を聴いていてもセンターボタンで現在時刻
とか知らせてくれたらいいのになあ。カレンダーもあるのだからついでに次の予定
とかも。

音声フィードバックのトレーナーの次はぜひ音声秘書をお願いします。

28日に発売された Nike + iPod 買いました。
http://www.apple.com/jp/ipod/nike/

靴にセンサーをつけておくだけで、走行距離や速度、消費カロリーが iPod nano
に表示されます。

一見音楽プレイヤーとはあんまり関連性が無いように見えるけど、音声で現在の
状況などを報告してくれるのです。いちいち画面を見なくても大丈夫。

まだ試しに少し歩いた程度ですが、何も設定していないのに距離や速度の表示が
結構正確に出ます。キャリブレーションもできるけど、他の万歩計等と違って
わざわざ歩幅を はかって入れなくてもいい。
ずっとこの点だけが面倒だと思っていたのですよ＞万歩計の歩幅設定

で、これ走行状況が逐一 iPod に記録されておりロガーとしても機能します。
iTunes 経由で Nike+ のサイトに情報が送られて、時間軸とともにグラフ表示
できたり、他のランナーの状況と比較できたりするから結構楽しい。
これを見るためにもう少し走ってみよう、という気になります。

まだ登録数も少ないので、数キロ程度の距離でも日本ランク 700位程度。
走らなくても大丈夫。まだまだウォーキングでもいいポジション狙えます。

足につける無線のセンサーといえばポラールを思い出すわけですが、Nike + iPod
はここまで本格的ではありません。
http://www.polar.jp/html/segments/Running.html

もっと気楽にはじめられて、ネットに登録するのが楽しみで、はまりそうな予感。

だけどやりこんだら心拍計もほしくなるだろうなあ・・というわけで
ハートレートモニタつきの上位機種が出てほしいです。

または、ポラールやガーミンあたりも対抗してオンラインサービスはじめてくれると
面白いんだけど。ネットワーク対応のサイクルコンピュータなんてのも出てほしい
ですね。

コンシューマ系の組み込みハードと PC の Direct3D では、気をつけなければいけ
ない点が異なっています。思わぬボトルネックが発生します。

とあるメーカーが開発した PC 向けのタイトルのサンプルで、非常に動作が重い
ものがありました。しかもモデルデータのせいで処理が重いので、データを軽く
して欲しいとの話でした。またデータのせいで使えるビデオカードにも制約が
出てしまうとの指摘でした。

画面は 3D のフィールドを表示するシンプルな画面で、背景もキャラクタもごく
普通のモデルデータです。

ところが非常に要求スペックが高く、ためしに起動した PC では 1fps も出てい
ない状況でした。

大体予想がつきましたが、おそらく GPU ではなく CPU の方で処理が落ちている
のでしょう。見たところデータフォルダ内には細切れになったテクスチャが大量
に入っていました。

PC の場合、Direct3D の描画 API の呼び出し回数によって速度が大幅に変わります。
そのためエンジン設計の第一歩は Draw の回数を減らすことからです。

描画はできるだけまとめてばらばらのオブジェクトも一回で描画できるようにします。
Draw 呼び出しの内部ではマテリアルやレンダーステートを切り替えられないので、
マテリアルの数がそのまま描画回数の増加につながります。

テクスチャはできるだけシートにまとめ、マテリアルパラメータは可能ならば頂点
に埋め込みます。

マテリアルやシェーダーの切り替えも負荷になるので、切り替えを最小限にするため
には描画の前にソートしておく必要があります。

また ShaderModel3.0 や、ATI RADEON の ShaderModel2.0 では、ジオメトリ
インスタンシングを使うことができます。頂点ストリームにジオメトリやマテリアル
を書き込んでおくことで、一度の描画呼び出しで大量のオブジェクトを描画可能です。

つまり、描画時には必ずこのような描画を減らす工夫が必要だということです。
そうでないと描画呼び出し API の実行だけで CPU サイクルを消費してしまいます。

コンシューマ系の組み込みハードウエアでは、描画 API の Call はそれほど負荷に
ならず、テクスチャの変更もほとんどサイクル数を消費しないものがあります。
そのためつい同じような考えで描画パイプラインを設計してしまうと思わぬ
ボトルネックに苦しむことになります。

WindowsVista + Direct3D10 では、ステート等のバッファを VRAM 上に確保できる
など、より負荷を軽くするためのさまざまな工夫が施されているようです。

Draw 呼び出し回数の次に考えられる CPU のボトルネックはバッファの lock です。
例えばキャラクタのスキニング等で頂点バッファを lock して書き換えると、GPU
との同期待ちで CPU が無駄に待っている可能性があります。

シェーダーで演算すれば解決なのですが、どうしても CPU で書き込みを行う場合は
フレームバッファと同じように頂点バッファを複数持つ必要があります。頂点バッ
ファを POOL 化して、書き換えた頂点を発行するたびに使用するバッファを切り
替えていきます。

このあたりのボトルネックは、今では PIX 等の解析ツールを見れば一目瞭然で
しょう。