スポンサーサイト

  • 2007.10.30 Tuesday
  • -
  • -
  • -
  • by スポンサードリンク

一定期間更新がないため広告を表示しています


なんか今更

久々に集中して考える力が甦ってきたというか、違うな。
今更当たり前のことに気づいた。
頭の中にあるのはとあるウェブページで見たDirectInput8の初期化ルーチンなんだけど、その中で、デバイスを拾い上げるルーチン(コールバックで)があるのだが、それの話。

今までなぜかずっとわからなかったのは
最後のところにコメントで
return false;
// return true;
// 複数のジョイスティックを取得する場合はreturn trueする

みたいなことが書いてあった。
でもって、これがなぜかという話。

簡単なことで
DirectInputDevice8を取得する->ジョイスティックゲット
で、関数の最後でreturn true(継続条件)
またコールバック関数が呼ばれるわけ。
でもってもう一個ジョイスティックがある場合は同じことをやって
ジョイスティックがもう無い場合は
デバイスの作成関数EnumDeviceとかその辺からNULLが返ってきて途中で
if( !ret )
{
return false;
}

となるもんで、ここで抜けられる。
ジョイスティックの列挙が不可能になった時点でコールバック関数が呼ばれなくなる。
…なるほど。
俺は馬鹿だったのか。
愚かだ。

というわけで、忘れないように書いておく。こんな馬鹿げたことを。
こんな簡単なことが瞬時にわからないなんて…底が見えるという物です。

ところでFizzBuzz。
あれなんなんだ。
あれが書けないプログラマって言う意味が全くわからないんだが。
正攻法で素直にそのまま書けばいいだろうに。
ショートコーディングのしがいは少しだけありそうだけど(それでもすぐにできそうな気が…)
それともあれなのか、いろんな言語でFizzBuzzできることを自慢するためのツールなのかあれは。でもって出てくる言語がなんかPythonだのPerlだの…にゃー。
AdaとかOCamlとか、Lispだといろんな人が書いてるだろうなあと。
雑記。

徹夜でカラオケした日のことは後で書きます。とりあえず、超楽しかった。

Movable TypeとかYDLRSとか -インプリメント・デイ-

本家ページのcurrent interesting(CI)コンテンツをMovableTypeの練習と称してMTでつくる。
ブログツールだが、CMS的にも使える。
ぶっちゃけスタイルシートがあればいいので(テンプレエンジンもあるが)割と自由がきくし、何より導入が楽。
PostgreSQLとPerl実行環境があれば間違いなく動く。
DBについてはMySQLでもBerkleyDBでもSQLiteでも動く(と書いてある)。

メニューバーは左側。これが世界の定説です(なんか昔どっかの研究者がマウスの動きを人間工学的に分析したら左側の方が総移動量が少なくなると書いてあったんです)。

YDLRSはLZSSを実装中。
実際にはBit読み書きはしなくて良いのだけれど、汎用のバッファクラスを作るのが面倒という理由でbitにbyteずつ書いているという手抜きっぷり。
メモリアロケータ作るまで待ってくれと。

LZSSはwikiにある説明と奥村先生のアルゴリズム事典では実装が若干異なるようである。
具体的には奥村先生のアルゴリズム事典の方が若干だが冗長であるということ。
もちろんそこは冗長にならない様に書き換えるギミックがある(ていうか誰でも思いつく)のでそのようにすれば数%程度は圧縮率が改善されることが期待される。
奥村先生のアルゴリズム事典のslide.cの実装は木といいつつも実はtrieだ。
trieはLZ78なんかだと割とポピュラーな実装なんだけど、LZ77の説明のところに書いてあったので、誤植を疑ったのだけれど、実装を読む限り、trieだ。
あれを見る限り、各ノードの右の子の数だけがリングバッファサイズよりsizeof(BYTE)だけ大きい。
これは、BYTE(=unsigned char)に対するtrieでいえば横の連なりを示しているのだろうと思う。

