DXライブラリ総合スレッド 2008

**名前は開発中のものです。** · 2008/10/25(土) 17:37:53

Cを習得した程度のスキルでも、
GUIのゲームを比較的容易に作成する事を可能にする、
「DXライブラリ」に関するスレッドです。

DXライブラリの詳細ついては
http://homepage2.nifty.com/natupaji/DxLib/
を参照して頂きたい。

DXライブラリに関するテクニックなどの情報交換などを行う事で、
多くのDXライブラリユーザのスキルの向上に役立てたら幸いです。

過去スレ：DXライブラリ総合スレッド
　　　　　　http://pc11.2ch.net/test/read.cgi/gamedev/1197468399/

**名前は開発中のものです。** · 2009/03/25(水) 09:38:24

でけた　ｔｈｘ

**名前は開発中のものです。** · 2009/03/25(水) 09:51:13

>>891
ちょっと調べたが、簡単には無理っぽいな

試したことが無いが、
SetUseGDIFlag(TRUE)すればコモンダイアログ等のGDIの画面上乗せ出来るようだ。
メインウィンドウのHWND取得して、CreateWindowEx等のAPIで自作したウィンドウハンドルを子ウィンドウとして登録。
メッセージプロシージャ等はAddMessageTakeOverWindowすればコールバックで戻ってくる模様。
.NETではないが、コモンコントロールを扱うのなら、こういう方法しかないとおもう。

ちなみに俺はスクロールバー・ボタン等については必要になった時に自作している。

**名前は開発中のものです。** · 2009/03/25(水) 12:24:54

初心者向け3Dライブラリの条件は
C++でなく、C言語に対応していること
そして、コマンド数が多い事
単純であることだろう、よって複雑な事は出来なくても良い。

DarkGDKのコマンドリストをUPする。
コマンド名を見れば動作の予測ができるでしょう
http://www.csync.net/service/file/view.cgi?id=1237950965

**名前は開発中のものです。** · 2009/03/25(水) 19:28:42

>>893 >>895
レスTHX。ListViewとかボタン（WINAPIと同じ挙動のやつ）を
作るとなるとかなり大変だからManaged DirectXの方でやることにするわ。

**名前は開発中のものです。** · 2009/03/25(水) 21:17:20

>>896
そもそも初心者が3Dに手を出すこと自体にかなり無理があると思うんだが。

**名前は開発中のものです。** · 2009/03/25(水) 22:14:20

Easy3Dは初心者に対しては本当に良く出来てる
HSPで3Dってのが個人的にはありえなかった

**名前は開発中のものです。** · 2009/03/26(木) 00:21:46

そもそも初心者はゲームの作り方自体がわかんないと思うけどなあ

**名前は開発中のものです。** · 2009/03/26(木) 00:33:28

DXライブラリのおかげでなんとかゲームらしきものが作れてるレベルの俺としては
３Ｄものなんて夢のまた夢。

**名前は開発中のものです。** · 2009/03/26(木) 02:33:02

3Dもそこまでハードルが高いとは思わないんだけどさ、
2Dと違って素材集めやモデリングが難しいんだよね。そして興味ない。
さらに3Dで作るゲームにアイデアがない。
最後に、3Dゲーって2Dゲーと違ってしょぼさが如実にあらわれるんだよね。

**名前は開発中のものです。** · 2009/03/26(木) 02:55:38

ハードルなんてあるのか？軸が１個増えた程度にしか･･･。

**名前は開発中のものです。** · 2009/03/26(木) 03:28:44

あたり判定やらモーションが難しいし面倒
衝突した場合、３Ｄの場合は食い込んで表示されて不自然だし
回転とかしたときのモデルの先端の座標やらがイメージしにくい

**名前は開発中のものです。** · 2009/03/26(木) 04:42:32

>>903は次世代コンシューマでメインPGで何作も作ってる程の凄腕のプログラマーに違いない。

**名前は開発中のものです。** · 2009/03/26(木) 06:38:45

カメラを意識しないようなゲームなら、ホントに軸が１個増えただけだと思うよ
計算が複雑になったり、グラフィックに掛ける手間が増えるから
初心者は2Dでゲーム製作に慣れてからの方がいいとは思うけど

**名前は開発中のものです。** · 2009/03/26(木) 06:44:13

PRG作るときのキャラ表示って２次元のグラフィックを三次元空間に配置したほうが楽？
二次元のキャラが２マスのサイズあるので、
NPCの前に立つのと、後ろに立つので被さり表示順序を変えなきゃならん。

３Dならこんなのないだろうになぁ

**名前は開発中のものです。** · 2009/03/26(木) 07:38:35

>>907
3Dでも基本的に同じだよ
奥行きの値で表示順をソートする必要がある

**名前は開発中のものです。** · 2009/03/26(木) 08:50:05

