DXライブラリ総合スレッドその3

**名前は開発中のものです。** · 2009/03/31(火) 01:14:36

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

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

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

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

**名前は開発中のものです。** · 2009/07/14(火) 04:49:20

＞とりあえず、タスク　がタスクマネージャーとかのタスク（application)の事なら、
その通り

＞単純にどっかが無限ループに嵌ったか、画面書き換えの部分を通らなくなったか（orキー入力の部分を・・・）
＞だろう。
そういった部分は見当たらなかった

何せＯＳを再起動させてそのプログラムを再び実行させたら何の問題もなく動いたのですからプログラムに原因があるとは思えないのですが

**名前は開発中のものです。** · 2009/07/14(火) 05:07:49

そういう現象が出てるのが君だけなんだから君のプログラムに問題があるか、
あるいは君だけが体験できるくらいレアな現象って事になるだろう？

調べる事ができるのは君だけなんだから
素直に>>680の忠告に従って、きちんと調べていけばいい。

「これで合ってるはず」なんて余計な「思い込み」はデバッグ作業の邪魔にしかならないぞ。

**名前は開発中のものです。** · 2009/07/14(火) 05:36:27

>>681
それだけの事で、プログラムに問題があるとは思えないって・・・・

とりあえず、
初期化なしでつかってる場合にはOS再起動とかで簡単に変わるし、
時間取得なんかをちゃんと処理してないと、
日にち跨ぎや時間跨ぎで、発生したりしなかったりする。

>>682も言うとおり、思い込みよりも手を動かしてデバックしなぁ。
プログラムは書いた通りに動いても、思った通りには動くとは限らないんだからさぁ。

**名前は開発中のものです。** · 2009/07/14(火) 06:46:29

だってデバッグしたけど分んないんだもん
まあ動くようになった訳だからそのまま何事もなかったかのように過ぎていくのだろう

**名前は開発中のものです。** · 2009/07/14(火) 07:14:55

forやwhileで使ってる変数の初期化忘れあたりが怪しいけどどうなんだろうな

**名前は開発中のものです。** · 2009/07/14(火) 07:53:46

