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/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
ありがとう
調べてみます

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

>>990
適当な変数にそのﾌﾚｰﾑで一回押されたか押されてないかを記憶しておけばいいんでは？

main{
int space = 0;
　　while(うんたら){ 　　//1フレーム間での処理
　　if (CheckHitKey(SPACE)==1)space=1;
　　Ａ　　；
　　Ｂ　　；
　　Ｃ　　；
　　space=0;
　　ScreenFlip();
　　}

}

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

>>990

「ifの処理があるごと」じゃなくて「ChecHitKey」が実行されるごとだけど、
ご想像の通り、１フレームに何回もチェックしてたら
Aでは行われてBでは行われないって事がおきるはずだね。

994さんが言われてるようにフレームの一箇所でだけチェックして記録しておくってのも手だけど、
やっぱり992さんの言われてるGetHitKeyStateAllが俺としてはお勧めかな。
これはこの命令だけで全てのキーの入力情報を記録するから、
フレームの最初に一回やっておけば、あとはそれを参照するだけでいい。

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

>>992
>>994
説明サンクス
上手くいきました！

>>995
なるほど、やはりでしたか。
それが原因のバグがでてましたがなんとか除けました。

**名前は開発中のものです。** · 2009/03/30(月) 21:58:12

ume

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

ume

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

ume

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

ume

**１００１** · Over 1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

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

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