開発日誌/2009/10月 - Neptune Wiki - Neptune

＞FrontPage＞開発日誌

Neptune Explorer プロジェクト発動・・・！ -　2009/10/26 (月) by myun2

みゅん２「わたしは　いつもおちるか　かたまってばかりの
　エクスプローラに　あきあきしていました。
　そこで　このソフトを　つくったです！」

どうもこんばんは。無駄に某サ○風です。（何

「Neptune Explorer」なるものを作り始めています。
理由は先にひらがなで書いた通り。Explorer の出来があんまりにも酷くて、落ちたりフリーズしたりが多々ある事に起因しています。

更に面倒な事に、Explorerは一つのプロセスでタスクバーも含んで管理しているため、フリーズしたりした際に explorer.exe をキルすると、タスクバーも死にます。
・・・別にそれだけならまだ良いんですが、問題はタスクトレイに置かれるアイコンで、大概のソフトはタスクトレイが復活しても、アイコンがちゃんと出て来なかったりします。
仕方がないので、そういった常駐アプリを再起動・・・非常に面倒です。

そんな時、考えるのは”ファイラー”です。一応当時（4年くらい前ですかね）一通りのファイラーは試してみたのですが・・・イマイチどれもクセがあり、気に入る事が出来ませんでした。

そして最終的には自作を考える訳なのですが・・・まともなモノを作ろうとするならば、結構相当な労力が必要な事は明白でした。
当時は、その思いを胸に秘めつつ、断念した訳なのですが・・・今ようやく、”作ろう！”と言う事に至っています。

理由として一番大きいのは「August Framework 2.0」による所。

MFCは・・・小さいプログラムであれば、むしろ簡単なくらいなのですが、規模が大きくなってきたり、細かい面まで弄ろうとすると非常に面倒な所があります。
そこらへん、August Framework ではかなり改善したつもりで、規模が大きくなってもそれほどプログラマの負担は変化しないようになっているかと思います。（ないし、今そういう風に作っている所）

この August Framework ならば・・・と思ったのです。
更には、DirectXアプリであるため、他のファイラーにはない、非常にグラフィカルな演出が出来るとも考えました。。

それともう一つは「Neptune Project v2.0」と言う計画なのですが・・・これは話し始めると長くなるのでまた別の機会に・・・（ぇ
（と言うかまぁ Neptune Explorer がある程度のレベルにまで成ってきたら、自然に出てくる話と思います。）

＞neptune_explorer_O9.zip

↑がその現状のモノ。・・・でもまだドライブを一覧出来ただけ。（何

そして無駄に、カーソルを合わせるとフェード効果があったりします。背景色は適当にRGB値打ったらなかなか面白い配色になったのでそのまま使用。（何

近いうちにちゃんとディレクトリ間を移動したり、ファイル開けたりと最低限の機能は実装させたいですね。

・・・それにしてもテキスト描画（ID3DXFont::DrawText）が非常に重い・・・。
恐らくHDDをいっぱい搭載しているPCで動かすと、CPU使用率が100%近く（ないしマルチコアなら割るコア数）行くと思います。

現在チケットを切って対策を検討中・・・。ID3DXFont::DrawText に頼らず自前で描画とか、キャッシュするとかその辺りになるんかなぁ・・・。

開発メモ -　2009/10/23 (金) by myun2

アセンブラだとかSIMD命令だとかその辺り。

忘れちゃうのと、今後誰か何かする際にも参考になると思うので、メモっておいてあります。

「俺はこんなライブラリなんかに頼らず、自前でSIMDするぜー！」な人にも参考になるかと思います。（この命令何クロックっぽい、とかも書いてありますよ）

＞http://sourceforge.jp/projects/open-mgl/wiki/%E9%96%8B%E7%99%BA%E3%83%A1%E3%83%A2

switch文 vs if文 -　2009/10/22 (木) by myun2

VC++のコンパイラは結構頭が良い。こんな最適化だってあった。
if elseにしたって、switch文と同性能のコードがされるんだろう・・・と思っていたら、実はそうではなかったようで・・・。

switch文の場合はジャンプテーブルで作成される。アセンブラコードで見ると

jmp   dword ptr  (4012A4h)[ecx*4] 

みたいな風になっている。ecxにはswitch文として指定した数値が入っていて、このアセンブルコードならば 4012A4h にジャンプテーブルが置いてある。ecxに*4しているのは、テーブルに書いてあるアドレスの一つが4バイト（32bit）であるため。後はそのジャンプテーブルのアドレスにジャンプすれば良い。ワンステップ。すごく速い。

一方、if elseの羅列の場合、律義にジャンプテーブルも使わず、一つづつチェックしているようで・・・。
例えジャンプテーブルに変換可能なようなif else文であってもそこまで見てはくれないらしい・・・。当然遅い。

と言う事で、コンパイラが結構頭良くなって来た今の時代でも、こう言った奴は未だにswitch文で書いてあげた方がいいようです。

SIMDとGPGPUとマルチコア -　2009/10/10 (土) by myun2

そういえば、と思い出したネタがあったので。暫く更新してないお詫び的なものも含めて、折角なので。

最近SIMD──まぁSSEとかその辺りですね──とか、GPGPU辺りに関して勉強していたりします。
と言うかアセンブラの勉強・・・かな。とある処理を行うのに何クロックくらいで終わっているのか？と言うのを計算していたりしてます。

なんでそんな事を始めたのかと言うと、August Framework──と言うよりも、そのベースとなっているAGHが、結構複雑で膨大なステップ数になってきたので、 その処理速度が実際の使用に耐え得るのかどうか？と言うのが気になってきたのです。。