>>907
俺は描画オブジェクトにZ値を持たせ、描画順をstd::listで記憶して表示順序変えてるよ。
Z値が同じ値なら、Y値の設置底面(top+heihtした値)で比較し、ソートする。

たぶんこれが一番楽で一番確実。
毎フレームソートするのはバカらしいから、極力必要最低限の回数にするようにしてね。

**名前は開発中のものです。** · 2009/03/26(木) 09:47:36

>>909
thx.
std::listってc++か・・

**名前は開発中のものです。** · 2009/03/26(木) 09:59:19

そうそう。これを機にSTL覚えなよ。
STLも万能ではないが、知っておくに越したこと無いね。
ちなみに、こういう並び替えが頻繁に行われるものはvectorやmapでもなく、list使うのが良い

**名前は開発中のものです。** · 2009/03/27(金) 07:03:04

オブジェクト指向のｃ＋＋のが、
何人いるかわからないNPCにとっては有効？

**名前は開発中のものです。** · 2009/03/27(金) 08:48:18

有効。C++じゃなくても書けるが、Cで書くよりははるかに柔軟に書ける。
スプライトを扱う基底クラスを継承してNPCクラス作ればいい。

厳密に言うと何人居るかわからないのはSTLのvectorが基本。(俺ならlist使うけどな)
NPC挙動はデザインパターンでいうところのStateかとStrategy

**名前は開発中のものです。** · 2009/03/27(金) 22:11:00

3D版で、衝突したポリゴンから法線ベクトルの取得ってできる？

**名前は開発中のものです。** · 2009/03/27(金) 23:21:19

3Dのスレ立てて、そこで議論しれ

**名前は開発中のものです。** · 2009/03/28(土) 00:15:58

俺は907じゃないけど。

今まで作ってきた２Ｄゲーでは画面表示の優先度が４段階くらいしかなくて
キャラの最大数も固定にして配列を利用して順番に表示していた。

次からはもうちっと一般的な組み方をするようにしようと、
listの使い方をいくつかのサイト巡って見てみたんだけど、どう使うんですか？　これ。

要素を追加とか参照する方法はいいとして……。

例えばDXライブラリ使って表示するとしたら、最低限でも
「表示優先度」「グラフィックハンドル」「表示座標(X,Y)」
が必要なわけですが、このうち「表示優先度」をlistに追加していき、最終的にソート？

でも「表示優先度」だけソートされてもしょうがない。「グラフィックハンドル」とかと繋がってないと。
とするとlistの項目に「グラフィックハンドル」その他も組み込める？

それとも、表示優先度の段階ごとにlistを用意して、それぞれに追加していく？
でもこれだと３Dゲーみたいに優先度がどこまで段階わけされるかわからない場合に使えないし……。

**名前は開発中のものです。** · 2009/03/28(土) 00:32:49

その3つをまとめた構造体をつくって優先度をキーにソートすればいいんじゃないの？

**名前は開発中のものです。** · 2009/03/28(土) 02:01:13

listをどう使うかなんてこのスレに関係ないだろ。

**名前は開発中のものです。** · 2009/03/28(土) 02:05:01

……と自治っぽいことを書いておくと、何故か反発して親切な馬鹿が教えてくれるよ。

**名前は開発中のものです。** · 2009/03/28(土) 09:35:01

>>916
クラスないしは構造体で「表示優先度」「グラフィックハンドル」「表示座標(X,Y)」などの情報をカプセル化して梱包する。
クラスには仮想関数でdraw()を持たせる。
この"クラスのポインタ"をstd::listとしてとあるImageListクラス(Singletonオブジェクト)が一律に保持し、優先度が変更されたタイミングでsortをして常に正しい描画順位になっているようにする。
そして、描画タイミング時(毎フレームに1回)に、drawを優先順位順になめるように実行すれば良い。
これで、簡易な描画システムの完成。システムと呼べるほどの出来ではないけどな。

俺の場合、さらにScreenクラス(独自の座標系とクリッピング領域を持つ)とノード型の親子関係で持たせることで柔軟に対応している。

**名前は開発中のものです。** · 2009/03/28(土) 09:41:07

>>919 - >>920
ﾜﾛﾀ

**名前は開発中のものです。** · 2009/03/28(土) 12:58:40

高度な話してるところ悪いんだけど初歩的な質問をさせてくれ。
ここで聞けって言われたもんで。

メニュー画面とゲーム画面を往復する度にメモリ使用量が上がってくんだけど、
読み込んだものはゲーム画面終了直前にInitSoundMemとInitGraphで全て削除するようにしても
上昇量よりはるかに小さい分しか変わらないし、
じゃあ今度は画像の読み込みを全部削除してみたら（画面は真っ暗になるけど）きれいさっぱり解決したから
やっぱ画像関係に原因があるのはわかったんだけど、

