DirectX総合スレ (Part2)

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

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

テンプレは >>2以降で

**名前は開発中のものです。** · 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使用率を見てくれ。
最近のビデオカードなら普通は対応しているはずなんだが。

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

>>243
すまん確認したら負荷なしだった…。
つい先日まで同カードで負荷100%いってたゲームがあったから駄目なもんだと思ってた。
相当駄目なやり方してたのかなｗ

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

>231
A()とCreateB()が何かはしらないが漏れならこうする
てかcase 1のbreakおかしいぞ
てか直値よりenum使って変更したときのミスを減らせ
enum {GAME_TITLE=0,GAME_A, GAME_B,GAME_END};
void Main(){
　　switch(Mode){
　　case GAME_TITLE:
　　　if( CreateA() )
　　　　　Mode=GAME_A;
　　　　　break;
　　case GAME_A:
　　　　　if( A() ){
　　　　　　　Mode=GAME_B;
　　　　　}
　　　　　break;
　　case GAME_B:
　　　　　if( CreateB() ){
　　　　　　Mode=GAME_END;
　　　　　}
　　　　　break;
　　default:
　　　　end=1;
　　　　break;
　　}
}

**245** · 04/10/26 23:02:35

すまんよくよんでなかった、ダメだな
もしCretateB()に対応するB()があったらこの方がシンプルじゃないか？
switch(Mode){
　　case GAME_TITLE:
　　　　if( CreateA() ){
　　　　　　A();
　　　　　　Mode=GAME_B;
　　　　　}
　　　　　break;
　　case GAME_B::
　　　　if( CreateB() ){
　　　　　　B();
　　　　　　Mode=GAME_END;
　　　　　}
　　　　　break;
　　default:
　　　　end=1;
　　　　break;
　　}
}
でもenumは使え

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

どうも231です。
DirectXのフリップ関数は各～関数で使ってその一つの関数が
タイトル画面やらゲーム画面でやってます。
たしかにこれで作っててどんどんcase文が増えてます。
皆様のご意見を拝見させて頂いた結果としては書いたやり方は駄目ですかね？
いっそのことMain()の中をwhile(0)でその中でシーンごとフェーズごとに
したほうがよろしいですかね？
とりあえずDirectXに関しては本ばっかり読んでまして実践向きの
プログラムを打ててないのが現状ですので皆様のご意見お伺いしたいと思っております。
よろしくお願い致します。

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

>>247
３０個以下でおさまるんなら気にすることないよ。
caseでやっちゃえ。
別にcaseが３０個以上ならんでたって俺は汚いソースだとは思わないよ。

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

関数ポインタを使いたい年頃なんだろう。
いまどきswitchは遅いから使うななんて時代じゃないよ。

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

Ｓｔｒａｔｅｇｙ/Stateパターンで一発解決の話題だな

**名前は開発中のものです。** · 04/10/27 07:54:41

クラス図は同じだが、Stragegyは違うこと無いか？

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

Stragegy

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

この場合はモロにstrategyの典型的な例だと思った

**名前は開発中のものです。** · 04/10/27 13:27:57

>>231の使用言語はCだと思うが

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

マリカーとかで対戦するとき画面分割があるじゃないですか、
そういった画面を2分割・4分割でする方法ありましたらご教授お願いします。

**名前は開発中のものです。** · 04/10/27 16:41:36

分割したいぶんだけ、一つ一つ描画すればいいだけだが、
いったい何が聞きたいのかわからん。

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

ビューポート変更してレンダリング

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

例えば箱を(0,0,0)に表示させてカメラの位置を変えて4画面でしようと思ったら。
Clear→ビューポート設定→カメラ設定→箱描画→
　　　ビューポート設定→カメラ設定→箱描画→
　　　ビューポート設定→カメラ設定→箱描画→
　　　ビューポート設定→カメラ設定→箱描画→Present
でOK?ってことですかね？
試したんですけどなんか画面がちかちかする。

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

>>258
勘だけど

Clear→ビューポート設定→カメラ設定→箱描画→
　　　 ZBufferClear→ビューポート設定→カメラ設定→箱描画→
　　　 ZBufferClear→ビューポート設定→カメラ設定→箱描画→
　　　 ZBufferClear→ビューポート設定→カメラ設定→箱描画→Present

で上手くいっちゃったりして・・・？

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

>>258
クリアの前に画面全体をビューポートに指定してる？

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

>>258
Clear→ビューポート設定→カメラ設定→箱描画→ Present
　　　ビューポート設定→カメラ設定→箱描画→ Present
　　　ビューポート設定→カメラ設定→箱描画→ Present
　　　ビューポート設定→カメラ設定→箱描画→Present
になってないか？

**名前は開発中のものです。** · 04/10/28 09:51:31

>83>96
ノートっつても最低スペックは決めれるだろ
比較的最近のノートを対象にするならDirectX7の3Dうごくだろ
少し古くてもDirectX6くらいは動くはず
そのあたりのDirectXのバージョンのアルファブレンド機能を使うのはOKだろ
じゃなきゃGDI+
でも、GDI+がどのWindowsまでサポートしてるかはしらないなぁ
アセンブラでごりごりやるなら全画面でやらなければ結構高速なんじゃないか?
紙芝居ゲーなら背景とアルファブレンド途中の画像をレンダリングしておいて、
それを張り付けるだけならマシンに負荷かけずに見た目上クロスフェードできるし、高速にできる
ファイルサイズがでかくなるけど
まぁクライアントも幅広いPCを対象にいれたいってのに必死なんだろ
でもDirectX6くらい動くだろ...