ま、色々考えるのは良いけどさ、さっさと実装してたしかめろよ。はい、実装します。
アルゴリズムをごりごり書くのは非常に楽しい。
LZSSの次はMT変換とか、BlockSorting(意味はわかるのでたったかたんと実装したい)、PPMなんかにも手を出してみたい。
PPMはこれから高圧縮率を目指すキーになる技術の様に捉えられているのかな。
LZMAなんかはSDKが公開されている様なので(確かオープンソース的ライセンスじゃなかったか)、ソースを読んで勉強したい。どうも圧縮率でいえばLZにもかかわらず凄まじい成績を叩き出すらしい(スライド窓8Mって…説明を読む限りメモリを馬鹿食いすることも無さそうなのでスマートな実装になっているんだろうな。その点だけでも読む価値があるかもしれない)。

COMBAT MANEUVERの開発はどこに行ったんだろう。シーングラフはグラフ構造自体は完成しましたが、specificなクラス(Translationクラスとか)の実装がまだ済んでません。
あのあたりはぶっちゃけ面倒なので姿勢制御のクラスからソースをコピペ(DRY原則違反も良いところ。ごめんなさいDRYを提唱したアメリカの偉い先生)でいいんじゃなかろうか。
動けば勝ち。

今日の晩ご飯も豚肉を使ったどんぶりです。
割合材料がないので適当に調理して載っけて食べるだけ。
今回は炒め豚丼ではなく、煮豚丼にしてみようかなっ※
(☆とか使えるはず無い)

ツンデレではなくネトラレが来るという僕の予言はあたらずも遠からずな様で、そういうゲームが出るみたいです。
楽しみですね。
過去にネトラレの心理学なるものをトピックとして扱った気がするので、よろしければそちらをお読みになられるとネトラレトラウマな皆さんも楽しめるのでは無かろうか。
「For my sister's case」とか「寝取られ」とかでブログ検索すると出ます。
(URL直リンするのが面倒なので、興味がある人は検索すればいいじゃない)

CIのページに萌えない経済学シリーズをちょっとずつ移行させていこうかと。
………わざとじゃないもん。
CIページも暇を見つけて充実させていきたい所存。シーングラフとか、その他諸々とか今年一年でもいろんなものを実装したので割と役に立つことがかけることを祈りつつ。

死体遺棄現場このチョーク跡
君の笑う顔にあきれてる
ポロリ、ピッコロ、課長、デミムーア
全員ずっと地獄島で

(ペロペロペロ 寺の壁を ペロペロペロ ペロペロロ はいはいっ!)
(好き好き好き 足だけ好き 好き好き好き 好きすフェティッシュ! 牛丼!)

ナタ!ナタ!ナタ! エビぞり刑事、ちょっとうるさい
モヤ、モヤ、モヤ マングローブ汚染しろ
すまし汁バケツ入れて 「日向でカルキ抜くの」
三日たって腐敗臭 かたまり浮いて 見なかったことに

(ホントはね総理大臣だったの、内緒だよ☆ 遺影!)

土管まっぷたつ、てか人がいる
ゴボウ巻き見たく壊れちゃうよ
図鑑めくる音ただ切ないね
デルバルバキツネ リスね

ポロリなぜだか急に自信付け
ピッコロ、課長、ムーア ケツを蹴る
木の実隠し場所 ただ 洪水で
ミスでちょっとだけ餓死しかけ

(塗る塗る塗る あんかけ塗る 身体に塗る ヌルヌルル はいはいっ!)
(ぬるぬるぬる のたうって昼 ぬるぬるぬる 仕事しろ 窮々)

矢田、矢田、矢田 予想は矢田 宇宙総理
原、原、原 呼ばれている 治療室
ロールシャッハ見てぐさっと おびえ出す チンパンジー
隣にも広がって 騒ぎ立てるが 一人だけ人(お父さん? もしかして、お父さん?)

