MFC その２

MFCでダイアログボックスが簡単に作れる事に気付いたので、

武器データをINIからダイアログで管理できるようにプログラム中です。

こんな感じで。

やはりダイアログで管理できると楽ですね。

MFC

VisualStudioを使い始めて１年経ち、初めてMFCを使ってみました。

使ってみた感想は・・・。すごく簡単。

Windowsプログラミングは面倒だと思い、今までゲーム製作用のツールはコマンドラインベースで作ってたのですが、まさかダイアログボックスがこんなに簡単に作れるとは。

１時間程度MSDNとgoogleで調べれば基本的なところは理解できてしまいますね。

キーコンフィグのダイアログボックスもMFC使っていれば少しは早く作れたかも。

ただ、良いとこだけではないですね。

CStringとか独自の形式が邪魔なのはなんとも。

別にC++には標準でstringありますし、要らないと思うのですが・・・。

CStringからchar *に変えるのは１行で済みますけど、その方法を見つけるまでが大変なんですよね。

製作情報

ファイルの読み込みにバグがあって修正していたら結構な時間が掛かってしまいました。

というわけで今回の画像

※画像は開発中のものです

ヒットすると赤くなるようになっています。

表示にRが４個並んでいます。これは、武器のリロードが完了しているかどうかを表しています。

K,Dは倒した数、倒された数です。

４人対戦にしてみると画面がごちゃごちゃしてるのがちょっと気になったり。

あとフレームレートが相変わらず悪いですね・・・。

FPS４０程度になってしまいます。単純に４回描写しているのでそのぐらいになるのは仕方ないのかも。

製作情報

対戦設定が３割ぐらいできました。

今回は特に見た目の変更がないので画像はなしです。

仕様の追加として、ダメージを受けた時ロボを真っ赤にすることで当たっているかどうかが分かりやすくなりました。今まではゲージが減っているかでしか判断できなかったので良くなったかも。

また、一人用のとき、ロボの色がランダムで変更されるようになりました。

微妙な色が多いですが。まあ・・・元々グラフィックはしょぼいので別にいいかな。

他にも、スプラッシュダメージをいままで設定してなかったので設定しました。ただ、スプラッシュ範囲が分かりにくいので、その辺をどうにかしたいところです。

他にもヒットした時の火花や爆発の描写の時レンダーステート変更を行う回数を減らしました。

ほんのわずかな高速化（笑）

完成度：75％

製作情報

最近忙しくて、なかなか更新できませんでした。

久々の更新。最後の製作情報は１ヶ月以上前ですね・・・。

また製作開始しました。出来れば一気に完成させてしまいたいところです。

というわけで、新たな画像を。

※画面は開発中のものです

ゲームオーバーの設定も完成。

一人用はほぼ出来ています。

あとは対戦や、COMの思考の強化、細かい仕様追加が出来れば公開できるレベルになると思います。

アイテムを追加しようかどうか悩んでいるのですが・・・、面倒なので入れないかもしれません（笑）

完成度：70％

３Dアニメーション

DirectXでモデリングデータを使用する場合Xファイルを使います。

アニメーションに対応しているのですが、メタセコイアだとアニメーションを付けられません。

アニメーションも作れるモデリングソフトで安いものというとLightWaveが有名ですが、それでも非常に高いですね。

私はモデリング専門ではないのでポリゴン数が少なく単純なものしか作れません。

そんなものにアニメーション付ける為だけに５万円も払ってられないので、フリーソフトでいいものが無いかと探してた時があったのですが・・・見つからず。

結局そのときは諦めたのですが、久々に探していたら見つけました。

http://www5d.biglobe.ne.jp/~ochikko/index.htm

MQO形式からアニメーションが作れて、Xファイルで出力可能でフリーソフト。

素晴らしいです。

まだDLしただけなので使い勝手などは分かりませんが、これから色々と調べてみようかと思います。

バグの無いプログラム

久々の更新となってしまいました。

普通にネタ切れだったり・・・。

さて、本題です。

例の感想文の本のネタですが、面白いものがありました。
要約するとこんな感じです。
「バグが無いプログラムをつくるにはプログラムが正しいことを証明すればよい。」
いや、そんな簡単に言いますがどうやって証明するんですか。
sinを求めるプログラムなんていうものであれば数学的に証明できるので良いですが、ゲームでプログラムが正しいことを証明せよって言われても無理です。
絶対不可能とはいいませんが、多分証明できた頃にはOSが５世代くらい先になってそうです。
現状では不可能なこと載せられても、トリビアにしかならないのですが・・・。

しかし将来コンピュータの性能が凄まじく上がればこれも現実的なデバッグになるのかもしれませんね。

量子コンピュータが実現すると今の１０億倍以上の性能になるといわれてます。