**名前は開発中のものです。** · 04/10/28 16:32:29

テクスチャ読み込みの関数とかＸファイル読み込み関数があるじゃないですか？
D3DXLoadMeshFromX・D3DXCreateTextureFromFileEx
データが大きくて読み込み時間が長いのでロード画面をつくりたいので
すが関数よんでも上の関数は処理は帰ってこないですよね。
ってことはロード画面はどうやって作ればいいんですかね？

**名前は開発中のものです。** · 04/10/28 16:40:35

directshowで画像取り込みのプログラムをしています。ってか卒研のテーマです。カメラからの画像のたれ
ながしはできますが一枚とるプログラムが完成しません。ビルドまではできるん
ですがActive movie windowを表示して5秒後くらいにwindowが真っ白になってフリーズ
します。回りにdirectX扱える人いなくてほんと困っています（担当の先生すら扱えないT_T）。誰か教えてください。
プログラムの流れは
ピンの列挙→main(本文)→フィルタグラフマネージャの作成→システムデバイス列挙子作成
→モニカの列挙→モニカをフィルタオブジェクトにバインド→フィルタを追加
→キャプチャビルドの作成→ファイルライタフィルタの設定→サンプルグラバの生成
→メディアタイプの設定→フィルタグラフの追加→サンプルグラバの接続
→グラバのモードを適切に設定→ファイルへ出力→キャプチャ開始→
→サイズの取得→一枚キャプチャ→バッファ取得→解放
どこが間違っているのかが分かりません。分かる人教えてくれませんか？

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

>>263
別スレッドにする。
>>264
どこでフリーズするか調べたら解決しないか？

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

>>264
マルチうぜー

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

>>263
手を抜きたきゃ、ロード画面描画＞表示されてからロード開始。

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

Xファイルで描画しているモデルを半透明処理したいのですが
αブレンディングを有効にしても変化しません。
誰か助けて

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

d3drs_srcblend, d3drs_destblend

**264** · 04/10/29 12:40:33

デバッガ使用しましたら無限ループしてるとこ発見しました。
do{
pSGrab->GetCurrentBuffer(&bufsize, NULL);
　}while(bufsize <= 0);
なぜここが無限ループしているか分かりません。bufsizeは
long *buffer = NULL;
long bufsize = 0;
て宣言しています。なぜ無限ループするかよろしければ教えてください。

**名前は開発中のものです。** · 04/10/29 12:48:36

>>270
マルチとは良い度胸だ

**名前は開発中のものです。** · 04/10/29 13:04:05

しかもマルチを指摘されてるのに
またのこのこ出てきて
謝るわけでもなければ悪びれた様子もなく
当然のごとく再び質問を投げるというナメた態度が気にいらない。

**名前は開発中のものです。** · 04/10/29 13:36:34

構うから図に乗るんだよ
構う方が悪い
動物相手するときと同じ

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

>270
戻り値のチェックくらいしてから来てください

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

>>270
卒論ってどこの大学だよ？
何勉強してんだ？

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

マルチ野郎は放置で。

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

アニメ風っていうのかな？トゥーンシェーディングっていうんですかね。
あれはどうやってるんですかね？Xファイルで試したいんですが。

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

>277
法線と光源から頂点の明るさを求めるんだけど
最後の出力を明るさじゃなくてテクスチャ座標にしてやるだけ
シェーダかじればすぐできる

**名前は開発中のものです。** · 04/10/29 19:44:02

>トゥーン
DQ8の影響かなｗ

**名前は開発中のものです。** · 04/10/29 19:55:27

いや、村上ジョ）ｒｙ

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

>279
もう新しい技術ではないんだけどな
もう２年以上前から初心者向けDirectX書籍で取り扱ってた気がする

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

>>268
自分LightWaveからXFile作ってるけど
そのままじゃ、Diffuse設定されてなかったから
半透明に出来なかった。

XFileの内容は分からないけど
Diffuseが設定されているか見てみては？

"ちゃんと確認した"なら
1,CloneMeshFVFでD3DFVF_DIFFUSE追加
2,GetVertexBuffer
3,lock
4,Diffuse設定
5,Unlock
6,Release

と、これで自分の奴は問題なく半透明

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

>>268 固定機能ならこんな感じで。
D3DCOLOR color = D3DCOLOR_ARGB( 128, 0, 0, 0 );
GetD3D()->SetRenderState( D3DRS_TEXTUREFACTOR, color );
GetD3D()->SetTextureStageState( 0, D3DTSS_ALPHAARG1, D3DTA_TFACTOR );
GetD3D()->SetRenderState( D3DRS_ALPHABLENDENABLE, TRUE );
// (描画)
GetD3D()->SetTextureStageState( 0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE );
GetD3D()->SetRenderState( D3DRS_ALPHABLENDENABLE, FALSE );

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

固定シェーダなんて使ってると馬鹿になるぞｗ