それはないと思うがなあ
その可能性のあるコードって、(実行時に処理を通ってるコードの中で）
while( (!ProcessMessage()) && (!keybuf[KEY_INPUT_ESCAPE]) )
しかなかったんだが（変な書き方でｽﾏｿ）
確かに　keybuf　はグローバル変数にしてしまってるし
char keybuf[256] = {0};
で初期化したつもりになってるけどどうなんか分らん
まあ動くようになったし確認しようにももうできないからな、動くから
まあ良しとして続けるしかないな

**名前は開発中のものです。** · 2009/07/14(火) 08:07:50

こうしてバグが量産され、ついにはうんともすんとも動かなくなりねあげる姿が

**名前は開発中のものです。** · 2009/07/14(火) 09:43:25

裏画面の内容をテクスチャにコピーする関数ってあったっけ？

**名前は開発中のものです。** · 2009/07/14(火) 20:58:42

「無いと思う」とかじゃなくて確かめないと。
プログラムに思い込みは絶対あかん。

**名前は開発中のものです。** · 2009/07/14(火) 23:37:46

だって動くようになったから確かめようがないじゃん
この先動かなくなる可能性ないわけではないが
そうなったところでこれ以上バグは見つからんだろうな、俺の力では

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

だからprintfとかで一つ一つ処理の中身を吐き出して見るんじゃん。
外見上動いてても、バグがあれば意図してないデータが含まれてる。

**名前は開発中のものです。** · 2009/07/15(水) 01:08:24

うーん、やっぱりバグがあるとはどうしても思えないし
多分printfとかで一つ一つ処理の中身を吐き出して見てもどの道今の俺の能力では
バグを発見できるとは思えないから忠告はありがたいがこのままいくことにするわ
以前も同じようなこと何回かあったしそんときもちゃんと完成まで漕ぎ付けているし

**名前は開発中のものです。** · 2009/07/15(水) 01:17:22

ID:wRlAP6qv
ID:ouOmT7td
お前さ、そんなスタンスなら、なんでわざわざここに書き込んだわけ？はじめから書き込むなよ。
なに、構って欲しかった？わざわざお前の書き込みに一生懸命考えてレスしてくれた
人達に失礼だと思わないの？

**名前は開発中のものです。** · 2009/07/15(水) 01:49:11

実際問題、再現性のないバグを修正するのは難しいよ。
プログラムを書いた本人に見当がつかないなら、他人の経験に頼るのも良いと思うよ。
自分がそんなバグにぶち当たったとしても根気だけで調べようとは思わないな。
時間が余ってるなら別だけど。

で、他人の立場から言うと、あれだけの情報で問題のありそうな点を指摘するのは無理だ。
アドバイスとしてはバグ発見を諦めるのではなく自分用バグリストを作ってそこに追加しろ。

**名前は開発中のものです。** · 2009/07/15(水) 02:09:56

何かヒント得られると思って…
でアドバイス通りに考えてみたけど駄目だった

**名前は開発中のものです。** · 2009/07/15(水) 02:15:50

>>695
そうか、お疲れ。
コード晒す勇気があれば、案外デバックしてくれる人が居るとおもうけど…
（自分一人だと考えがなかなか間違いに気付きにくいからコードレビューは有効だと思う）

　「アドバイス通りに考えてみた」ってのは、
もちろん、printfとかでデバック情報をポコポコ吐き出させたけど、バグらしき場所が見あたらなかった
って意味だよね。念のため。

**名前は開発中のものです。** · 2009/07/15(水) 02:28:23

ソースうｐしろ
無理なら帰れ

**名前は開発中のものです。** · 2009/07/15(水) 06:33:25

最小のコードを切り出してる最中に問題が解決することって結構あるよね？
俺だけ？

**名前は開発中のものです。** · 2009/07/15(水) 07:55:06

あるある
意外とバグって見当つけてたとこ以外にあったりするもんなんだよなぁ

**名前は開発中のものです。** · 2009/07/15(水) 08:38:43

>>696
>>692でデバッグしてないと言ってるじゃん。

**名前は開発中のものです。** · 2009/07/15(水) 10:08:04

バグを直接見つけようとしないで、確実にそのバグを再現できるようにするのが第一歩

**名前は開発中のものです。** · 2009/07/15(水) 10:45:30

>>701
分かる分かるｗ
そしてバグを再現させるのは非プログラマに丸投げする俺

**名前は開発中のものです。** · 2009/07/15(水) 11:25:55

で少しずつ条件を変えてあたりをつけていく。

**名前は開発中のものです。** · 2009/07/15(水) 20:48:39

おまえら仕様書切らないから
テストも作れないし
そもそもバグなのか想定なのかも混乱するんだろ？

**名前は開発中のものです。** · 2009/07/15(水) 21:06:50

分け入っても分け入ってもバグの山

**名前は開発中のものです。** · 2009/07/15(水) 21:09:53

仕様書、製造終了してから書いた記憶しかないなぁ…

**名前は開発中のものです。** · 2009/07/15(水) 23:03:43

>>704
最終的にうまく動作するものが仕様です。
どだい、仕様書でバグが防げると思ってる法が異常。
仕様書の想定だろうが、結果駄目ならバグだろ！

**名前は開発中のものです。** · 2009/07/15(水) 23:17:51

個人製作だし仕様書なんて全部脳内の香港式です
仕様の段階でバグ出すレベルの人はちょっとヤバイ。

**名前は開発中のものです。** · 2009/07/16(木) 00:10:27

脳内でまとめようとして、てこずるものを
紙に書いてみたらあっさり解決ってのはよくあることだけどな。

**名前は開発中のものです。** · 2009/07/16(木) 03:15:22

そういえば話はずれるけど、「仕様を全てきっちり書いて、それを紙に印刷しておく
のが重要なんです！」と力説する新人が入った時を思い出した

**名前は開発中のものです。** · 2009/07/16(木) 10:03:06

人それぞれで、
仕様書がなければダメになる人とそうでない人がいる。
始めた時は正しい方向に向かっていたが、
出来上がった時には違った方向を向いている、
世の中にはそんな人も多くいる。
チームで進めるとき、意思の統一が重要で
依頼しても、出来上がりが違うものになるのは困り者。
人それぞれなので、きちんとできるひともいるので、そのような人は不要と言われる

**名前は開発中のものです。** · 2009/07/16(木) 10:53:13

もし、違うものが出来上がってきたら、
「言った、言わない」の問題になってしまうから
あらかじめ、ちゃんと紙にして保存しておくって事だろう。

できるできないの問題じゃないよ。
自分のため、相手のための保険みたいなもんだ。

**名前は開発中のものです。** · 2009/07/16(木) 11:11:34

掛け捨て保険ではない。
チームで行う時の基盤になる、開発ドキュメントとして
取り扱い説明書として、保守業務の基準として必須のものである。

**名前は開発中のものです。** · 2009/07/16(木) 11:30:46

チームでやるなら仕様書必須
作り方が違うだろ
ttp://marupeke296.com/DXCLS_BottumUpStructingOfClass.html

**名前は開発中のものです。** · 2009/07/16(木) 13:48:32

コメント見ただけで仕様が把握できるようなソースが書けるようになりたい
いつかは。

**名前は開発中のものです。** · 2009/07/16(木) 16:20:01

コメント書かなくても把握できるソースが理想かな。

**名前は開発中のものです。** · 2009/07/16(木) 16:29:44

どうも英語のコメントは読むのも書くのも苦手で……

**名前は開発中のものです。** · 2009/07/16(木) 17:36:09

悪ノリではっちゃけたコメント書いてるのは俺だけではないはず

**名前は開発中のものです。** · 2009/07/16(木) 21:20:58

>>715
ダウト
仕様はソースと答え合わせする為のもの
ソースみて内容がわかるのと、本来どうあるべきなのかは別問題

**名前は開発中のものです。** · 2009/07/16(木) 22:04:34

そうか個人製作の場合ととチーム製作の場合と仕様書と仕様と仕様バグとバグを
はっきり切り分けないで話してるからこんなにカオスなのか

**名前は開発中のものです。** · 2009/07/17(金) 09:45:51

みんな自分の話してるだけだからな

**名前は開発中のものです。** · 2009/07/17(金) 09:47:37

メンバ関数でモジュール化するだけだよ、基本的には
それにコメントは確かに大事だが
関数名をgetScreenFrameParSecondみたいにきちんと書けば、仕様が明らかにわかる

クラス・変数名も同じ
例えばiteratorをitとか省略して書くのはダメ
タイプ速度は速くなるが、後のコーディングで詰まるから、作業は全く速くなってない。むしろ遅くなる
省略しなければiteratorという言葉を知らない他人が見ても、ググれば意味がわかる

あとは、日本語で名前つける人がいるけど
ネットに和英辞書あるんだから使ってほしい
英語の勉強になるし国際化にも対応できる

**名前は開発中のものです。** · 2009/07/17(金) 10:08:40

そこまで欧米コンプレックス持ってないし…。
国外にソース晒すほど立派なもん作れるなんてうぬぼれてない。

**名前は開発中のものです。** · 2009/07/17(金) 10:48:52

自分で分かりやすいのが一番

**名前は開発中のものです。** · 2009/07/17(金) 11:36:53

趣味の範囲内だし態々・・・

**名前は開発中のものです。** · 2009/07/17(金) 14:37:53

熊々翻訳しなきゃわからないレベルの英単語は使わないかな

**名前は開発中のものです。** · 2009/07/17(金) 14:42:09

FileHandle ofh ( FileName, ">" );
とかは問題ないと思うけどな。宣言のクラス名で大体分かるし。
宣言が遠すぎて分からんような関数ならその時点で問題だし。

**名前は開発中のものです。** · 2009/07/17(金) 15:20:17

というか、「ローカルスコープの」識別名は短いのが主流な気がするんだけど。
定番の良書とかでも普通みんなそうだし、Linuxカーネルみたいな大物ソースでも
そうだし。
結局、識別名だけで理解できる情報は限られるのも現実。そうでなければ、それこそ
アプリケーションハンガリアンなんかを全識別名に徹底すれば最高なのかもしれない
けど、実際は関数エントリにはしっかりした出入り仕様のコメントが欲しい訳で。

まぁ、スレ違いなんだけどね。
正直、D3DXのせいで、「扱いやすくする」という使命のラッパーライブラリの系統
は居場所を失ってるから、このスレの居場所も同様によく分からないんだよなぁ。

**名前は開発中のものです。** · 2009/07/17(金) 15:37:38

　　 ∩＿＿＿∩
　　 | ノ　　　　　ヽ
　　/　　●　　　● |　　　　　クマ知ってるか。
　 |　　　　( _●_)　ミ　　　　出雲地方では、木と岩と水の在る場所を「熊々しい谷」と呼ぶ。
　彡､　　　|∪|　　､｀＼　　　「熊々しい」とは、神々しいの意味だ。
/　＿＿　ヽノ　/´>　 )
(＿＿＿）　　　/　(_／
　|　　　　　　 /
　|　　／＼　＼
　|　/　　　 )　 )
　∪　　　（　＼
　　　　　　＼＿)