本題
DXライブラリって画像関係で、読み込んだの以外に変なのを生成したりしてるんですか？

あとどうやらそのゲーム画面で初めて登場する画像が描写される度にもメモリ使用量がちょっと上がるみたい。
これも画面真っ暗にしたらきれいさっぱりいった。

**名前は開発中のものです。** · 2009/03/28(土) 13:40:42

>>879
代入なら精度は落ちないけど、計算すると精度は落ちるよ。
double同士の四則演算をすると DxLib_Init前と後で、精度が違うから
同じ計算をしても結果が異なることがある。

**名前は開発中のものです。** · 2009/03/28(土) 13:50:45

>>923
何度読んでも俺には何言ってるのか分からん。
精度が違うって何言ってる・・・。

**名前は開発中のものです。** · 2009/03/28(土) 14:00:54

>>924
わかりにくくてすまん。
例を書いてみた。

double a = 0;

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
double v1 = 3.1415926535897931 + a;
ChangeWindowMode(TRUE);
if(DxLib_Init() < 0) return false;
double v2 = 3.1415926535897931 + a;
return 0;
}
v1と v2の値を比べてみてくれ。

**名前は開発中のものです。** · 2009/03/28(土) 14:04:24

>>925
あ、return falseはまずかった。
return 0の間違いってことで。

**名前は開発中のものです。** · 2009/03/28(土) 14:08:18

あ。わざわざ例挙げてもらってすまん。良いたい事は分かった。
DXライブラリでDirect3D使う場合だとFpuPreserveしてるからdouble型の演算レジスタ弄ってるわけね。
俺3D機能使わずにDirectDrawの方で書いてるから気づかなかったわ。

**名前は開発中のものです。** · 2009/03/28(土) 14:48:40

>>925,926
Direct3DのFPU関連の対処法についてDXライブラリのソース調べてみたら、
// FPUの精度を落とさない設定を使用するかどうかを設定する、DxLib_Init を呼び出す前のみ有効( TRUE:使用する(精度が落ちない) FALSE:使用しない(精度を落とす(デフォルト) )SetUseFPUPreserveFlag( int Flag );
を見つけたよ。
double型を使う場合はTRUEにしても良いかもね。（精度は上がるが速度が落ちるので好みに）

でも、俺はfloat派だから関係ないが～。

**名前は開発中のものです。** · 2009/03/28(土) 15:03:24

パンツってみんな脱いでるの？あとカップルいるけど警察に捕まったりしないの？

**名前は開発中のものです。** · 2009/03/28(土) 16:05:39

>>922
メモリ使用量の上昇具合ってどんな感じ？
コードを晒してくれると原因が分かりやすいんだがな。

画面遷移時に使われなくなったハンドルについて
・イメージハンドルはDeleteGraphで個別に全て解放をしているか？
・フォントの再生成をしていないか？
を見直してみてくれ。
特にフォントは文字サーフェスをキャッシュしているから、DeleteFontToHandleしないとメモリが解放されない。
その上で、フォントの再生成をしてしまうとメモリ使用量がじょじょに増大する結果になるよ。

**名前は開発中のものです。** · 2009/03/28(土) 16:48:52

>>930

・メモリの上昇具合
メ＝メニュー画面、ゲ＝ゲーム画面
メ59M
ゲ108M
メ107M
ゲ112M
メ118M
ゲ124M
メ129M

・イメージハンドルはDeleteGraphで個別に全て解放をしているか？
さっき言ったとおり、Init～で全部まとめて消去してる。

・フォントの再生成をしていないか？
よこわからないがフォント関係はいじらずデフォルト？の文字で単純に出力してるが、それでもアレ？
ていうかさっき言ったとおり画像を読み込むところだけ切り取ったら全部解決したので画像関係のアレだと思うんだが……

**名前は開発中のものです。** · 2009/03/28(土) 17:33:23

切り取らずに、画像を読み込み終えたところでInit～してみたらどうなるかな。

**名前は開発中のものです。** · 2009/03/28(土) 17:40:00

>>931
>ていうかさっき言ったとおり画像を読み込むところだけ切り取ったら全部解決したので画像関係のアレだと思うんだが……
ちょっとこの文章の意味がわからんな。
画像を読み込むのを切り取っちゃったら画像が読み取れないんじゃないか？
それとも、状態変移での2度目に読み込みを飛ばすってこと？
でもその前にInitGraphしてるのなら、グラフィックハンドルは解放されて無効になってるはずだよ。(描画できないはず)

えっととりあえず言うと、画面遷移時にInitGraphで全部消しちゃうのはオススメできない。
使い終わったグラフィックハンドルについては面倒でも個別にDeleteGraphしてみるのが良い。(サウンドもDeleteSoundMemを使う)
俺の場合これで画面遷移時でもメモリ上昇は変わらないよ。

