DirectX総合スレ (Part2)

**名前は開発中のものです。** · 04/09/22 23:30:32

DirectXについては基本このスレで話していこうとものです。
基礎的な質問＋高度な質問も簡潔かつ簡単に答えることをモットーにして頂き
このスレの回転を早めて常にアクティブなスレにしたいと思っております。
このスレに質問等を書かれる方はまず最初に自分でしっかりと調べたのちに聞かれることをお願いします。
質問に対する答えも簡潔に出来る限りわかりやすくお願い致します。

テンプレは >>2以降で

**143** · 04/10/11 16:49:16

ちなみにライトは自前でなにか難しい事をやってるとかではなくて
普通にDXで用意されてる
D3DLIGHT9のポイントライトとかスポットライト等です。

**名前は開発中のものです。** · 04/10/11 16:55:31

>>143
法線は設定してあるか？

**名前は開発中のものです。** · 04/10/11 17:18:51

>>145
>テクスチャを貼っていないオブジェクトにはきちんとライトが反映されてるようなんですが、

って書いてるんだが。

**名前は開発中のものです。** · 04/10/11 17:24:14

>>143
とりあえずこれは確認しろ。

device.TextureState[0].ColorArgument1 = TextureArgument.TextureColor;
device.TextureState[0].ColorArgument2 = TextureArgument.Diffuse;
device.TextureState[0].ColorOperation = TextureOperation.Modulate;

**名前は開発中のものです。** · 04/10/11 17:25:22

そもそも固定なのかシェーダなのかすら書いてないし、ステートの設定の情報も無し。
その状態で何を答えろと？

**名前は開発中のものです。** · 04/10/11 17:25:54

>>146
テクスチャを張ってあるオブジェクトと、張ってないオブジェクトは別物だろ？

テクスチャを張ってあるオブジェクトに、法線が設定されているかと聞いているのだが。

**143** · 04/10/11 17:37:38

すいません。
LightWaveのXfileエクスポーターを使ってるんですが、
その設定の問題だったようです。
「Replace surface color with texture」
のチェックをはずしたら上手くいった模様です。

**名前は開発中のものです。** · 04/10/11 17:38:06

ﾁｸｼｮｰ

**名前は開発中のものです。** · 04/10/11 19:31:18

うんこがでちまったよ

**名前は開発中のものです。** · 04/10/11 19:33:47

ｸｿｰ

**名前は開発中のものです。** · 04/10/11 19:39:30

ちんこがでちまったよ

**名前は開発中のものです。** · 04/10/11 19:53:42

今日は、風呂でもぐろう。

**名前は開発中のものです。** · 04/10/11 21:04:30

LightWaveネタが出たので、ちと質問ですが
モーション付Xファイルは読み込めば、そのまま上手く動作しますか？
他に3dsMax以外でモーション付Xファイルを出力するツールてありますかね？

**名前は開発中のものです。** · 04/10/11 22:05:42

D-StormのLightWave用X-Fileエクスポーターでは
まともにモーション付きX-Fileを出力できないです。

全てのボーンにウェイトマップをきっちり割り当てて
use weight map onlyを指定するといくらかまともに出力されるかも。

漏れは自作のコンバーター使ってます。

X-File出力できるツール(コンバーター)は
有名どころだとPolyTransとか？使ったことないですけど。

**名前は開発中のものです。** · 04/10/11 23:45:03

