DirectX総合スレ (Part5)

**名前は開発中のものです。** · 2006/09/08(金) 23:56:42

言語はC++
他の言語使ってる奴はいますぐ消えろ

**864** · 2006/11/06(月) 11:44:40

質問に煽りで返して、煽り返されたら顔真っ赤ですか
答える義務がないとか言うなら無視するか、知らないでいいだろ
結局ソフトでは無理ということですな

**名前は開発中のものです。** · 2006/11/06(月) 12:27:48

何も分かってないのに質問してくる奴はたぶん頭がどうかしてる。

**名前は開発中のものです。** · 2006/11/06(月) 12:29:39

>>888
1フレーム描画する間にメッセージ処理を1回しかしてないとか。
メッセージループはキューが空になるまで回さないと駄目だよ。

**名前は開発中のものです。** · 2006/11/06(月) 17:08:24

>>888
メインループが問題だと思うなら君のメインループを晒したほうがいいんじゃね？
関係ないが俺が会社で支給されたキーボードはゲームで使うと明らかに遅延してる
糞キーボードだったりする。

**名前は開発中のものです。** · 2006/11/06(月) 18:02:51

>>864
ネットゲームばっかりやってないで
仕事探せよ

**名前は開発中のものです。** · 2006/11/06(月) 18:31:26

864を見てから、DirectInputだけじゃなくてタイマ関係のAPIもフックして
記録しておけば、大抵のゲームはリプレイ撮れそうだなーと考えている
俺ガイル。

**名前は開発中のものです。** · 2006/11/06(月) 18:39:32

>>891
>>892
for(;;)
{
while(PeekMessage(&msg,NULL,0,0,PM_REMOVE)) DispatchMessage(&msg);
render();
d->Present(NULL,NULL,NULL,NULL);
Sleep(0);
}
だいたいこんなかんじです

無意味にSleepを挟んで30FPSくらいにまで落した方が60FPSでてるときよりも
マウスの動きへの追従に関しては良かったり

**名前は開発中のものです。** · 2006/11/06(月) 19:04:42

DispatchMessage だけじゃなくて、TranslateMessage もするのが普通じゃね？

それが原因とは思えないが・・

**名前は開発中のものです。** · 2006/11/06(月) 19:06:31

たとえばWM_PAINT、WM_PAINT、WM_MOUSEMOVEの３つのメッセージが
キューにあった場合、そのループだとマウスを拾うのが
3フレーム後ということになる

**名前は開発中のものです。** · 2006/11/06(月) 19:08:19

うそつくな俺

**名前は開発中のものです。** · 2006/11/06(月) 19:40:52

>>889が完璧に華麗なスルーされてて笑ったｗ
反応しちゃってごめん、このレスも無視してくれｗ

**名前は開発中のものです。** · 2006/11/06(月) 19:49:21

>>897
while や for を中括弧で括らないのは
見辛さという面でもメンテナンス面でも問題ありだよな。

**名前は開発中のものです。** · 2006/11/06(月) 20:45:44

PeekMessage
PM_REMOVE

**名前は開発中のものです。** · 2006/11/06(月) 20:59:15

まぁあれだ。結局俺には原因は分からないが、
メッセージループとゲームのメインループは
スレッドを分けた方が良いかもしれないと。

**名前は開発中のものです。** · 2006/11/06(月) 21:14:37

>>895
まさかとは思うけどメインスレッドのプライオリティを高くとかしてたりはしないよね？
あと通常ループでもSleepでOSにCPUリソースは回してやるほうがいい
でもSleep(0)で十分なはずなのでそれでうまくいかないのはちょっと分からん

**名前は開発中のものです。** · 2006/11/06(月) 22:06:31

>>894
処理落ちもコマ落ちも乱数列も全部再現できるならな。

**名前は開発中のものです。** · 2006/11/06(月) 23:18:23

>>895
俺の勘違いならいいんだが・・・IDirect3DDevice9::SetCursorPositionとか使ってる？
自力でマウスの座標にスプライト描いてたりするとフレームレートに比例して遅延するわけだが・・・。

**名前は開発中のものです。** · 2006/11/07(火) 01:29:54

>>904
乱数の仕組み知らなそうだな…

**名前は開発中のものです。** · 2006/11/07(火) 03:01:33