あれれ唇がもう触れている
君のまつげが瞳に映る
鼓動波打つ速さ急上昇
そういう 殺し方も ありか

ボソリ 「時計が止まる瞬間に 女子更衣室忍び込もう」
三人寄ればきっと 文殊の知恵
「きっとドアも開かない」

(ああ、神様 先週からチワワが左スネに噛みついて離れないんです 家!)

すまし汁バケツ捨てて 平和な家族の日々
なにげなく ふわっと 舞ったチリ埃
ふと事切れる(なんたって、こんなの初めてだぞ バクテリア?)

あれレオか椎名 俺、大統領
四畳半の広さ もてあます
ポロリ、袖からみえた さくらんぼ
腕ごと噛みちぎって 地獄絵図

あれれ 世界がぐるり回ってる
白衣の重武装 取り囲む
ずっと待ってた 化学防護隊
囲む 実家 封鎖地域

(好き好き好き 食糞好き 好き好き好き ロビOソン はいはいっ!)
(キッス! すきすき すきすきすき すきすきすき すき家めし 十分!)

YDLRS1

まあ、サブプロジェクトではあるわけだが、ゲームシステム向けの圧縮アーカイバであるところの、YDLRS1が(ひとまず)完成。

若干のバグが残っているが、通常使用にはさほど問題ないだろう。まあ、致命的ではあるのだけれど。

メモリ破壊ではまった。
デバッガが便利だということがわかって良かった。
メモリをいちいちぐねぐね内部でやるとパフォーマンス的にもちょっとあれなので、自前のメモリ管理ライブラリぐらい書いておこうと思った所存。
特にブロックごとに解凍するこのプログラムでは、解凍したデータのバッファをreallocで保持するために結構メモリのフラグメントが激しい模様。
900KBの4倍程度メモリを食う。非常に効率が悪い。
スピードに関しても、符号化ルーチンは一切最適化をかけていないので、別段早くない(遅くもないが)。

ひとまず完成、というのは、バグがあるというだけでなく、
「現状では静的Huffman符号化しかやってない」ということから。
アーカイバ自体はYDLRSArcStreamとしてアクセスできる。
このクラスは、符号化やモデル化処理を下請けのYDLRSEncoderBase系クラス(Huffman符号化の場合YDLRSCoderHuffman)に丸投げする。
符号化クラスからデータを受け取るとそいつに適当なヘッダをつけて、CRC32を吐いてアーカイバに放り込む、という風になっている。
というわけで、ここから先符号化形式をある程度柔軟に置き換えることが可能なのです。
ユーザ視点からいえば
「復号化のとにかく早いLZ78とメモリに優しいCHCで」
とか
「とにかく圧縮率! LZMAとRangeCoder(PPMはでも可)じゃあ!」
とか、扱うファイルによって圧縮方式を決められる。
YDLRSEncoderBase系クラスも中身は空っぽで実際の処理を行うクラスへの橋渡しに過ぎないため、ソースコードさえあれば、エンコード結果をポインタで渡せる構造になっていればアルゴリズムを自由に追加できる。
ここが大事。
というわけで、ここからどんどんYDLRS1は強いアーカイバになっていくのですよ。
オブジェクト指向ばりばりのCODECって意外と珍しいのではないかという気が一瞬したが、まあ、誰だってやるよな。

というわけで、久しぶりの更新ですが、特におもしろいことを書くつもりはない!

…突然だが、そして「仮に」の話だが、
…主人公が男であるという設定はどこに行ったんだろう。
あともうなんていうか、内容はどうでもいい。俺は後藤麻衣の声が聞きたいだけで観るぞ。…み、みるんだからねっ!
いや、今ツンデレとかもう寒いだろ。すでに。
あとPPMは割と圧縮率を上げるのが難しいらしい。要、勉強。やりたいことはたくさんあるがいかんせん時間が少ない。
瑣事を切り捨てる勇気も、実はない。

シーングラフ書いてます -やっと実装開始-

