決して格闘技ではありません。ボックス化です。
いまだにC#でボックス化を意識的に使わないとうまく使えないです。
クラスが参照のコピーでしかなくて、クラスでの実体のコピーはそのためにコンストラクタ(C++でいうとことのコピコン)が必要になります。またC#では構造体は値型なのです。
C++はクラスも構造体もどちらも同じように定義ができますし、アクセスメンバの初期状態の違いだけで、本質的にどちらもC#で言うところの値型です。でもそのくせ、コピコンが必要です。
ボックス化を意識的にやりだすと、もうこれはほとんどC/C++のポインタとかと同じです。むしろそちらのほうが表記が明確なだけ気が楽になります。
まぁ、これが言語の特性なので、これを理解できるような段階に上ってきていることが喜ばしいです。(的外れかどうかはおいておいて
SystemKのkioku氏がSpecialなページを作ってくださいました。
http://kioku.sys-k.net/4kgfxmon/
先に言うと、私の勉強不足で、gfxが何を指しているのかよく分かっていません。Graphics Flexible eXtention?(知らんが)画像可変的な外部拡張?
ただ機能的によく似ているのがProcessingかなぁ、と。
でもこの特集の中で重要なのは、モデルデータではなくて、ピクセルデータの当たり判定という観点かなぁ。そこは詳しく説明されていた、と思った。。。
すばらしい特集なので、いろいろなところで吹聴していきたいなぁと思いました。
(今日は思ってばっかりだな)
P.S. とりあえずプログラミング多言語マニアになりそうです。
P.S.2 はやくゲームをやれるだけの余力がほしいです。ヴァルキュリアやりてー
5/12/2009
4/22/2009
Fast Light Tool Kit
Fast Light Tool Kitの初心者のためのチュートリアルを少し見た。
これはWindowsの.NETのFormの作り方によく似た感じを覚える。
クラスをインスタンス化して、Begin()-End()の間でコントロールを設置している。そのあとでShow()、表示させて、Run()でメッセージループの開始をしている。このWindowのクラスの抽象度はとてもいいと思う。惜しむらくはBeginとEndに目的語に当たるものをちゃんと設定してほしかった。あるいはUnlock-Lockといった対になることとその間だけでなにかが許可されていることを表す関数名がよかった。
この抽象度は.NETのFormも同じぐらいだ。これは、C#のFormの動きをみればよく分かる。どちらが先とか言うことではなくて、この設計思想はたとえばボタンをすぐに乗っければいいと思う人にとっては、Begin()-End()のロック機構がまどろっこしいだろうし、呪文にしては、Begin-Endは上記の理由で不適切だと思う。
ぱっと見た感じだけど、よく考えられていると思う。そしてなにより扱いやすそうだ。抽象度が適当だと思う。このライブラリは更新も割りと頻繁に行われているようなので、当分はいけるのかな。日本語の解説サイトがないことがもしかしたら普及が遅い理由なのかもしれない。あるいはFLTKがクロスが不十分か、Macが非対応か?
そしてクロスプラットフォームにそれほどこだわるのはなぜか?実行形式にされないと結局はどの環境でも使えないし、そもそもパフォーマンスをあげるのは、やはりオーダーメイドで、仮想レイヤーが少ない場合だろう。この流れでいうと、Windowsのみで、クロスプラットフォームサポートを捨てた日本製のToolKitの開発というのも意外とアリなのかもしれない。解説サイトが日本語は当たり前だ。でも技術的な知識の蓄積は見込めないし、コードの修正、改造なども頻繁とは行かないだろう。海外のユーザーがつかわないと技術的な情報の蓄積が見込めない(母体数と能動的参加者の明白な差)ので、海外の技術者コミュニティにコミットしたものがいいだろう。それでいうとGLUTとFLTKはいいのだろう・・・
あとは映像製作用に特化した細分化された巨大なライブラリ群かな…
細分化された巨大なライブラリというのは、必要に応じて、使うライブラリを減らせるということでファイルサイズに制約がある場合に対応できて、なおかつ製作中は多くのライブラリでサポートすることによって撮影を簡便にすることだ。・・・え、既存のライブラリを集めればいいって?そりゃそうだ。
さらにさらにいうとライブラリの信頼性については、各々が確認してから使うしかないのがつらい。ライブラリの信頼性はアプリケーションの信頼性だし、もろもろのソースコードにまつわる問題と一蓮托生だ。とりあえず自分でWindowsのFormをC++ベースで抽象化してみる。・・・本当はC#が好きです。
これはWindowsの.NETのFormの作り方によく似た感じを覚える。
クラスをインスタンス化して、Begin()-End()の間でコントロールを設置している。そのあとでShow()、表示させて、Run()でメッセージループの開始をしている。このWindowのクラスの抽象度はとてもいいと思う。惜しむらくはBeginとEndに目的語に当たるものをちゃんと設定してほしかった。あるいはUnlock-Lockといった対になることとその間だけでなにかが許可されていることを表す関数名がよかった。
この抽象度は.NETのFormも同じぐらいだ。これは、C#のFormの動きをみればよく分かる。どちらが先とか言うことではなくて、この設計思想はたとえばボタンをすぐに乗っければいいと思う人にとっては、Begin()-End()のロック機構がまどろっこしいだろうし、呪文にしては、Begin-Endは上記の理由で不適切だと思う。
ぱっと見た感じだけど、よく考えられていると思う。そしてなにより扱いやすそうだ。抽象度が適当だと思う。このライブラリは更新も割りと頻繁に行われているようなので、当分はいけるのかな。日本語の解説サイトがないことがもしかしたら普及が遅い理由なのかもしれない。あるいはFLTKがクロスが不十分か、Macが非対応か?
そしてクロスプラットフォームにそれほどこだわるのはなぜか?実行形式にされないと結局はどの環境でも使えないし、そもそもパフォーマンスをあげるのは、やはりオーダーメイドで、仮想レイヤーが少ない場合だろう。この流れでいうと、Windowsのみで、クロスプラットフォームサポートを捨てた日本製のToolKitの開発というのも意外とアリなのかもしれない。解説サイトが日本語は当たり前だ。でも技術的な知識の蓄積は見込めないし、コードの修正、改造なども頻繁とは行かないだろう。海外のユーザーがつかわないと技術的な情報の蓄積が見込めない(母体数と能動的参加者の明白な差)ので、海外の技術者コミュニティにコミットしたものがいいだろう。それでいうとGLUTとFLTKはいいのだろう・・・
あとは映像製作用に特化した細分化された巨大なライブラリ群かな…
細分化された巨大なライブラリというのは、必要に応じて、使うライブラリを減らせるということでファイルサイズに制約がある場合に対応できて、なおかつ製作中は多くのライブラリでサポートすることによって撮影を簡便にすることだ。・・・え、既存のライブラリを集めればいいって?そりゃそうだ。
さらにさらにいうとライブラリの信頼性については、各々が確認してから使うしかないのがつらい。ライブラリの信頼性はアプリケーションの信頼性だし、もろもろのソースコードにまつわる問題と一蓮托生だ。とりあえず自分でWindowsのFormをC++ベースで抽象化してみる。・・・本当はC#が好きです。
最近のGLUTってどうなの?
- 最近、OpenGLの補助ライブラリ、GLUTってどうなのだろう。
とりあえず目に付いたのは、http://ja.wikipedia.org/wiki/FLTK
FLTKがクロスプラットフォームの補助ライブラリなのですが、正直これに関してはまた使用してみていないので、謎です。
それほど大きな仕組みを必要としていないので、カメラのクラス、関数や行列計算関数のライブラリとGUIの制御のライブラリ、画像処理ライブラリの組み合わせがいいなぁ…必要最低限の分をくみ上げるのにはちょいと時間がかかりすぎるので、周辺の情報をかき集めて、回答を探してみる。
とりあえず自前でBITMAPを扱える程度の能力とバイナリファイルの解析をするだけの忍耐が出来たので、画像のほうはいざとなれば、どうにでもできる。
- OpenGLをなぜ今やりだすのか、ということ。
きっと日本でのはじめての海外勢を呼んでのPatryには間に合わないけど、その領域に近づきたいから、がんばってみよう。会社のほうはまだ残業代もつかないし、定時で帰れるし。。w
登録:
投稿 (Atom)