その発言だけ見ると
>>906は乱数列の初期化の仕組みを知らなそうに見えるのだが

**名前は開発中のものです。** · 2006/11/07(火) 06:03:52

タイマをフックして記録時と再生時に同じ値を返すようにしたら
むしろ別の乱数列を生成する方が難しいと思うが。

**名前は開発中のものです。** · 2006/11/07(火) 10:48:06

>>906
タイマをフックしてただけで乱数の初期化関数に適切なシードを渡せるんだ？
すごいね。

それとも>>894は自作ゲームの話をしてるのかな？
だったら漏れが文盲だ。

**名前は開発中のものです。** · 2006/11/07(火) 12:30:39

>>907-909
馬鹿か？何もわかってないのはお前等の方。
乱数からその系列のシードが割り出せるとでも思ってんのか？
勘違いも甚だしいぞ。

**名前は開発中のものです。** · 2006/11/07(火) 12:36:51

>>910
タイマーフックして、シードを固定化するって話じゃないの？

**名前は開発中のものです。** · 2006/11/07(火) 12:46:36

複数のスレッドから乱数を共有するようになってたらアウトだと思うんだがそこはどうすんの？

**名前は開発中のものです。** · 2006/11/07(火) 13:54:36

いっそ仮想マシンでも作ってろよ

>>895
マウスを管理するにもCPUパワーは必要だし、その辺のプロセスに実行権を
確実に与えるためにもSleepの引数は1以上にするといいのでは？
特にUSBのマウスやパッドはアプリケーションのCPU使用率が高くなると
遅延が起きやすいとかいう噂があるし(未確認)。

**名前は開発中のものです。** · 2006/11/07(火) 14:03:41

とりあえず、何もしてない状態でもマウスぐるんぐるんまわしてるだけで
3GHzなオレのマシンでも
CPU使用率ふえまくりんぐ

**名前は開発中のものです。** · 2006/11/07(火) 22:02:56

>>910
皮肉もわからないなら2chなんかに書き込まないほうがいいよｗ
＞乱数からその系列のシードが割り出せる
↑誰もこんな話はしていない。>>864からの流れは完全無視ですか？
DirectInputで入力処理してるらしいプロセスに
外部からフックをかけてリプレイ再現できないかって話だろ。

だとしたら例えば乱数のシードがわかったところで
それをどうやって初期化関数に渡すんだい？
逆アセしてジャンプ先を書き換えるかね？
タイマ関係をフックするのとは全く関係ない話になってくるよな。

**名前は開発中のものです。** · 2006/11/07(火) 23:10:00

ひょっとして915とかはゲームが起動してからフックすると思っているのかな？
普通はこういうのはWinMainより前の段階でフックを仕込むものだから、
シングルスレッドならあまり心配ないと思うが。

マルチスレッドだと簡単に破綻しそうだけどね。

**名前は開発中のものです。** · 2006/11/07(火) 23:49:29

話が混乱してるね。

メインループの話は、マウス処理とかのフックとは別でしょ？
しかも、>>864 は別アプリのマウス処理をフックしたいって話だから
>>916 はそもそも間違えてる。

**名前は開発中のものです。** · 2006/11/08(水) 00:04:21

すいません、ちょっと質問なんですが2chのDirectX関連のスレに書き込むときに無駄に喧嘩腰にならなくなるようなツールって無いでしょうか？
一応自分でぐぐってみたんだけど見つかりません。

**名前は開発中のものです。** · 2006/11/08(水) 00:14:05

>>918
みんなの心の中にありますヽ（´ー｀）ノ

けんか腰の人はプログラムできない中坊とみなします。

**名前は開発中のものです。** · 2006/11/08(水) 00:15:41

>>918
教えて君氏ねよ

**名前は開発中のものです。** · 2006/11/08(水) 00:29:44

>>917
別アプリのフックの話だよ。
俺はDirectInputはやったことないが、D3Dのフックはいつもやってる。

っていうか、乱数のシードが云々言ってる人は、ゲームの実行中に
いつでも記録/再生ができるような万能リプレイを想像してるんじゃない？