Intel Core 2 Duo キャンペーン事務局とか言うところからプレゼントが届いた。
牛革マウスパッド。
…応募した記憶はない。
そしてプレゼントは別に欲しいと思わない。
しくじった。
とりあえず、貴重かもなので置いておくけど、使わない(使えない)だろうなあ。

シーングラフ書いてます。

グラフツリーを探索するときに、そのノードの実行時型情報が必要なのですが、C++でRTTI使うまでもないということで、自作RTTIコード。
GetObjectTypeで、オブジェクト型のenumがとれて、そいつで判断する。
ここら辺はGizmo3Dからぱくりました。
とはいえ、こうするのが普通なんだろうけど。
NVSGの方は、テンプレートとdynamic_castをうまく使って型があっているかどうかを見ているようです。

抽象クラスObjectの下に具象クラスNodeとか、Animationとか、Cameraとか、Mapとかがあって、Nodeの下には、GroupとLeaf。
GroupはさらにTransformとかEnvironmentとかに分かれる。
LeafはGeometryとVolume。
必要になったら追加できるようにプレーンな構成にしてみました。
Stateというオブジェクトを用意して、こいつに必要な情報を詰め込んでNodeにくっつけることで、属性を変化させることが出来ます。実際には固定シェーダを使わないので、TextureとShaderだけを変化させることになると思いますが。

どのシーングラフを見ても大体こんな感じの構成です。

あとは実装詰めていってうまくいかなかったら書き直すなりなんなりしましょう。書くに限るね。もちろんきちんと見通しを持って書かないと駄目なんだけど。

シーングラフはまだまだ -実装に移るタイミング-

冬に体験版が出るのはほぼ絶望的な状況です。
こんにちは、開発者です。

シーングラフの実装で色々考えてます。
シンプルな構成にして見切り発車にするという手もあります。
根本的なところを間違えなければいくらでも拡張が出来るのが、OOPの良いところです。
ただ、いろんな実装を見てからでも遅くないというのが正直なところ。
この手のことを書いた本というのが見つからないし、このぐらい自力でやれよと言うところなのかな。
試行錯誤をやりたいところですが、軽く組んで、もう一度組み直すというリソース過多に耐えられそうにないので、慎重にならざるを得ないのが駄目なところ。
正直プライベートの開発時間が全然とれません。
もう少ししたら暇になるかななどと不信心なことを考えてます。
(誤用)
GizmoSDKというなかなか良さそうなグラフィックスライブラリを見つけたのでそいつのプログラミングマニュアル(a4 105ページ!)のシーングラフの項を読みながら、今ある設計をブラッシュアップしているところです。
シーングラフの必要性から、構造、どのように使われるべきかまで、基本から詳しく書いてあります。
正直これ一本で足りるかも。
斜め読みしかしてないので、じっくり読んでみる所存。
まとめて本家のCIにでも適当翻訳割愛和訳版で置いておくのも手かな。

Why did you suddenly disappeared -つづき-

前回までのあらすじ
戦闘機は本体と、エンジンと、ミサイルと、パイロットと、その他諸々からなっている。
Fighter->Disappeared()
で戦闘機の本体だけ消えるとかアホすぎる。人類はそれを解決する術を既に持っているので使おう。

//------------------------------------------------------

ちうわけで、続き。

要は言いたいことというのは、オブジェクトは階層構造を持っている、ということ。
”世界の根っこ”を始点としたツリー構造な訳です。
…どっかで聞いたような設定。まあいい。

例えば、戦闘機をロールさせる。
ロールって言うのは、進行方向の軸周り回転のこと。
Fighter->RotationX()
(普通はロールピッチヨーの順なのでロールがX軸に割り当てられることが多い。加藤先生の航空機力学入門がそうなっているので、それに従います)
そうすると戦闘機の本体だけがロールする。
すると、空中にミサイルとパイロットと…etc…が浮かんだ状態になる。
ここでも、戦闘機にロールをさせたら、従属するオブジェクトの位置ベクトルにも同様の変換をしないといけない。
人体だともっとわかりやすいかもしれない。
腕を回すコマンドを発信して、腕だけ回って手が階段の手すりに残る…。そんな映画がありました。
世界を回せば世界の中の全てのものの座標も変換されなければいけない。