結局は自作するかちまちま書いてくしかないのか…(´A`)

**名前は開発中のものです。** · 04/10/12 03:07:17

ちんこでもしごいてな

**名前は開発中のものです。** · 04/10/14 00:01:52

お前ら、ぬるぽは好きガッ？

**名前は開発中のものです。** · 04/10/18 02:01:54

ぬるぽは好きだガッ、何か？

**名前は開発中のものです。** · 04/10/20 18:13:21

今、DirectXを使ってエフェクトを作っているのですが、空のテクスチャを
用意してそこに色の情報を書き込みたいのですがLockなどを使うと思うのですが
よくわかりません。
空テクスチャに対してはどういったことをすれば色を書き込めるのでしょうか。
分かる方おりましたら教えていただけますか。

**名前は開発中のものです。** · 04/10/20 18:20:16

いやその通りなんだけど…実際にやってみたら？
t-potとかを参考に。

**名前は開発中のものです。** · 04/10/20 18:36:36

DirectXを使うならC#とVB.netだと、どっちが良いですかね？
資料が豊富なほうがイイかな、とも思ってるんですが。

**名前は開発中のものです。** · 04/10/20 18:41:41

どっちもどっちだけど多分C#のほうが資料は多いんじゃないかな。
英語版ヘルプとかでもC#の記述が多いし

**名前は開発中のものです。** · 04/10/20 19:09:42

最近のDirectXってC#のソースはあってもVBのは入ってないっぽい。
Cマガジンも日経ソフトウェアもC#の記事しかやらない。

ネタっぽく書くとこんな感じ。
C#>>>C++>>>（超えられない壁)>>>HSP>LGP>>>VB>>>(あの夏の思い出)>>>Delphi

**名前は開発中のものです。** · 04/10/20 19:28:36

>166
(あの夏の思い出)はもう少し↑だろ

**名前は開発中のものです。** · 04/10/20 22:54:32

毎回、テクスチャ240*240に色を書き込んでそれをポリゴンにはっつけて
るんですがどうしてもスピードに問題があって10フレーム未満しかでないん
ですが何か改善策ありますでしょうか。
現在は毎回ロック・色書き込み・アンロックを繰り返してテクスチャを
書き換えてそれをポリゴンにはっつけてます。

**名前は開発中のものです。** · 04/10/20 22:55:09

>>165-166
さんくすです（・∀・）
VBは人気無くなっちったな。

**名前は開発中のものです。** · 04/10/20 22:57:23

>>168
Usage.Dynamicなテクスチャで作ってる？
あと、毎フレーム240*240のテクスチャに書き込むというのはかなり膨大な作業になりそう。
どうしてもその作業が必要なら仕方ないけど、他の方法で近いことができそうなら、そうしたほうがいい。

**名前は開発中のものです。** · 04/10/20 23:17:22

>>166
俺のレベルだとC#,C++のサンプルさえあればDelphiで困らないけどね。

**名前は開発中のものです。** · 04/10/21 00:01:41

>>167
Del6のリリースが夏だったからかけてるんだYO！

>>171
C++はそうだけどC#は違うだろｗ
DelphiのヘッダはC++からのコンバートだからC#とは使える機能に若干の違いがあるよ
さらに細かい事をいえば構造体とか移植者が適当に定義してるから一貫性がないし

**名前は開発中のものです。** · 04/10/21 00:02:57

Usage.Dynamicというのはポリゴンへ描画するときテクスチャの
座標を変えて違う色を描画する方法のことですか？

FPSの計算をしたのですが何も描画しない状態でも６０FPS前後しか
でないのですがサイトなどで公開されているFPSを計るものでは
１２０とかでてるのですが原因がわかりません。
分かる方おりましたらアドバイスお願いします。

**名前は開発中のものです。** · 04/10/21 00:29:25

240*240は小さくできないの？
64*64とか
あとはもう一つテクスチャを準備して交互に書き込んでいくと、
もしかしたら少しは速度がでるかも

**名前は開発中のものです。** · 04/10/21 01:07:34

>>173
60FPS前後なのは、自分でウエイトをかけるようにして、
デバイスを作っているからだろう。
サンプル丸写しで何も考えずに出来合の物を使うから、
そうやって基本的なことが出来なんだよ。

**名前は開発中のものです。** · 04/10/21 01:23:16

ウェイトをはずせｗ

**名前は開発中のものです。** · 04/10/21 01:26:05

>>173
VRAMってのは普通にメモリを読み書きしようとすると遅い、とにかく遅い
そのVRAMに毎フレームで240*240なんていう広大な領域を更新するのは無理
だがUsage.Dynamicで宣言したテクスチャはVRAMじゃなくてAGPメモリに確保する
こうするとボトルネックとなっていたメモリアクセス速度は回避される

そもそもその毎フレーム書き換えたテクスチャで何をするのか、ちょっと聞いてみたい

**名前は開発中のものです。** · 04/10/21 02:22:24

今173読み返したら見当違いの回答だったらしいなorz
Usage.Dynamicってのはnew Texture()の時に渡す引数のこと
ManagedじゃなくてCOM直叩きとかなら、D3DUSAGE_DYNAMICをCreateTextureに渡す感じ

**名前は開発中のものです。** · 04/10/21 02:26:05

320x240のムービーをリアルタイムにテクスチャにレンダリングしたことがあるが、
こま落ちなしで余裕で60ｆｐｓ出たぞ。

流れは、
Pool.SystemMemoryなテクスチャをLock→書き込み→Unlock→
Pool.Defaultなテクスチャに.UpdateTexture。
至極単純。

**名前は開発中のものです。** · 04/10/21 02:37:23

>>173
FPS=60は、画面更新時に同期待ちをする設定になってるから。
C++の場合は、CreateDevice に渡す構造体 D3DPRESENT_PARAMETERS の
メンバ PresentationInterval を D3DPRESENT_INTERVAL_IMMEDIATE にすれば
同期待ちしなくなる。

**名前は開発中のものです。** · 04/10/21 11:30:56

そもそも、256*256のテクスチャじゃなくていいのか？

**名前は開発中のものです。** · 04/10/21 19:05:15

そもそも、60fps以上の数値って、理論値だろ。
モニタが60Hzなのに400fpsなんてあり得ない。
BeginSceneからEndSceneまでにかかった時間を逆算してるだけ。

**名前は開発中のものです。** · 04/10/21 19:31:15

　　　　>>182

　　　　　　　　　＼　　　∩─ｰ､　　　====
　　　　　　　　　　＼／　●　､_ ｀ヽ　　======
　　　　　　　　　　　/ ＼(　●　 ● |つ
　　　　　　　　　　　|　　 X_入__ノ　ミ　　　そんな餌で俺が釣られクマー！
　　　　　　　　　　　､　(＿／　　　ノ　/⌒l
　　　　　　　　　　　 /＼＿＿＿ノﾞ＿/　 /　　=====
　　　　　　　　　　〈　　　　　　　　＿_ノ　　====
　　　　　　　　　　　＼　＼＿　　　　＼
　　　　　　　　　　　　　＼＿__）　　　　　＼　　　======　　　(´⌒
　　　　　　　　　　　　　　　　＼　　＿＿_ ＼＿＿　　(´⌒;;(´⌒;;
　　　　　　　　　　　　　　　　　＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(´⌒;　(´⌒;;;

**名前は開発中のものです。** · 04/10/21 19:35:48

いや釣りじゃなく本気でそう思い込んでる気がする。

**名前は開発中のものです。** · 04/10/21 19:41:49

そもそもモニタが60Hz固定じゃないし
それはモニタの描画速度であってDirectXがVGAに転送する頻度とは関係ないし
ｸﾏｰ

**名前は開発中のものです。** · 04/10/21 19:52:16

モニタ
ディスプレイアダプタ
（ここから下はプログラマ次第）
描画ループ
内部（ロジック)ループ

これごっちゃにするのはFPS議論の基本だね♪

シューティングゲーム製作技術総合　５機目
http://pc5.2ch.net/test/read.cgi/gamedev/1098034919/
FPS(ﾌﾚｰﾑﾚｰﾄ) VSYNC(垂直同期ﾘﾌﾚｯｼｭﾚｰﾄ) 　←できればFPS議論はここにまとめたい。
http://bbs.gamdev.org/test/read.cgi/gamedev/1063274576/

**名前は開発中のものです。** · 04/10/21 20:43:45

モニタが60Hz・・・すでに前提から間違ってる

**名前は開発中のものです。** · 04/10/21 21:06:12

＞60fps以上
突っ込みどころは色々あるが、
以上という言葉で60FPSを含めてしまっている時点で、
プログラマとしてはその知能に致命的な障害を持っている。

**名前は開発中のものです。** · 04/10/22 08:34:09

サーフェスからテクスチャに書き込みたいのですがそんな命令あります？

**名前は開発中のものです。** · 04/10/22 08:43:35

>>189
無いんじゃね？
サーフェスにはテクスチャを
テクスチャにはサーフェスを取り付けて
そっちに対して、サーフェスにテクスチャを書き込み。

**名前は開発中のものです。** · 04/10/22 11:53:19

テクスチャからサーフェース取得すれば、
ある程度選択幅がでてくるだろうに。

もしくは、Lockして自前で転送。

**名前は開発中のものです。** · 04/10/22 14:36:20

> サーフェース
発音注意

**名前は開発中のものです。** · 04/10/22 16:53:26

テクスチャのUV座標情報が、ほぼ全ての面（の頂点）に付いている
モデルって珍しく無いと思うのですが、
この場合、IndexBufferはほとんど無意味ですよね？

無意味どころか有害な気がするんですが、実際どうなんでしょうか。

**名前は開発中のものです。** · 04/10/22 16:58:59

一般的なモデリングデータの共通のメッシュで、頂点ごとのUVがバラバラであるケースはほとんど無い。
球面で法線が異なることなら多いけど。

**名前は開発中のものです。** · 04/10/22 17:10:48

>193
何が有害かわからないけどある程度複雑なモデルになると、
描画の時に2度以上指定しないといけない頂点がでてくるんだが、
IndexBufferを使っておくとお得な気がしませんか？

例えば↓のような四角形をトライアングルリストで描画するとして
1 2

3 4
IndexBufferを使った場合と使わなかった場合、それぞれどうVertexBufferを確保するか考えてみたら？

**名前は開発中のものです。** · 04/10/22 17:10:51

>>194
私が今解析してたモデルデータ達が特殊なのか…。
おかげで安心してIndexBufferを使って行けそうです。レスありがとうございました。

**名前は開発中のものです。** · 04/10/22 17:12:53

くっ、ちゃんとリロードしたのになぁ…3秒差か
というわけで、>>195さんもありがとうございましたー

**名前は開発中のものです。** · 04/10/22 18:18:16

共有頂点の問題だろ。質問する方は分ってないから質問するんだけど
答える方が理解出来ないのな…

要はIndexBufferで共有頂点を指したいが、座標は同じでもUVが違う(マテリアルが違う)
そんな時は、そのUVの違う頂点が存在するようにデータを持ってる。
その時に共有頂点がない訳だからindexBufferはいらないだろ？って質問。
Xファイルしか見たことないやつ等なのかな？質問に答えてるのって。

例え共有頂点がなくとも、Indexを指定すれば(0,1,2,3,4,...と順並びでも)
描画が速い場合・も・ある、のでIndexBufferがあっても意味無い事はない。

**名前は開発中のものです。** · 04/10/22 18:51:47

http://www.geocities.co.jp/SiliconValley-Oakland/9582/GamePrg/index.htm
このサイトの炎の表現２っていうのがあるんですけどそれをDirectX９で
表現したいと思い試みているのですがプログラムをよんで解析してるんですが
いまいち掴めません。
アドバイスよろしければお願いします。

**名前は開発中のものです。** · 04/10/22 19:50:38

>>199
その技法はあまりDXのバージョンに依存しないと思われる。

**名前は開発中のものです。** · 04/10/22 20:00:31

>>198
> 0,1,2,3,4,...と順並びでも

我が意を得たりというか、コンバートするとまさにこの状態なんですよ。それで疑問に思いまして…。
いや良かったです、速い場合があるんですね。その辺もう少し勉強してみます。
回答ありがとうございました！

**名前は開発中のものです。** · 04/10/23 01:14:18

頂点シェーダやらピクセルシェーダやらプログラマブルシェーダやら
何やらかんやらありますがテクスチャ1枚を貼り付けたCUBEを100個
表示させるのならどれが一番速いですかね？
and
それぞれはどういった特徴があるのでしょうか？

**名前は開発中のものです。** · 04/10/23 01:19:21

全く見当違いの質問でどう答えたらよいのやら…ｗ
ホンダのエンジンとブリジストンのタイヤと日本石油のガソリンがありますが
100kmを走るにはどれが一番速いですか？って聞いてるようなもんだぞ

**名前は開発中のものです。** · 04/10/23 01:33:21

>>202
プログラマブルシェーダって要するにシェーダをプログラムで組む奴ですよ。
つまり頂点シェーダとピクセルシェーダを包括するものだと思っとけｗ
頂点シェーダはモデルの頂点のシェーダ。（なんつーの？点１つ１つにほどこす計算みたいな？）
ピクセルシェーダはモデルのピクセルのシェーダ。（ポリゴンの色塗りに施す仕掛けだな）

つまり頂点シェーダとピクセルシェーダは同時に使える（使う）別々の処理を行うもので比べてもしゃーないのですよ。

**名前は開発中のものです。** · 04/10/23 02:04:18

どれも使わない固定パイプラインが一番速いです。

**名前は開発中のものです。** · 04/10/23 02:25:04

>>205
測ったこと無いけど固定パイプラインって色々やってるじゃん。
ライトを５つも６つも付けても、バンプや環境マップが設定できるでしょ（たしかｗ）
遅いと思うよ。（処理によると思うけど）

**名前は開発中のものです。** · 04/10/23 03:33:36

モデルに対し
ＵＶマッピングで1枚のテクスチャを貼る方法と面一枚一枚に複数貼る方法とでは
どちらが速度が速いのでしょうか？

**名前は開発中のものです。** · 04/10/23 04:19:16

>>207
一枚のテクスチャを貼るほうが速いとされているけど
俺が測った感じだと数と場合による。

普通のモデルだったら一枚のテクスチャの方がはやいよ。多分。
でも、一画面にどう考えても入らないモデルをぎっちりまとめておくと
テクスチャ云々の問題よりモデルを分割して描画（つまり画面に入らない部分のモデルの計算からしない）
をすることができないから、それはそれでおそいんじゃねぇかなと予想してみる。
どうだろ。（ちなみに勘）

**名前は開発中のものです。** · 04/10/23 15:08:06

テクスチャセットの呼び出しは少ない方が当然いい

**名前は開発中のものです。** · 04/10/23 17:28:27

>>209
それはそうなんだけど。
一画面におさまる程度の大きさを超えた場合ってどうなるんだろうね。
つまり広大な地形の類とかさ。
真ん中に立って北を向いたとすると、そのときの描画自体は南のデータなんかいらないわけじゃん。
でもテクスチャやモデルは北と南の両方のデータがまとまってるわけじゃん。
こういう問題を含めると単純にまとめておくと速いって認識もどうよと思うわけよ。

スカイボックスの類なんてやったとすると一枚一枚別にした方がはやいんじゃねーかと考えてみたりして（もちろん勘）

**名前は開発中のものです。** · 04/10/23 17:37:00

一枚のテクスチャを複数のモデルデータで共有すればいいだけの話では？

**名前は開発中のものです。** · 04/10/23 20:27:44

>210
テクスチャは一つでもいいと思う
モデルは分割して見えない部分は描画しないってのも手だと思うけど
スカイボックスっていうぐらいだから頂点数は少ないでしょ
だったら分割してできるコストの方が大きい気がする

スカイボックスを軽く描画したいんだったら、できるだけ最後に描画したほうがパフォーマンスは稼げる
半透明（アルファ値を持つ）のものがあるとそっちの方を後に描画しないといけないけど
基本は手前から描いていく

>202はもうすこし理解してから質問しましょう
>頂点シェーダやらピクセルシェーダやらプログラマブルシェーダ
この時点で理解不足です
いや、煽りじゃなくてある程度理解がないと適切な質問もできないし、
返答を理解することもできないだろうから非効率だと思うんで

**名前は開発中のものです。** · 04/10/24 00:42:31

トゥームレイダーの暗闇をともすアイテム（マッチ）のような処理がしたいのですが
方法がよく分からないです。頂点カラーを操作しているのでしょうか？

**名前は開発中のものです。** · 04/10/24 01:48:44

ポイントライト

**名前は開発中のものです。** · 04/10/24 13:47:50

すみません、DirectX9で３Dのゲームを作っている初心者なんですが、
スコアなどをテクスチャを貼り付けたポリゴンで表示したいのですが、
常に画面の同じ位置に表示させる方法が分かりません。
どうかこんな俺に救いの手をお願いします。

**名前は開発中のものです。** · 04/10/24 14:14:03

D3DFVF_XYZRHW

**名前は開発中のものです。** · 04/10/24 15:34:27

カニ型ロボットを攻撃すると足やハサミが取れていくシーンを作りたいと思ってます。
そこで方法として
胴体ｘ１　足ｘ６　目ｘ２　ハサミｘ２　計１１個のポリゴンモデルすべてに同じボーン構造をもたせた
Xファイルを出力し、プログラム側で親子関係を持たせて結合、連動させるというのを思いついたのですが
この方法は正しいでしょうか？もっと他に良い方法など無いでしょうか？

**名前は開発中のものです。** · 04/10/24 16:07:17

>>216
ありがとうございます。こんなに簡単な方法だったんですね。
かなり勘違いしてました。
ビルボードとかの技術を使わないといけないのかと思っていました・・・。　orz =3

**名前は開発中のものです。** · 04/10/24 19:34:17

VC++でLPDIRECT3DVERTEXBUFFER9 vbを宣言しているmain.cppから
CreateA()してからA()、Aの戻り値が1ならCreateB()してB()という関数を呼び出してます。

A.cppのcreateA()という関数の中で
　　externでvbを外部呼出しして
　　CreateVertexBuffer命令・Lock・書き込み・unlockのあと
A.cppのA()という関数で
　　その頂点データを使用して描画しています。

B.cppのcreateB()という関数の中で
　　externでvbを外部呼出しして
　　CreateVertexBuffer命令・Lock・書き込み・unlockのあと
B.cppのB()という関数で
　　その頂点データを使用して描画しています。

B()関数を呼び出して描画しようとしてるのですができません。
原因わかりますでしょうか？
説明が下手で申し訳ありませんがよろしくお願いします。

**名前は開発中のものです。** · 04/10/24 19:37:54

できない、って、どういう具合にできないの？
エラーコードが帰ってきたりするならそれも教えて欲しいんだが

**名前は開発中のものです。** · 04/10/24 19:50:05

頂点の情報は設定されているみたいなんですがテクスチャが張られてないみたいです。

**名前は開発中のものです。** · 04/10/24 21:06:51

みたいじゃなくて確認しろよ

**名前は開発中のものです。** · 04/10/24 23:53:00

（例）
HRESULT hr;
hr = pD3DDevice->SetTexture( 0, pTexture );
if( FAILED( hr ) )
return FALSE;
こんなんとか

hr = pD3DDevice->SetStreamSource( 0, pVB, 0, sizeof(頂点データ) );
if( FAILED( hr ) )
return FALSE;

とかやってみては？
CreateVertexBufferも DrawPrimitiveも
失敗すれば　hr　にエラーが返ってくるから
どの設定が悪かったのか分かるかも。
張られて無いならエラーだしてるんでは？

もし俺なら、ＡのプログラムをＢに
コピー＆ペーストして動かしてみる（ｗ

**名前は開発中のものです。** · 04/10/25 00:53:04

main（）からswitch（mode）でCreateAを通らしてmodeの値を変えてAに飛んで
Crate～ってのが頂点データとか設定とかだけやっててすぐにTRUE返して。
A関数で描画を行なってるんですけどA関数はキーボードに反応させて１を
押したらTRUE返してCreateBに移ってこれもまたデータの設定とかで
B関数に飛んでまわしてるんですけど。
CreateA→Aでは欲しい結果は返ってきててそのあと返り値でCreateB→B
にいくとおかしくってるんですよね。
これでCreatA→Aを通さず、CreatB→Bだけだと成功するんですよね。
CreateVertexBufferのLock→書き込み→unlockって別に何度というか
2回しても大丈夫ですよね。

**名前は開発中のものです。** · 04/10/25 01:39:10

個人的にアクロバティックな動き方だと思うんだけど
switch(mode)
{
value1:
     CreateA();
     break;
value2:
     if( A() == TRUE )
          CreateB();
     break;
}
////////////////////
BOOL A()
{
     描画
     if( キー操作 )
          return TRUE;
     return FALSE;
}

void CreateB()
{
     B();
}

void B()
{
     描画
}
こういうこつ？

**名前は開発中のものです。** · 04/10/25 02:01:03

VertexBufferは何度も書き直しても大丈夫だけど
(自分のプログラムはしょっちゅうやっている　いいか悪いかは知らねｗ）

処理の順番に問題があるような、そんな貴方に

『出来るだけシンプルに。しかしシンプル過ぎず。』

225を元にしてだけど、Aという関数が仕事し過ぎのような。

**名前は開発中のものです。** · 04/10/25 03:27:46

説明通りか検証もない動作をグダグタ述べるならソースをUPしろ。
多分一発で解決だと思う。
コーディングミスってオチでね。

**名前は開発中のものです。** · 04/10/25 15:44:08

＞225
そういうことです。

**名前は開発中のものです。** · 04/10/25 21:01:54

＞226
Aという関数が仕事し過ぎのようなとはどういうことですか？

**名前は開発中のものです。** · 04/10/26 18:31:24

>>229
一つの関数で多くの処理をやりすぎているってことだろ

つーか、225氏も言うとおりだが、プログラムがかなり怪しい動き方をしてると思うよ。
やりたい作業の手順の書き下し方がよくないんだろうと思うけれどなぁ。

**名前は開発中のものです。** · 04/10/26 19:24:05

ゲームを作ってるんですがタイトル画面→ゲーム画面っていうふうにしようと思って
while (!end){
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE)){
　TranslateMessage(&msg);　DispatchMessage(&msg);
}else{
　Main();
}
}
ーーーーー
void Main(){
　　switch(Mode){
　　case 0:
　　　if( CreateA() )
　　　　　Mode=1;
　　　　　break;
　　case 1:
　　　　　if( A() ){
　　　　　　if( CreateB() ){
　　　　　　　Mode=2;
　　　　　　　break;
　　　　　　}
　　　　}
　　default:
　　　　end=1;
　　}
}

こんな感じでCreate～で頂点データの作成とか設定を書き込んで
～関数で描画って感じでしてるんですがアクロバティックですかね。
オーソドックスなスタイルを教えていただけませんでしょうか？
ちなみに欲しい結果はえられましたのでだいじょうび。

**名前は開発中のものです。** · 04/10/26 19:51:17

Mainって・・・

**名前は開発中のものです。** · 04/10/26 20:09:39

モード分けなんてしないで
タイトルロゴもボスシーンもエンディングもメニュー画面もすべて同じゲーム中のイベントとして考えればよい。
プログラムが始まってシステムの初期化が終わればメインループを抜けることは（ゲーム終了時をのぞき）無い。

**名前は開発中のものです。** · 04/10/26 20:30:31

そもそもメッセージがないときにCPUをぶん回すその書き方は、
あちこちで見かけるが、最悪のコーディングなんだが。

**名前は開発中のものです。** · 04/10/26 20:31:16

>>231

**名前は開発中のものです。** · 04/10/26 20:53:00

>>234
べつにいいんじゃねぇ？
DirectXのフリップ関数はいってるんだろどうせ。
なら大丈夫じゃね。

**名前は開発中のものです。** · 04/10/26 20:57:49

>>231の方法だとモードが増えたらその分だけcase文を増やさなきゃならん、
モードが増えてもメインループのコードには手を付けなくて済むように書く

この手のプログラムは「状態の時間進行」と「現在状態の描画」の繰り返しなわけよ。
その2つの作業をする関数を定義しといたModeBase抽象クラスでも作っておいて
メインループはそいつを駆動させるように書く。
んでモード変更があったらポインタを入れ替えるだけで済む、と大体こんな感じ

>>236
余談だがPresentはCPUパワーを開放しないから
やっぱSleepをどっかで入れないと駄目らしい

**名前は開発中のものです。** · 04/10/26 21:06:11

>>237
それってモードいくつ作ることが前提なシステムなんだよ。
話聞いてると３～４こで済みそうなのに、
なんでそんなアホみたいに量産しないと元がとれないような設計勧めるんだ？
おそらくな、>>231はな、
タイトル画面→ゲーム画面→エンディング画面
でいいんだよ。
だったらcase文が一番シンプルで綺麗にかけるじゃねぇか。

>余談だがPresentはCPUパワーを開放しないから
俺のプログラム、Sleep入れて無いけどタスクマネージャで見てもCPU100%いかないよ。

**名前は開発中のものです。** · 04/10/26 21:11:09

ビデオカードが対応していれば、垂直同期待ちでCPUは使用されないが、
今度は同期待ちの間、メッセージが処理されなくなる。
素直にイベントとスレッドを分けるべき。

**名前は開発中のものです。** · 04/10/26 21:13:58

>>239
その結論はもちろんビデオカードの対応状況を調べた上での結論と思っていいんだろうね。

**名前は開発中のものです。** · 04/10/26 21:28:05

>>240
確認したのはGeForce2/4、Radeon9600で、全て対応していたが、
市場の出回っているビデオカードを一つ残らず調べろと言うことなのか？

**名前は開発中のものです。** · 04/10/26 21:37:32

俺Detonator(GF3Ti)もCatalyst(RADEON9500Pro)も使ってるけど両方とも100%だわ。

それと>>239に対して>>240は全く見当はずれの回答をしているように思えるわけで

ついでにswitchと関数ポインタ系のやり方ってどっちがシンプルかって
それは人によって評価違うだろうしなんとも言えんけれど
俺はオーソドックスなのはやっぱ関数ポインタな気がするけどどうだろう

**名前は開発中のものです。** · 04/10/26 21:47:01

>>242
確認してもらいたいんだが、
DX9cSDKサンプルからOptimizedMesh.exe(負荷の軽いサンプルなら何でも)を実行して、
デバイス設定をINTERVAL_DEFAULTに変更してCPU使用率を見てくれ。
最近のビデオカードなら普通は対応しているはずなんだが。