**名前は開発中のものです。** · 2009/07/17(金) 22:02:14

>>722レベルの長文関数名を記述すると
引数がある場合とかに
複数行にわたってしまって
なんだか見づらくならない？

今まで見たソースだとgetScrFPS程度には略してるけど
おまえらどうなの？

**名前は開発中のものです。** · 2009/07/17(金) 22:12:33

略すと判んなくなる時以外は略してる。

**名前は開発中のものです。** · 2009/07/17(金) 22:12:54

目的や用途によって使い分けてる。

**名前は開発中のものです。** · 2009/07/17(金) 22:29:41

クラスの中に座標XとYをまとめてクラスか構造体にしておいて、他の関数などに渡すときに
ひとつのGetPos()って関数で渡すにはどうしたらいいかな？
考えてみたんだけど、どうしても一つでいろいろなところで使える方法がみつからないんだよ。
まだプログラム経験が短いもんで。

**名前は開発中のものです。** · 2009/07/17(金) 22:47:07

構造体を返せばいいと思うけど、そういうことではない？

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

まあ状況によるけど。
基本Gｅｔは単一変数を返す方がいい。
内部の構造体のデータを返すのは間違っている。
その場合はとるのではなく、チェックしてもらう。
bool chk_XXXX （pos *dat）；　　が正しい。
で、この関数はインラインであれば、スピード的には何の問題も無い。