頭のいい人なら、非循環有向グラフというやつを思い浮かべると思いますが、その通り。ツリーって言うことはつまりそういうことです。
rootが一つではないこともあるため、ツリーではなく、グラフといいます。

これがシーングラフ。

Wikipediaに正しく詳しく載っているので、そちらを見てください。

Scene graph - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Scene_graph

トイレに行きたくなってきたので今日はここまで。
実装をしないと…。
ノートパソコンの購入は諸般の事情により一ヶ月延期。
鉄騎が無性に欲しくなり購入を計画中。欲しい欲しい欲しい!

// BALDRBULLET REVELLION 初回限定版はもう無いらしい。…サントラが欲しかった…。サントラ売りに出しませんか…?emitが聴きたい。♪Why did you suddenly disappered〜。雰囲気の良い曲。

Why did you suddenly disappeared -本格的3Dグラフィックエンジンへの第一歩-

真面目にやることにしました。
というわけで、シーングラフ。
どっちみちどうにかしてオブジェクト管理はやろうと。
でもって、例えば!

CFighter : public CModel{/*実装省略*/}
CLand : public CModel {}
CSky : public CModel {}

とかやって、
CModel::CModel()
{
  linklist->Add( this );
}

みたいにして描画オブジェクトリンクリストに放り込むと。
でもって
linklist->Draw()
とやると描画してくれると言うようなのがまあ手抜きといえば手抜き。
普通は、こういうオブジェクトは階層構造になっていて
戦闘機
->戦闘機の本体
->翼の動くところ
->ミサイルとか
->ジェットエンジンのジェット
->ヴェイパートレイル

であったり、ミサイルも
ミサイル
->本体
->ジェット

となっているし、他のオブジェクトもたいてい浅い階層構造を持っている場合が多い。
これが、フライトシミュレータでないとこの階層構造はもっと深くなることが多い。

ここで、この戦闘機が視界に入らないとする。
すると、その武装も描かなくていいし、ヴェイパーもジェットも描かなくていい。
当たり前なんだけど、当たり前じゃない。
戦闘機のオブジェクトに対して
CFighter.visible( false );
としても他のオブジェクトには影響が出ない。
出るようにするとすれば
CModel *CMissile::Parent;
なるメンバ変数…プロパティを用意して、オブジェクト集合全体をスキャンしてParent == CFighterのそのインスタンスを示しているヤツをvisible( false )とするようにする。

これを繰り返していくと当たり前だが木構造になる。
というか、木構造で実装すべき。
ここで問題なのが、
・普通のランバート照明モデルでレンダリング
・さらにボリュームシャドウが欲しい
・こいつはHDR照明効果もつけたい
・被写界深度効果もやりたい
とすると、それぞれ別々に木がいる(要はNパスレンダリング…マルチパスレンダリングというと格好いい)。
でも、普通のプログラマはそういうことをしない。同じツリーをいくつも持つなんて痴がましい。

というところで次回。
とか言う前に実装をしろよ屑。いや、それが忙しくって英語の宿題を2週連続でぶっちぎるという…。

空間と時間のカリング1 -試行錯誤-

ランドスケープエンジンを考える。
モデルを用意するのが面倒。
DEMを読んでXに変換するユーティリティとか面倒すぎる。
とりあえずエンジンだけ先行開発。
カリングはDirectX側で自動で行われるのでメッシュを適度に分割する程度でも問題ないと言えば問題ない。
まあ、ここはプログラマーとしてカリングぐらい出来ないと駄目だろうと言うことで実装だけしてみよう。
BSPとかPSVとか、挑戦的な科目は色々ある。