起動する段階から入力を全て記録しておいて再生できるようにするってのは、
俺は自分のプログラムにはデバッグ用に組み込むことが多いよ。
記録/再生モードでは乱数のシード固定、fpsも固定してる。
乱数はタイトル画面の入力待ちのときに回してる。

**名前は開発中のものです。** · 2006/11/08(水) 00:57:06

アプリケーションがDirectInputから取得する
デバイスの入力データは
IDirectInputDevice8::GetDeviceData又は
IDirectInputDevice8::GetDeviceStateから
得られる配列だろ。
フック云々やろうが、横取りするのは無理じゃね？
あ、イベント使用オンリー？

**名前は開発中のものです。** · 2006/11/08(水) 01:06:22

例えそこに完全に同じ値を返せたとしても

内部がマルチスレッドで動いていて
複数のスレッドが乱数生成機を共有して使っていたら(←これ自体どうかと思うが)
どうにもならないって話

**名前は開発中のものです。** · 2006/11/08(水) 01:14:10

>>922
APIだろうがCOMだろうが、好きな関数にフックを仕込めるよ。
やり方は自分で勉強してくれ。OSが標準で用意してるわけじゃないから。

>>923
乱数を共有していなくても、ファイル読み込み等を別スレッドでやっていて
メインスレッドが待っている間に画面の更新をしていたりするだけで
厳しいと思う。

**名前は開発中のものです。** · 2006/11/08(水) 01:42:30

>>924
ラッパーか、なるほど忘れてた

**名前は開発中のものです。** · 2006/11/08(水) 01:54:34

インデックスバッファを使うと複数回使われる頂点に対する行列演算が
一回で済むため高速になる。

っていう理解でOKですか？

**名前は開発中のものです。** · 2006/11/08(水) 02:06:40

>>926
それはドライバ以下実装依存だと思う。
その最適化を行う為には、VertexShader後頂点データを
どっかに保存しとかなきゃならない。
実際のチップは毎度毎度計算の方が速いから、そんなことしないよってパターンじゃないかな？
ってことでIndexBufferのメリットは、重複頂点が無くなってVertexBufferのサイズが減ってｳﾏｰの方か

**名前は開発中のものです。** · 2006/11/08(水) 05:15:49

ほー、そうなのですか。サンクスです

**名前は開発中のものです。** · 2006/11/08(水) 10:27:55

>>927
>GPUはVertexShader後の頂点データを保存しなきゃならない

それが頂点キャッシュだろ。いくらGPUがパイプライン化しやすいからって、
ボーンやら照明計算を含んだ複雑な処理を、キャッシュから拾ってくるより
毎回計算する方が速いってこたぁない。

**名前は開発中のものです。** · 2006/11/08(水) 11:20:58

>実際のチップは毎度毎度計算の方が速いから
滅茶苦茶を断言で書くなよｗ

**名前は開発中のものです。** · 2006/11/08(水) 12:28:30

頂点キャッシュはかなりサイズが小さいから、キャッシュを意識して
頂点の順番を並べ替えないと、ほとんど恩恵ないよ。
GeForce6で24頂点のFIFOだね。たぶん7も一緒。

**名前は開発中のものです。** · 2006/11/08(水) 14:46:09

その為のStreamOut

**名前は開発中のものです。** · 2006/11/08(水) 22:06:45

てか変換済みの頂点だったらVRAMに置いといて、終わったら消すだけでも十分効果あるだろ。

実際Zバッファやバックバッファは毎フレーム破棄するように作れるし。

**名前は開発中のものです。** · 2006/11/09(木) 06:28:09

DrawIndexedPrimitiveなんかで多数のポリゴンを描画する時、一度のLock/UnLockでメモリコピーすべきですか？
何回もLock/Unlcokするのはいかにも遅そうな気がするんですけども。

**名前は開発中のものです。** · 2006/11/09(木) 06:37:42

一度にコピーできないなら、コピーできる分だけさっさと書き込んで
DrawPrimitiveを呼んで描画を開始させた方が速いと思う。
もちろんLockで処理がブロックしないように、NOOVERWRITEや
DISCARDを適切に使って。

**名前は開発中のものです。** · 2006/11/09(木) 16:17:05

>>934
こんなところで質問してねーで実測しろよ。

**名前は開発中のものです。** · 2006/11/09(木) 17:55:45

