DirectX総合スレ (Part5)

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

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

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

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

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

D3DPTEXTURECAPS_NONPOW2CONDITIONAL

つまり、ディメンジョンが 2 の累乗でないテクスチャは、シェーダ内で計算されるテクスチャ座標を使ってアドレス指定したりサンプリングしたりすることはできません。
このタイプの処理は従属読み込みと呼ばれ、これらのタイプのテクスチャに対しては実行できません。

まぁ紆余曲折下が・・・リファレンス読もうぜ。

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

>>987
>（色々と制限はあるが）
その制限にtexreg2ar texreg2gb が引っかかっているということですよね。
texreg2ar texreg2gb が 2^n サイズ制限に引っかからないカードって有りますかね。
有るのでしたら今すぐにでも買い換えたいのですが。
でもどうやって探せばよいのだろう。メーカーに電話するしかないのかしら。

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

いやいやいや普通に2^nでテクスチャ作れよｗ

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

>>990
http://www.netsphere.jp/dxinfo/
ここで D3DPTEXTURECAPS_POW2 と D3DPTEXTURECAPS_NONPOW2CONDITIONAL
が両方とも Yes になっていないビデオカードを探しな。
NVIDIA の GeForce 6000 シリーズ以降ならたぶん大丈夫。

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

>>988
いやだって、2^nサイズしかテクスチャ作れないって言い張る人が多かったから
そうなのかなと。

>>SEFYYBum
あー貴方は神様です。心から感謝します。なるほど、そういう制限があったのか。
長らくお付き合いいただいた皆様、本当にどうもありがとう御座いました。

こうなると、今度はtexreg2arとtexreg2gbの欠陥仕様をどうしたものか・・・
頭が痛い・・・

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

自分に都合悪いと欠陥呼ばわりってのもどうなの・・・
2^n以外のテクスチャサイズのほうが一般的じゃないは理解してるんだろうか。

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

ってかPS2.0使えば解決するんじゃないの？

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

>>994
私は 2^n サイズしか使えないことを欠陥だと主張しているのではありません。
>>960 の前半と >>983を読んでみてください。

texreg2ar と texreg2gb は色の再マップに使われるとマニュアルに
も書いてあります。
しかしこれは実際にはうまくいきません。これはあきらかに欠陥仕様だと思います。

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

だから2^nじゃなきゃダメともリファレンスに書いてあるだろうが。
都合のいいところしか読めないのかよｗ

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

2^nしか使えないことはどうでも良いのです。
ただ、texreg2ar と texreg2gb は色値255において、テクスチャ座標1.0(テクスチャ範囲外)
を叩きにいきます。これは好ましい仕様だとは思えません。
色の再マップを行ううえで回避不能な問題を発生します。
(もともと色の再マップを行うためだけに作られた命令であるにもかかわらず)
色値255を他の色再マップすることが原理的に不可能です。

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

なんだ、結局無駄にスレ消費しただけじゃん。

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

1000取る人は次スレ立ててくださいね。
私は無理でした。

**１００１** · Over 1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。