未だ問題あるようなら、同じグラフィックハンドルに画像を読み直す命令としてReloadGraphというのがあるので、これで上書き読み込みする手もある。
あと、DXライブラリでのメモリ使用量と数を確認する命令DxGetAllocSizeとDxGetAllocNumを使って、どのタイミングで発生するのかを確認するのも手。

フォントについてはCreateFontHandleしてないなら問題ないよ。

**名前は開発中のものです。** · 2009/03/28(土) 18:38:40

>じゃあ今度は画像の読み込みを全部削除してみたら（画面は真っ暗になるけど）きれいさっぱり解決したから
>やっぱ画像関係に原因があるのはわかったんだけど、

って事でしょう。

>えっととりあえず言うと、画面遷移時にInitGraphで全部消しちゃうのはオススメできない。

これ、気になるので、よければその理由を教えて欲しい。

**名前は開発中のものです。** · 2009/03/28(土) 19:05:08

>>932　読み込んだ直後にInit～やったけどダメだった。なので

>>933　Deleteでそれぞれやってみたけどやっぱダメだった……
あと、WaitTimerとかでところどころ止めながその隙にタスクマネージャで見る方法でもいいよね？
上昇のタイミングはもちろん画像読み込みの時で、問題なのはデリートの時に少ししか下がらないで、
あと各画像がそのゲーム画面で初めて表示されるときも微量ずつ謎の上昇……

ていうか普通はデリートすればあっさり上がるんだな……なんでデリートがちょっとしか効かないんだ。

**名前は開発中のものです。** · 2009/03/28(土) 19:43:04

>>944
リソースの管理はなるべくプログラマが厳密にした方が良いって理由。
InitGraphだとMakeScreenやMakeGraphやCreateGraphFromSoftImageで作った画像も全部丸ごと削除されてしまうから。
DeleteGraphなら無効なハンドル渡したときに戻り値で-1返すし、どのハンドルが解放されたのかを明示的に指示した方が分かりやすい。
自分はグラフィックハンドル周りはクラスでカプセル化してデストラクタで必ずDeleteGraphして解放するようにしてる。

>>935
>あと各画像がそのゲーム画面で初めて表示されるときも微量ずつ謎の上昇……
これは正常な動作だよ。最初の表示1回目はメモリ確保される。

うーん。どっかでDXライブラリ以外の箇所でnew(malloc)したメモリをdelete(free)せずにメモリリークしてないかい？
MSVC環境なら_CrtSetDbgFlag()があるからチェックしてみて。

**名前は開発中のものです。** · 2009/03/28(土) 20:01:35

>>936　そうか最初の１回は上がって普通なのか。
あとメモリの動的確保ならやってない。画像関係の問題ってわかっててるし。
CrtSetDbgFlagって言うのをググってみたけどデバッグ環境が必要みたいだね。
そりゃ無理な話だ……

あまりしたくないんだけど、ゲーム画面のコードを晒せば原因判明するかな？

**名前は開発中のものです。** · 2009/03/28(土) 20:15:33

Borland C++使ってるのなら_CRT関数は使えない。Microsoft Visual Studio専用関数だからね。
さすがに現状で、要因を探すのは難しいな。

**名前は開発中のものです。** · 2009/03/28(土) 21:42:26

それは……晒しても無駄って意味だよな。

**名前は開発中のものです。** · 2009/03/28(土) 21:46:24

いや、発言だけじゃ原因が特定できないってこと。
コード出してくれればもちろん見るよ。

**名前は開発中のものです。** · 2009/03/28(土) 22:09:09

http://www1.axfc.net/uploader/He/so/210050
pass : dx
根っからの初心者ゆえ、稚拙かつわかりにくいけどお願いします。

**名前は開発中のものです。** · 2009/03/28(土) 22:18:26

>>941
DLしてみたよ。想像以上のソースだったｗ

えっと、原因はLoadSoftImageに対して、DeleteGraphを使ってるところ。
DeleteSoftImageを使いましょう。

**名前は開発中のものです。** · 2009/03/28(土) 22:39:34

ちょ、ちょっと待っててね……そのまんま範囲内全置換しても強制終了する。原因究明中。

**名前は開発中のものです。** · 2009/03/28(土) 22:50:21

凄まじいソースだなｗｗ

**名前は開発中のものです。** · 2009/03/28(土) 22:58:12

前にもこんなソースを見たことがあるぞ

**名前は開発中のものです。** · 2009/03/28(土) 23:17:44

ID:8c8Vy+u+ありがとう！　100kぐらいずつしか上がらなくなった！　感謝感激雨霰、３か月悩み抜いた甲斐があったってもんですぜ。

>>945　晒したのは初めてだぜ。

あと、ソース長くてもミスが見つかりにくくなるぐらいなもんだよな、問題は……

**名前は開発中のものです。** · 2009/03/28(土) 23:23:41