考え方が逆。

**名前は開発中のものです。** · 2009/07/17(金) 23:06:22

補足、クラス内のデータの処理はそのクラスの関数で行う！
これ基本中の基本

**名前は開発中のものです。** · 2009/07/17(金) 23:31:36

皆が何言ってるかさっぱりわかんないぜ！

でもゲームは作れてるぜ！

**名前は開発中のものです。** · 2009/07/17(金) 23:36:29

FPSはそれ自体で意味がわかるから使うけどScrは無いわ

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

class A があって xが public なメンバの場合 A.xでアクセスするのと
private の場合 getx(){return x;} でアクセスするのと速度変わらんのか

**名前は開発中のものです。** · 2009/07/18(土) 08:04:35

>>739
詳しい事はしらんが、常識的な範囲でコンパイルを考えれば、
最適化が普通だったら遅くなる理由は無いと思う。

最適化をしないなら、クラスから関数のアドレスに飛んで、
そこで値：ｘを取得して、それをどっかに格納な分
遅くなるんだろうけど・・・。

**名前は開発中のものです。** · 2009/07/18(土) 08:54:43

>>740
ちょっと違う
getx(){return x;} がクラスの中に書かれ、そのクラスがヘッダーファイルなら。
インライン展開されるので
aa　=　getx(){return x;}
　||
aa　=　A.x　と同じ
最適化は関係ない

