つーさのくーかん

3月です。

体調不良気味でえｓサボってDirect3D周りの記事読んでたら、10時間経ってました。やばい。

C++使おうと思ったら、C++にはGCがないから、
自分でGCを作った方がいいのか、それともSmartなポインタを駆使すべきなのか。
まぁ、自分でGC作ろうと思ったら研究が足りないので、おかしなGC作ってメモリリークさせるよりは、
Smartなポインタクラスを作った方がきっと成功しそうな気はしますよね。

パフォーマンス

以下ｇｄｇｄ

パフォーマンスねぇ……。
C++はパフォーマンスがC#と全然違いますかね。
C#でゲーム作ってる人があまりに少なすぎて、そもそもパフォーマンスの比較とかやってる人いないですね。
どこ見ても、ツール作りにはC#おいしいけど、ゲーム作るならC++みたいな記述が目につきます。
いつか、デリゲートの使い方ついて実行速度を測ったことがありましたっけね。

匿名メソッドは匿名メソッドのまま使ったら最強ね！　とか書いてますが、
これ実際に他の方法だと1万回の実行に1ms掛かるんですよね。

ゲームは1秒60フレーム。1フレーム16ms。
つまり、これだったら、400オブジェクトで頭打ち ですよ。
実際は描画もあるから、そんなに時間使えるわけでもない。TLEの恐怖が見えてきますね。
まぁ、ゲーム中で扱ってるオブジェクトすべてに対して2重ループはないにしても……。
これ、C++だとどうなんですかね。何使うかにもよるんでしょうが。
そーやって考えると、いくらC#が便利だからつってもパフォーマンス無視できんなぁと、思ったり。
C++だともっと速いんでしょうか。

あー、でも、TopCoderとか、2秒でせいぜい100Mのオーダーに抑えなさいって1秒に5000万回だから、
先の記事でも1番速い方法で書けば、そんなにかわんないっちゃかわんない？　そんなことはない？
ただ、C#使うにしても、速い方法と遅い方法がある。その辺よく理解せずに適当にやっちゃうと死ねますな。
いやぁ、まぁ、プログラムって全部そうだと思いますけど。

QoFRのオブジェクトの構造は見事に失敗してるわけです。newがくそ遅い。
テクスチャを必要に応じて動的にロードしてるんですが、そのロード済みか否かの判定に時間が掛かる。
ファイル名をキーにしたハッシュテーブルなんですが、パスの正規化処理に結構時間が掛かってそうな。
そーいう意味では初代QoFの方がずっとマシだった。
ロード済みかどうかなんて判定せずに、全部起動時にまとめてstaticロード。

今時、PCのVRAMは贅沢で、僕のEeePCですら AvailableTextureMemory は 150MB以上なんで、
しかも、PoolにManagedしておけば、よほどのことがない限りは平気なわけで、
StaticResourceLoaderもGSDKに標準化したし、全部staticに持つのもある意味正解とも。
……据え置き機はそうでもなさそうですが。

GSDKの次期バージョンである GSDK3 もC#で書くと思うんですが、
「ただでさえ遅いんだから」というのを肝に銘じておくのと、
この辺のリソース周りについて、「GSDKのオヌヌメの方法」とゆーのを確立したい。

最近、弾幕STGのソースを読んでみたいと思う。
画面に描画するオブジェクトの数があれだけ多い(たぶん？)のにパフォーマンスがあまり落ちない印象がある。

今のところGSDKではSpriteを使って画面にテクスチャを描いてる。
かつて、VertexBufferに四角形を追加してU,V弄って描画する実験とかもしたけど、
Spriteインターフェースの半分も性能が出ない。私の書き方が拙かったのかなぁ。
それがずっと気になっている。まぁ、2DならSpriteだけあったら十分なんだけど。

ふぅ。また、中身のないエントリになってしまった。
ブログのカテゴリ、整理したいなぁ