>>あと、ソース長くてもミスが見つかりにくくなるぐらいなもんだよな、問題は……
それが一番困ると思うぜ

**名前は開発中のものです。** · 2009/03/28(土) 23:27:14

分割ｵﾇﾇﾒ
れっつextern

**名前は開発中のものです。** · 2009/03/28(土) 23:29:47

ああそうか。externが原因の１つかもしれないと思ってできるだけ避けてたんだ。
だけど大丈夫なのか。じゃあ関数使いまくれるぜ。

**名前は開発中のものです。** · 2009/03/28(土) 23:30:56

>>946
ういうい。どうもです。
コード晒すのは勇気いるけど、コードを隠すプログラマは例外なくダメプログラマに育つからね。
その点、コードを出したのはすばらしいと思うよ。3ヶ月悩んだものがコード出したら10分足らずで解決できたように早期解決できるし両得だ。

あと、デバッグ環境が無いみたいだけどVisual C++ 2008 Express Edition(無償)を使うと良いよ。
http://www.microsoft.com/japan/msdn/vstudio/Express/
デバッグが使えるのは大きいし、コンパイラの性能が良いから、Borland C++5.5よりも大体1.2倍ぐらいはプログラムが速くなるさ。

**名前は開発中のものです。** · 2009/03/28(土) 23:46:31

なんかSP1てついてるけどこれでいいんだな……やてみるぜ。ありがとう。

**名前は開発中のものです。** · 2009/03/29(日) 00:08:50

>>951
そうそう。それでok
VS2008へのDXライブラリの組み込み方はDXライブラリ公式サイトに書いてあるよ。
http://homepage2.nifty.com/natupaji/DxLib/dxuse_vc2008express.html

**名前は開発中のものです。** · 2009/03/29(日) 00:20:45

>>945
おそらくそれはしょぼんのアクションだ。

**名前は開発中のものです。** · 2009/03/29(日) 00:33:04

>>953
ああ、それだわ
>>136-145 あたりでも話題になってるな

**名前は開発中のものです。** · 2009/03/29(日) 00:39:32

>>953
すごいなこれ。
リファクタリングの腕がつくから試してみようかと思ったが、
さすがにマジックナンバーが多すぎてちょっと無理っぽいわ。

//自由な値
int xx[91];
double xd[11];
string xs[31];
とか無茶すぎるだろｗ

**名前は開発中のものです。** · 2009/03/29(日) 00:56:39

BCCdeveloperでは大丈夫だったのに
全部の関数で「～で既に宣言されています」
って出る……何のためのヘッダだよ……

**名前は開発中のものです。** · 2009/03/29(日) 00:57:59

あ、ID変わってる。どうも、ショボン二世です。

**名前は開発中のものです。** · 2009/03/29(日) 01:00:10

>>956
ヘッダの先頭に
#pragma once
と書く

**名前は開発中のものです。** · 2009/03/29(日) 01:04:35

#pragma onceだとVCでしか使えないから、
正確にはインクルードガードをするのが良いんだけどね。(__HOGE_H__は自分のヘッダファイル名)

#ifndef __HOGE_H__
#define __HOGE_H__
（ヘッダ本文）
#endif // __HOGE_H__

ま、どうせVCしか使わないんだろうからどっちでも良いよ。

**名前は開発中のものです。** · 2009/03/29(日) 01:19:07

3ヶ月解けなかったものを10分で解けちゃう人がいると聞いて飛んできたわけじゃないんですけど、
C++でメンバ関数ポインタって使ってもいいもんなんですかね。
goto思想のようなものでもお行儀のようなものでもいいんだけど、普通はどんなもんか教えてください。
ついさっきメンバ関数ポインタっぽいものがあったらスマートに書けるなーと思って検索したら発見しました。
もし具体例が必要なら提示しますので教えてください。

**名前は開発中のものです。** · 2009/03/29(日) 01:22:41

