09/06/22 22:28:04
四十年勤め上げた會社を退職し早二十年、何やら張り合いの無い日々を送る内、
大學生の孫に「退屈しのぎに遣って見たまへ」と勸められた弐チヤンネル。
當初は「こんな電腦?示板、何たる幼稚加減」と莫迦にしてゐたものの、
遣つて見ると存外に面白ひ。
華やかな色彩の髪と目を持つうら若き乙女に「ゆとり乙」と何度と無く罵られるにつけ、
食ふや食はずやで慌しく過ぎ去つた學生時代が自ずと思ひ返され、
「戰爭さえ無ければ、小生もこのやうな青春が送れたやも知れぬ」と獨りごちる事も屡々。
すつかり?となつた今では、孫の部屋から白銀色の電腦計算機をせしめては書齋に篭もり
存分に「祭り」を堪能する毎日を送つている。
「小四女兒遺棄事件」なるスレツドを拜讀した際には、その餘りに不憫な境遇と過酷な
運命に落?し、臺所で葱を刻む家内に「かような理不盡が許されて良いものか!」と
熱辯を振るって呆れられる始末。年甲斐も無い、とはこの事と後で赤面する事しきり。
下手の横好きとは云え「繼續は力なり」の言葉通り、最近ではブラクラの回避や
コピペの管理にも慣れ、「好きこそものの上手なれ」を座右の銘として弐ゲツトに勵んでいる。
同年代の友人達が癡呆や重い病に惱まされる中、老いて尚矍鑠としてオフ會に向かえるのも、
偏に弐チヤンネルの御蔭かと思えば、再三に渡る「半年ROMつてろ」の罵り文句も、
何やら「まだまだ死ぬには早いよ」と言われているやうで愉快極まれり。
一つ間違えれば自らが乗り込んでいた機體と同じ名前を持つコテハンに出會える日を
樂しみにしつつ、今日もデスプレヱに向かう。
それでは、弐ゲツト。
3:デフォルトの名無しさん
09/06/23 11:51:53
乙
4:デフォルトの名無しさん
09/06/23 21:08:35
スキンメッシュのクラス化を試みているんだが、
メソッドとソフトウェアフラグだけはグローバルに置かないとエラー終了する
何故？
クラスのメンバに含めるのは無理？
5:デフォルトの名無しさん
09/06/23 21:22:46
それはスキンメッシュ関係なくC++が分かってない
6:デフォルトの名無しさん
09/06/24 02:08:52
staticで解決したお
7:デフォルトの名無しさん
09/06/24 09:00:00
staticはやめましょう
8:デフォルトの名無しさん
09/06/24 09:12:22
staticは別に悪くないだろ。
>>4のソースは悪いのは確定だが。
9:デフォルトの名無しさん
09/06/24 10:03:48
サンプルにあるDrawSubsetを使うmesh描画でモデルを描画してみたのですが糞重いです
同じPCで市販のゲームというか無料MMOなんかを見ると
どれもこれももっと大量のモデルを表示してるように見えるのですが
それでも十分な速度が出ています
これらはどうやってるのでしょうか？
モデルを細かく分割して、視野に入るものだけを描画とかはしています
何か根本的に別の描画方法だったりするのでしょうか？
10:デフォルトの名無しさん
09/06/24 10:37:33
それだけでは状況がよくわからん
どう重いのか、メッシュの数やポリゴン数、シェーダー使ってるかやFPSはどの程度なのかまで網羅されてないとな
結論から言うとDrawSubset以外の描画は無いけどな
11:デフォルトの名無しさん
09/06/24 10:59:19
PIX仕え
12:デフォルトの名無しさん
09/06/24 11:13:22
ID3DXFont::DrawTextA で日本語が文字化けするのはどんな理由が考えられますか？
渡している文字列 (char*) をデバッガで確認するとちゃんとなってます。
プロジェクトのプロパティで、「文字セット」は「設定なし」になっています。
13:デフォルトの名無しさん
09/06/24 11:15:48
ためしに MultiByteToWideChar で CP_THREAD_ACP で wchar_t* に変換したものを DrawTextW にわたしても、
やっぱり文字化けしているのです。DrawText にそのままわたしても、char* と wchar_t* どちらも文字化けします。
14:デフォルトの名無しさん
09/06/24 11:16:18
炎を表現するためにパーティクルを行っているのですが、質問です。
・1つの炎を表現するのに、DrawPrimitiveUPを1回使っています。10個程度の炎を画面に出しています。
・ポイントスプライトを使っています
これで、100個程度のポイントスプライト×10炎 を表示していうのですが、動作の重さで疑問点があるのです。
描画にかかる時間（DrawPrimitiveUPを呼び出す前から、Presentが終わるまでの時間）を測っていると
・画面に大きく映るように、カメラの視野角を変えた場合
・画面にすごく小さく映るように、カメラの視野角を変えた場合
で、後者のほうが遅いのです。
前者だと10ms、後者だと17msくらいになります。
比較する際、カメラの視野角以外は一切変えていません。
何かしら「ポリゴンは小さく表示しすぎると遅くなる」などの制限があるのでしょうか？
15:デフォルトの名無しさん
09/06/24 11:31:36
最近のSDKのサンプルを読んでいたら
s_hModD3D9 = LoadLibrary( L"d3d9.dll" );
のように、Direct3DのDLLなどを動的に読み込んでいました。
昔の本などによると、あまりよろしくない手法で、だからこそ
「対応したDirectXがインストールされていないマシンだと、DLL不足を指摘するダイアログがでて終了するので、ユーザーにわかりやすい警告ダイアログを出せない」
とかされていたような・・・
16:デフォルトの名無しさん
09/06/24 11:54:00
だからこそからの繋がりがよく分からん
自前の警告を出すためにプログラムからロードしろって事？
17:デフォルトの名無しさん
09/06/24 11:56:00
視野角狭くした状態でも全部の頂点・面が画面内に入ってんの？
18:デフォルトの名無しさん
09/06/24 13:21:10
>>17
はい、画面内に視野角が広くても、狭くても、全ておさまっています。
頂点シェーダの負荷は変わらないでしょうし、
ピクセルシェーダの呼び出し回数はむしろ大きく映っている方が多いはず・・・
と悩んでいるところです。
19:デフォルトの名無しさん
09/06/24 13:24:56
日経盛り返してきました、ありがとうございます
あと５０円上がったら利食いしますのでそれまで上げてください
20:デフォルトの名無しさん
09/06/24 20:04:50
>>14
ポイントスプライトが大きいが為に
殆どのピクセルのZテストが通らなくなって
結果、更新されるピクセル数が少なくなってるとか。
21:デフォルトの名無しさん
09/06/24 20:35:05
DirectX9で2Dゲームを作ろうとしていまして、画像ファイルが独自フォーマットで
メモリ上に展開してそこからsurfaceに変換して、たくさんのアイテムやキャラクタが
存在するわけですけど、それらはまとめてバックバッファのsurfaceにupdateSurface()
を使って描画しようと企んでいるのですが、一つ問題がありまして
というのは、この様にsurfaceにばかりたよって描画してしまうと、アルファブレンディング
が出来ないということです
surfaceをアルファブレンディングしてバックバッファに書き込むということさえ出来たら
いいのですが、textureやらsprite辺りが全く理解できていないので分かりません
全部textureとして持ってspriteに描画すれば解決しそうだというのは分かるのですが、
surfaceとして持てるものをわざわざ全てtextureとして持つのは少し躊躇いがあります
何かいい方法はあるでしょうか
22:デフォルトの名無しさん
09/06/24 20:38:38
ポイントスプライトって回転ないから
小さく薄いパーティクルを無駄に数を出しがちじゃね？
炎・煙・水しぶきとか形のあるものはランダムに角度付けたいじゃん。
23:デフォルトの名無しさん
09/06/24 20:40:41
>>21
バックバッファ更新用の
キャラクタが描かれたサーフェイスは
どうやって作っている？
そこにキャラを描く際、アルファを
反映させればいいんじゃないの？
24:デフォルトの名無しさん
09/06/24 20:43:41
>21
画像データをサーフェイスに溜め込んで、描画はStreachRectやりきりたいということですね？
そんな手法でいろいろやろうとしてるのは世界であなただけです。だれもノウハウ持ってませんよ。
25:デフォルトの名無しさん
09/06/24 20:49:09
>>23
実はまだ作っていはいないんですが、色々と調べたところ
1. 空のsurfaceを作って、lockrectして色情報を書き込んでいく
2. D3DXLoadSurfaceFromMemoryを使う
この二つが候補に挙がっていまして、2.を使おうと思っています
MSDNを良く見ると、ここでアルファを設定できるみたいですね
これでUpdateSurfaceの時にうまく動くのですね？
今の段階では必要になるかは分からないですが、アルファ値が動的に変わるような
surfaceの場合、既にあるsurfaceのアルファ値を変えられるのか、それとも
また新たにsurfaceを作らないといけないのかどちらでしょう？
26:デフォルトの名無しさん
09/06/24 20:52:06
>>24
その通りです
普通はspriteにtextureを描くのでしょうけど、どうもそれらの正体がはっきりとしなくて使い渋っているのです
加えて、メモリにある色情報からtextureを作成する方法も分からなかったのも原因の一つです
27:デフォルトの名無しさん
09/06/24 21:09:19
>>メモリにある色情報からtextureを作成する方法も分からなかった
サイズ分のテクスチャを生成して
ロックして色情報を書き込むだけでいいだろ
28:デフォルトの名無しさん
09/06/24 21:10:28
SetStreamSourse
DrawPrimitive
をセットで何回も呼び出すよりも
CPUでそれを１つのトライアングルリストにまとめて
DrawPrimitiveUP一回で描画する方が速いのですが
これはストリームソースの使い方が間違ってるでしょうか？
29:デフォルトの名無しさん
09/06/24 21:58:05
>>28
DrawPrimitiveのオーバーヘッドの影響かな？
頂点数を相対的に増やしていけば、
その差は縮まるんじゃないかなぁ。
30:デフォルトの名無しさん
09/06/24 21:58:51
DrawPrimitiveの読み出しがそもそも遅い
31:デフォルトの名無しさん
09/06/24 22:24:39
HLSLでVSからPSにグローバル変数で値を持ち越す事って出来ないですよね？
なんか挙動を見る限り入ってなさそうで・・・
32:デフォルトの名無しさん
09/06/24 22:56:41
>>29-30
頂点数と転送回数のバランス次第ではありえるということですね
ありがとうございます
33:デフォルトの名無しさん
09/06/24 23:07:15
>>31
そもそもシェーダからグローバルメモリへの
書き込みは出来ません。(DX10はしらね)
34:デフォルトの名無しさん
09/06/24 23:41:51
>>33
varyingみたいに使えればなーと思ったんですが
やはりVSから構造体に詰めて渡すしかないんですね
ありがとうございます
35:デフォルトの名無しさん
09/06/24 23:52:10
>>34
そもそもそれぞれが並列処理で動いてるのにグローバル変数をどうやって管理するつもりだったんだ？
シェーダーは逐次処理でまわってるわけじゃないぞ。
36:デフォルトの名無しさん
09/06/25 01:49:39
シェーダーを延々と長々書き足していったら途中で動かなくなってしまい
どうやら一定量超えると動かないみたいなのですが、これは容量オーバーなのでしょうか？
37:デフォルトの名無しさん
09/06/25 01:57:19
シェーダープロファイルでインストラクション数に制限がある
38:デフォルトの名無しさん
09/06/25 02:05:59
ありがとうございます
39:デフォルトの名無しさん
09/06/25 09:39:40
>>20
情報不足で申し訳ない。
加算合成なので、Zテストはしていないんです。
ただ、どちらにしろそれが「小さい方が遅い」結果にはつながらない気がしますね。
>>22
むしろ角度をつけないのが良い。とか思っていましたが、そういうものでしょうか。
確かに飛び散る火の粉がいつも同じ形なのは問題かもしれませんね
40:デフォルトの名無しさん
09/06/25 09:43:47
後考えられるとすれば、縮小時は元の解像度より下がってフィルタがかかってる
拡大時は元の解像度より上がってフィルタがかかってない
そういうフィルタ設定でテクスチャを張ってる前提だけど。
テクスチャ外してみたらどうなるよ
41:デフォルトの名無しさん
09/06/25 13:11:04
ウィンドウを一色で塗りつぶすことって出来ますか?
42:デフォルトの名無しさん
09/06/25 13:18:28
>>40
ミップマップの生成はD3DX_DEFAULTで、拡大も縮小もLINARです。
テクスチャ外しても再現しました。
視野角ではなくカメラからの距離（遠くなり、小さく描画されている時の方が遅い）でも、再現しました。
それと、パーティクルの生成数を10倍にしたところ、「大きく映っているほうが遅い」という常識的な結果になりました。
つまりまとめますと
「描画量が少ないと、小さく映っているほうが遅い時がある」
って感じですね。
これだとロジックのどこかにバグがあるかと思われるかもしれませんが、本当にカメラ位置しか変えずにコンパイルしています。
描画量が少ないと。といっても、毎フレーム100個ほどのポイントスプライトを描画しているんですけどね。
500個にしたら逆転しました。（小さく映っているほうが速くなりました）
43:デフォルトの名無しさん
09/06/25 14:35:03
インスタンス処理について質問があります
サンプルのInstancingなのですが、技法３、定数のインスタンス化の処理はあまり意味ないように思えるのですが
これって効果あるのでしょうか？
for( int nRemainingBoxes = 0; nRemainingBoxes < g_NumBoxes; nRemainingBoxes++ )
{
// set the box Instancing array
V( g_pEffect->SetVector( g_HandleBoxInstance_Position, &g_vBoxInstance_Position[nRemainingBoxes] ) );
V( g_pEffect->SetVector( g_HandleBoxInstance_Color, (D3DXVECTOR4*)&g_vBoxInstance_Color[nRemainingBoxes] ) );
// The effect interface queues up the changes and performs them
// with the CommitChanges call. You do not need to call CommitChanges if
// you are not setting any parameters between the BeginPass and EndPass.
V( g_pEffect->CommitChanges() );
V( pd3dDevice->DrawIndexedPrimitive( D3DPT_TRIANGLELIST, 0, 0, 4 * 6, 0, 6 * 2 ) );
}
44:デフォルトの名無しさん
09/06/25 15:19:18
>>43
サンプルをみたが、1(HWInstancing)以外は
あまり意味はないな。
1の比較対象として、用意しているに過ぎない。
特に3は、普通に描画してるだけだな。
45:デフォルトの名無しさん
09/06/25 15:39:45
ありがとうございます。
2だとDrawPriitiveを減らせる効果はあるぐらいですかね
同じモデルを複数回描画するのを効率化したいのですが、
ハードウェアインスタンスを使えたら使う、使えなければ普通に描画するしかないということでしょうか？
46:デフォルトの名無しさん
09/06/25 15:54:08
2だか忘れたけど、同じモデルデータを大量に複製して
頂点にID持たせてつなげてビデオメモリに転送しとく奴だっけ？
板ポリゴン大量に扱いたいけどハードウェアインスタンス使えないって時に結構使えて気もするが
47:デフォルトの名無しさん
09/06/25 16:01:07
>>46
2はそうだね。
無駄重複が大量にあるのは、
キモイな。
1は、メッシュx1、DrawPrimitive x1
2は、メッシュxN、DrawPrimitive x1
3は、メッシュx1、DrawPrimitive xN
4は、メッシュx1、DrawPrimitive xN
かな。
48:デフォルトの名無しさん
09/06/25 16:10:09
>>45
そうだね。HWのそれ以外
DPを減らす方法は無いと思う。(D3D9)
ただ、サンプルの2はボックスの頂点データを
そのまま大量に複製しているように見えるが、
座標データを定数や頂点テクスチャに移せるなら、
頂点バッファは純粋にインデックスのみって構成も
可能だよね。
これがいけるんならサンプル2も、対象に入りそうだな。
49:デフォルトの名無しさん
09/06/25 17:06:01
初歩的な質問で申し訳ありません。
C言語が必要になり、根っからの文系人間が「Cの絵本」という本でもってプログラミングに挑戦しています。
if文のところで、
#include <stdio.h>
main()
{
int s = 65;
printf("あなたの点数は%d点です。\n", s);
if(s < 70)
{
printf("平均点まであと%d点。\n", 70-s);
printf("がんばりましょう！\n");
}
else
{
printf("よくできました！\n");
}
}
という文を作りました。
ここから月数に応じてコメントを表示するプログラム（1月ならばwinter、3月ならspringといった具合に）を作りたいのですが、どのように変化を加えればよいのでしょうか？
月は1月～12月までなので、13月以上と1月未満の数値を打ち込んだ場合はerrorと表示させたいです。
よろしくお願いします。
50:デフォルトの名無しさん
09/06/25 17:09:52
凄くすれ違いです・・
51:デフォルトの名無しさん
09/06/25 18:05:34
SetRenderTargetで描くのと
UpdateSurfaceでコピーするのは
どっちが速いですか？
52:デフォルトの名無しさん
09/06/25 19:11:09
頂点バッファ作成で躓いてますorz
struct VERTEX
{
float x,y,z;
DWORD color;
enum{ FVF = D3DFVF_XYZ | D3DFVF_DIFFUSE };
};
IDirect3DVertexBuffer9* pvb = NULL;
Graphics->GetDevice()->CreateVertexBuffer( sizeof(VERTEX)*3, D3DUSAGE_DYNAMIC, VERTEX::FVF, D3DPOOL_MANAGED, &pvb, NULL );
ってやってるんですがCreateVertexBufferを呼んでもpvbがNULLのままで・・・
エラーではD3DERR_INVALIDCALLが返ってきてます．
MSDNみると
メソッドの呼び出しが無効である。
たとえば、メソッドのパラメータに無効な値が設定されている場合などである。
とあるのですがおかしいところも見当たらない気がします．
どこか他で不具合出てるのでしょうか・・・．
思い当たる節がないので困ってます
53:デフォルトの名無しさん
09/06/25 19:21:20
インデックスバッファや頂点バッファは
D3DPOOL_MANAGEDをD3DUSAGE_DYNAMICでは作れなったかったきが気がする
D3DPOOL_DEFAULTが推奨
54:デフォルトの名無しさん
09/06/25 19:27:29
動的なバッファにする必要がないなら
D3DPOOL_MANAGEDのままで使用方法に0を指定するのも有
55:デフォルトの名無しさん
09/06/25 21:22:56
髪の毛みたいなソフトボディ？のアニメーションもキーフレームアニメーションでできるのですか？
56:デフォルトの名無しさん
09/06/25 21:52:41
スキニングを探してるのか？
57:52
09/06/25 21:54:53
ご協力ありがとうございました．
CreateVertexBuffer解決しました．
Usageを0にしたのと
D3DPRESENT_PARAMETERS構造体の
AutoDepthStencilFormatをD3DFMT_D24FS8にしていたのを
D3DFMT_D24S8に変更でいけました．
58:デフォルトの名無しさん
09/06/25 22:29:41
DirectInputについて質問です。
秒間60回入力を拾っても、描画の垂直同期待ちとかで
一瞬予定通りに拾えない時間帯があると思います。
（ペイントソフトを作ってマウスで線を描くと、線が切れる部分が出る）
自分はマルチスレッドで入力を回収し、バッファにためておくことで解決しようと
考案中なのですが、みなさんが他に良い方法を使用していたら、教えてください
59:デフォルトの名無しさん
09/06/25 22:32:43
DirectInputでマウスさんさとゃでめよん
60:デフォルトの名無しさん
09/06/26 00:06:10
>>58
変なことやらないほうがよくね？
仮に１フレームで押してる・押してないと２つの状態がとれたときにそれはどっちが優先なの？
たまに押した状態がくっついてるような変なアプリみるけど
それって小細工のたまものだと思うｗ
61:デフォルトの名無しさん
09/06/26 00:11:20
IDirectInputDevice8::GetDeviceDataで
入力履歴の配列が得られる。
これで何時押されて、何時離されたか
判断出来る。
62:デフォルトの名無しさん
09/06/26 01:22:24
それってパッドの入力履歴とれる？
63:デフォルトの名無しさん
09/06/26 08:58:01
>>58
入力はスレッドでやり、スレッド優先度を高くしておく。
ただしそのままだとそいつが処理を食ってしまうので、きちんとWaitEventやらで沈黙することが大事。
64:デフォルトの名無しさん
09/06/26 19:04:47
普通のメッシュファイルは表示できるんだけど、
テクスチャとかマテリアルでアルファ値が設定されていないものを
任意のアルファ値で半透明に表示する方法はないですか？
65:デフォルトの名無しさん
09/06/26 19:07:38
そういうシェーダを書く。
マジで。
固定シェーダ（笑）でもできるけど、面倒この上ないよ
66:デフォルトの名無しさん
09/06/26 19:10:32
なんか質問するごとにシェーダでやれと言われまくるんだよなー
そろそろ勉強したほうがいいのかな
どこから勉強すりゃいいのかよくわからんのだが
67:デフォルトの名無しさん
09/06/26 19:10:40
D3DTA_TFACTORを使えば簡単だけど
シェーダーでやった方がいいな
68:デフォルトの名無しさん
09/06/26 19:12:48
SetTextureStageState( D3DTSS_CONSTANT, 任意色 );
SetTextureStageState( D3DTSS_ALPHAOP, D3DTOP_SELECTARG1 );
SetTextureStageState( D3DTSS_ALPHAARG1, D3DTA_CONSTANT );
別に面倒ってほどでもないなあ
69:デフォルトの名無しさん
09/06/26 19:14:39
>>66
エフェクトからやれ。
エフェクトファイルは必須だから。
70:デフォルトの名無しさん
09/06/26 19:19:25
スプライトをSetRenderTargetの咲に描くにはどうしますか？
71:デフォルトの名無しさん
09/06/26 20:24:01
>>66
はぁ？
ていうか今日はじめて今日できる
ウンコする時間も考慮すると後３～４時間？
余裕過ぎる
そんな程度
72:デフォルトの名無しさん
09/06/26 21:27:55
>>66
気持はわかるが、マジでシェーダオンリーにしたほうがいい。
本気で。
俺も固定シェーダにこだわってゲームつくってたけど、プログラマブルシェーダに移行したら天国だった。
73:デフォルトの名無しさん
09/06/26 21:39:47
HLSLがC言語だとすると、固定シェーダーは得体の知れないアセンブラ
74:デフォルトの名無しさん
09/06/26 22:17:20
シェーダーの勉強のとっかかりになるところでいいところない？
いきなり高度なことやってるページばかりしかなくてこまる
75:デフォルトの名無しさん
09/06/26 22:19:11
×固定シェーダ
○固定機能
間違った用語を平気で使い続ける馬鹿って何なの？
76:デフォルトの名無しさん
09/06/26 23:03:47
たぶん、プログラマブルなシェーダに対しての、プログラマブルじゃない固定という意図では？
77:デフォルトの名無しさん
09/06/26 23:24:27
まぁ将来シェーダーいじるようなゲームプログラマーになりたいとかじゃなけりゃ
好きなもんを好きなように使っておけとしか言えないが。
78:デフォルトの名無しさん
09/06/26 23:31:04
アホが68件程度しか発見できないのがせめてもの救い
URLﾘﾝｸ(www.google.co.jp)
79:デフォルトの名無しさん
09/06/26 23:36:47
まあでも固定機能パイプラインを示す
適当な言葉がないのも事実。
固定シェーダでいいんじゃないの。
80:デフォルトの名無しさん
09/06/26 23:39:21
固定機能パイプラインで良いんじゃ
81:デフォルトの名無しさん
09/06/27 00:39:43
定食
82:デフォルトの名無しさん
09/06/27 01:02:27
内部を考えると固定のシェーダーとも言えなくもないがｗ
83:デフォルトの名無しさん
09/06/27 02:46:10
通じりゃいいだろ
こだわるところじゃない
84:デフォルトの名無しさん
09/06/27 02:49:13
DirectX11では
「演算シェーダ」「ハルシェーダ」「ドメインシェーダ」の
三つのプログラマブルシェーダと
テッセレーションを行うための「固定機能シェーダ」が新設されるそうな
もう紛らわしいから固定機能パイプラインは無かった子にして良いよ
85:デフォルトの名無しさん
09/06/27 07:12:24
もう固定機能パイプラインをちゃんと言うしかないな
86:デフォルトの名無しさん
09/06/27 08:20:06
固定機能パイプラインが無くなる事で
良書が増えるといいねぇ
87:デフォルトの名無しさん
09/06/27 12:36:05
directxライブラリと標準ライブラリを同時に使うことってできないんでしょうか?
88:デフォルトの名無しさん
09/06/27 12:40:39
勝手に使えよ。
89:デフォルトの名無しさん
09/06/27 12:44:25
多分同じ変数や関数が複数回使われてるみたいなエラー出たんだろ
90:デフォルトの名無しさん
09/06/27 13:00:26
DirectXつかっててそんなの出るか・・・？
91:デフォルトの名無しさん
09/06/27 19:52:46
maxとminがdefineされてるから、
std::maxとstd::minと衝突するってやつか？
NO_MINMAXでぐぐればいけた気がする。
92:デフォルトの名無しさん
09/06/28 21:09:13
同じMS製品でそんなの出るとか不良品じゃねーか
93:デフォルトの名無しさん
09/06/28 22:03:18
もともとmaxとかminとか定義してたライブラリありまくるぜ
vectorとか標準ライブラリ作った人なんでこんな名前にしたんだと思った
std::～っていちいち書くぐらいしかないのかな？
94:デフォルトの名無しさん
09/06/28 22:32:35
いちいち書いたほうがいい
STLだけ差し替えたりするし。
95:デフォルトの名無しさん
09/06/28 23:46:05
SYSPROCはどこに書けばいいの？
96:デフォルトの名無しさん
09/06/29 12:42:29
>>93
DirectXのmin maxはマクロだから、std::つけてもエラーが出る。
97:デフォルトの名無しさん
09/06/29 16:29:55
rad0 が #define されてるのが地味にトラップ。
98:デフォルトの名無しさん
09/06/29 23:07:23
DirectInput8のGetDeviceStateメソッドでジョイパッドの入力を生で受け取り
コード側でそれを、否定・論理積を使ってトリガ情報に加工して使おうとしています。
当該処理はDLLに放り込みました。
それを、Win32コンソールアプリケーションをドライバにしてforループでガンガン回しながら
テスト実行してみたところ、ベタ入力もトリガ入力も正しく取れるのですが、
本番環境のWin32アプリケーションに組み込んでみたところ、
トリガ入力がベタ同然の振る舞いをするようになってしまいました。
理屈の上では、メインループでどれだけの時間がかかろうと、かかるまいと、
GetDeviceStateが押された瞬間にキーが押しっぱなしでさえあれば
トリガとしてのふるまいをしてくれるはず・・・と期待しているのですが、どうにもなりません。
これって、いわゆる「直接入力における取りこぼし」ってやつなんでしょうか・・・
99:デフォルトの名無しさん
09/06/30 01:46:34
外人｢OH～ユーアーサムラーイCOOL！｣
農民｢ノー…アイ アム ア ファーマー…｣
外人｢オウマイゴー アイムソーリー ユーアープアー｣
100:デフォルトの名無しさん
09/06/30 03:09:45
>>98
実を言うとそこまで深く突っ込んで調べたことが無い。
そのテスト版のプログラムもし公開できるものなら見てみたいよ
101:デフォルトの名無しさん
09/06/30 19:24:25
ＤＬＬにした時点でどこのキーとってるのか俺にはわからないけど
メインの処理のキー入力を勝手にとってくるもんなの？そーゆーのって？
102:デフォルトの名無しさん
09/06/30 19:30:02
法線とライトの内積を求めてその値で境界の範囲を決めるトゥーンシェードで
Sio29さんのCelsView見たく境界の色をあいまいにするのってどうやってやるんですか？
103:デフォルトの名無しさん
09/06/30 19:34:53
>>102
本人に聞いてこいよ
104:デフォルトの名無しさん
09/06/30 19:38:42
>>102
参照するトゥーンマップの段階の変わり目をグラデーションにするだけ
105:デフォルトの名無しさん
09/06/30 19:41:18
>>103
つっこみありがとう
Sio29さん独特の技術なら聞いてこようと思います
やりたい事がわかりやすいように例を挙げただけだったんですが
106:デフォルトの名無しさん
09/06/30 19:43:30
>>104
それじゃなんねーと思うぜ
法線は段階的に角度がついてるわけじゃねーし
107:デフォルトの名無しさん
09/06/30 19:43:40
>>104
ありがとうございます
色の決定にトゥーンマップを使用していないのでつまづいています
108:デフォルトの名無しさん
09/06/30 19:53:43
>>106
なんで？
頂点シェーダでマップの参照位置を計算してピクセルシェーダにわたして
実際の色参照をピクセルシェーダでやれば問題ないんだけど
109:デフォルトの名無しさん
09/06/30 19:57:30
>>107
トゥーンマップを使わないでどうやってるの？
いちいち内積の値でifで条件分けして陰つけてるの？
110:デフォルトの名無しさん
09/06/30 20:02:58
>>108
関係なくね？
例えば立方体の辺にグラデ入れたいとしてその方法で何かつくの？
111:デフォルトの名無しさん
09/06/30 20:07:34
VS上の法線などのベクトルは、
PSには線形補間されて渡される。
112:デフォルトの名無しさん
09/06/30 20:12:47
>>110はライティングの仕組みを全く理解してないと思われ
そんなこと言ったら普通のグローシェーディングもできないことになる
113:デフォルトの名無しさん
09/06/30 20:12:51
>>111
だから頭の中でそれでグラデがつくか考えてみろっての
114:デフォルトの名無しさん
09/06/30 20:14:52
>>112
だからその仕組みとこの仕組みがリンクしてねぇって俺は主張してるわけだよ
115:102
09/06/30 20:23:13
>>109
そうです、ifで条件つけてやってます
マテリアルごとにトーンマップを用意するのが面倒なので
116:デフォルトの名無しさん
09/06/30 20:30:46
>>114
VSの計算結果で頂点Aが黒で頂点Ｂか白としましょう
PSで頂点AとBの中間地点のピクセルを描画するときは
線形補間された灰色という値が入ってきますよね？
だから通常のライティングが成立してるのはわかりますよね？
VSで頂点Aのマップの参照位置を(u,v)=(0,0)
Bの参照位置を(u,v)=(1,0)としましょう
PSでAとＢのちょうどまんなかのピクセル描画時には
線形補完された(u,v)=(0.5,0)という値が入ってきます
この値をつかってマップの色をサンプリングすればOKなのですよ
117:デフォルトの名無しさん
09/06/30 22:35:53
>>116
そこまで来てねぇよｗ
法線の値でグラデかけたマップから値とりにいくところで
うまくいかねぇと思うぜ
118:デフォルトの名無しさん
09/06/30 23:37:11
customUI使うには何をincludeすればいいでしょうか。
ソース分割とかやったことなくてさっぱりわかりません。
bccDeveloper使ってやっています。
119:デフォルトの名無しさん
09/06/30 23:52:15
>>117
URLﾘﾝｸ(www.arakin.dyndns.org)
ここが比較的わかりやすいから、見てみれば。
そこのテクスチャの色は2色、輪郭を含めて3色だが、
その3色の境界にグラデをかければ、最終的な
出力画像にもグラデが掛かるだろ。
120:デフォルトの名無しさん
09/06/30 23:55:02
>>118
CustomUIの中のCoreとOptionalプロジェクトを
インポートして使う。
VCならそのままだが、bccDeveloperはシラね。
121:デフォルトの名無しさん
09/07/01 00:00:58
>>119
かかんねぇよ
よく考えろよ
122:デフォルトの名無しさん
09/07/01 00:12:20
げちょげちょすっげキタネェのができるぞ
トゥーンマップ（？）でうまくいくのって２～３色ぐらいでグラデなしの
ときだけのような希ガス
綺麗にならないのはグラデがかかってほしいところでちょうど
法線（内積？）が段階的にかわってくれるとは限らないってところがポイントだと思う
つまり、内積→マップの値の変換でうまくいかない
123:デフォルトの名無しさん
09/07/01 00:50:19
境界って輪郭線じゃなくてシェーディングの部分でしょ？
だったら実際のところトーンマップの中間をグラデにしてるだけだと思うが＞CelView
きたねぇところはきたねぇし
124:デフォルトの名無しさん
09/07/01 01:54:32
>>123
境界の認識はあってるよ
実はCelView見てないけど
だったら高解像度になるにつれ余計なことしないほうがいいな
ようはシェーディングの境界をぼかしたいわけじゃなくて
シェーディングの境界がジャギってんのが気に入らないんだろ？
125:デフォルトの名無しさん
09/07/01 11:42:26
プログラマブルシェーダについて質問です。
bool型定数を使った静的分岐をやろうとしました。
URLﾘﾝｸ(msdn.microsoft.com)(VS.85).aspx
＞静的分岐では、ブール型のシェーダー定数に基づいてシェーダー コード ブロックのオン/オフを切り替えることができます。
＞これは、現在レンダリングされているオブジェクトの種類に基づいて
＞コード パスを有効または無効にできる便利な方法です。
＞描画呼び出しの間では、どの機能を現在のシェーダーでサポートするかを決定し、
＞その動作に必要なブール フラグを設定できます。
＞ブール定数で無効にされたステートメントは、シェーダー実行中にスキップされます。
下記のようにやってみたのですが、
fcx.exeでコンパイルしたものを覗いたところ、cmp命令が使われてしまっていました。
それでは分岐による負荷がかかってしまいますよね。
分岐負荷がかからないコードブロック単位での静的分岐とは、どうやるのでしょうか？
bool UseTexture;
float4 PS(VS_OUTPUT In) : COLOR
{
if (UseTexture)
{
In.Color *= tex2D(DecaleSamp, In.TexDecale);
}
return In.Color;
}
126:デフォルトの名無しさん
09/07/01 14:57:45
#ifdef
#else
#endif
127:デフォルトの名無しさん
09/07/01 18:58:43
>>125
静的に決定させる為には、
静的に決定出来なきゃ駄目だよね。
>>125のコードだと、「bool UseTexture」は
いつ何時変わる可能性があるので、コンパイラは
決め撃ちすることは出来ない。
方法としては、>>126のプリプロセッサ以外に、
①「static const UseTexture = true;」にする。
②シェーダの引数で受け取り、passで分岐する。
float4 PS(VS_OUTPUT In,
uniform bool UseTexture ) : COLOR
{
if (UseTexture)
{
In.Color *= tex2D(DecaleSamp, In.TexDecale);
}
return In.Color;
}
technique T
{
pass P0{ pixelShader = compile PIXELSHADER_TARGET PS( false );}
pass P1{ pixelShader = compile PIXELSHADER_TARGET PS( true );}
}
いづれも、最適化とプリシェーダはONにしておくこと。
128:デフォルトの名無しさん
09/07/01 20:01:27
>>126-127
アドバイスありがとうございます。
静的分岐とは言え、さすがにON/OFFのチェンジはしたいので
>>126や、>>127の①というわけにはいきません。
ひとまず、>>127の②ではうまくいきました。
そこで再質問なのですが、グローバル定数は、uniformとして扱われるMSの説明に書いてある上、
1回の描画命令の間では不変ですよね？
グローバル定数ではダメなのでしょうか？（ダメだったから>>125はダメだったわけですが…）
正直引数のuniformでやる方法ですと、
pass P0{ pixelShader = compile PIXELSHADER_TARGET PS( false );}
pass P1{ pixelShader = compile PIXELSHADER_TARGET PS( true );}
このようにtrueの場合とfalseの場合をいちいち定義しなければならず、
組み合わせが多い場合（ライトON/OFF、影ON/OFFなどなど）に組み合わせ爆発が厄介そうです。
uniform int の場合はintの取りうる範囲が多すぎるため、
PS(0) PS(1) のように定義しなければならないのはわかるのですが、
MSの説明を見る限り「bool型のシェーダ定数は特別扱いだよ」みたいに読めるのですが、
bool型を使うことによる利点のようなものは何かないのでしょうか？
MSの説明を見て
129:デフォルトの名無しさん
09/07/01 20:38:08
>>128
＞1回の描画命令の間では不変ですよね？
シェーダの生存期間は、コンパイルによって
exe(的なもの)として生成されてから、破棄されるまでの間です。
描画命令間ではありません。
定数が静的であるとは、生成から破棄の間静的であることです。
描画命令の間不変としたいなら、描画毎のコンパイルが必要。
＞組み合わせが多い場合（ライトON/OFF、影ON/OFFなどなど）に組み合わせ爆発が厄介そうです。
そうです。これはD3D9世代の欠点でもあります。
これを補う為に、フラグメントシェーダやデファードレンダリングなどがあったりします。
DX11では動的リンクが加わるそうなんで、ちょっとはマシになるかも。
130:デフォルトの名無しさん
09/07/01 22:30:38
DX11でシェーダの連結ができるって大騒ぎしてるけどさ
なんかDX9のフラグメントリンカーの存在忘れたような大騒ぎがよな
無かったことにされてるのか？？
情報もえらく少ないし。
131:デフォルトの名無しさん
09/07/01 22:35:50
シェーダ爆発なんて騒ぐのはキレイなエンジン作りたいやつだけで
普通は運用でどうにでもなるだろ。
132:デフォルトの名無しさん
09/07/01 23:20:36
>>130
URLﾘﾝｸ(wlog.flatlib.jp)
URLﾘﾝｸ(wlog.flatlib.jp)
このブログがわかりやすいが、DynamicShaderLinkageは
動的リンクというよりは、サブルーチンコールに近いものらしい。
イメージとしては、動的にShaderの部品を組み上げて
１つのShaderを作るのがフラグメントリンカならば、
とりあえず全てがつまったmain()プログラム的なShaderを１つ作って、
動的に個々の分岐を決定出来るのがDynamicShaderLinkageということになる。
これが良くなったかどうかわからんが、より普通になった感じだな。
133:デフォルトの名無しさん
09/07/01 23:24:51
>>130
フラグメントリンカを使ってる人は
今現在、世界で4人、
商用・非商用プログラムで使われてる例はゼロらしいよ。
134:デフォルトの名無しさん
09/07/02 01:10:26
現状のＰＣ構成だと殆どのケースでネックになるのがＣＰＵだから
ＧＰＵで多少分岐したところで全体の速度に大差はないからな。
多少のシェーダー負荷は承知の上でまとめちまうほうが管理が楽。
135:デフォルトの名無しさん
09/07/02 01:39:03
DirectSound で再生しながら、
横軸に周波数、縦軸に音量を表すようなグラフを
リアルタイムで描きたいです。
とりあえずＷＡＶを再生するところはできてるんですけど、
そのようなグラフを描くにはどうすればいいですか？
136:デフォルトの名無しさん
09/07/02 01:48:55
すれ違いじゃねっかな。
再生できてるならそのデータをそのまま解析すればいい。
どういう風なデータ構造になってるか分からないって質問は論外。
137:デフォルトの名無しさん
09/07/02 01:49:57
spectrum analyzer source code
でググったら。
138:デフォルトの名無しさん
09/07/02 14:05:54
フルスクリーン描画をしているときに画面中にダイアログを表示するのってどうやるの？
フルスクリーン描画しているウィンドウがフォーカスを失うと
device->Present()が失敗してしまう問題と、
フルスクリーン描画をかけるとほかのウィンドウが表示されてても
描画内容が上書きされてしまう問題とがあるわけだけど。
139:デフォルトの名無しさん
09/07/02 18:24:20
深度バッファシャドウについて質問です。
完全な影になる部分は、RGBA(0.5f, 0.5f ,0.5f, 1.0f)であるとします。
普通の理屈通り使うと、ライトから見て裏面になる部分は、深度バッファシャドウ的に影であると判定されますよね。
でも、ライトから見て裏面になる部分は、すでに頂点シェーダ上でCOLOR0の値が半減しているはずです。
ピクセルシェーダでの判定にひっかかったからといって、さらに半減してしまうと、影が濃すぎることになりますよね。
これは、頂点シェーダでは影による表面色の補正をかけず「影の濃さ」を計算してピクセルシェーダに渡し、
深度バッファシャドウとライティングのシャドウを先に計算し、最後に表面色に反映。としなければならないのでしょうか？
140:デフォルトの名無しさん
09/07/02 19:52:52
影と陰ね
これは同じ物理現象だよね
たしか
141:デフォルトの名無しさん
09/07/02 19:57:29
シャドウマップのサンプルがあるんだからそれ見ればいいだろ
三項演算子使ってるから
142:デフォルトの名無しさん
09/07/02 20:01:13
Direct3Dの色ってどうして少数使うの？
遅いでしょ。
143:デフォルトの名無しさん
09/07/02 20:06:18
シャドウマップを影を追加する為のギミックとして
使うのではなく、
光が当たっているかどうかの判断に使うといい。
144:デフォルトの名無しさん
09/07/02 20:08:04
>>142
正規化してるだけ
145:デフォルトの名無しさん
09/07/02 20:24:56
>>143
あ、なるほど。
すんなり理解できました。わかりやすい教示ありがとうございます。
146:デフォルトの名無しさん
09/07/03 08:54:10
>>142
GPUでは小数のほうが早い
147:デフォルトの名無しさん
09/07/03 15:42:01
SAFE_RELEASEマクロの代わりに以下のようなインライン関数を書いたのですが、IUnknownのポインタがうまく変換されないのでコンパイルができません
inline void SafeRelease(IUnknown *& pUnk)
{
if (pUnk)
{
pUnk->Reelase();
pUnk = NULL;
}
}
以下ポインタの型変換をテストしてみたものですが、どうしてエラーになるコードが駄目なのかがわかりません
このように変換ができない理由を教えて下さい
IDirect3D9 * pD3D9 = Direct3DCreate9(D3D_SDK_VERSION);
//IUnknown *& rp = pD3D9; // エラー
//IUnknown *& rp = (IUnknown*)pD3D9; // キャストしてもエラー
IUnknown * p = pD3D9;
IUnknown *& rp = p; // 一時変数にコピーしてからだとOK
[ VC++2008 EE / DirectX SDK March 2009 ]
148:デフォルトの名無しさん
09/07/03 16:08:38
IUnknown *& rp = pD3D9; // エラー
149:デフォルトの名無しさん
09/07/03 16:17:09
関数のコンパイルが成功しない理由は148だと思うのですが、どうしてこの変換が認められないのか教えて下さい
150:デフォルトの名無しさん
09/07/03 16:22:25
ポインタは変換可能だが、参照は変換できないというだけ。
151:デフォルトの名無しさん
09/07/03 16:27:14
ありがとうございました。
152:デフォルトの名無しさん
09/07/03 20:49:27
あえて関数化する必要がないしなー
153:デフォルトの名無しさん
09/07/03 22:56:19
スマポ使えってこった
154:デフォルトの名無しさん
09/07/04 18:42:31
むむ
RegexOptions^ Option = gcnew RegexOptions();
Option |= RegexOptions::CultureInvariant;
これでコンパイルエラーerror C2676が出てしまいました・・。
155:デフォルトの名無しさん
09/07/04 19:23:53
>>154
型が違うんだから当然じゃないか。
156:デフォルトの名無しさん
09/07/04 20:12:07
すまぽってComPtr的な動作したっけ？
157:デフォルトの名無しさん
09/07/04 21:21:41
無理、よって完全に的外れ。
158:デフォルトの名無しさん
09/07/04 21:28:58
／￣￣￣＼
/ ⌒ ⌒ ヽ
/ （ ●）（●） |
| （__人__） } …
/､. ｀ ⌒´ ヽ
/ |
| | /
ヽ_| ┌─┐ |丿
| ├─┤ |
| ├─┤ |
159:デフォルトの名無しさん
09/07/04 21:31:47
レベル低いなぁ
160:デフォルトの名無しさん
09/07/04 23:51:17
directX9で2Dゲームを作る為にPNG画像を表示しようと思ったのですが
D3DXCreateTextureFromFileInMemoryEx(g_pD3DDevice,ptr,SizeofResource(NULL, hRsrc),40,40,8,0,D3DFMT_UNKNOWN,D3DPOOL_MANAGED,
D3DX_DEFAULT,D3DX_DEFAULT,0,NULL,NULL, &img[i]);
で40pxの画像を読み込むと64pxに拡大されて表示されてしまいます。
元の画像のサイズのままで読み込みたいのですがどうすればいいでしょうか。
161:デフォルトの名無しさん
09/07/04 23:57:44
自分でそうなるようにしているからだろ。
他人の作ったAPIが使えない、ヘルプを読むつもりもないのなら、
全部自前で読み込めよ。
162:160
09/07/05 00:25:32
>>161
URLﾘﾝｸ(msdn.microsoft.com)
このページと自分の持ってる本を参考にしても分かりませんでした。
参考になるサイトや本を紹介して頂くだけでも有りがたいのでどうかアドバイスをお願いします。
163:デフォルトの名無しさん
09/07/05 00:31:33
>>160
VGAによってはそうなる。
自分のＰＣだけで無くどこでも動くようにするなら、テクスチャは２のべき乗サイズになると想定したほうがいい。
164:デフォルトの名無しさん
09/07/05 00:41:59
>>163
VGAのせいじゃねえよ。
どんだけ馬鹿なんだよ？
>>162
引き延ばす設定が入っているから。
いったいヘルプのどこを読んだんだよ？
165:デフォルトの名無しさん
09/07/05 00:51:21
VGAによってはサイズ制限があるから
D3DXがフラグの設定どおりに拡張してテクスチャを作る。
⇒VGAのせいってコトだったんじゃね？
166:デフォルトの名無しさん
09/07/05 00:53:34
客：アプリが起動しません。 サポ：デフラグかけてみて。 客：直りました。
動くプログラムを早く作るのは、いちいち理屈を勉強するプログラマではなく、魔法を信じるプログラマの方である。
167:デフォルトの名無しさん
09/07/05 01:03:38
俺の経験だけかもしれんが
デフラグをかけた（かける必要が出た？）ＰＣは例外なく復活は無くお亡くなりになるｗ
168:デフォルトの名無しさん
09/07/05 01:10:16
NT4時代から毎日かけているがそんなことは無かったぜ。
169:デフォルトの名無しさん
09/07/05 01:13:08
まめにやってると数秒だな
170:デフォルトの名無しさん
09/07/05 01:23:50
>>160
ところでテクスチャのサイズと表示のサイズには何の関係性もないんだけど
なぜ拡大されていると判断したの？
作成したテクスチャのGetLevelDescでサイズを取得してみて
本当にサイズが64のテクスチャとして作られているか確認したの？
もしそうならそれはビデオカードの問題
テクスチャのサイズが40なのに64で表示されているっていうなら
それは表示のさせ方の問題
貼り付けてるポリゴンはどうなってるの？
射影行列の設定は？
viewポートとウインドウサイズが一致してないとかは？
171:160
09/07/05 02:01:54
>>170
GetLevelDescでサイズを取得したら64×64でした。
Draw関数で40pxに縮小して表示してみたんですが若干ぼやけてしまいました。
テクスチャは２Ｄ画像を表示させるのに適していないってことでしょうか。
画像を表示させる別の方法を探してみます。
アドバイス有難うございました。
172:デフォルトの名無しさん
09/07/05 02:08:31
>>171
2Dゲーム作るならOpenCVでいいんじゃない？
173:デフォルトの名無しさん
09/07/05 02:28:18
>>171
元々テクスチャというのは不定形のメッシュに伸び縮みさせながら貼り付ける道具だから、
デフォルトでフィルターがかかるようになっている。
FilterとMipFilterをD3DX_FILTER_NONEにすれば補間は起こらないよ。
>>164
初心者に嘘ばかり教えない。
おまえ、ネットブック（GMA950）で動作チェックしたことないだろ？
174:160
09/07/05 02:49:04
>>173
ありがとうございます。
黒い領域が残ったけどクリッピングで消せそうなので大丈夫そうです。
VCproだと64×64になってしまったのですが、ExpressEditionでプロジェクトを
作り直したら40×40のテクスチャを作れました。
原因はVCの設定ミスなんでしょうか・・・
175:デフォルトの名無しさん
09/07/05 05:17:56
スキンメッシュをリソースファイルから呼び出すにはどうすれば良いですか？
176:デフォルトの名無しさん
09/07/05 06:58:30
>>173
GMA950はNONPOW2CONDITIONALがYesだったと思うが。
NONPOW2CONDITIONALはドライバレベルで対応できる機能だから、
よほど古くてドライバが更新されてないのでなければ使える。
177:デフォルトの名無しさん
09/07/05 09:14:36
デフラグを頻繁に行うと間違いなくHDDにダメージを与える事になる
PCの調子がおかしい時は基盤とかにホコリがたまってて電源不足になってる可能性あり
178:デフォルトの名無しさん
09/07/05 09:28:29
>>174
なんでUVを適切に設定しないでクリッピングなんだ？
意味分からん
＞原因はVCの設定ミスなんでしょうか・・・
人の話を聞かない奴だな
179:デフォルトの名無しさん
09/07/05 12:49:38
断片化した状態で使うのは常にデフラグをかけているのと同義
180:デフォルトの名無しさん
09/07/05 12:59:03
結局確率の話でしかないだろ。
対象のファイルが
・頻繁に読む・固定長で書き込み
HDD側で2桁程度の高速化
・永久に使用しない
無益
・追記する場合
また断片化する
181:デフォルトの名無しさん
09/07/05 13:18:19
まぁSSDにしとけってこったな
182:デフォルトの名無しさん
09/07/05 13:32:41
はいはい、スレ違いスレ違い
183:デフォルトの名無しさん
09/07/05 14:02:30
コンパイルしようと思ったら
1>------ ビルド開始: プロジェクト: a, 構成: Debug Win32 ------
1>コンパイルしています...
1>main.cpp
1>マニフェストをリソースにコンパイルしています...
1>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
1>Copyright (C) Microsoft Corporation. All rights reserved.
1>リンクしています...
1>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __CrtSetCheckCount は既に MSVCRTD.lib(MSVCR90D.dll) で定義されています。
1>LIBCMTD.lib(crt0dat.obj) : error LNK2005: _exit は既に MSVCRTD.lib(MSVCR90D.dll) で定義されています。
1>LIBCMTD.lib(crt0dat.obj) : error LNK2005: __exit は既に MSVCRTD.lib(MSVCR90D.dll) で定義されています。
・
・
1>libjpeg_d.lib(jpegtran.obj) : error LNK2019: 未解決の外部シンボル _keymatch が関数 _parse_switches で参照されました。
1>D:\Program Files\VC\project\a\Debug\a.exe : fatal error LNK1120: 外部参照 9 が未解決です。
1>ビルドログは "file://d:\Program Files\VC\project\a\Debug\BuildLog.htm" に保存されました。
1>a - エラー 40、警告 2
========== ビルド: 0 正常終了、1 失敗、0 更新不要、0 スキップ ==========
と出ます。何が原因でしょうか?
コード自体は
URLﾘﾝｸ(homepage2.nifty.com)
の6.プログラムを組む、というプログラムです
184:デフォルトの名無しさん
09/07/05 14:08:36
>>183
はいはい、CRTの設定ミス。全プロジェクトで統一しようね。
185:デフォルトの名無しさん
09/07/05 14:22:53
>>184
ありがとうございます
CRTよくわかりませんがぐぐって調べてみます
186:デフォルトの名無しさん
09/07/05 14:30:59
>>184
できました。ありがとございました
187:デフォルトの名無しさん
09/07/05 16:22:43
他アプリ（DirectXモノ）画面に上書き描画出来るようになったんだが、チラツキが多すぎて微妙です。
タイマーを使っているのが間違いだと思うのですが、解決方法ありますか？
Presentフックが王道とは思うのですが、vsync待ちの処理ができる方法があるならアドバイスいただけないでしょうか。
188:デフォルトの名無しさん
09/07/05 17:24:43
質問です。
D3Dで地面に影メッシュを表示しようと思うのですが、地面とまったく同じ高さに描くと
Z-fightingが起こってしまいますよね。
これに対処するためわずかに地面から浮かせていたのですが、Z-fightingが起こらない程度に浮かせると
影の位置がずれているのが結構見えてしまいます。
そこで「描画位置はそのままに、Zバッファでの比較の際バイアスをかける」方法がないか探しているのですが、
どうにも見当たりません。
バイアスをかける方法があれば教えていただきたいのです
よろしくお願いします。
189:デフォルトの名無しさん
09/07/05 17:42:25
188自己解決です
float bias = -0.1f;
pDev->SetRenderState(D3DRS_DEPTHBIAS, *((DWORD*)&bias));
で出来ました。
が、D3DRS_DEPTHBIASはマイナーな上、サポートしていないグラボも少なくないとか？
このあたりの情報おもちのかたいらっしゃいましたら、教えていただければと思います。
190:デフォルトの名無しさん
09/07/05 17:49:41
>>188
単純に地面のあとから描けばいいような気がするんだが、それで問題があるんだろうか。
191:デフォルトの名無しさん
09/07/05 17:49:43
シェーダーでやれば問題ない。
192:デフォルトの名無しさん
09/07/05 18:08:42
質問です。
Xファイルとやらでオブジェクトを表示させようとしたのですが、メッシュ（？）だけ表示されて色の情報が描写されません。
同じようなことがあった人がいたら解決法を教えてください。お願いします
193:デフォルトの名無しさん
09/07/05 18:22:42
あーいーうーえーおー
あ
あしかの赤ちゃん雨の中
赤い雨傘甘えん坊
い
いちご畑の一年生
石ころ一個 コロコロ
う
宇宙の海で運動会
え
円盤遠足絵の具で絵日記
お
折り紙のオルガンで
あ い う え お の 音楽
あーいーうーえーおー
194:デフォルトの名無しさん
09/07/05 18:38:47
再現する最低限のコード晒すといい。
195:デフォルトの名無しさん
09/07/05 18:41:30
Xファイルはあくまでデータのコンテナであって、
中のデータをどう描画するかは自分次第。
よって自分でやっていないからとしか言いようがない。
196:デフォルトの名無しさん
09/07/05 20:23:51
色々やってみたら、テクスチャのファイルネームに何も入っていないことがわかりました。何とかなりそうです、ありがとうござました
197:デフォルトの名無しさん
09/07/05 20:34:55
GDIのコントロールを描画しようというのが根本的に王道ではない。
王道だったらMicrosoftがやってる。
198:デフォルトの名無しさん
09/07/05 22:22:34
>>197
ありがとうございます
描画対象エリアのみ2D使ってるぽいところに2D上書き予定なのですが、
zが手前になるように追加描画が出来るか調べてみようかと思います
199:デフォルトの名無しさん
09/07/06 15:39:10
質問です。
ピクセルシェーダの色出力を省略し、深度バッファへの書き込みだけを行う方法があったと思うのですが
どなたかわかる方いらっしゃいますでしょうか？
PixelShaderの返り値をvoidにしたらHLSLコンパイルエラーになりましたし、
PixelShader = NULL;
にしたら妙な色が書き込まれてしまいました。
200:デフォルトの名無しさん
09/07/06 16:41:02
SetRenderState()で色の書き込みをマスクする。
DirectX１０ならSetRenderTargetでNULLをいれる。
201:デフォルトの名無しさん
09/07/06 16:50:02
D3DRS_COLORWRITEENABLE
ですね。
ただこれは、マスクを0にしてもピクセルシェーダ自体は呼び出されてしまうようです。
ピクセルシェーダ自体を呼び出さずに済ませてしまう方法があったような気がするのですが・・・
曖昧な記憶で申し訳ないです
202:デフォルトの名無しさん
09/07/06 17:48:55
9でも連打ーターゲットNULLでいけなかったっけ
203:デフォルトの名無しさん
09/07/06 18:12:17
>>201
DirectX9にはない。
0.0を出力しとけ。
普通は色の出力を全部マスクしていればドライバー側で
PixelShaderの処理はスキップしてくれるはず。
>>202
インデックス０に対してはNULL無理。
204:デフォルトの名無しさん
09/07/06 20:31:43
ピクセルシェーダから深度値を変更できるんだから、
カラー出力しなくてもスキップされるわけないだろう。
205:デフォルトの名無しさん
09/07/06 20:35:20
深度値を出力した時だけ早期Zカリングがスキップされたりするんだから
カラーマスクと深度出力をみて不要ならスキップもしてるだろ。
206:デフォルトの名無しさん
09/07/06 20:56:12
スキンメッシュのプログラムはマテリアルを設定してないの？
207:デフォルトの名無しさん
09/07/06 21:28:10
それは自分次第だろ。
208:デフォルトの名無しさん
09/07/06 21:44:46
HELP ME
Xファイルを表示するためにマテリアルの数を変数に格納したはずなのになぜか格納されていません。
推測で原因を教えてください
209:デフォルトの名無しさん
09/07/06 21:57:48
推測だがお前が悪い
210:デフォルトの名無しさん
09/07/06 22:54:50
directsoundでIDirectSoundBuffer8::SetVolumeをセットしても音量に変化がありません。なぜだすか？
211:デフォルトの名無しさん
09/07/06 22:57:08
>>210
っ 初期化
212:デフォルトの名無しさん
09/07/06 23:49:24
>>211
IDirectSound8::CreateSoundBufferが内部で初期化してるけど、音量変更前にもう一回初期化するってこと？
そもそもループ内でそれやるの難しくない？
213:デフォルトの名無しさん
09/07/06 23:56:55
最初にやれよ
214:デフォルトの名無しさん
09/07/07 00:01:05
CreateのときにDSBCAPS_CTRLVOLUMEフラグを立ててないからって落ちじゃ？
215:デフォルトの名無しさん
09/07/07 00:51:34
a
216:デフォルトの名無しさん
09/07/07 01:02:16
ＤＩ８で pDI8->EnumDevices でデバイスを列挙するのはわかるんだが
pJoyDevice->EnumObjectsでプロパティを列挙したときに何が取得できるかよくわからない
たぶんボタンがいくつあるとか軸の範囲とかの取得・設定ができるんだと思うんだけど
EnumObjectsCallback内でpJoyDevice->SetPropertyとかやっているサンプルが多く、
これだとpJoyDeviceが１つのときは問題ないんだろうけど
複数のpJoyDeviceを扱いたいときとかどうすればいいのだろう？
とか考えるとさらによくわからなくなりまつ
BOOL CALLBACK EnumObjectsCallback( const DIDEVICEOBJECTINSTANCE* pdidoi,VOID* pContext )
のpContextに、プロパティ設定したいデバイスのpJoyDeviceでも渡して
pContext->SetPropertyとでもしておけばいいんでしょうか？
217:デフォルトの名無しさん
09/07/07 01:12:08
PCでパッド2個つけて2人用プレイって需要あるんかな
格闘ゲームでも1P vs COM か COM vs COMしか利用されないだろ
218:デフォルトの名無しさん
09/07/07 02:16:04
家庭用ゲーム機のエミュとか？
219:デフォルトの名無しさん
09/07/07 09:15:32
URLﾘﾝｸ(abnormal.sakura.ne.jp)
l i i i i l
／￣ヽ 昼l ゝ ノ ゝ ノゝ ノ
, o ', 食ご l i´ ｀i ＿ i´ 講 ｀i ｀l
ﾚ､ヮ __/ べはl l ／ ＼ l 義 l l
/ ヽ よん.l {@ @ i が l l
_/ l ヽ うを l } し_ / お
しl i ｉ l > ⊃ < わ
l ｰﾄ lヽ、 / l ヽ っ
￣￣¨¨'~~ ‐‐‐--─| ヽ ､ / /l 丶 .l｀＼ た
＿＿__ ＿＿ | (_/ | } l｀＼|
|| |ＷＣ| | へ へ ヽ､ l ! ＼||
|| ￣￣ |／ ＼ ｀ヽ、 ヽし! ／|| ｶﾞﾀｯ
|| | ／ ／ ヽ､||
◎|| | ／ ／ ヽ、
￣￣ ¨¨¨ー─‐‐--- ,,, ＿＿ __＿_
,, ＿ | ￣¨¨｀ ー─---
モパ ／ ｀､ | モパ |:::::::::::::::
グク / ヽ | グク ／ ￣ ヽ:::::モパ
モパ./ ● ●l | モパ l @ @ l:::グク
グク l U し Ｕ l | グク } し_ /::::モパ
l u ＿__ u l | ＿ /=ﾃ⊃ <＿グク
>u､ _` --' _Uィ l ◎ー）/キ' ~ ＼ヽ
／ 0 ￣ uヽ | | | | i二二二i-' ) ',
. / u 0 ヽ| ~~~ ~ l ヽ--┬ ' ./
テ＝＝tニﾄ | /￣/￣￣｀ ﾉ /
／￣）￣ |￣￣￣￣￣| | | |二二二)
220:sage
09/07/07 18:55:08
>>216
pJoyDevice->EnumObjects は 第３引数で指定したフラグの情報が取得できる
例えば軸情報なら DIDFT_AXIS を指定すればいい。
URLﾘﾝｸ(msdn.microsoft.com)
>BOOL CALLBACK EnumObjectsCallback( const DIDEVICEOBJECTINSTANCE* pdidoi,VOID* pContext )
引数には DIDEVICEOBJECTINSTANCE オブジェクト と EnumObject で渡した第２引数 pContext がある。
コールバック関数で指定したフラグの情報を含む DIDEVICEOBJECTINSTANCE オブジェクトから pContext に情報を
引っ張ってくればいい。
ex)
Joystick* pJoy = (Joystick*)pContext;
if (pdidoi->guidType == GUID_XAxis) /* 処理 */
221:デフォルトの名無しさん
09/07/07 21:13:24
トイレでプログラミングはしても良くて助かった
222:デフォルトの名無しさん
09/07/07 21:32:50
監視カメラ設置かよ
223:デフォルトの名無しさん
09/07/07 23:14:53
あれあれ？
俺ライブラリをVistaに対応する前にWindows7とかでちゃったｗ
224:デフォルトの名無しさん
09/07/07 23:30:55
これはどんな仕組みなの？
URLﾘﾝｸ(www.teatime.ne.jp)
225:デフォルトの名無しさん
09/07/07 23:42:55
DirectXと関係ない宣伝行為乙
226:デフォルトの名無しさん
09/07/07 23:47:07
どう見てもDirectXだが
推奨環境
Vista 日本語版WindowsXP / Vista
Intel(R)Core(TM)2 Duo プロセッサ 2.40ＧＨｚ 以上
メモリ 以上 2.0ＧB 以上
DirectX9.0cに完全対応し
ビデオメモリ256ＭＢ以上で
ピクセルシェーダー2搭載の
GeForceまたはRADEONシリーズ
（メーカーから最新のグラフィック
ドライバサポート必須）
画面解像度1280Ｘ960ピクセル
フルカラー推奨
メインメモリと共有と表記のあるビデオシステムは動作保証外となります
サウンド DirectSoundに完全対応したサウンドカード
ＤＶＤ-ROM 4倍速以上のドライブ
HDD 5.0ＧB以上の空き容量
227:デフォルトの名無しさん
09/07/07 23:54:16
224の仕組みとDirectXは関係ない。
OpenCVのスレにでも行けばいいかと。
228:デフォルトの名無しさん
09/07/08 01:44:18
てｓ
229:デフォルトの名無しさん
09/07/08 09:02:37
>>223
よう俺
230:デフォルトの名無しさん
09/07/08 09:16:19
宇 宙 の 大 規 模 構 造
（太陽の∞倍）
￣￣￣￣￣￣￣￣￣￣￣￣￣￣∧￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
帝ハ神ナリ！帝ハ神ナリ！
グ レ ー ト ウ ォ ー ル
￣￣ `―（長さ：太陽の3500兆倍、幅：太陽の2100兆倍) ＿＿ , -―
∧
守るも攻めるも黒鉄の～♪
_,,,,,,,,_
／｀ ｀'i､
超銀河団 | l ＜ゴミクズども氏ねよｗｗｗｗｗ
ﾞl、 /
｀'ｰ---'"
（太陽の約680兆倍～）
銀河系 o ＜太陽？誰だよそれｗｗｗｗ
（太陽の6800万倍）
IRS5 。 ＜太陽？俺の国民だよ
（太陽の10000倍）
太陽 . ＜たいようたいよう～！
（直径140万km）
231:デフォルトの名無しさん
09/07/08 11:44:25
カメラの使用はDirectShowの範疇でありDirectXではない。
232:デフォルトの名無しさん
09/07/08 14:56:39
DirectX9のフックについて、初心者向けの詳しいHPはありませんか？
当方、VC（++は少し苦手）、VB、Delphi分かります。dllのコンパイルも出来ます。
目標は、フルスクリーンの別アプリ画面に自前のグラフィックを描画することです。
レベルが低い質問かもしれませんが、よろしくお願いします。
233:232
09/07/08 15:02:38
別アプリのhWnd取得と画像データの取得までは出来たのですが、描画の方が上手くいきません。
234:デフォルトの名無しさん
09/07/08 15:08:48
またおまえか
235:デフォルトの名無しさん
09/07/08 15:12:14
16と16の平たいを毎回敷き詰めて描くと
テクスチャに写植して描くはどちらが速いか？
236:デフォルトの名無しさん
09/07/08 15:19:37
実測しろ
237:デフォルトの名無しさん
09/07/08 15:20:59
日本語がおかしいが
敷き詰めて書くのが1回の命令で出来るならそっちの方がいいんじゃね？
ただのループならWARP指定汁
238:デフォルトの名無しさん
09/07/08 16:18:32
>>234
やはり直接フックがベストですか！
有り難う御座いました。
239:デフォルトの名無しさん
09/07/08 17:23:37
質問です。
カメラから見た時の、あるメッシュの「厚み」を調べる方法を考えています。
サイコロのような凸型物体ならば、
・裏面を描画し、テクスチャAに深度値として書き込む。
・表面を描画し、テクスチャBに深度値として書き込む。
とし、A-Bで厚みが出ると思います。
（深度バッファシャドウの時のように、深度値をz/wで0～1にしてしまうと、歪んでしまうので単純にzを記録する必要がありますが）
ただ、「コ」の字を上から見た時のような場合の厚み合計の出し方が思いつきません。
「コ」を真上から見た際、上辺の厚みと、下辺の厚みの合計が知りたいのです。
何か良い手はありますでしょうか？
240:デフォルトの名無しさん
09/07/08 17:34:02
>>239
表面/裏面と分けるのではなく、カリングを無効にした状態でZFUNCを
LESSEQUAL、GREATEREQUALにして描画する。
241:デフォルトの名無しさん
09/07/08 17:39:32
>>239
加算合成すればいいのではない？
裏面のZ値の合計から表面のZ値の合計を引く
0～1の範囲をはみ出ないようにしないといけないけれど
242:デフォルトの名無しさん
09/07/08 17:49:10
>>240
すいません、その結果何が解決するかがちょっと分からないのですが…。
一番奥であるポリゴンまでの距離が記録されるだけかと。
>>241
素晴らしいです！
まさにその通りですね！
(Af - An) + (Bf - Bn) == ((Af + Bf) - (An + Bn))
ということですね。
ありがとうございました。
243:デフォルトの名無しさん
09/07/08 18:31:47
３Ｄゲームのプログラミングを始めようと思うのですが
オススメの書籍はありますか？
244:240
09/07/08 18:59:59
>>242
上辺の厚みと下辺の厚みの合計ってとこ見てなかった。
コが1枚ずつの面ってことじゃなくて、厚みのある凹ってことね。
245:216
09/07/08 19:25:37
>>220
EnumObjectsCallbackで何をやってるのかようやく理解できますた
VOID* pContext に LPDIRECTINPUTDEVICE8 を渡して
コントローラーごとに個別にプロパティが設定できるようになりました
ありがとうござますた
246:デフォルトの名無しさん
09/07/08 19:27:41
>>243
DirectX逆引き大全５００が鉄板だと思うが
Ｇｏｏｇｌｅのオンライン書籍立ち読みで見れるので見るといい
247:デフォルトの名無しさん
09/07/08 21:33:09
いまググって調べた。 東京１２.９６０.８８３人の内、支那人１４９.１１３人だな。
堂々コリア人を抜いてる。 （０９年５月調べ）
約、１００人に１．１５人いるんだな。
248:デフォルトの名無しさん
09/07/08 22:49:17
初心者ですが質問させてください。
現在DirectSoundを使った音声キャプチャプログラムを作成しています。
マイクやライン、サウンドミキサなどの入力先を指定してキャプチャを行いたいので
次の手順でキャプチャデバイスオブジェクトの作成を行っています。
手順1.DirectSoundCaptureEnumerate関数を使用して利用可能なデバイスを列挙
手順2.手順1で列挙したGUIDから任意の入力先のGUIDを選択し
DirectSoundCaptureCreate8関数の第1引数に設定しキャプチャデバイスオブジェクトの作成
Vista環境では手順1のDirectSoundCaptureEnumerate関数で
マイクやラインなど録音デバイスの項目に表示されている
入力先の数だけデバイスの情報が取得できて
入力先を選択してのキャプチャが実施できるのですが、
XP環境では１つのデバイスしか列挙できず入力先の指定が行えません。
（録音コントロールにはマイク、ライン入力など複数の入力先が表示されています。
録音コントロールで選択されている入力先の音しかキャプチャ出来ません。）
XPでは入力先を指定してのキャプチャデバイスオブジェクトの作成は行えないものなのでしょうか？
不可能な場合は何か入力先を指定してキャプチャするよい方法はないでしょうか？
よろしくお願いします。
249:デフォルトの名無しさん
09/07/08 23:44:16
Ring 3 Circus のDirect3D9 Hookingを改造して
Direct3D9を使ったゲームの画像を取得するプログラムを作ったんですが
デバイス作成時にバックバッファをロック可能にするフラグを指定していないと
バックバッファの内容が取得できないようです。
それでIDirect3DSwapChain9::GetPresentParametersを呼んで、
得られたD3DPRESENT_PARAMETERSのFlagsを
flags |= D3DPRESENTFLAG_LOCKABLE_BACKBUFFER
のように変更し、Resetを読んだら、HRESULTがD3DERR_INVALIDCALLに・・。
Resetはだめみたいです。
ランチャとか用意して、バックバッファをロック可能でデバイスを作成させるのは使うとき面倒です。
ほかにバックバッファの内容を取得する方法は無いんでしょうか
250:デフォルトの名無しさん
09/07/09 00:36:26
取得しないといけない状況がまったく思いつかないので分からない。
251:デフォルトの名無しさん
09/07/09 00:45:51
IDirect3DDevice9::StretchRectでコピーすりゃいいんでないの
252:デフォルトの名無しさん
09/07/09 10:30:42
質問です
パーティクル(たくさんのビルボード)を表現するのに
DrawPrimitiveUP + D3DPT_TRIANGLELIST
を使っています。
1つのビルボードを表現するのに6頂点。
100個なら600頂点のデータをDrawPrimitiveUPに渡す必要があるのですが、これが思いのほか遅い気がします。
パーティクルを表現するのに、DrawPrimitiveUPを使うのは常道なのでしょうか？
DrawPrimitiveUPによって、メインメモリーからVRAMに転送するコストが大きいのが遅い原因かな？と思います。
ただ、パーティクルは移動なども毎フレーム行われるため、DrawPrimitive（UPではない）のほうでは実現が難しい気がします。
（結局は毎フレームStreamに流す作業が必要。これではVRAMへの転送コストは変わらない）
253:デフォルトの名無しさん
09/07/09 10:47:49
AGPメモリ
254:デフォルトの名無しさん
09/07/09 11:05:55
どんなパーティクルを想定してるのかわからないけど
６頂点のポリじゃなくて１頂点のポイントスプライトにしてみるとか
そうすると制御が楽になるので簡単な飛び散りくらいなら
頂点シェーダで動かせるようにもなるし
255:デフォルトの名無しさん
09/07/09 11:16:33
>>252
ホントにDrawPrimitiveUPの呼び出しだけを計測してる？
頂点演算って毎フレームCPUにやらせると結構負荷かかるよ。
パーティクルの移動計算が幾何学的なものならシェーダーにやらせたほうがいい。
256:デフォルトの名無しさん
09/07/09 11:31:06
レスありがとうございます
>>254
ポイントスプライトも考えたのですが（ポイントスプライトで実装しているパーティクルもあるので）、
今回は頂点毎に違う方向を向いた法線が必要だった（疑似ボリュームパーティクル）ため、ビルボードにすることにしました
目指しているのは疑似ボリュームパーティクルによる煙表現です
>>252
実験としてDrawPrimitiveUPに流し込む（FVFで定義した頂点フォーマットの）構造体を編集せず、描画し続けさせてみました。
ほぼ同等の速度のようです。
おそらくCPUパワーはほとんど足を引っ張っていないかと思われます。
257:デフォルトの名無しさん
09/07/09 11:43:31
>>256
TriangleStripなら4頂点で済むよ。
DirectXのバージョンが分からんが、たぶんヘルプに「動的な～」頂点バッファ処理云々の項があって
そこにDrawPrimitiveで、頂点位置が毎フレーム変わるようなものの処理の仕方が書いてあるはず。
簡単に言えば、頂点バッファを確保して、後は毎フレームに
バッファをロック＞書き込み＞一杯になったらアンロックしてDrawPrimitive＞再度バッファを…
更にインデックスバッファを使ってTriangleStripにすれば、転送コストはかなり違ってくるわよ。
258:デフォルトの名無しさん
09/07/09 11:49:37
Stripじゃ縮退ポリゴンで2頂点増えるから、減らないだろう。
259:デフォルトの名無しさん
09/07/09 11:57:46
バッファをロックするんじゃ、結局遅いと思うが
260:デフォルトの名無しさん
09/07/09 12:10:23
インデックスは毎回転送する必要がないから、流すデータ量は減るんじゃないか
261:デフォルトの名無しさん
09/07/09 12:17:30
微妙な即レスが続いて、なんか答えるのが馬鹿馬鹿しくなってきたが
>>258
2通りにとれるな。もう少し理由を言ってみ。縮退ポリなんか使わんよ。
>>259
今時そんな…ではDrawPrimitiveUPはどうやってVRAMに送ってるんだ？
ロックとDrawは極力まとめるんだ。まぁ、UP系もそれなりに上手くやってくれるけど。
確かLunaの作者が昔実験結果を掲載してくれてたけど、今はなくなっちゃったみたいだな。
262:デフォルトの名無しさん
09/07/09 12:45:15
スプライトって全部板なんだから頂点情報ひとつで十分だろ
263:デフォルトの名無しさん
09/07/09 12:49:55
>>261
縮退ポリゴンを使わずに、複数のビルボードをStripで描画するってどうやるの？
264:デフォルトの名無しさん
09/07/09 12:55:40
>>261
いまどきそんな。とか言ったって、DrawPrimitiveUPより早くならなきゃ質問に答えたことにはならないんだぜ？
しかも今回は、毎フレーム1回しかUPを呼び出さだないわけだし、どうやってUP以上に「ロックとDrawをまとめる」んだよ？
265:デフォルトの名無しさん
09/07/09 13:01:22
>>263-264
ごめんなさい
俺こそが質問者の質問をよく読んでない、ただの馬鹿馬鹿しい男でした
266:デフォルトの名無しさん
09/07/09 13:07:44
ちゃんと自分の間違いを謝れる奴は、伸びる奴
267:デフォルトの名無しさん
09/07/09 13:10:27
>>256
そこまで試したならついでに、静的なVertexBufferに頂点データ入れてみて
本当に転送が問題なのかも確かめた方がいいかと。
268:デフォルトの名無しさん
09/07/09 13:15:57
/j^i
./ ;!
/ /_＿,,..
/ `(_t＿,__〕
/ '(_t＿,__〕
/ ｛_i＿,__〕
／ ノ {_i＿_〉
／ ＿,..-'"
／ ／
～～～～～～～～～～～～～～～～
269:デフォルトの名無しさん
09/07/09 13:23:51
だから動的更新ならAGPメモリ使えよ。
270:デフォルトの名無しさん
09/07/09 13:40:13
>>263
インデックスバッファ
>>264
まず>>259でロックが遅いなんて書くから、UPでもロックのコストは変わらないと書いた。
「動的な～」の項読んでみろと。>>253氏のも乗ってたはず。
で更にUP系でIB使うと、毎回IBの転送が起こるよな？
ところが非UP系ならば初期（或いはVBサイズ変更時のみ）コストだけで済む。
で、更に頂点数の転送量は2/3に抑えられる。
もう少しいうと、DrawPrimitiveUP系の場合、計算用のアクセスしやすいバッファの他に、
描画用の配列をメインメモリに取って、更にVRAMにも同じのが出来るわけだ。無駄だと思うがねぇ。
まぁ、好きに実装したらいいじゃないの。なんでそんな必死よ>>265-266
271:デフォルトの名無しさん
09/07/09 13:43:23
>>252がDrawPrimitiveUPを連投してるなら
それをまずやめるべき。
>>257方式で、まとめるのが一番良い方法だろうな。
余力と環境があるなら、ジオメトリインスタンシングも
試して欲しいところだが。
272:デフォルトの名無しさん
09/07/09 14:06:50
結局「縮退ポリゴンを使わずに、複数のビルボードをStripで描画する」方法の説明がないわけだが
273:デフォルトの名無しさん
09/07/09 14:11:03
インデックスで縮退用のを適当に一枚かますってことか
それでなくてもDrawPrimitiveUPにこだわる人は、
描画数増えたときどうするんだろ？
274:デフォルトの名無しさん
09/07/09 14:24:44
「DirectSoundで鳴らしている音」を録音したいのですが、
どうすればよいでしょうか？
例えば、自作ゲームの「BGM」と「プレイ中に適宜鳴る効果音」の両方を
１つのWAVファイルに録音したいと思っています。
よろしくお願いします。
275:デフォルトの名無しさん
09/07/09 14:27:40
縮退ポリは使わないと言ってるだろ
276:デフォルトの名無しさん
09/07/09 14:39:01
なんか大人と子供だな
277:デフォルトの名無しさん
09/07/09 14:40:13
そもそも2000～3000ポリゴン以下ならDrawPrimitive系もDrawPrimitiveUP系も
速度にほとんど差がないんだが、みんな計測した上で話をしてるんだろうか？
278:デフォルトの名無しさん
09/07/09 14:43:08
誰もそこの速度差は問題にしていないけどな
279:デフォルトの名無しさん
09/07/09 14:46:15
259です。
>>270
＞UPでもロックのコストは変わらないと書いた
259で書いてるのは「結局（UPと同じくらい）遅いと思うが」という意味です。
280:デフォルトの名無しさん
09/07/09 14:54:53
>>277 >>278
むしろ本当に3000ポリゴン程度で差が出るなら問題じゃね？
速いほう使った方がいいだろ
281:デフォルトの名無しさん
09/07/09 15:07:02
たくさんのご意見ありがとうございます。
まず、UPをやめる＋INDEX化で転送量が2/3になるのは良さそうです。
やってみます。
さらにINDEXバッファは1回だけ書けば書き換え無用ですから、純粋に2/3になりそうで良いですね。
TriangleStripで～という方法は、いまいちわかりません。
離れた位置の四角ポリゴン（実際は三角ポリ×2）を描画する必要がある以上、TriangleStripは使えないのではないでしょうか？
縮退ポリゴン（描画されない細い三角ポリゴン）を使うことによる手法も聞いたことはありますが。
AGPメモリというのが最初よくわかりませんでしたが、D3DUSAGE_DYNAMICを指定することなんですね。
こちらも試してみます。
このほかに、下記のような手法も考えたのですが、一般的ではないのでしょうか？
説明を楽にするために、INDEXではない方法での説明とします。
・「四角形を1つ描画するのに必要な情報」を作る。つまり6頂点分。
頂点データの中にD3DFVF_SPECULARを加え、その領域に「何個目の四角形か」を入れておく。
・上記の6頂点×描画しうる四角形分の”静的”頂点バッファを作り、情報を書き込む。
その際D3DFVF_SPECULARの領域に入れている「何個目の四角形か」をきちんと適切な値にしておく。
・パーティクルを表現するには、四角形毎の座標情報を更新する必要がある
そこでID3DXEffect::SetVectorArray()で座標情報を渡す
・エフェクト側ではD3DCOLORtoUBYTE4を使って、対応するVectorArrayの座標情報を引き出し、頂点座標に加算する
問題点として、ビルボードをカメラに正面向けにするためのMATRIX変換を頂点シェーダ内でやる必要があります。
（今までは、頂点データ内のxyzを正面向くように調整済みだった）
282:デフォルトの名無しさん
09/07/09 15:16:38
>>281
長々書いてあるが、テストすれば分かることだから自分でやってくれ。
Index関係の思い出といえば、
Indexバッファを途中から使うための引数の与え方が全然資料が無いことだった。
正しく動作させるまでかなり試行錯誤したな。
一度動けばなんてことないんだが。
283:デフォルトの名無しさん
09/07/09 15:24:58
>>282
詳しく
前にIndexバッファを途中から使おうとしたんだけど
GeForceとIntel系チップセットでは想定通りの動きをしたんだけど
ATＩ系のビデオカードではうまく動いてくれなかったんだよね
284:282
09/07/09 15:28:43
>>283
逆に、マジかと言いたい。
オレはGeForceで開発した上でIntel系とATI系でも動いてることを確認する形を取ったが、
Direct3DのAPIレベルで互換性が無いような違いが
IndexedBufferレベルであるんだろうか？
285:デフォルトの名無しさん
09/07/09 15:44:09
>>281
全然わからんが、要はこれがしたいのか？
FVFが通るか、不安があるけど。
uniform float4x4 g_world_transform[n] = { ... };
static const float4 g_local_position[4] = { ... }; // for box vertices
struct vertex_in_t
{
uint24 transform_index; // 0~n
uint8 position_index; // 0~3
};
struct vertex_out_t
{
float4 positon;
float4 color;
};
void vp_main( in vertex_in_t iv, out vertex_out_t ov )
{
float4x4 world_transform = g_world_transform[iv.transform_index];
float4 local_positon = g_local_position[iv.position_index];
ov.position = mul( local_positon, world_transform );
pv.color = float4(1,1,1,1);
}
286:デフォルトの名無しさん
09/07/09 17:34:48
縮退ポリゴンとはなんぞや？
287:デフォルトの名無しさん
09/07/09 17:43:39
>>286
面積が0のポリゴン
ストリップは数珠繋ぎしか出来ないけど
途中面積が0のポリゴンを繋げれば
バラバラに見えるでしょ
288:デフォルトの名無しさん
09/07/09 17:52:37
報告です。
281で提唱した方法だとでかかる時間を1とすると、
AGPメモリに置く方法は2
DrawPrimitiveUPでやる方法は3
となりました。
何の因果か、きれいに1:2:3になりました。
281で提唱した方法だと、実質VRAMへ転送している量はvector4 * particleNumでかなり節約できます。
その他ですと、
float x, y, z;
float nx, ny, nz;
DWORD color;
float u, v;
でfloat * 9 * particleNumほど転送しているので、二倍超転送していることになります。
やはりボトルネックはこのあたりなのでしょう。
次は、ストリームを分けることで、AGPメモリに置く方法をとりつつxyzの値しか転送しないようにしてみます。
289:デフォルトの名無しさん
09/07/09 17:59:13
1*1のポリゴン用意して
トランス演算とDraてPrimitive繰り返せばよくね？
290:デフォルトの名無しさん
09/07/09 18:21:59
>>281を見てると「それってInstancingじゃね？」と言いたくなる
URLﾘﾝｸ(msdn.microsoft.com)(VS.85).aspx
291:デフォルトの名無しさん
09/07/09 18:48:59
小沢の西松建設問題の時
09/01/21 西松建設社長を逮捕
09/01/21 元西松建設専務 死亡
09/02/24 長野知事の元秘書(西松建設事件での参考人) 死亡
（電柱にロープを巻きつけ首吊り自殺）
09/03/01 「小沢一郎氏と秘書と、ダム工事のただならぬ関係」を追及してきた記者(吉岡元議員) ソウルで取材中に死亡
09/03/03 民主党岩手支部家宅捜索
09/03/04 民主党事務所のある相模原卸売市場全焼
助かった人
小沢氏の第一秘書・大久保容疑者も自殺の恐れが出てきたため、検察が緊急逮捕
鳩山の献金問題
292:デフォルトの名無しさん
09/07/09 23:14:37
288です。
288の報告は、いわゆるオンボでの実験で、頂点シェーダがソフトウェアで行われていました。
グラボつき（GF9600）の環境で試したところ、
UP系 5
AGP 8
281法 1
の割合で時間がかかりました。
AGP法のほうが、UPよりも遅くなっているのが印象的です。
>>290
面白い記事ありがとうございます。
まさしくこれですね。
293:デフォルトの名無しさん
09/07/09 23:42:09
なんかやり方が下手な気がする
ソースあげてみ
294:デフォルトの名無しさん
09/07/09 23:49:07
つかindexbufferも使えない素人のコードによる測定になんの価値があるんだ
いつまでやる気だろ
295:デフォルトの名無しさん
09/07/09 23:57:00
>面白い記事ありがとうございます。
節子…それ、公式サンプルや
一般的な方法がわかって良かったんじゃね
296:デフォルトの名無しさん
09/07/09 23:59:00
まともなグラボならUP使ったほうが早いのは常識だろ
293とか294は典型的な2ch馬鹿だな
297:デフォルトの名無しさん
09/07/10 00:04:24
>>293
一番あやしいのは、逆に遅くなってるAGPのやつですよね。
pDev->CreateVertexBuffer(
sizeof(D3DVERTEX) * 4 * MAX_SMOKE,
D3DUSAGE_DYNAMIC | D3DUSAGE_WRITEONLY ,
MYFVF,
D3DPOOL_DEFAULT,
&m_buffer,
NULL
);
pDev->CreateIndexBuffer(
sizeof(WORD) * 6 * MAX_SMOKE,
D3DUSAGE_WRITEONLY ,
D3DFMT_INDEX16,
D3DPOOL_DEFAULT,
&m_index,
NULL
);
で生成し、毎フレーム下記のようになっています。
>>294 IndexBufferは使ってますよ
m_buffer->Lock(0, sizeof(D3DVERTEX) * 4 * m_smokes.size(), (void**)&vertex, D3DLOCK_DISCARD);
m_buffer->Unlock();
pDev->SetStreamSource(0, m_buffer, 0, sizeof(D3DVERTEX));
pDev->SetIndices(m_index);
pDev->SetFVF(MYFVF);
pDev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 4 * m_smokes.size(), 0, 2 * m_smokes.size());
298:294
09/07/10 00:04:34
>>296
は？UP云々なんて一言も言ってないんだがｗ
299:デフォルトの名無しさん
09/07/10 00:05:10
>>296
その根拠は？
>>292
動的バッファLock時のオプションは
どうしてる？
300:デフォルトの名無しさん
09/07/10 00:14:21
>>297
む、こりゃちょっとひどい気がする
スレちゃんと読んでないけど、xyzは毎フレーム変化してるんだよな？
どのタイミングで更新してるんだい？
301:デフォルトの名無しさん
09/07/10 00:19:30
>>299
D3DLOCK_DISCARDですね。
m_buffer->Lock(0, sizeof(D3DVERTEX) * 4 * m_smokes.size(), (void**)&vertex, D3DLOCK_DISCARD);
この行が、動的バッファのロックです。
LockとUnlockの間に「ここで頂点情報を書き込んでいます」とか書くべきでした。すいません
>>300
え、初心者サイトのサンプルをほぼそのまま使ったのですが、妙でしょうか？
ｘｙｚの更新は、Lockの前に行っています。
m_smokesというのが、ビルボードの中心座標の配列vector<D3DXVECTOR3>です。
302:デフォルトの名無しさん
09/07/10 00:24:23
ちゃんとD3DLOCK_DISCARDでロックしてるし、
動的バッファの取り扱いは、特に問題はなさそう。
へえ、これでUP系の半分の性能なんだ、信じられんｗ
303:デフォルトの名無しさん
09/07/10 00:29:11
>>302
オンボ環境ではしっかりUPのほうが遅かったので、環境によるような気がします。
明日再度オンボ環境の場所に行くので、再度慎重に測り直してみます。
304:デフォルトの名無しさん
09/07/10 00:30:56
>>301
うーむ、Lockの前に更新って、矛盾してないか
このソースだとDYNAMICでバッファを確保した意味がないよ？
305:デフォルトの名無しさん
09/07/10 00:34:25
こりゃ計測方法も怪しくなってきたなｗ
両方のソース示さない限り無意味だろｗ
306:デフォルトの名無しさん
09/07/10 00:39:25
>>304
すいません。ちょっと更新の意味を取り違えているのかもしれません
for(DWORD i = 0; i < m_smokes.size(); ++i)
{
m_smokes[i].y += 0.1f;
}
m_buffer->Lock(0, sizeof(D3DVERTEX) * 4 * m_smokes.size(), (void**)&vertex, D3DLOCK_DISCARD);
for(DWORD i = 0; i < m_smokes.size(); ++i)
{
(D3DVERTEX) *p = &vertex[i * 4];
p[0].x = m_smokes[i].x - 0.5f;
p[0].y = m_smokes[i].y + 0.5f;
p[0].z = m_smokes[i].z;
p[1].x = m_smokes[i].x + 0.5f;
p[1].y = m_smokes[i].y + 0.5f;
p[1].z = m_smokes[i].z;
p[2].x = m_smokes[i].x + 0.5f;
p[2].y = m_smokes[i].y - 0.5f;
p[2].z = m_smokes[i].z;
p[3].x = m_smokes[i].x - 0.5f;
p[3].y = m_smokes[i].y - 0.5f;
p[3].z = m_smokes[i].z;
}
m_buffer->Unlock();
こんな感じにやっています。
実際は座標のほかに、normal, color, uv もセットしています。
あと、もうちょいマシなコピーの仕方をしています。
>>305
単純に1000フレーム回るまでの時間を計測しています。
描画以外はほとんど何もやっていないのと、座標移動計算はまったくといってよいほど時間をくっていないのを確認済みです。
307:デフォルトの名無しさん
09/07/10 00:41:06
>>294=>>298=>>305
初心者スレ荒らして楽しい？
他人の足引っ張って立って、自分の価値を高めることにはならないぜ？
無意味だと思うならスルーしてなよ
308:デフォルトの名無しさん
09/07/10 00:43:46
特に問題あるようなソースには見えないな
UP系のほうが早い場合があるというのは面白い
UPはドライバ側で何かしらの最適化を行っているのかもね
309:デフォルトの名無しさん
09/07/10 00:44:01
>>307
連続でお疲れさんｗ
310:デフォルトの名無しさん
09/07/10 00:45:48
294 indexbufferも使えない素人が！（ｷﾘｯ!!
297 >>294 IndexBufferは使ってますよ
腹抱えてﾜﾛﾀｗ
311:デフォルトの名無しさん
09/07/10 00:53:01
久々に有益情報が出てるな
俺は何も考えずにDrawPrimitiveUP使ってた
Instancingとやらを使うと速度が5倍になるとかマジパネェから俺も実験してみるわ
312:デフォルトの名無しさん
09/07/10 00:53:04
俺のソースでは、mallocaで確保した一時バッファにデータを作ってから
Lock→memcpyでまるごとコピー→Unlock と、
ロックしている時間が短くなるようにしてたな。
なんとなくその方が良かろうと思っただけで、計測してないから鵜呑みにはするな。
313:デフォルトの名無しさん
09/07/10 00:57:20
294じゃないけど、よくおまえらそこまで無条件で信用できるな。
煽る気はないけど、ソースのないベンチなんて昔は弾いていた気がするんだが。
314:デフォルトの名無しさん
09/07/10 01:01:39
DirectX10使えば縮退ポリゴンもいらねーしデータ転送量も抑えられるしでウハウハ。
SO使えば座標更新もGPUで出来てさらにウハウハ。
315:デフォルトの名無しさん
09/07/10 01:06:14
>>312
D3DLOCK_DISCARDを指定すると、
一時バッファを用意してくれるらしいので
その処理は冗長と言える。
316:デフォルトの名無しさん
09/07/10 01:16:45
俺もGeforce9600GTなんで、さくっと試してみたよ
DrawIndexedPrimitiveとDrawIndexedPrimitiveUP
LVetexで位置のみ毎時更新
前者は動的バッファがたまり次第フラッシュ
後者もそれに合わせようと思ったけど、面倒なんでメモリ一括確保
疲れてるんで固定機能でやったけど、1万ポリでも誤差程度
寝る
317:デフォルトの名無しさん
09/07/10 01:20:16
>>316
そうなるはずだ。
UP系かそうでないかでそんなに差が出るというのはちょっとおかしいんじゃないか。
プリミティブの座標更新をGPUにやらせることで全体の高速化を図るというのならまだ分かるが。
318:デフォルトの名無しさん
09/07/10 01:30:53
>>316
結局描画におけるGPUの時間が変わらないからフレーム単位だと時間は変わらないが
DrawPrimitive()とDrawPrimitiveUp()だと関数から帰ってくるまでの時間にかなり差があったと思うが。
319:デフォルトの名無しさん
09/07/10 02:04:48
DirectShowのスレでも質問したのですが、スレの勢いを考えてこちらにも質問させていただきます。
DirectShowでGeekなページを参考に動画再生をするプログラムを作りました
URLﾘﾝｸ(www.geekpage.jp)
参考ＵＲＬでは『put_Rateの引数を2.0などに変更すると倍速再生になります。
put_Rateの引数に負の値（マイナスの値）を渡すと巻き戻し再生になります』
とありますが、
pMediaPosition->put_Rate(0.5);
のput_Rateの引数を負の値にしても大部分のフィルタは逆再生をサポートしていないため実行されません。
そこでIMediaSeekingかIMediaPositionを用いて、または用いなくてもいいのでdirectshowで
動画の巻き戻しをするプログラムを作りたいのですが、どうすればよいのやら困っています。
何か良い考えはないでしょうか？
是非知恵をおかしください！
320:デフォルトの名無しさん
09/07/10 04:29:31
テクスチャのサンプリングをWrapにして何度も繰り返すような貼り方をすると負荷が高いと聞いたんですが
これは本当ですか？
使用するテクスチャが小さくなるから、むしろこっちのほうが良いと思ったんですが
自分の環境（ GTX280 )では違いが見られなかったんですが
オンボードのような低スペックのビデオカードだと遅くなったりしますか？
321:デフォルトの名無しさん
09/07/10 08:27:10
うそです。
322:デフォルトの名無しさん
09/07/10 08:28:23
ゲームの動画再生にDirectShowはいつも使っているけど、再生速度の変更が必要になったことがないから知らない。
323:デフォルトの名無しさん
09/07/10 08:34:33
AGPっていつの時代だよw
324:デフォルトの名無しさん
09/07/10 09:08:50
ソース無いベンチなんて意味ないよ
ということではあるそうですが、一応報告しておきます
グラボつき（GF9600）の環境で試したところ、
UP系 5
AGP 8
281法 1
オンボ環境で試したとところ
UP系 10
AGP 9
281法 8.5
くらいの処理時間になりました。
あくまで同一環境内での比率なので、GF9600の数値とオンボの数値には関係性はありません。
まったく同じ実行ファイルで実験しました。
>>316
私の実験と差がありそうなのは下記2つっぽいですね
＞座標だけ更新
座標だけストリームを分けて、そこだけ更新したということでしょうか？
（私のは、座標のほかに法線・カラー・UVも毎フレームVRAMに転送しています）
＞前者は動的バッファがたまり次第フラッシュ
これはどういう方法でしょうか？
D3DLOCK_DISCARDではない方法ですかね
325:デフォルトの名無しさん
09/07/10 11:36:58
定数レジスタの数について質問があります
DX8時代は96
DX9時代は256
というのはなんとなく知っているのですが、これは頂点シェーダのバージョンに依存しているのでしょうか？
もしそうだとして
定数レジスタを200個近く使っている状態で
VertexShader = compile vs_1_1 vertexShader();
とやったとき、問題なく動作してしまうのが不思議です
エラーもでませんし、見た目も問題なく表示されてしまうのです
326:デフォルトの名無しさん
09/07/10 12:08:32
最低サイズが だろ？
詳細はcapsで調べれたと思う
どのみち最低サイズを守った方が利口だが
327:デフォルトの名無しさん
09/07/10 13:03:54
ICH10RでSSD2台で7RCでRAID0組みたいです。途中でFDDからRAIDドライバ読み込み必要ですか？
328:デフォルトの名無しさん
09/07/10 23:54:37
>>324です。
原因がわかりました。
どうやら、>>306のように、ロックしてからループで書きこんでいくのはよろしくないようです。
>>312のように、一時バッファを用意して全部メインメモリ上で書きこんでから、Lock。
memcpyでいっきに流し込みすぐUnlock
とやることで、UP系と同等の性能になりました。
「これならUPでいいじゃん」って思ってしまいますね…。
329:316
09/07/11 12:23:40
>>324
なんの工夫もなくロックして位置や色を書き込み
memcpy未使用
フラッシュはバッファに溜まったものを吐き出すって意味
今時使わない？俺もロートルか
330:316
09/07/11 13:00:33
memcpyでもやってみたが同じだな
フォーラムをざっと見てきたが、UPはレガシー扱いで間違いないだろう
・UPはハードウェアサポートが約束されていない
・UPは中間バッファを勝手に使うからパフォーマンスが落ちる(チューニングしづらい)
少なくとも2倍から3倍のメモリを使う
・描画命令を出しても、完了してから制御を戻すわけでないので、UPのために確保したメモリがいつまで妥当であるべきかが不定
・例え変化が無くてもmemcpyが描画命令のたびに呼ばれる(最適化が出来ない)
問題の件だが、冗長なメモリコピーがそのままUPのコストになるので、
扱う頂点数が増えるほどUPは不利になるだろう
おそらく結果が逆転してしまうなら、正しく使えてないのだと思う
331:デフォルトの名無しさん
09/07/11 13:12:57
ロックが長いってだけで、1.6倍の遅延に繋がるとは思えない。
なぜそうなるのか、シナリオが作れない。
誰か説明してくれない？
332:デフォルトの名無しさん
09/07/11 13:35:23
>>330
・描画命令を出しても、完了してから制御を戻すわけでないので、UPのために確保したメモリがいつまで妥当であるべきかが不定
流石にこれはないだろ。
UPを呼び出した直後に、確保したメモリーを壊してしまっても大丈夫だよ
333:316
09/07/11 14:12:18
>>332
さてどうだろうな
描画命令はFIFOで処理されタイミングは不定
投げ入れ側は(Sendではなく)Post扱い
そしてUPの場合、向こう側で全コピーが必ず発生している
壊したメモリがたまたま生きていただけかもしれない
*大丈夫だった*以上のことは言えないはずだ
334:デフォルトの名無しさん
09/07/11 14:15:00
UP系は関数から抜けたときにはソースのデータは破棄してOKなはず。
ようするに中でメモリ確保してコピーして保持してるって事だけどな。
335:デフォルトの名無しさん
09/07/11 14:21:21
ハハ、DrawPrimitiveUPは
何時クラッシュするかわからない
ファイナルハゲマル丼的な関数というわけですね。
わかります。
336:デフォルトの名無しさん
09/07/11 14:23:18
>IDirect3DDevice9::DrawPrimitiveUP に渡す頂点データは、呼び出しの後も保持する必要はない。
>MicrosoftR Direct3DR は、呼び出しから戻る前に、そのデータへのアクセスを完了する。
>>330の引用元の信用がガタッと減ったな
337:デフォルトの名無しさん
09/07/11 14:25:35
MSDNの記事くらいは読もうよ。
＞IDirect3DDevice9::DrawPrimitiveUP に渡す頂点データは、呼び出しの後も保持する必要はない。
＞MicrosoftR Direct3DR は、呼び出しから戻る前に、そのデータへのアクセスを完了する。
338:316
09/07/11 14:27:54
>>336
こりゃすまなかったな
引用元はよく使うGDevだ
しかし全コピーが発生するのは間違いないだろう
339:デフォルトの名無しさん
09/07/11 14:30:06
>>336
だからこそUP系は遅いんだろ
>>318で既に出ているけど
340:デフォルトの名無しさん
09/07/11 14:30:50
UP系は中でDYNAMICなバッファのプールに対してLOCK_DISCARDと
DrawPrimitiveを必要な数繰り返していると推測できる。
341:デフォルトの名無しさん
09/07/11 15:01:39
>>340
その間制御を戻さないならば、CPU時間が減るし、
コピー後に制御を戻すとしても、メモリとコピー時間が無駄なわけだよね。
どう考えてもUP系の方が速くなるはずがないのだけど、
そもそも質問主以外にそんな結果の人はいるんですかね？いないなら不毛な気が・・・。