DirectX総合スレ (Part2)

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

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

テンプレは >>2以降で

**名前は開発中のものです。** · 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

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

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

＞固定シェーダ
たしかにそんな存在しないものが使えるのは馬鹿くらいだろう。
>>284みたいな。

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

馬鹿な284がいるスレはこちらですか？

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

はい、こちらです。

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

>>285-287
自作自演ご苦労ｗ
でもね、絶対後悔するから素直にシェーダ組んだ方がいいよｗ
テクスチャ貼って、適当に色が付けれて、αが効いてりゃいいなら絶対にそっちの方がいい。

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

なんで？

**283** · 04/10/29 23:47:05

固定機能は暗黙の制約がいろいろあって
トラブルの元だからね。
…公で固定機能に言及するときは「シェーダの方がベター」
みたいな予防線が必須みたいだね。

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

別に固定機能だって使えてりゃOKさ、予防線なんかいらないよ
環境も考えずにシェーダシェーダ言っている方が愚かしい

**名前は開発中のものです。** · 04/10/30 02:07:55

>>291
はぁ？
実は、よくわかってないだろｗ

**名前は開発中のものです。** · 04/10/30 02:08:53

＞環境も考えずにシェーダシェーダ言っている方が愚かしい
固定機能のみ、の環境なんて方が愚かしいと思えるけど…
環境を考えて…固定機能!となる環境が愚かしいw
今時固定機能が貧弱でも
頂点シェーダーVer1.1をソフトウェアで動かした方がマシな場合が多いでしょ。

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

ピクセルシェーダ2が使える環境なら迷わずシェーダ使うけど
それ未満の環境だとシェーダなんぞめんどくさくて使いたくもないなぁ
というのが俺的な感想

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

固定パイプよりバーテクスシェーダ使った方が早いのは間違いないのかね。
ハードウェア処理よりCPUでやるソフトウェアバーテクスシェーダのが速かったと言う話はちょっと聞いたことあるが。

**名前は開発中のものです。** · 04/10/30 03:43:37

パーテックスシェーダ使えばサポートしてるＰＣでより快適に動いてくれるんだから問題ないだろ。
サポートしてなくたってそれなりに動くし。

問題は固定パイプ独特のくせだよ。
あの腐った構造見てると、ホント、イライラする。
固定パイプ特有の動き覚えなきゃいけないし、なんのためにもならない。
触っても今後に生きてこない。

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

そこまでボロクソに言う必要はないと思うがなあ。
シェーダ使ったほうが直感的に作れるのは間違いないが。
固定パイプだって見事にできてると思うよ。

まあ294でも書いたが頂点シェーダなんぞどーでもいいから
とりあえずピクセルシェーダ2を使わせろと言いたいんだが
流石にPS2は対応環境が限られてくるから趣味プログラミングでしか使えないのが寂しい。

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

>>296
> サポートしてなくたってそれなりに動くし。
羨ましい発言だな

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

つまり固定を使っているFFXIの制作者達は馬鹿ばっかりと言いたいわけか。

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

>>299
固定かどうかはわからないはずだけど。
どうやって調べたの？

つか、もし俺が作るなら、
スキニング使う時点でシェーダ使った方が楽ではあるね。

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

頂点シェーダだけでも使用するというアプローチは場合によっては
アリかもしれないけど(スキニングとか)、ほとんどの場合、
主役はピクセルシェーダだからねぇ。
頂点シェーダだけでは半透明化すら困難っぽいし。

頂点シェーダをソフト処理しようと思ったら、デバイス生成時に
D3DCREATE_SOFTWARE_VERTEXPROCESSING とか指定しないといけないと思うけど、
例えばスキニングをする描画の時だけこれを効かせる(他の描画はハードで処理)
みたいなことは無理なのかな。