全く意味がわからない｡･ﾟﾟ(ﾉД`)
今まで何を勘違いしたか知らないけどヘッダファイルに直接関数を書いてた。
BCCに帰りたくなったけど少しでも軽くするためにがんばります。
修行の旅に出ますありがとうございましたﾉｼ

**名前は開発中のものです。** · 2009/03/29(日) 01:39:41

>>960
staticなメンバ関数について関数ポインタをとるのなら文法的には合ってるが作法的にはよろしくないとは思う。
(クラスは設計者と利用者が異なる観点ではオーバーライドされる可能性があるという意味で。)

けれど仕様上、静的なコールバックを要求する場合(Windowsメッセージプロシージャ等)だと、
staticなメンバ関数を指定した方が読みやすいと俺は思う。
この場合、staticメンバ変数から、Singletonオブジェクトを参照してインスタンスを得る方法を自分は多用しています。

自分で設計するのであれば、C++なら関数ポインタを使わずに、インターフェースクラスから派生する手法だったり、
純仮想関数をオーバーライドする設計(いわゆるStrategyパターン)を使うかな。

ただ、タスクのようなごった煮の振る舞いをしたいのであれば関数ポインタを使うこともしばしばあります。

**名前は開発中のものです。** · 2009/03/29(日) 01:41:04

×この場合、staticメンバ変数から、Singletonオブジェクトを参照してインスタンスを得る方法を自分は多用しています。
○この場合、staticメンバ関数内で、Singletonオブジェクトを参照してインスタンスを得る方法を自分は多用しています。

**名前は開発中のものです。** · 2009/03/29(日) 02:00:32

>>962
staticではないメンバ関数ポインタでした。
個人製作だから、という言い訳の前提のもと、シングルトンデザパタとかも使わずアプリケーションの最初で１つ生成し、アプリケーションの最後で破棄されるっていうクラスの中なんですが、
staticなクラスにするのもいいのですが今回の話とは関係なさそうなので割愛します。

問題の箇所は、MyClassオブジェクトを生成したint main()から見て、あるMyClass.A()は特定の１度しか呼ばれず、あるMyClass.B()は1フレーム中で毎回呼ばれます。
そして、MyClass.B()はMyClass.C()やMyClass.D()やMyClass.E()のうちどれかを呼びます。
当然B()に呼ばれるC()やD()やE()も毎回呼ばれないと困るのですが、呼ぶ先のメソッドが変わっても困るのです。
そこで、例えばランダムにC()D()E()のどれか一つを呼ぶことを決定したいのですが、
フラグ等を使ってB()内で一度だけ決定するのもいいのですが、
A()で決定しメンバ関数ポインタに入れておき、後にB()で決定された先を読んでもらおうという感じです。
A()では同じような処理を複数するので一括しておきたいのと、C()D()E()のようなメソッドはさらに多くあるので
A()内でメンバ関数ポインタで管理した方がいいかなと思いました。
乱文ごめんなさい。

**名前は開発中のものです。** · 2009/03/29(日) 02:22:47

>>964
言っていることをそのまま実装すると
staticでないメンバ変数の関数ポインタ(MyClass.B()～C())を参照するとエラー出るよね。
「仮想関数のポインタが参照されました」というのが。

デザパタを使いたくないのであれば、方法は1つしかない。

メンバ関数のアドレスをthisポインタからのオフセットアドレス値から算出するという手段で、けっこう裏技。
かなりの裏技でC++に熟知してないと普通は使わない方法だね。
実装方法は
http://www7b.biglobe.ne.jp/~robe/cpphtml/html03/cpp03057.html
このサイトの57章と58章に書いてあるよ。

**名前は開発中のものです。** · 2009/03/29(日) 03:00:28

>>965
まさにそのサイトも見て実装しました。
そしてまさにその使い方の事を聞きたかったのです。分かりにくい説明でごめんなさい。

ただ参考になりました。ありがとうございました。
デザインパターンも勉強してみて試行錯誤してみたいと思います。

蛇足ですが、C++でゲーム作ると（staticな?）アプリケーションクラスを一つ作って、
int main()の中のメインループの中でアプリケーションクラスを呼び出すことから始まりますよね。
で、オブジェクト指向っぽく設計とか考えてやっても結局アプリケーションクラスの中でCの構造化プログラミングをしてるだけっぽくなっちゃってました。
今回もメンバ関数ポインタを呼ぶのも関数ポインタを使った構造化プログラミングっぽいです。。
他の人のソースを眺めてみると頻繁にインスタンスを生成したり破棄したりしてますが、
自分の書いたものはあまりせず、結局全部グローバル関数でも同じじゃん！みたいななっちゃいます。
一応継承とかも使ってみるも、ちょっとしたコードの再利用程度でしかなく、ポリモーフィズムなんて実現できないです。
まあ経験が足りないんでしょうね。。精進します。

**名前は開発中のものです。** · 2009/03/29(日) 03:09:57

>>964のやりたい処理はこれでＯＫなハズ
サンプルソース書いたよ
http://www.dotup.org/uploda/www.dotup.org13651.cpp.html

**名前は開発中のものです。** · 2009/03/29(日) 03:21:31

>>967
わざわざありがとうございます。
ソース見させていただきました。
ほぼ同じように実装しました。
実際にはポインタに入る関数はA()が決めるのですが同じですね。

**名前は開発中のものです。** · 2009/03/29(日) 03:22:49

>>960
普通につかって全く問題ない。Cとは表記が違うのだけ注意。
他のクラスには適用できないし、キャストも許可されないので、むしろCより安全に使える

>>964だとこんなかんじ

class Hoge {
public:
Hoge() : target(NULL) {}
typedef void (Hoge::*TargetType)(int param);
TargetType target;
void A() {
TargetType funcs[] = { &Hoge::C, &Hoge::D, &Hoge::E };
target = funcs[rand() % 3];
}
void B(int param) { (this->*target)(param);}
void C(int param) { printf("C called:%d", param);}
void D(int param) { printf("D called:%d", param);}
void E(int param) { printf("E called:%d", param);}
};

>>965
「メンバ関数ポインタ」について調べることをおすすめする

**名前は開発中のものです。** · 2009/03/29(日) 03:25:13

てか、965さんちゃんとわかってるんじゃん…

裏技でもなんでもないよってことで。

**名前は開発中のものです。** · 2009/03/29(日) 03:30:37

>>966
おっと、書き込む前にリロードすればよかった。
デザパタは相当C++やJavaが相当手馴れた頃に初めて見てみると、目から鱗な考え方なんだ。
素人が下手に手を出しても意味が分からないまま終わっちゃう。
大規模アプリを作れるレベルになって設計と実装に悩みだした頃に読むと良いよ。
ゲーム製作に特に使うのはSingleton,Strategy,TemplateMethod,Facade辺り。次にAbstractFadtoryやObserver。後のはほとんど使わない。

オブジェクト指向がする必要の無い局面って結構あるから、
何が何でもオブジェクト指向にこだわって実装していくのも逆に生産性が下がるというのは966も体感していると思う。
クラスは拡張性と多様性を残しつつ、YAGNIの原則で最低限だけを実装していく。というのが一番の理想。これが中々難しいけどね。
自分は、時にベタのCで書くこともあって、C++じゃご法度なextern宣言も使ったりする。(理由はめんどくさいという一点で)
インスタンスの生成/破棄はなるべく少ない方がパフォーマンスはモチロン出るので、966の書くプログラムは良いコードだと思うけどね。

**名前は開発中のものです。** · 2009/03/29(日) 03:33:52

ちょっと補足。

同じようなオブジェクトの微妙な動作違い、なら、設計的には
インターフェースを継承してオーバライドしたほうがいい。

この手法は同一オブジェクト内でのステート処理にむいてる。
何度も呼ばれて判定のオーバーヘッドの影響が無視できないような場合には特に有効。

**名前は開発中のものです。** · 2009/03/29(日) 03:40:51

>>970
もちろん知ってるさ。C/C++は20年選手に逝きそうなんだ……。
裏技扱いしたのは、理由があって、
多重継承をした仮想関数(純ではない)のアドレスを取得しようとして、thisポインタのサイズ(4byte)が変わる為に上手くアドレスが取れないことが以前にあった。(オフセット値がなぜかずれるためにアラインメント調整が必要になる)
という理由でコンパイラによっては非推奨な書き方だったりするんだ。
これはコンパイラのバグで、TurboC++ではダメだった記憶がある。
MSVCではたぶん大丈夫だが、一応使わないでおこうとしてた。

**名前は開発中のものです。** · 2009/03/29(日) 03:45:29

ごめん。TurboC++だったか記憶にない。CodeWarriorだったかもしれん。
どちらにしても15年前ほど前の事だったからたぶん今では問題ないと思う。

**名前は開発中のものです。** · 2009/03/29(日) 03:45:43

>>969
ふむふむ、全く問題ないのですね！
提示してくれたソースもよくわかるのですが、た…typedef…。
勉強不足のためなんとなくでしかわからないですがなんとなく分かった感じです。
こんな感じでもいいですかね？
class Hoge {
public:
void (Hoge::*pf)(int param);
void A(int x) {
if(x == 0) pf = &Hoge::C;
if(x == 1) pf = &Hoge::D;
if(x == 2) pf = &Hoge::E;
}
void B(int param) { (this->*pf)(param);}
void C(int param) { printf("C called:%d", param);}
void D(int param) { printf("D called:%d", param);}
void E(int param) { printf("E called:%d", param);}
};

int main(){

Hoge obj;
int i;
scanf("%d", &i);
obj.A(i);

obj.B(10);
return 0;
}

**名前は開発中のものです。** · 2009/03/29(日) 03:53:35

大先輩！失礼いたしました…

あー、コンパイラのバグ……。そういうのは一度ふむと使わなくなりがちですな（苦笑）

状態遷移系の処理の他だと、半自動のバインド処理の類を書くときとかに、
テンプレートと組み合わせてばりばり使ってたりします。

**名前は開発中のものです。** · 2009/03/29(日) 03:57:18

>>975
typedefは、宣言した複雑な型をシンプルに表記できて、
書き方覚えるととてもすっきりするので、時間あったら勉強してみてください

表記はそれで特に問題はないですが、その条件判定なら
switch　つかったほうがいいと思いますです。

**名前は開発中のものです。** · 2009/03/29(日) 04:13:27

なんという頼もしいスレ…
起きててよかった。
勉強してきます=3

**名前は開発中のものです。** · 2009/03/29(日) 07:10:28

まーたDXライブラリと関係ない話して。
初心者相手に技術自慢したいならc++関係のスレに行けばいいのに。
そこでは相手にもされない程度なのか?

DXライブラリ

**名前は開発中のものです。** · 2009/03/29(日) 07:26:38

それだけのベテランがDXライブラリを使ってる（のだろう）事が驚き。

俺はCについてはド素人同然なので、いろいろ教えてもらえるのは助かる。
確かにスレ違いではあるんだが、DXライブラリを使ってること前提で
話をしたい場合もあるし。

**名前は開発中のものです。** · 2009/03/29(日) 10:08:36

>>980
趣味でゲーム作ってるのが長い人には、Ｃの書き方でパパーッと書き上げる事もできるし、
（Windows95の頃から始めたような人なら短いものならOOじゃない方がある程度の大きさでも楽だったりするしね。）
３Ｄに手出す（主にデータ的な部分）のが面倒な人には、
余計なモンついてなくて２Ｄに特化してるのに、　変な癖が少ないから使いやすい。
あと、最初からゲームパッドとかに対応は何気に使えるし。

車輪の再開発をやってきた様な人には、
ソースもあるからちょっとだけ手を加えたい時とかも　其れが可能で、
わざわざRequestしないで良いのは、時間的にもモチベーション的にも良い選択肢。

初心者にも優しいライブラリだけど、其れだからといって
昔のＨＳＰみたいに、他の言語知ったら使いたくなくなるような不自由さがあるわけでもない。
まぁ、DirectXバリバリつかうぜ!!って人とかには別だろうけど。

**名前は開発中のものです。** · 2009/03/29(日) 12:18:31

>>973
それバグでもなんでもねえし、
ポインタのサイズは変わらないだろ

**名前は開発中のものです。** · 2009/03/29(日) 13:11:06

普段はこのスレは過疎ってるから別にいいじゃないのか？　DXライブラリでゲーム作るテクとしてメンバ関数ポインタを使うこともあるかもしれないしさ。

>>982
正確に書くと、継承した場合のメンバ関数ポインタのサイズが4バイトとは限らない(コンパイラ依存)
多重継承や仮想継承をしている場合、正しいポインタサイズを返すために8バイトや12バイトとなることがある。
しかし、昔のバグコンパイラではこの点が考慮されておらず必ず4バイト固定だった時代があり、派生や仮想関数を呼び出そうとするとアラインメントを調節する必要があった。
ということ。ポインタは必ず4バイトというのは早計だよ。

**名前は開発中のものです。** · 2009/03/29(日) 18:18:24

>>983
何故得意気なのか理解できんが、
それはサイズが変わるとは言わないだろ？
結局のところ、静的なサイズは確定している。

**名前は開発中のものです。** · 2009/03/29(日) 21:00:34

>>984
RTTIしていると大問題。

なんか、微妙にスレ違いだし、
偉そうにしているといわれたようなので黙って老害は去りますね。
失礼しやした。

**名前は開発中のものです。** · 2009/03/29(日) 22:56:36

どこが得意気なのやら

で、次スレはどうするんよ

**名前は開発中のものです。** · 2009/03/30(月) 00:07:56

DXライブラリ総合スレッドその３、で建てればいいんじゃね。

**名前は開発中のものです。** · 2009/03/30(月) 01:19:18

>>990頼んだ

**名前は開発中のものです。** · 2009/03/30(月) 01:54:36

>静的なサイズは確定している

> RTTIしていると大問題。

会話になってねぇww

**名前は開発中のものです。** · 2009/03/30(月) 18:27:06

質問です

{
{ 　　//1フレーム間での処理
　　Ａ　　；
　　Ｂ　　；
　　Ｃ　；
}
ScreenFlip();
}

すごく大まかに言って↑このようにゲーム作ってるのですが
CheckHitKeyの判定ってって「フレームの最初のみ」に行われるんでしょうか？
それとも「ifの処理があるごと」なんでしょうか？

もし後者ならif CheckHitKey(SPACE)==1　みたいな処理をＡ部とＢ部両方に入れた場合、
Ａが行われてる瞬間にＳＰＡＣＥ離しちゃったら
Ａは行われてＢは行われないっていうことも起きちゃうんでしょうか？

**名前は開発中のものです。** · 2009/03/30(月) 18:39:19

最初の大括弧はmainでその次はforとかのループの括弧か…？

**名前は開発中のものです。** · 2009/03/30(月) 18:42:02

int GetHitKeyStateAll( char *KeyStateBuf ) ;
を使えば起きない

**名前は開発中のものです。** · 2009/03/30(月) 18:43:28

>>991
そんな感じです。すみません。
>>992
ありがとう
調べてみます

DXライブラリ 総合スレッド 2008

DXライブラリ総合スレッド 2008