すみません質問です。
あるモデラからDirectX用に独自形式でデータ（モデルとスキンアニメーション）をエクスポートしているのですが、
そのモデラのＺ軸は手前側がプラスなので、奥がプラスになるDirectXで表示すると変になってしまいました。
正常に表示するには、どうすれば良いのでしょう？

**名前は開発中のものです。** · 2006/11/09(木) 19:00:04

>>937
アニメーションまで含んでるなら変換はそれなりに面倒。
長くなりすぎるのでキーワードだけ置いとく。[右手左手擬ベクトル]

**名前は開発中のものです。** · 2006/11/09(木) 20:16:11

[Z反転、カリング]

**名前は開発中のものです。** · 2006/11/10(金) 01:06:39

[あきらめてオナニー]

**名前は開発中のものです。** · 2006/11/10(金) 20:06:55

テクスチャって全部一枚に収めてuv座標で切り取って貼り付けるのと
ポリゴンごとに一枚ずつ用意するのとどっちが良いんでしょうか？

**名前は開発中のものです。** · 2006/11/10(金) 20:13:56

ケースバイケース
だがDirectXで重いからやるなハゲといわれている事を
考えるなら答えは分かっているはずだ。

**名前は開発中のものです。** · 2006/11/12(日) 07:25:35

サンプルを手コピーすればdirectXを使えるようになりますか？

**名前は開発中のものです。** · 2006/11/12(日) 08:01:52

>>943
サンプルを手コピーして動いたのを「DirectXが使えた」と言うならね。

**名前は開発中のものです。** · 2006/11/12(日) 08:33:25

やっぱ書籍を買わないとダメか

**名前は開発中のものです。** · 2006/11/12(日) 08:52:14

要は理解して応用につなげられるか、だろ

**名前は開発中のものです。** · 2006/11/12(日) 09:40:04

>>964あぁ、なるほど、そういうことですか、それならその内身に付く気がするので、まずサンプルをやってみます。みなさんレスありがとうございました

**名前は開発中のものです。** · 2006/11/12(日) 09:40:55

>>946 の間違いでつ

**名前は開発中のものです。** · 2006/11/12(日) 09:48:34

言い表しようのないキモさを持ったキャラだな

**名前は開発中のものです。** · 2006/11/12(日) 18:14:36

俺はサンプルを手コピーして、
それぞれの処理を表面的かつ自分なりに解釈し、
然るべきタイミングに処理が行われるように再配置し、
足りない処理を色々と付け加えて、
完成したゲームを某所にコッソリ登録したりしているが、
とてもじゃないが恥ずかしくてDirectXを理解しているなんて言えない…

で、サンプルなりチュートリアル見てわからない事があったら書籍買うといいよ。
書籍のほうが判りやすいとは限らないが、
同じ事でも違う方向から見ると、簡単に理解できる事もたまには在る。

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

迷ってるんだったら
本買え
時間を買ってると思えば安い

**名前は開発中のものです。** · 2006/11/12(日) 22:42:19

>>951
そーだよなー俺も最近は悩まないですぐ買う事にしてる。
んで理解できたら速攻ヤフオクとかで売ってる。
古い本とか人気の無い本以外は、定価の５割以上は戻ってくるのでいい感じ。

**名前は開発中のものです。** · 2006/11/15(水) 02:00:13

DrawIndexedPrimitiveで三角形を6000個ぐらい描画する際、
200個ぐらい転送するごとにDrawIndexedPrimitive呼んでいるんですが、
NOOVERWRITEでロックしてもしなくても速度ほとんど代わりませんでした。
これってどこかでやりかた間違ってるってことでしょうか？
それともNOOVERWRITE使っても大して速くならないんですかね？

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

システムメモリにバッファもってDISCARDで全部転送したらどうなる？
まぁGPUの負荷を正確に調べるのは無理ってMSも言ってるが。

**名前は開発中のものです。** · 2006/11/15(水) 21:38:08

質問させてください。

ピクセルシェーダーのtexreg2arとtexreg2gbにおいて、
参照テクスチャのサイズが 2^n 以外の場合に正常に作動してくれません。
具体的には常に黒が返ってきてしまいます。
また、リファレンスラスタライザで実行した場合には、どのようなサイズでも正常に
作動しております。
このことから、おそらく私の使用しているハード(radeon 9000pro)特有の制限ではないかと
疑っていますが、実際のところ、どうなのでしょうか?