**名前は開発中のものです。** · 2009/07/18(土) 08:56:36

あ、ちょっとまて、C++のみの話な、他の言語は知らん

**名前は開発中のものです。** · 2009/07/18(土) 10:41:55

それはヘッダに直接定義書いてるからinline付いてるだけじゃね
ソース側で定義でもinlineつけて展開できるなら同じじゃないっけか
後、クラス内での処理はインラインしてくれるのが普通だったきがする
メンバ関数内で別のメンバ関数呼び出して処理とか
まー、>>736か

**名前は開発中のものです。** · 2009/07/18(土) 14:09:33

インスタンスが確保されてる状態なら、参照を返せばいい。
class Foo {
　Pos pos_;
public:
　Pos& GetPos() { return pos_; }
　const Pos& GetPos() const { return pos_; }
};

スコープの外側にインスタンスを返すなら、参照渡しじゃ無理なので、コンパイラの
NRVOに期待して、例えば以下のように書くことになる。
inline Pos GetPos() {
　Pos result;
/* code */
　return result;
}

NRVO非対応でRVOだけ対応のコンパイラだと、
inline Pos GetPos() {
/* code */
　return Pos( /* code */ );
}
こういうコードじゃないと>>741の言うような最適化は掛からない。
コンパイラーメーカーもC++標準化委員会もNRVOが掛かるように頑張ってるはずだが、
実装状況はコンパイラによってまちまちなんで調べてくれ。多分検索すればすぐ分かる。
VC++なら2005からNRVO行けるっぽい。/O1くらいでもNRVOは掛かる模様。
プロファイラで後から最適化ってのも常道だけど、I/F設計段階の話はそうもいかないし
なぁ。
まぁ、俺なら基本的には参照渡し、リターンで解体される自動変数なら値渡しで返して、
後者がボトルネックになるならインライン化でたぶんNRVO発動でおｋ、って書く。で、
「この設計だと遅そうだしポインタ渡そう」って言われたら、実際どうなるか興味ある
んでベンチでも書いたり、ついでに↓みたいなのも一緒に見たりしながら相談する。
http://msdn.microsoft.com/en-us/library/ms364057(VS.80).aspx

**名前は開発中のものです。** · 2009/07/18(土) 14:20:17

>>744補足
スコープの外に「自動」インスタンスを返すなら、だな。

つーか、二つめと三つめは最初の質問のシチュエーションから逸脱してるな。すまん。
まぁでも、メンバ関数でもNRVOは重要なんで、仕組みは知っておいた方が。

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

//●ジャンぷ

if(key & PAD_INPUT_B){
for(double t=0; t<10; t=t+0.1){
int vo = -60;
int ay=10;
jikidata.y = vo * t + 1/2 * ay * t*t + jikidata.y;
WaitTimer( 1000 );
jikidata.ghandle = LoadGraph("media\\imgbb4792ea7ec6f3d_frame_0009.bmp");
}
}

DXライブラリを使ってアクションゲームのジャンプをプログラムしたいんですが
これで実行すると、キャラが止まったり、動かなくなってしまうんですが、どこを改変すればいいんでしょうか？

**名前は開発中のものです。** · 2009/07/19(日) 05:51:18

>>746
正直どこにつっこめばいいかわからないので
公式のサンプルを参考にすればいいとだけ言っておく
http://homepage2.nifty.com/natupaji/DxLib/dxprogram.html#N2

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

WaitTimerは使っちゃだめれす＞＜

**名前は開発中のものです。** · 2009/07/19(日) 21:11:12

フラッシュマン

**名前は開発中のものです。** · 2009/07/20(月) 01:05:51

