速くなりました。光源入りで 4つ表示して 23.2fps。
その(2) の時は 1つで 18.5fps しか出ていなかったデータです。

TouchDiamond (Qualcomm MSM7201A) Direct3DMobile

● 前回 調べた結果から

数値を見る限り 30fps でフレーム 10000頂点くらいがいいところでしょうか。
しかもデータ側の頂点数ではなく実演算の頂点数です。
ポリゴン数だとがんばって 3000～4000ポリゴン相当くらい。

さらに裏面や画面外など、描画してないけど計算してしまったポリゴンも含むので
実際に使うと予想以上に少なく感じるはずです。
頂点がかなり足を引っ張る形になります。
(API 呼び出しのオーバーヘッドとかフィル周りはまだ未調査です)
Dreamcast とか PSP クラス とかとても無理で、おそらく DS 未満。

光源を入れるとさらに 2.5 倍ほど重くなるようです。

いろいろ考えた結果、caps が HWTRANSFORMANDLIGHT を返してくるのはたぶん嘘では
ないかと。頂点はおそらく CPU 計算です。

試しに CPU だけで頂点の変換を行ってみたところ、同等以上の速度で描画することができました。
しかも FPU (VFP) が乗ってない CPU で float 演算しているのにこの速度。
caps が NATIVEFLOAT を返してくるので D3DM も CPU で float 演算している可能性が
あります。

固定少数でためしたら、float よりちょっとだけ速くなりました。
これが 最初にのせた 23.2fps の結果となります。

最適化とかほとんど考慮していないのに、それなりに速いのには理由があります。

　・クリッピングしていない
　・頂点バッファ単位で変換しているので共有頂点は一度しか計算していない
　・光源計算は必要最小限で不要なものを省いている

よって実際に使える状態まで機能を入れるともっと負担が多くなるはずです。

●ここまでの結論

　Touch Diamond で D3DM を使う場合
　・CPU で自前で頂点演算をやる
　・CPU 内で完結するものは固定小数演算

自前で書けば、プログラマブルシェーダーのように必要最小限な処理に最適化できます。
ライティングなども実用的な速度で動作すると思います。

●問題点

実際に CPU で頂点演算をしてみると、いくつか問題が出てきました。

・rhw の挙動がおかしい

　自分でスクリーンスペースまで変換した場合、変換後の頂点の rhw の挙動が
　どうもおかしい。狙った通りの結果になりません。
　これがだめだとパースペクティブコレクションが効かないので少々致命的です。

・Fixed 形式の頂点だと Texture の uv が出ない

　負の uv 値でおかしなテクスチャの値になる。原因調査中

関連エントリ
・HTC Touch Diamond で Direct3DMobile その(3) 実際の頂点性能
・HTC Touch Diamond で Direct3DMobile を使う。その (2)
・HTC Touch Diamond で Direct3DMobile を使う。ハードウエアアクセラレータ