OS: Windows XP SP1
DX: DirectX 9.0c
GPU: RADEON 9000PRO

**名前は開発中のものです。** · 2006/11/15(水) 21:52:08

＞2^n 以外の場合に正常に作動
テクスチャのサイズが 2^n 以外を使うことの方がありえないんだが。

そもそも 2^n 以外のサイズをサポートしてるハードウェアの方がレア。
自分で３Dエンジン組めばわかるが 2^n ってのは非常に効率いいのよ。

どうしてもっていうならまずはCAPS調べてサポートしてるかちゃんと調べようぜ。

**名前は開発中のものです。** · 2006/11/15(水) 22:08:28

>そもそも 2^n 以外のサイズをサポートしてるハードウェアの方がレア。

それは texreg2gb、texreg2ar に限った話でしょうか?
私の知る限り、よほど古いカードで無い限り、
テクスチャの 2^n 制限は無くなったものと思いますが。
それとCAPSを調べても、texreg2gb、texreg2arが 2^n 以外のサイズを
サポートしているかどうかまでは判からないものと思えます。
ちなみに私が確認した限り、 texreg2gb、texreg2ar 以外の命令では
2^n 制限は認められませんでした。

**名前は開発中のものです。** · 2006/11/15(水) 22:57:25

最新かどうかは君の判断に任せるが、
愛用のRadeon X1900XT は 2^n 制限がある。

個人的には 2^n 以外のテクスチャを使うという選択肢がありえないが・・・
そもそも 2^n 以外のサイズのテクスチャが必要になる事ってないだろう。

あとD3DX系の関数でテクスチャを読んでるなら、
2^n 以外をサポートしてない時は、内部で 2^n のテクスチャ作って返してくるぞ。
つまりテクスチャの端の方をサンプリングすると何もないので真っ黒。

リファレンスラスタライザで動いてるなら9割プログラムのミスだと思うが。

リファレンスならサイズの制限はない、つまりいかなる場合でも1.0をサンプリングすると一番端になる。
制限がある場合D3DXがでかいテクスチャの左上に展開してテクスチャをよこしてくるので、
1.0をサンプリングすると何もないrgba(0,0,0,0)が帰ってくる、ってところじゃないのかね。

**名前は開発中のものです。** · 2006/11/15(水) 23:13:28

>>957
そのソフトが完全に決まった環境でしか実行されないんだったらいいんじゃね。
俺は2^nしか使わないけど。しかも小心者なので２５６ｘ２５６制限でやってる。

**名前は開発中のものです。** · 2006/11/15(水) 23:22:21

>愛用のRadeon X1900XT は 2^n 制限がある。

それは texreg2gb、texreg2ar に限った話でしょうか?
私の使用しているRADEON 9000PROでは、2^n以外のテクスチャを作成することも出来ますし、
ポリゴンに貼り付けることも出来ますし、レンダリングターゲットに指定してレンダリングする
こともできます。

>そもそも 2^n 以外のサイズのテクスチャが必要になる事ってないだろう。
例としては、フレームバッファがあげられるかと思います。

texreg2ar、texreg2gb命令は、引数の色をテクスチャ座標としてテクスチャをサンプリングする
命令です。私はこの命令を使って色の再マッピングを行おうと考えておりました。
ところが、この命令は色値0～255を座標値0.0～1.0へと正規化してしまいます。
その結果、色値255は座標1.0、つまり、テクスチャ範囲外になってしまい、思うように
再マッピング出来ません。
この問題を解決するには、色値255を使わないようにして、
さらにテクスチャサイズを254x254にするしか方法が無いように思えます。
他にもっと良い方法はあるでしょうか。

**名前は開発中のものです。** · 2006/11/15(水) 23:29:37

ttp://monsho.hp.infoseek.co.jp/dx/dx46.html
ここに置いてあるサンプルプログラムは、texreg2arがサイズ128x128のテクスチャを参照しています。
これは2^nではありませんので、私の環境(RADEON 9000PRO)では期待される結果が得られません。
皆さんの環境ではどうでしょうか。
GPUの名前と合わせて、結果を教えていただけませんでしょうか?