友人が誕生日だったらしい。はぴにゅー。直接コメント欄に書くのは照れくさいので(=いきなり不自然なので)ここから祝います。はぴにゅー。

ノート購入は来月へ延期。予想外の出費があるかもしれないので。
ここだよ♪ここだよ♪ 誘うな。俺をそんなところに誘わないでください。うわあ。

空を… -Realtime Outdoor Light Scattering Rendering-

in/out-scattering
パフェとサンデーってどう違うの?
たいていの質問には打てば響くようにレスポンス早く返答できるおれなのだが…。

パフェParfaitはフランス語。英語だとPerfect。
フランス料理に供される冷やした果物のデザートがはじまりとされるが、フランス人パーフェクト大好きということで卵黄に砂糖、ホイップクリームフルーツピューレなどを加えて冷やして固めたアイスクリームになった。これがパルフェ。
日本人にかかるとこいつがなぜかスポンジやらクリームやら果物やらアイスクリームやらがてんこ盛りにグラスに入った食い物になった。パ(ル)フェ。

サンデーはSundae。英語だとSunday。
元はクリームソーダだったんだが(禁酒法時代)、教会に「贅沢な堕落した食べ物」という烙印を押されて売りに出せなくなってしまった。この手の飲食店が繁盛するのは休日。日曜日は安息日なのでみんな休むべきだという教会の方針に反することになってしまうから教会は嫌がったんだな。ということでクリームソーダが売れない代わりにアイスクリームにシロップをかけて(上下逆にした)サンデーという食べ物にした。当てつけだな。「これは教会の禁止したクリームソーダじゃないんだぞ!」
元々綴りは「Sunday」だったのだけど、さすがに教会が怒ったので「Sundae」という綴りになった。

パフェは細長いグラスに長いスプーン。
サンデーは底の浅く口の広い器で食べる。

サンデーの方が低価格で今日される場合が多い。
(quote from wakipedia-うどんのぬるぬるは目に入ったらすぐ洗いな- )


ということらしい。ちなみにリトルウィッチパルフェの中国語バージョンは「小魔女 妃」
久しぶりに火星計画がやりたくなった。
辺境に都市を造っていかに速やかに大きく成長させるかが醍醐味。
緊急調達を使えばなんとかならんこともないが、さじ加減が腕の見せ所というヤツだ。



フォントが表示できるようになりました。
結構綺麗でしょ?
特別なことはしていないので、特別綺麗に出せるような別のエンジンも考えています。
ちょっと処理は重いけど、あらかじめテクスチャを生成しておいて使うインターミッションのプログラマブルムービー的に使うと。
これ、字間調節がめちゃくちゃなのは時間が無くて詰めが甘いからです。
あと出直します。
今は天球の実装中。綺麗に出るようにライトのクラスを書いてます。
あとはフォグ。フォグも頂点シェーダで書きます。
シェーダバージョン2_0対応の予定。頑張れば1_1対応のlow qualityモードもつける予定。

大気における光散乱のシミュレーションと動的雲シェーダあたりを書いたらランドスケープ処理でも書こうかしら。
メッシュをいくつか大きめにとって、飛んでいく先々に付け足していくと。
ある意味カリング処理。手抜き過ぎるか…。真面目に考えます。

// で、一週間後ぐらい

空を実装完了。
GDC2002におけるATI Reserch:Naty Hoffman氏のプレゼンとか論文とかにあるReal-time outdoor light scattering Renderingを実装。
QuadlapleDの開発者SANDMAN氏のウェブページやOPEN-PROGRAMINGを大いに参考にした結果やっと完成。
係数の調整が適当なのと天球の大きさがちゃんと出来てないので、正確に再現できていませんが、それっぽい雰囲気は出てます。