結構ゲームプログラミングってのは速度に関してシビアですからね・・・。たった16msの間に（FPS60として）全ての処理を完了しなければなりません。
折角使い勝手の良いフレームワークを作ったとしても、「遅くて使い物にならん！！」では使ってもらえないでしょうから・・・
もし「全然遅くて使い物にならん」と言う事が前もって分かれば、フレームワークの作りを変えるなり、いっそ開発停止と言うのもあり得ますし、
「遅いけど使いやすいフレームワーク」と言う方向性に持っていく事も出来ます。

で、まぁそうやって色々と調べていく中で、「何故この処理はこんなに時間が掛かるのか？」、ないし逆に「何でこの処理はこんなに早いのか？」
等と言う事が気になり始めて、アセンブラ──と言うよりもCPUの中身の事にまで手を出し始めた次第なのです。

元々アセンブラとかそこらへんは、むしろ嫌いな部類だったのですが──まぁそれは当時学生時代。しかも高坊の頃。
その頃に比べたら格段にスキルも上がりましたから。今なら当時ちんぷんかんぷんで訳が分からず
「・・・俺にはCがあるからアセンブラなんか要らないもん！」だったのも、理解できると思ったのです。

で、そうやって勉強していって、x87 FPU命令（浮動小数点計算）は遅いだとか、imul（整数掛け算の命令）は結構遅・・・かったが、昨今のCPUでは3～4クロック程度で終わる事もある、と言う知識を得たりもしました。

最終的・・・と言うか最近の時点では、ついにはMMX命令、SSE命令にまで辿り着きました。また、Intelは次世代SIMDとして「Intel AVX」なるものを考えている・・・といったような事も。
”GPGPU”と言うものも結構本格的に進んできているようで、”CUDA”なる開発環境が提供されている事も知りました。時代はどうやら今後、ベクトル演算前提の世界へと突入して行くようです。

Open-MGL/Neptuneでは元々、そういったCPUのアーキテクチャ・方向性が変わって来ても、ユーザがコードを書き換えずともフレームワーク側で柔軟で対応出来る様にしたいなぁ、と言うのを考えていました。 ・・・現時点では、それに関する実装は何もない訳なのですが・・・。まぁメニーコア時代がいずれ来るだろうから、多スレッドで処理する機構とかを考えないとなぁ、等と言うような事を考えていました。

しかしベクトル演算時代の到来となれば、少し話は違ってきます。単純にマルチスレッド化するだけでは駄目でしょう。並列演算させるよう、専用の命令で書かなければいけないのです。
別にそう言った命令を使うようにするだけならば何ら問題はないのですが・・・現状のフレームワークの構造では、そもそも対応出来ないかもしれません。

・・・まぁ、現状ではまだ「CUDAをPCにインストールしてみた」程度の段階。
もうちょっとGPGPUやSIMD命令に使い慣れてみない事には、どうすればいいかはちょっとすぐには見えてきませんね・・・。
また、聞くところによると、”Larrabee”なるメニーコアCPUも登場する予定だとか。そうすると、時代は・・・メニーコア？それともベクトル演算？それとも両方・・・！？

まぁ現状ではなんとも言えないので、それ一点のみに力を注ぎ込む訳ではなく、「趣味の範囲内で」色々と調べたり、遊んだりしている程度に留めとこうかなと思っています。

無題 -　2009/10/10 (土) by myun2

どうも。最近は全く更新してませんでしたね・・・。

最近はまぁ、相変わらずずっと、Open-MGLプロジェクトの方をメンテナンスしています。
つってもちょこちょこ、Neptuneプロジェクトの方にも幾つかのコミットがされていたりもするのですが・・・まぁそれに関してはまた別の機会に。（何

えーっと、前回の日誌が7/14みたいなので、そっからのSVNログを見てみると───
どうも殆どが、August Framework 2.0 の実装のようですね。

August Framework 1.0 と同程度の機能レベルに持ってくため、結構思いのほか時間を食っていたようです。
んまぁ単に構造を変えるだけでなく、あちこちメンテナンスしたり、使い勝手も相当改善しましたからね。
それから仕事が最近忙しかった、と言うのもあるかと思います。

後は Roast+ の方をちょこちょこコミットしていたようですね。

今後暫く、当面の予定としては、さっきに「また別の機会に」と言っていた奴───を実装するためには幾つかAGHの方を改版する必要がありそうなので、まぁそれと、
後は「エフェクトコントロール」や「コンテナコントロール」に関するチュートリアルを書きたい所。
それと Roast+ の初版をリリースしたいなぁ、と思っています。

結構やること山積みだなぁ。（苦笑

最近は、日誌離れをし、開発中の独り言はぶつぶつTwitterで呟いてたりします。（何

つっても、くだらないポスト（オタ系とか）も多いので・・・Followしようだなんて決して探したりしてはいけません。（何

あと、ロードマップの方にもまとめてしまっていたりするので・・・
別にぶっちゃけ日誌にわざわざ書くような事もないんだよなぁ・・・

そんな訳で、日誌の役割をTwitterかロードマップ、もしくはその両方に移行する、なーんて案もちょこちょこ考えてたりはするのですが、
まだまだ具体的にはまとまってない感じです（Twitterのアカウントは別垢にするか。しないか。でも別垢にしちゃうと全く無更新になって、殆ど現状の日誌と変わらなくて意味なさそうだし・・・とか）。

日誌を自然消滅させてしまう・・・と言うのも手。（何
ぶっちゃけロードマップさえあれば十分かもしんないしねー。

まぁとりあえず暫くは検討中です。