>>748
リアルタイム処理で使うのは駄目に決まってるな
フェードアウト後の待ち時間とかに使うのが正しい
でも個人的にはウェイト系の関数やら処理体系作って、それを使えばいいと思う
while(……){
　//ここにwaitから切り放したい処理を書く
　//例えば、ゲームは止まっても風景は動かしたい
　//処理ごとにwaitを分ければさらに色々なことができる
　if(waitFlag==FALSE){
　　//ここにwait前にやりたい処理を書く
　　//waitTime、waitFlagは本来条件式で設定するのが望ましい
　　waitTime=1500;//1500ミリ秒=1.5秒
　　waitFlag=TRUE;
　}else{
　　if(1ミリ秒経過したら){
　　　waitTime--;
　　}
　　if(waitTime==0){//1.5秒経った
　　　waitFlag==FALSE;
　　}else{
　　　//waitTime=0未満;を描いたな？と怒る
　　　//エラーフラグを大量に埋めるのは開発の最適化とアンチートに役立つ
　　}
　}
}

こんな

**名前は開発中のものです。** · 2009/07/20(月) 01:09:47

最後のとこはelse if(waitTime<0)だた

**名前は開発中のものです。** · 2009/07/20(月) 18:56:48

ジャンプするたびに画像をロードしまくってどうする

**名前は開発中のものです。** · 2009/07/20(月) 23:05:51

>>750
これならどの環境でもキッチリ結果が出るね
カウンタ回すしかやったことないから参考になるわ
だけどアクションとかだと遅延おきてカクカクにならないかな

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

同じフォルダ内にあるＴＴＦフォントを使って文字列描画したいんですけどそれはＤＸライブラリでできますか？
フォントのファイル名を指定して読み込みするような関数が見つからなくてどうすればいいか困ってるんですが

**名前は開発中のものです。** · 2009/07/23(木) 01:22:02

なんかソレっぽいサンプルどっかで見かけたような気が……

**名前は開発中のものです。** · 2009/07/23(木) 01:49:57

ごめん適当なこと言った
ＤＸライブラリでは出来ないような気がする
でもフォントファイルを一時的に開くプログラムがあれば通常のフォントと同じように
名前の指定だけで使えるはず……

**754** · 2009/07/23(木) 02:35:05

ありがとう！！探してみて解決したよ！！

結果はWin32APIのAddFontResourceEx関数を使えば一時的にTTFファイルからフォントリストに登録できるみたい
第二引数に0x10(FR_PRIVATE)を渡せばそのプロセスだけで使えるようになるぽ
使い終えたらRemoveFontResourceExで開放する必要もあるみたい。登録時とまったく同じ引数で呼び出す必要あり

AddFontResourceEx("hoge.ttf", 0x10, 0); // これでhogeフォントを登録。DxLibのEnumFontNameでも表示されるはず。
RemoveFontResourceEx("hoge.ttf", 0x10, 0); // 削除。引数を↑と同じにしないといけないらしい

いくらDxLib関係でググっても見つからなかったので少々冗長気味に解説してみたよ
正直この機能はDxLibにラップされてても違和感無いと思うんだけど

**名前は開発中のものです。** · 2009/07/23(木) 03:39:18

確かに自動対応してもいいレベルではある

**名前は開発中のものです。** · 2009/07/23(木) 21:34:58

暗転ってどうやってやってる？

**名前は開発中のものです。** · 2009/07/23(木) 21:51:01

普通に画像を表示して、その上にかぶせるように真っ黒な画像を少しずつ濃くしながら表示。
完全に濃くなったら、表示する画像を切り替える。
真っ黒な画像を少しずつ薄くしながら表示する。完全に薄くなったら、以後、真っ黒な画像は表示しない。

これでいいと思う。

**名前は開発中のものです。** · 2009/07/23(木) 23:37:10

SetDrawBlendModeとDrawBoxでやってるな。

**名前は開発中のものです。** · 2009/07/24(金) 02:52:41

これ一旦止めた音楽止めた場所から再開させることできないのか

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

できるけど
Dxlib.h内を、サウンドハンドルの再生位置で検索

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

ありがとうございます
やってみました
PlaySoundMem でやってるときは GetSoundCurrentPosition で取得すればいいのかな
でやってみましたが GetSoundCurrentPosition がいくら再生してるときでも０しか返ってこないのですが
ちゃんと引数に正しい SoundHandle 入れてますよ

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