参考リンク:
Electrical Fireworks ひとりごち2004 - 8/17 Rayleighさん
http://www-fu.magma.ne.jp/~hayase/hitori/h2004_0817.html
Naty Hoffman氏の論文 - Rendering Outdoor Light Scattering in Real Time
http://www.ati.com/developer/dx9/ATI-LightScattering.pdf
Naty Hoffman氏によるGDC2002のスライド - Rendering Outdoor Light Scattering in Real Time
http://www.ati.com/developer/gdc/ROLSIRT8.pdf
鬼武者3にこれが実装されてる話他 impress GAME Watch
http://www.watch.impress.co.jp/game/docs/20030916/oni3_2.htm
OPEN-PROGRAMING - 2002.3.28 Rendering Outdoor Light Scattering
http://homepage1.nifty.com/open-prog/article/article07.html
屋外ライティング - assari(とても良くまとまっていて有用です。お世話になりました)
http://harumune.s56.xrea.com/assari/index.php?%B2%B0%B3%B0%A5%E9%A5%A4%A5%C6%A5%A3%A5%F3%A5%B0

// 実装の詳しい内容とかはあとで本家に書きます。CI初記事になる予定
次はランドスケープの実装か…。
だいたい行動半径はエースコンバットを見習って100kmぐらいか。
松見公園そばの道路を離陸して神奈川南部を空爆すると200kmぐらいか…(地図帳を確認してみる)…もっと近かった。100km以内だ。
ここの地形をDEMかなんかをうまーく使ってメッシュに変えて色々やればなんとかなるか。
データ量がひどくなりそう。
上手いこと考えないと。

ノートパソコン買う予定。
Core 2 Duo載せるかも(しかしいらないよなあ…個人でそんなプロセッサ性能いるか? これ以上早くしたいソフトって映像関連かゲームしか思いつかない。プロユースにはまだまだ足りないかもしれないが)。
今のところ考えてるのは爆発することでお馴染みのvaio。
あえて挑戦するところに男気を感じて欲しい。
この時期にvaioを買う男気を買ってくたーはPS3をプレゼントするくらいしてくれても良いんじゃないだろうか。
PS2を安く調達する方法とかも考えてます。
やっぱりフライトシミュレータ作る以上エースコンバットとかエナジーエアフォースとか見ないと駄目かなと。
水面の表現をどうしようか考えてる最中です。
上手いこと出来ないかな。

ぼーっと2chを漂ってみる。
世間にはびこる間違った軍事常識を〜は面白い。
間違った軍事常識を書き込むのか、訂正したものを書き込むのかを統一したらいいんじゃないだろうか。
リアル過ぎて大コケした戦争ゲーム〜というネタスレ。
リアルすぎる設定を考えて書き込むスレッド。
たまにむしろ面白いゲームが出てくるのが面白い。

ぼくは暗号解読班
ぼくは装填手
拡張パック「ぼくは無線手兼前方MG手」
ぼくは要撃管制官
ぼくは航空整備員

ぼくは〜シリーズ。要撃管制官は面白いかも。
ザ・シリーズも名前から思いつきやすいので多く書き込まれてたり。
マニュアルがものすごく分厚いというか、下手をすれば本棚が埋まる程度に多い。

自主防衛派vs日米安保派vs〜は遠くから眺めてると面白い。
不毛だ。歴史を見回すと経済大国が軍事に手をかけ始めると滅亡間近だったり…。
いや、特に意見はないです。
核とか止めようぜ。金かかって仕方ない。場所もないし。
空母も…海外派兵しないんだったら当分見送ろうよ。半世紀後ぐらいから始めよう。
正面装備に事欠いてるこの状態で核とかあり得ない。72式が全部退いてからにしようよ。
空自の主力FIがちゃんと揃ってからにしようよ…と。ハイローミックス戦略はまだ続くんだろうか。
F-22Aに対艦ミサイルつけるのは萌えますね。実によい。XACMで頑張ってみよう。いいなあ。
YF-23というのも実はあり得るのではないだろうかと。F-35もいいけどやっぱりF-22Aかなあ。

絵とかないぞ -時間もないし技術も無いぞ-

