くまりゅう日記

もっと過去の日記
[.NET | BeOS | Blender | COLLADA | fossil | mono | monotone | NPR | OpenGL | PeerCastStation | Riko | Ruby | Silverlight | TRPG | XNA | ゲーム | ゲーム作り | ]

2008-10-28 時間がなさすぎる

_ 何もできん

朝起きて仕事行って、帰ってくると0時近く。

すぐ寝るも体調が悪いので早起きもできず、起きたらもう仕事行く時間なので家を出て、帰ってきたらもう寝る時間。

ありえん。

対策。風邪を引かない。これ重要。

無駄に仕事しない。やっぱ最近無駄に仕事してるとしか思えん。仕事してる振りはやばいな。

これだけで一日数時間は余裕でるはずだー。

_ [OpenGL] NVIDIA OpenGL3.0対応

NVIDIAのOpenGL3.0対応ドライバが新しくなってた。

Linux版もあるけど前からあったっけ。しかしどっちにしろうちにはGeForceがない。

ARB_framebuffer_objectのサポートが追加されてて、前のドライバには書いてあった、サイズ違いのテクスチャがアタッチできないという制限が書かれていない。つまりできるってことだろうか。すげーな。

あ、っつーか前のβドライバからの変更点書いてあるじゃん。

  • Linux版の追加
  • FBOに異なるサイズのアタッチが可能に
  • VAOのバグ修正と速度向上
  • EXT_texture_swizzleのサポート
  • Transform feedbackの足りなかった機能対応
  • いろいろバグ修正

EXT_texture_swizzleはテクスチャ読む前にコンポーネント単位でいれかえできるように設定できる機能。rを読んだと思ったらaを読んでいた…何を言ってるのか(ryという機能らしい。

なんでそんな微妙な拡張をいまさら…と思ったらPS3でできるから移植しやすいように追加されたらしい。PS3でも使うんだろうかそれ。

しかし、まだtexture_rgがサポート無いってのはなんでなんだろう。圧縮とかかな。

あとCg Toolkit2.1が出てる

βが出てたときと変わらずおもにD3D10対応のバージョンアップだけど。GLSLプロファイルが強化ってあるけどそろそろ真面目に動くんだろうか。

それはともかく、なんかcgcのヘルプ出力を見ると、変なプロファイルが増えてるんだよねぇ。

gp4_1fpとかgp4_1vpとかその辺。gp4fpとかは前からあるしドキュメントにも書いてあるNV_fragment_program4なんかの拡張に対応するプロファイル。

でもgp4_1系はNVFp4.1とかのヘッダの未知なアセンブリを出力しやがる。

これはどのGPUで使えてどんな機能があるんだか、いまのところどこにも書いてないんだよね。

まあそのうち正式にドキュメントに載れば分かる物なんだが。

_ ClickOnceよさげ

ひにけにXNAを見てClickOnceについて調べてみたんだが思ったよりよさげだった。

ブラウザから直インストールできる物、ぐらいに考えてたんだけど、オンラインアップデートも自動でやってもらえるのか。

.NETアプリケーションでなんたらかんたらと言う話だが、.NET Framework2.0が必要なだけで、べつに.NETアプリの必要はなさそうに思える。完全信頼にするのは必須な気がするが。

これならexerbで作ったWindowsアプリのインストールとかアップデートにも使えるのだろうか。オンラインアップデートとか標準の仕組があるなら使いたいんだよね。

XNAでも便利だろうけど、XNAはXInputしかつかえないのがネックだからなぁ。

DirectInputも使おうとすると別にMDXも入れないと…。

ひにけにXNAの方、なんでログインユーザー名をそんなに問題にするのかと思ったら、非現実のお嫁さんかそうか。

スクリーンショットの壁紙が大変なことになってるくらい切実だな。

_ [Riko] そうだ、CPUを使おう

OpenGLスレ見てて思ったんだけど、やっぱりなんでもGPUでやるのは間違ってるな。

頂点処理とかジオメトリシェーダとか別にGPUでやる程でもないし*1、CPUでやった方が柔軟に処理できるな。

そのうちOpenCLとか使えるようになったら頂点処理はそっちで、とか考えてたんだけど、べつにいまCPUでやるようにしてもいいな。

とはいっても頂点処理をRubyでやるわけにはいかん。 それは遅すぎるだろう。

しかしCで書くのはどうなんだろう。書くこと自体は別にいいんだが、Ruby側からみれば固定シェーダみたいになるのでは…。

まあいいか。どうせ頂点処理したいのなんて今のところスキニング位だ。他にいろいろ必要になったらまた考えよう。

まあ本当にCPU処理したいのはNPRやるときなんだけどね。シェーダでは制限が多すぎるぜ。

さて、CPUでCでストリーム処理するなら、ネイティブなスレッド分けて処理できそうだ。Rubyでゲーム作ると現状どうしても余ってしまう無駄なCPUコアを使ってやるぜ。

マルチプラットフォームでマルチスレッドって面倒そうだな。とりあえずWin32APIとpthreadに対応すればいいんだろうか。

なんかpthreadは罠なプラットフォームがあった気がするけど、まあWindowsとMac以外はよくわからんので気にしなくていいか。問題があってから考えよう。

本当の問題はいつものことだが作業する時間が(ry

*1  もちろん切実に問題になるような処理してる人は別だが、個人レベルでは1シーンに十万頂点とかなるまい?


ページのトップへ | トップ «前の日記(2008-10-22) 最新 次の日記(2008-10-30)» | 編集 | kumaryu.net by kumaryu