ごめん、検証してなかった
PlaySoundMemのTopPositionFlagを0にすれば
取りあえずは途中から再生できるはず

**名前は開発中のものです。** · 2009/07/24(金) 06:13:08

ありがとうございました、できました

**名前は開発中のものです。** · 2009/07/24(金) 08:59:47

DXライブラリ卒でD3D9使ってるけど、久々にDXライブラリ時代のソース引っ張り出して
ちょっと懐かしかった。pchも使ってなかったんだなぁとか。
つーかpch使ってない奴も多そうだから勝手に手順説明するぜ。

1. プロジェクト→新しい項目の追加→ヘッダーファイルでstdafx.hをプロジェクトに追加
2. プロジェクト→新しい項目の追加→C++ファイルでstdafx.cppをプロジェクトに追加
3. DxLib.hや標準ライブラリなど、自作でない巨大ヘッダのinclude文を*.cppから全部削除して、
代わりにstdafx.hの中に全部突っ込む（自作ヘッダは普通に*.cppで各自includeする方がいい）
/* stdafx.hの例 */
#pragma once
#include <DxLib.h>
#include <string>
using std::string;
/* ここまで */
4. 全ての*.cppの最初に#include "stdafx.h"を書く（コメントは前に入れてもおｋ）
ちなみにstdafx.cppは、#include "stdafx.h"の一行だけでおｋ
5. ソリューションエクスプローラでプロジェクト名を右クリックしてプロパティを開き、左上の
構成を「すべての構成」にして、構成プロパティ→C/C++→プリコンパイル済みヘッダー→
プリコンパイル済みヘッダーの作成/使用を「プリコンパイル済みヘッダーファイルを使用する
(/Yu)」に変更する
6. ソリューションエクスプローラで「stdafx.cpp」を右クリックしてプロパティを開き、左上の
構成を「すべての構成」にして、構成プロパティ→C/C++→プリコンパイル済みヘッダー→
プリコンパイル済みヘッダーの作成/使用を「プリコンパイル済みヘッダーファイルを作成する
(/Yc)」に変更する

これで、stdafx.hを変更する時以外は、ビルド速度がかなり劇的に上がるはず。
大した作業にはならないはずだから一度試すといい。

**名前は開発中のものです。** · 2009/07/24(金) 09:09:49

ああ、気付きにくいかもしれないことを補足。
自作ヘッダから<string>とか<math.h>とか使いたい場合も、「必ず全ての*.cppの最初で
stdafx.hがインクルードされる」という規則だから、結局は自作ヘッダがインクルードされる
時点ではstdafx.hが既に読み込み済みになってる。
なので、自作ヘッダに#include <string>とか書く必要も無し。自作ヘッダで使いたい標準の
ライブラリなんかのincludeも、全部stdafx.hに逃がせばおｋ。

**名前は開発中のものです。** · 2009/07/24(金) 17:40:08

これは便利そうですね
デメリットとかはありますか？

**名前は開発中のものです。** · 2009/07/24(金) 18:12:52

今の俺には何のことだかさっぱりだがメモっておく

**名前は開発中のものです。** · 2009/07/24(金) 19:26:36

デメリットは思い当たらないなぁ。
「使いたい外部ライブラリのヘッダを全部何も考えずにstdafx.hに入れまくれ」
「全てのcppファイルの頭でstdafx.hをインクルードしろ」
ってルールが縛りといえば縛りだけど、むしろ楽になるだけだと思う。コンパイルも
別次元に速くなるし。

原理的には、stdafx.hの中身をコンパイルし終わったとこでいったん止めちゃって、
中間情報として拡張子pchのファイルに保存しておき、*.cppをコンパイルする時に
その情報を使い回して、#include "stdafx.h"まで読み飛ばして、それ以降のソース
だけコンパイルするイメージ。実際に内部がどう動いてるかは知らないけど。
なので、cppの頭で#include "stdafx.h"を入れ忘れると、
「プリコンパイル済みヘッダーの検索中に予期せぬ EOF を検出しました」
とか言われる。
stdafx.hの中には、C++のソースなら何書いても多分平気だから、大抵の使い方には
対応できると思われ。あまり頻繁に書き換えると、そのたびにpch作り直しで効果が
薄まるけど、自作ヘッダでも「更新少ない」「かなり色々なソースから参照される」
みたいな奴はstdafx.hに入れちゃってもいいと思う。

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