**960** · 2006/11/15(水) 23:31:19

訂正
さらにテクスチャサイズを254x254にするしか方法が無いように思えます。
↓
さらにテクスチャサイズを255x255にするしか方法が無いように思えます。

**名前は開発中のものです。** · 2006/11/15(水) 23:39:15

ごめんなさい128x128は2^nですよね。
あれ、じゃぁなんで私の環境で動かないのだろう・・・
>>961は忘れてください、ごめんなさい。

**名前は開発中のものです。** · 2006/11/16(木) 00:09:26

>>960
> 私の使用しているRADEON 9000PROでは、2^n以外のテクスチャを作成することも出来ますし、

作成できてると思ってるそのテクスチャの、実サイズを取得してみて。
本当に意図したサイズになってるか確認してみないと
>>958 の言ってること無視できないでしょ？

俺はビンゴだと思ってるけどね。
テクスチャ任意サイズは対応してないって考えた方がいいよ。
もちろん、texreg2gb、texreg2arに限った話じゃないよ。（同じ質問ｳｾﾞｰよｗ

**名前は開発中のものです。** · 2006/11/16(木) 00:13:48

ちなみに、ウチの RADEON9000PRO は、D3DPTEXTURECAPS_POW2 が YESだよ。
２のべき乗じゃないテクスチャは駄目です。

**名前は開発中のものです。** · 2006/11/16(木) 00:24:19

>>960
>愛用のRadeon X1900XT は 2^n 制限がある。
宣言もなにもそもそも作成に制限がある。

D3DX系でCreateすると内部で勝手ででかいサイズのテクスチャ返してくるっていってるだろ。
640x480でCreateすると1024x512のテクスチャが返ってくるのが普通なのだが、
ちゃんと作成されたテクスチャのサイズやフォーマット見て確認してるのか？

フレームバッファはでかいテクスチャにClipしてレンダリング、
あるいはでかいテクスチャにそのままレンダリングして、縮小してFSAAっぽくしてる。
ところによっては別のサーフェイスにレンダリングしてから、エフェクト時だけテクスチャにCopyRectして使ってる。

あとUVマッピングの意味を理解しような。
テクスチャサイズを255とかいってる意味はわかるが、あまりにも意味不明。

**名前は開発中のものです。** · 2006/11/16(木) 00:30:01

「256とか512ってキリのいい数字だな！」っと盲信してる俺様はセーフ。

**名前は開発中のものです。** · 2006/11/16(木) 00:43:23

実サイズはどうでも良いのです。ドライバーが内部でどういった最適化
をしていようがDirectXの上から叩くことしか出来ない私には関係の無いことですから。
問題としているのはテクスチャアドレッシングまわりの話で、実サイズはどうでも良い話になります。

例えば、255x255のサイズのテクスチャを作ったとしましょう。
ここで、ドライバの最適化により実際には256x256のサイズのテクスチャが
作成されていたとしても、それはプログラマには関係の無い話といえます。
ただ、255x255と256x256のテクスチャでは、内部表現は同じだったとしても、
テクスチャアドレッシングのされ方は変わります。
なので255x255と256x256のテクスチャを使い分けることには意味があると考えます。

**名前は開発中のものです。** · 2006/11/16(木) 00:49:19