コントローラでぐりぐりできたよ。
Aボタンを押すと項目が変わって
・Rayleigh散乱係数
・Mie散乱係数
・Henyey-Greenstein位相関数で近似したMie散乱指向性(離心率g)
・カメラ位置
・カメラ注視点

の項目にフォーカスが移ってアナログスティックで係数をいじれます。
ようやくまともなデバッグ環境だよ。

PS2のゲーム開発とかでも実機にデータ流し込んでアナログスティックでぐりぐりするらしい。エースコンバット5は実機のグラフィックメモリに直接アクセスしてコンピュータからパラメータをいじれるらしい。凄いね。さすがNBGIだね。木をフォトショップで生成したりしたいね。すごくしたいね。ゲリラ的アプリケーション開発万歳

画像を出したいけどここは自宅じゃないのでプログラムもソースも手元に無いぞ。
何とか冬ぐらいまでにまともに見られるデモ的なものを出したい。

雪解けを待っていたデモ - クドリャフカそのほか開発

http://lovelove.rabi-en-rose.net/blog.php?n=213

こういう数種類のデモを積み重ねていく手法は開発手法としてはありだと思う。
一番の利点はいろんな技術を比較的クリーンなエンジンで試したり回したりして、最適な混合具合を見られること。
シェーダの管理とか面倒くさくなりそうだ。そこら辺を上手く回避しつつ技術蓄積を測る一手法として見習いたい。ライブラリの方をもう一工夫してシェーダ周りをもうちょっと使いやすくしたい。
ハンドルをプログラマが管理しなくていいほうほうってないものかしら。
全部ライブラリに持たせてその都度問い合わせるというのもありっちゃありな気がする。
リソース管理とかしてないです。
CDynamicTextは一工夫して比較的高速に連続描画ができるようになった。
ここから先はキャッシングなどのビデオからひと足置いた最適化が必要か。

// 書きかけ

profile
某大学第三学群情報学類所属。 グラフィックスエンジン、圧縮アルゴリズム、ゲームエンジンなど
feedmeter
人気ブログランキング - SENSE-LESS MANEUVER 2nd
selected entries
categories
archives
links
recent comment
search this site.
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM
recommend
PHPサイバーテロの技法―攻撃と防御の実際
PHPサイバーテロの技法―攻撃と防御の実際 (JUGEMレビュー »)
GIJOE
とりあえず読まなければならない本。phpプログラマならばこの本の内容をすべて押さえているべきの気がする。
recommend
初めてのPHP5
初めてのPHP5 (JUGEMレビュー »)
デイビッド スクラー, David Sklar, 桑村 潤, 廣川 類
recommend
Debian GNU/Linux徹底入門第3版 Sarge対応
Debian GNU/Linux徹底入門第3版 Sarge対応 (JUGEMレビュー »)
武藤 健志
400ページぐらい読了。
徹底入門!
Linuxを導入し始めるという人向けのわかりやすい入門書です。設定項目を一つ一つきちんと説明するので冗長になりがちですが、抜け目はなさそうです。
recommend
 (JUGEMレビュー »)

DirectXGraphicsの関数について丁寧な説明がしてあるという趣向の本。初心者は買い。応用的なところはあんまりありません(6章の半分くらい?)。
recommend
C++の設計と進化
C++の設計と進化 (JUGEMレビュー »)
ビョーン ストラウストラップ, Bjarne Stroustrup, 岩谷 宏, エピステーメ
3章13節まで読了。
recommend
Happy Hacking Keyboard Lite2 USB JP 黒
Happy Hacking Keyboard Lite2 USB JP 黒 (JUGEMレビュー »)

現在絶賛使用中。Professinalは高い。
実用これで十分です。
recommend
Effective STL―STLを効果的に使いこなす50の鉄則
Effective STL―STLを効果的に使いこなす50の鉄則 (JUGEMレビュー »)
スコット メイヤーズ, Scott Meyers, 細谷 昭
欲しい。STL使いは持っていた方がいいとのことです。
sponsored links