IBMが２０年後に実現させようと頑張ってるそうですし、もしかすると１００年後あたりには現実的なデバッグになってるかもしれませんね。

ソートアルゴリズム

テーマとしてはプログラミングかなとも思ったのですが大したこと書かないのでブログにしました。

ソートアルゴリズムというと色々あります。

私がアルゴリズム含め知っているソートは

O(n^2)で単純選択法、バブルソート

O(n log n)でクイックソート、マージソート、ヒープソート、直接挿入法

でしょうか。他にもなにかあったかもしれませんが、今ぱっと思い浮かぶのはこのくらいです。

有名なのはバブルソートと、クイックソートでしょうか。

他のソートはあんまり使われないかも。

バブルソートなんかは簡単に実装できますが、クイックソートは再帰関数かスタックを使わないといけないので何気に面倒です。

でもCの標準関数にqsort関数があります。

恐らく他の言語でも同様の関数はあるでしょう。

一から作るのも大変ですし折角なので使っちゃいましょう。関数のポインタがあってちょっととっつきにくいかもしれませんが、慣れれば簡単です。

ソートなんかゲームで使うの？

とか思うかもしれませんが使うときは使います。

たとえば半透明のものを描写する場合、奥から描写していかないと上手く表示されません。なので奥行き順にソートする必要があります。Zソートと言ったかな？（自信なし）。

今作っているゲームでは現状でも重いのでアルファテストでそれっぽくみせてるだけでZソートは使ってませんが・・・。

製作情報？

DirectXヘルプにて「Direct3D API 呼び出しの正確なプロファイル」というところがあります。
その付録にレンダリングステートを変更した時に掛かるコストについてかかれています。
意外とコストかかるものですね・・・。
マルチターゲットレンダリングなんかかなり重そうな気配が・・・。
というわけでマルチターゲットレンダリングを減らしました。
また、レーザーを今までD3DXLineで描写してたところをポリゴンで表示させるようにしました。
ちょっと違和感がありますが許容範囲ってことで・・・。
それでもまだまだ重いので色々と修正した方が良さそうです。

C++の素敵機能、ビットフィールド

C++は非常に多機能です。
そんななかでなかなか面白い機能があったので紹介します

ビットフィールド
フラグを管理する場合はON/OFFなので１ビットで済みます。
ところが、bool型は通常１バイト使用しますし、Windowsプログラミングで使う
BOOLだとint型で４バイト使うことになります。

「フラグを３０個管理したい。でもメモリを極力節約したい。」

こんな時int型は32ビットマシンなら32ビットなのでint型変数１個で代用できます。
しかし、処理を行うとなるとマスクかけたりビットシフトしたりとかなり面倒です。それを解決するのがビットフィールドという機能なわけです。
ビットフィールドは構造体に宣言することが出来ます。

struct bit{
unsigned int bitA : 1;
unsigned int bitB : 1;
unsigned int bitC : 1;
unsigned int bitD : 3;
};

型 変数名 : ビット数;
といった形ですね。型はunsigned intを使うことが多いようです。
実際に使うときは

struct bit b;
b.bitA=1;

みたいに変数のように扱えます。
bitA,B,Cには0か1、bitDには0～7を代入できます。
勿論構造体なので、ビットフィールドと普通の変数の混在も可能です。

これで終わらない機能
例えば次のような場合どうでしょうか
struct bit{
unsigned int bitA : 1;
unsigned int bitB : 30;
unsigned int bitC : 10;
unsigned int bitD : 10;
};

この場合32ビットに入りきりません。int型２つ分に分けられます。
すると、このようになります。

32bit			32bit
1bit	30bit	bitCの1bit	bitCの9bit	10bit	余り

bitCを扱う場合に処理が重くなるのは分かりますね。
ところが素晴らしい機能を持つC++。

名前なしでビット幅0という特殊なものを使うと、強制的に次の語に行きます。

つまり

struct bit{
unsigned int bitA : 1;
unsigned int bitB : 30;
unsigned int 　　 : 0;
unsigned int bitC : 10;
unsigned int bitD : 10;
};

とすると

32bit			32bit
1bit	30bit	余り	10bit	10bit	余り

のようになります。
また、名前なしでビット幅ありにすると・・・。
struct bit{
unsigned int : 1;
unsigned int bitB : 1;
unsigned int : 24;
unsigned int bitC : 5;
unsigned int bitD : 1;
};
こんな感じになります

32bit
1bit(使用不可）	1bit	24bit(使用不可)	5bit	1bit

凄い機能です。

マニアックすぎる。
しかし、今メモリはギガバイトの時代です。
普通に考えてビットフィールド自体使わない気がしてならないのですが・・・。

無いよりあった方がいいってことですかね。

BOOL型1000個作っても4KBですしあまり利点なさそうなのがなんとも。