>>968 誰だﾃﾒｰヽ(`Д´)ノ

**名前は開発中のものです。** · 2006/11/16(木) 00:51:19

仮に >>968 が >>960 だったとして、
ここで質問していながら、なぜ他人のアドバイスを聞き入れない？

**名前は開発中のものです。** · 2006/11/16(木) 00:54:53

こら、矛盾してるぞ
>968
＞ここで、ドライバの最適化により実際には256x256のサイズのテクスチャが
＞作成されていたとしても、それはプログラマには関係の無い話といえます。

>>955
＞ピクセルシェーダーのtexreg2arとtexreg2gbにおいて、
＞参照テクスチャのサイズが 2^n 以外の場合に正常に作動してくれません。

むちゃくちゃ関係有るし。

**名前は開発中のものです。** · 2006/11/16(木) 00:56:21

内部表現はどうであれ、見た目上のサイズが n^2 以外となるテクスチャに対して
texreg2gb、texreg2ar を使用すると、正しい値を返してこない、
というのが正確な私の質問になると思われます。
紛らわしい表現をしてごめんなさい。

あと、D3DX系のCreateは使っておりません。
IDirect3DDevice9::CreateTextureを使って作成しております。

それと、見た目上のテクスチャの大きさが 2^n 以外でも
texreg2gb、texreg2ar が正常に動くビデオカードを誰か知りませんか?

**名前は開発中のものです。** · 2006/11/16(木) 00:58:52

イチイチここで質問する程度の能力しか無いなら
素直にpow2サイズのみ使っておけ

以上

**名前は開発中のものです。** · 2006/11/16(木) 01:04:04

だーかーらー
>>958 の人が親切に答えてるだろ！！
> つまりテクスチャの端の方をサンプリングすると何もないので真っ黒。

2^nしか対応してない環境で、2^n以外のテクスチャを作った場合に
内部でどうなるかを理解してないから、不具合だと思い込んでるだけなんだよ。

もちろん、texreg2gb、texreg2arに限った話じゃねーぞ！！！！

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

>>970
2^nサイズのテクスチャを使いたいのは山々なのですが、>>960に書いたとおり、
texreg2ar、texreg2gbに欠陥的仕様が御座いまして、どうしても255x255サイズのテクスチャ
を使用せざるを得ません。しかしなぜかtexreg2ar、texreg2gbで255x255サイズのテクスチャを
使用すると、正しい値を返してくれません。他のtex命令などの処理は255x255のサイズでも問題なく
行えます。
注)ここで言う255x255は見た目上のサイズのこと。

>>971
見た目上のサイズを255x255に指定したいだけなので、ビデオカード内での
内部表現は問題としません。なぜならテクスチャアドレッシングは見た目上のサイズにのみ左右されるからです。

**名前は開発中のものです。** · 2006/11/16(木) 01:14:33

すまんが、↓が全然理解できない。

> ところが、この命令は色値0～255を座標値0.0～1.0へと正規化してしまいます。
> その結果、色値255は座標1.0、つまり、テクスチャ範囲外になってしまい、思うように
> 再マッピング出来ません。

テクスチャ座標は1.0で範囲外にならんよ。
255x255にしなくちゃいけない理由が分からない。

あと、「見た目上のサイズ」が分からない。
プログラムで処理する以上、内部のことは理解してないと駄目。

2^n以外のテクスチャを作成した（つもり）時に、実際にどれだけの
サイズのテクスチャが出来てるのか理解しないと、テクスチャ座標を
正確に指定できない。

**名前は開発中のものです。** · 2006/11/16(木) 01:15:40

>>974
D3DX系のテクスチャ関数は一切使用しておりません。
使用しているのはIDirect3DDevice9::CreateTextureのみです。
IDirect3DDevice9::CreateTextureは勝手に内部でテクスチャサイズを調節
したりしません。
ドライバはテクスチャの内部表現を適切なサイズに調節するかもしれませんが、
それはDirectXを通してアクセスしている限りプログラマには関係の無い話となります。

> つまりテクスチャの端の方をサンプリングすると何もないので真っ黒。
どこにアクセスしても常に黒が返ってきます。

**名前は開発中のものです。** · 2006/11/16(木) 01:17:25

>ところが、この命令は色値0～255を座標値0.0～1.0へと正規化してしまいます。
>その結果、色値255は座標1.0、つまり、テクスチャ範囲外になってしまい、思うように
>再マッピング出来ません。

256x256サイズの画像はX座標(0～255) Y座標（0～255）だからそれでいいんじゃねーの？

**名前は開発中のものです。** · 2006/11/16(木) 01:19:01

>>977
いいから、黙って実際に作ったテクスチャの本当のサイズを調べろ。

>どこにアクセスしても常に黒が返ってきます。
テクスチャ自体が正しく設定されてるのか、新しい疑問が浮上するだけだが。

texreg2ar、texreg2gbつかわなくて直値で試してみた？

**名前は開発中のものです。** · 2006/11/16(木) 01:23:06

作ったテクスチャの（本当の）サイズを調べる方法↓

D3DSURFACE_DESC desc;
texture->GetLevelDesc(0, &desc);
float width = (float)desc.Width;
float height = (float)desc.Height;

**名前は開発中のものです。** · 2006/11/16(木) 01:24:21

j2RP45RNさんはやさしいなぁ

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

問題点が山積みだから一つ一つクリアにしていかないと・・

書き込みが1000に近づいてきたし、もう寝るんで結果でたら
あとは自力でがんばれ。>>ID:bg7PnqAA

**名前は開発中のものです。** · 2006/11/16(木) 01:35:22

>テクスチャ座標は1.0で範囲外にならんよ。
>255x255にしなくちゃいけない理由が分からない。
DirectXのマニュアルによりますと、テクスチャ座標は以下の式で決定されます。

以下マニュアルより抜粋

T_x=(u*M_x)-0.5
T_y=(v*M_y)-0.5
テクスチャ座標の下限と上限の 0.0 と 1.0 をこれらの公式に代入すると、
テクスチャ座標 0.0 は反復テクスチャマップの最初と最後のテクセル間の
中間点にマッピングされる。テクスチャ座標 1.0 は、現在の補間テクスチャ
マップの最後のテクセルと次の補間テクスチャマップ間の中間点にマッピングされる。

～ここまで抜粋

これをニヤーポイントでフィルタリングしますと、テクスチャ座標の切り上げが発生し、
結果、0.0は最初の座標を、1.0は一番外のテクセルの一つ向こうを指すことになります。

>あと、「見た目上のサイズ」が分からない。
見た目上のサイズとは、DirectXを通して見えるテクスチャのサイズのことです。
テクスチャアドレッシングはこの値のみに左右されます。
ドライバーが実際にテクスチャ割り当てたメモリサイズをプログラマが気にする必要はありません。

**名前は開発中のものです。** · 2006/11/16(木) 01:39:06

だから、今すぐ>>980でテクスチャサイズをチェックしろ。
これがおまえの言うところのプログラマが気にすべき「DirectXを通して見えるテクスチャのサイズ」なんだから。

**名前は開発中のものです。** · 2006/11/16(木) 01:40:32

>D3DX系のテクスチャ関数は一切使用しておりません。
>使用しているのはIDirect3DDevice9::CreateTextureのみです。
>どこにアクセスしても常に黒が返ってきます。

あのさぁ・・・せめてCreateTextureの返り値くらい調べたら？

**名前は開発中のものです。** · 2006/11/16(木) 01:52:42

>>980
調べました。255x255のテクスチャを作成したところ、
Width=255
Height=255
となりました。ドライバレベルでは256x256サイズのテクスチャが確保されていることでしょうが、
DirectXはそれを吸収してくれています。
このテクスチャのテクスチャサイズは 255x255、ドライバレベルでの(プログラマには関係の無い)
テクスチャブロックのサイズは(おそらく) 256x256 ということでFAでしょう。
つまり、DirectXではいかなるサイズのテクスチャの作成も可能だということになります。

そしてこのテクスチャをポリゴンに貼り付ける(tex命令)ことも出来れば、
レンダリングターゲットにしてレンダリングできることもできることを確認しました。
なのに、texreg2ar texreg2gb だけはうまくいきません。

>>985
調べました。そのテクスチャをポリゴンに貼り付けて表示してみたりもしました。
正常に表示されました。

**名前は開発中のものです。** · 2006/11/16(木) 01:54:28

>>956,958,965,966
D3DPTEXTURECAPS_POW2がYesでも
D3DPTEXTURECAPS_NONPOW2CONDITIONALもYesなら
2のn乗以外のテクスチャは使えるよ。（色々と制限はあるが）
そして、これに対応してないビデオカードなんて相当古いのしかない。

ようするに、いまどき2のn乗以外のテクスチャが使えないハードウェアの方がレア。

**名前は開発中のものです。** · 2006/11/16(木) 01:59:06

>>986
それならドライバレベルでも255×255が確保されている。

> ドライバレベルでは256x256サイズのテクスチャが確保されていることでしょうが、
> DirectXはそれを吸収してくれています。
> このテクスチャのテクスチャサイズは 255x255、ドライバレベルでの(プログラマには関係の無い)
> テクスチャブロックのサイズは(おそらく) 256x256 ということでFAでしょう。

根拠のない勝手な理屈を付けて自分を納得させるのはやめようぜ。