当たり判定はこうすればいい。
プレイヤーキャラクターを移動させたければこうすればいい。

といった部品部品は作れるけど、いざゲーム自体を作ろうとなったら全然作れないんだ。
いったいどうしたらいいのかな・・・？

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

その部品を組み立てればゲームになるはずなんだが
一体何が問題なんだ？

それを言わずして質問されてもわかるはずがない。

**名前は開発中のものです。** · 2009/07/25(土) 15:37:45

>>772
とりあえず目標を決めてはどうか。

ただし、あまり大作でも作れなきゃ意味がないので、
初期の携帯電話用ゲームや、初期のファミコン、インベーダゲーム、倉庫番あたりを目指す。
矢印キーだけ、せいぜいそこにボタン１個くらいで遊べるゲームが楽でいい。

目標が決まったら、それを「部品」に分解する。
うまく部品単位になればお前さんの勝利。

**名前は開発中のものです。** · 2009/07/25(土) 17:05:50

綺麗な部品作りの楽しさとゲーム作りの楽しさは、何というかちょうど90度くらい
ずれた方向性がある。両方うまい人はすごくいい。
最初の一歩はとにかく単純に、ゲーム内容どうでもいいから一本のゲームとして
成り立ってる物を作る、つーこと。極端な話、全部WinMain()に入ってても一向に
構わない。（綺麗な部品作りに慣れてるならそうはならないだろうが）
部品は必要性を実感してから作る方が最適になりやすい。いわゆるシーズじゃなく
ニーズで作る。先に需要を予測して部品を作る、ってのはほどほどにすべき。
で、「クソゲー作ってもなぁ」と思うなら、いっそ最初から真面目に本気ゲーを
作り始めてしまっても全然問題ない。

**名前は開発中のものです。** · 2009/07/26(日) 08:48:42

個々の部品の作り方が分かっていても、それらを全部組み合わせて、うまく動くようにするのは結構大変。
特にシーンやリソースの管理が入ってくるとかなり面倒になる。
そういう点ではやっぱり最初は１面のみの単純なゲームから始めた方がいいね。
プログラムが大きくなればなるほどバグ取りも大変になるから、最初は小規模から始めた方がいい。
自分はいつも最初からあれこれ入れようとして墓穴を掘ってる。

**名前は開発中のものです。** · 2009/07/26(日) 11:40:31

プログラムを書く能力とゲームを組み立てる能力は、全くの別物
紙にステータスを書いて遊ぶとか、人形をいじって遊ぶとか
そういうアナログな手法でイメージを立てて設計する
何も考えずにプログラムを先に書くのは意味がない。

ゲームを考える（妄想する）、ゲームを作る、ゲームを遊ぶ
この３つのどれが欠けてもうまくいかない
まず面白いシステムや世界観を考える
次にプログラム、シナリオ、絵、音楽などで形にする
最後に完成品を遊び倒して面白いゲームに近付ける
ゲームは工業製品だから、作り手の職人気質がもろに出るよ

**名前は開発中のものです。** · 2009/07/26(日) 11:57:44

>>772は単に大枠の設計が分からないとかそういうことなんじゃね？
>>776のいうシーン管理とかそういう骨組みの構造とか

**名前は開発中のものです。** · 2009/07/26(日) 23:48:51

stdafx.hにいれた上で、そのソースに必要なヘッダはあえて書くソースに書くようにしてる

**名前は開発中のものです。** · 2009/07/27(月) 00:01:10

俺は何も考えずにいきなりプログラム作るぞ。
特に最初のうちは、あんまり考えないほうがいいと思うんだけどな。
緻密に設計していくのは、ミニゲームを何本か完成させた後のほうがいいと思う。

DXライブラリ 総合スレッド その3

DXライブラリ総合スレッドその3