DirectX総合スレ (Part5)

すいません、質問です。
SRPGを作っているので、
DirectXでなんとか平行投影で射影変換が実現
できないか模索しているのですが、どなたかご存知ありませんか。

斜め上後方からの見下ろし視点で、高低差のある立体的な四角形マスのマップ。
言語はVisualC++。DirectX9を使います。
自力で探していますが、もしアドバイス等いただけるとありがたいです。
よろしくお願いします。

10 ：名前は開発中のものです。：2006/09/09(土) 02:32:48 ID:sE0M1v20

>>9
よくわかんないけど、画面の平面にすべての頂点をペタンと貼りつけて、
画面枠に入った頂点が最終描画になるわけだよね？
じゃあ、計算式ってカメラ？画面？のローカルに移してＺ値を全て無視したものが変換後の頂点じゃね？
ってか、そういう式を作ればいいんじゃね？

11 ：名前は開発中のものです。：2006/09/09(土) 08:00:17 ID:0HGMyLQc

ものすごく遠くからものすごく視野角を狭くして描画すれば平行投影になるんじゃないのか。

12 ：名前は開発中のものです。：2006/09/09(土) 09:27:23 ID:sE0M1v20

>>11
そんなことしなくても平行投影だからカメラからみて単純にＺ方向を抜いた奴だってば。

13 ：名前は開発中のものです。：2006/09/09(土) 10:06:41 ID:wJiQZPcD

話の流れが読めないが
D3DXMatrixOrtho*H
じゃ駄目なのか

14 ：名前は開発中のものです。：2006/09/09(土) 10:56:42 ID:aA5FvX7Q

>>10-12
ありがとうございます。参考になりました。

>>13
調べて検討してみます。

15 ：名前は開発中のものです。：2006/09/09(土) 11:04:12 ID:aA5FvX7Q

どうやら、D3DXMatirxOrthLH()で正射影マトリクスを
生成できるらしいということが分かりました！
本当にありがとうございます。助かりました。

16 ：名前は開発中のものです。：2006/09/09(土) 13:34:55 ID:wJiQZPcD

それは良かった

まぁ君のクソゲーについてはともかくとして
>>11みたいな奇天烈な発想ってどうやりゃ出てくんのかな
やっぱ頭空っぽじゃないと夢詰め込めないんだろうな

17 ：名前は開発中のものです。：2006/09/09(土) 13:49:00 ID:aA5FvX7Q

>>16
クソゲにならないよう、気をつけさせていただきますね＾＾
では、失礼。

18 ：名前は開発中のものです。：2006/09/09(土) 14:25:28 ID:MLAHt6Xk

>>16
昔は3Dグラフィックソフトで平行投影できないものとかあって
その手法を使ったから、奇天烈な発想というわけではないと思うが。
写真だって似たような事をする場合もあるしね。

19 ：名前は開発中のものです。：2006/09/09(土) 15:01:53 ID:HNgrCKi9

平行投影という概念自体に沿ったごく自然な発想ではある。

20 ：名前は開発中のものです。：2006/09/09(土) 22:24:55 ID:CACnMXXa

>>16
こういうやつに限ってAPIとかで用意されてないと
「この環境ではできません」とか抜かすんだろうな。

21 ：名前は開発中のものです。：2006/09/09(土) 22:58:31 ID:o0Vq96gA

はいはい。煽り厨は来なくてもいいから。

22 ：名前は開発中のものです。：2006/09/09(土) 23:31:13 ID:lF2w3Y56

Matrix系の関数がAPIで用意されてるっつーのも相当レアな環境だと思うが・・・

23 ：名前は開発中のものです。：2006/09/10(日) 00:21:44 ID:7oN2Z5Lm

でも、こんなん、なんかメリットあんのかな？
いくらSRPGだって正射影って使うんか？
ふつうに描画したほうが普通に見た目いいと思うんだけどｗ

24 ：名前は開発中のものです。：2006/09/10(日) 01:56:22 ID:ndTCJOXf

>>23
日本一とか、フライトプランとかを真似てるだけ。
SRPGで正射影使ってないほうが珍しいんじゃないか？

斜め上からの視点だと、マスの高さが一定でもカメラから遠くなるほど小さく表示されるんじゃ、
奥のほうのマップが見難いんじゃないか、と。高低差有りだから余計に。
キャラやエフェクトは2Dドットだから、奥側の敵に攻撃したときの見え方とかも不安。

25 ：名前は開発中のものです。：2006/09/10(日) 03:45:56 ID:Ni9A6K9O

>>23
3Dとしてリアルならば見た目がいい、というものでもないだろう。
ゲームなのだから、分かりやすさも重要。
そのゲームや場面に適した表現方法ならばなんでもありだろう。

26 ：名前は開発中のものです。：2006/09/10(日) 08:54:13 ID:5QPW+vii

FFTも正射影だったような気がする

27 ：名前は開発中のものです。：2006/09/10(日) 12:05:28 ID:3ovxvACH

他が正射影だからって、それに倣うのも芸がないよな(´Д｀)

せっかくヒントをもらったのに検討もせずに無下にしては
新しい表現は生まれてこないよ。少しくらい想像してみなよ。

28 ：名前は開発中のものです。：2006/09/10(日) 16:36:14 ID:OW1/CPbW

既に透視投影と平行投影を比較検討した上で平行を選んだんだろうし、
それを実現するための質問なんだから>>27の案は受け入れがたいんじゃない？

>>22
OpenGLでもglOrthoとかあるし、ライブラリとしてまとめるなら
用意しておくのが普通のような気がする。俺のような低脳にも使いやすいように。

29 ：976氏の展開：2006/09/10(日) 17:41:37 ID:+2D4JAPB

そうそう。分かりやすさが重要。
３Ｄサルみたいに、リアルならウホウホって低脳だけじゃねーんだよ世の中は。
サルは、ゲーム内容はなんか何でもよくリアル３Ｄなら満足なんだから、いいカモなんだおｗ。

30 ：名前は開発中のものです。：2006/09/10(日) 17:44:20 ID:+2D4JAPB

何故か名前が残ってたｗ

31 ：名前は開発中のものです。：2006/09/10(日) 18:28:13 ID:/HqP+7XA

今度は何で躓いたんだ？恥ずかしがらずに書き込んでみたらどうだ？

32 ：名前は開発中のものです。：2006/09/10(日) 19:46:10 ID:7oN2Z5Lm

>>29
いや、SRPGってさ、なんで全体見渡す必要があるのかさっぱりわからん。
ああいうシステムなのに、ああいう視点のゲームなのもぶっちゃけ理解できない。
戦闘前準備がすべてで目の前の敵を殺せるなら殺したほうがいいよな。
つか、目の前の敵殺さないとこっちがヤバイよね？
だいたいどのゲームでそうでしょ？
ＦＥにしてもＳＦにしてもＦＦＴでもＳＮでもどれもいっしょじゃん。
プレイしてる奴、頭弱いだろｗ
あのゲームで戦略がどうとか言ってるのはよっぽどどうかしてる人でしょ？
ゲームの見所としては移動して行動決定したら後は演出勝負っしょ？
だったら３Ｄ視点のが面白いし可能性は広がってくと思うんだけどなぁ・・・。

ああ、何がいいたいかっていうと今のSRPG作り続けてる奴は
脳みそ化石状態だからあんなんしか作れないだけで
別に考え付いた末の結論ってわけじゃないと思うよ。

33 ：名前は開発中のものです。：2006/09/10(日) 19:53:24 ID:bsqmGzR2

ゲ製作板なんだから、>>32に見本を見せてもらいたい。

34 ：名前は開発中のものです。：2006/09/10(日) 20:00:47 ID:ppKNThgl

ゲ製作板だからこそ手本なんかを要求するのは論外だが。

35 ：名前は開発中のものです。：2006/09/10(日) 20:05:40 ID:/HqP+7XA

まぁ、前スレのログが見れれば確認してみるといいが、
>>29は何も考えてないし、多分もうこのスレに沸く度胸も無いので、
話のネタとしてはいいけど、本気でツッコミ入れる事も無いと思うぞ。

36 ：名前は開発中のものです。：2006/09/10(日) 20:31:38 ID:Ni9A6K9O

>>32
SRPGに何を求めてるかは人それぞれだろ。
そもそもSRPGというジャンルが何を指すかも曖昧だけど。

32が戦闘時の演出を重視するのは勝手だが、
そんな部分に興味がない奴も多いぞ。(DirectXスレで言うのもなんだが。)
グラフィックは世界観や戦闘時の状況を把握するための助けにはなるが、
それ自体のせいでテンポが悪くなったり見づらくなるくらいならいらん、とか。
演出を重視するにしても、ゲーム的、漫画的な表現や
記号化したシンプルなものなど、その方向性は様々で、
必ずしもリアルなものではなくていい。

昔ながらのSRPGが作り続けられているのは、そういうのが好きな人がいるからで、
別にそれに興味ない人が横槍を入れるものではないよ。
演出重視のSRPGがしたければ自分で買うなり作るなりすればよろし。

別にリアルな３Ｄを否定しているのではないよ。そういう方向の技術が進歩すること自体は歓迎。
でも別に皆がそっちを向く必要はない。
DirectXを使って3Dをやるにしても、何もリアルな絵にする方向ではなくて、
ゲームならでは表現なり使用方法なりがあると思う。

37 ：名前は開発中のものです。：2006/09/10(日) 20:40:17 ID:7oN2Z5Lm

>>36
俺はこのままだと普通にSTGの後を辿ると思うけどね。
それに俺が言ってるのは演出重視だけじゃなくて
SRPGが3Dにならんと進化でない類のゲームだからだ。

38 ：名前は開発中のものです。：2006/09/10(日) 20:52:27 ID:7oN2Z5Lm

STGを殺したのは間違いなく、脳みそ化石状態の開発者のせいだと俺は思ってる。
作りたいものを作る、それは勝手だけど。
それをやっていると死んでしまうジャンルが確かに存在する。
要はゲームを進化させない開発者ってのは、昔の開発者の築いた蓄えを食い潰してるだけだと俺は思うけどね。

39 ：名前は開発中のものです。：2006/09/10(日) 20:58:45 ID:5QPW+vii

分かった分かった

40 ：名前は開発中のものです。：2006/09/10(日) 21:04:35 ID:9rYyE7u/

ID:7oN2Z5Lmはゲーサロ逝けよ

41 ：名前は開発中のものです。：2006/09/10(日) 21:08:52 ID:xUi4Ofrs

>>38の考える進化って何？

42 ：名前は開発中のものです。：2006/09/10(日) 21:14:15 ID:7oN2Z5Lm

>>41
まず、単純にゲームに関わってくる情報の量を増やすこと。
これを上手くゲームに取り入れて行くこと。
２Ｄ→３Ｄはこれが一番難しい。

43 ：名前は開発中のものです。：2006/09/10(日) 21:18:12 ID:Ni9A6K9O

>>41
>ああいうシステムなのに、ああいう視点のゲームなのもぶっちゃけ理解できない。
>戦闘前準備がすべてで目の前の敵を殺せるなら殺したほうがいいよな。
>つか、目の前の敵殺さないとこっちがヤバイよね？
>だいたいどのゲームでそうでしょ？
この文章から察するに、
「頭を使うややこしいゲームなんてできないよ。
　僕にも楽しめるように、単純に目の前の敵をやっつける派手なゲームにしてください。」

44 ：名前は開発中のものです。：2006/09/10(日) 21:24:15 ID:3ovxvACH

>>28
>既に透視投影と平行投影を比較検討した上で平行を選んだんだろうし、

アホかｗ
昔はＢＧ面（マップチップ方式）しかないから
苦肉の策でクォータービューやってたんだよ。

完全に自由に３Ｄ表現できる今こそ
新しい表現を開拓してやるぜ！っつー気持ちで頑張れよ！！

45 ：名前は開発中のものです。：2006/09/10(日) 21:32:56 ID:6dtSS5eH

常に新しい方法を使うべきだという考えには賛同できない
それこそ似たようなものばかりになる

46 ：名前は開発中のものです。：2006/09/10(日) 21:38:47 ID:vPeJWa9v

別に趣味なんだから何でも好きにすればいいじゃん。

47 ：名前は開発中のものです。：2006/09/10(日) 21:40:34 ID:3ovxvACH

そりゃアンタの勝手だ。オールドスタイルを好む人もいるからな。

だけどさ、「常に新しい」どころか昔から何も変わってないことに
危機感とか抱かないのか？もしかして開発者じゃない？？

俺は >>23 の素朴な疑問から、新しい可能性を見出したよ。

48 ：名前は開発中のものです。：2006/09/10(日) 21:46:40 ID:3ovxvACH

AGE OF EMPIRES IIIのゲーム画面
http://www.watch.impress.co.jp/game/docs/20050310/age311.htm

けしてリアルなのを薦める訳じゃないんだが、
こっちの視点の方が「さあ行くぜ！！」って気分にならないか？

49 ：名前は開発中のものです。：2006/09/10(日) 21:51:56 ID:6dtSS5eH

＞そりゃアンタの勝手だ。オールドスタイルを好む人もいるからな。
だったら最初から口出しするなと…

平行投影ならではの表現ってのもあるでしょ。
陳腐な発想だが、たとえばエッシャーの滝みたいな不整合を含むマップとか。
リアルな方向"だけ"に進まなくてもいいじゃん。

50 ：名前は開発中のものです。：2006/09/10(日) 21:55:39 ID:ppKNThgl

>>48
そんなのが趣味で作れるわけないだろう・・・

51 ：名前は開発中のものです。：2006/09/10(日) 21:58:47 ID:7JZG++3m

つかおまいの言うリアルなのが、今、多すぎだろ。
で、リアルがゆえに情報量が多くなり、操作仕切れなくなった。
結果、大雑把な操作(自動補正つき)のゲームばかりになった。

今はむしろ、リアルさが本当にゲームとしての面白さに繋がるのかについて、考える時期だろ。

52 ：名前は開発中のものです。：2006/09/10(日) 22:09:29 ID:Ni9A6K9O

>>48
個人的な感想をいってしまえば、「ならない」かなぁ。

おれもリアルなのを否定するわけじゃないから、リアルな表現が進化するのも見てみたい。
それに、ただ見た目が良くなるだけなら進化と呼べるほどのものではないと思うけど、
3Dであることを活かした、従来にない画期的なシステムやルールのゲームが出るなら大歓迎。

>>51
システム的に空間を3次元で扱っても、煩わしさが増えただけっていうのが多いよね。
コンピュータは進化するほど扱える情報が増えていくけど、
受け取る側の人間にはどうしても限界がある。
リアルになったことにより直感的に把握できるようになった部分もあるだろうけど、
むしろ分かりにくい部分も増えたと思う。

2Dであるからこそ、あと1マスが届くか届かないかの葛藤があったり、
たくさんのユニットをまずあーしてこーして次にそーしてとか把握しやすかったり。
将棋や碁なんて見た目はリアルの対極にあるけど、
単純化したゆえの楽しさ、奥の深さはあるからね。

53 ：名前は開発中のものです。：2006/09/10(日) 22:20:54 ID:9rYyE7u/

いい加減スレ違いうざいんだけど。

54 ：名前は開発中のものです。：2006/09/10(日) 22:23:31 ID:3ovxvACH

> けしてリアルなのを薦める訳じゃないんだが、
誰もコレを読んでないから、もうどうでもいいや。

スレ違いスマン。

55 ：名前は開発中のものです。：2006/09/10(日) 22:24:20 ID:wZK1vegR

>>48
９ですが、やはりマスをいじるタイプのSRPGの場合は、
ちょっと見難いかなぁ……という気がしましたけど、
このゲームはRTSなのでこれはこれでイイと思います。
てゆか、やってみてー！

>>51-52
同感です。詰め将棋のような面白さのある
一風変わったSRPGを目指して開発中です。

56 ：名前は開発中のものです。：2006/09/10(日) 22:25:56 ID:LcveiUYj

将棋風ならバンマスということで終了。

57 ：名前は開発中のものです。：2006/09/10(日) 23:16:36 ID:Uo5RLZ/U

じゃぁリアルな将棋だな。駒の表面ばバンプでかつ文字の
くぼみに質感を出さなければならない。もちろん影も。
盤自体も高級感溢れるグラフィックでないといけないな。

58 ：名前は開発中のものです。：2006/09/10(日) 23:56:21 ID:Gh+JFtjs

無意味だな

59 ：名前は開発中のものです。：2006/09/11(月) 00:12:50 ID:tyKTM/Cv

ゲームの存在自体が無意味だけどな。

60 ：名前は開発中のものです。：2006/09/11(月) 00:19:45 ID:ljPU9jqB

い　や　そ　の　理　屈　は　お　か　し　い

61 ：名前は開発中のものです。：2006/09/11(月) 01:59:28 ID:vxGXDMh2

なにがリアルか、という話になる。ベクトルの問題。
昨今のトレンドは物理演算だよ。

62 ：名前は開発中のものです。：2006/09/11(月) 03:03:56 ID:8YY9owEl

まえにマップチップ形式のテクスチャを使う言っただけでゲーム内容まで
気にしてくれた親切な方がまた御光臨されたのか…

63 ：名前は開発中のものです。：2006/09/11(月) 10:03:12 ID:buAXBqZi

ここはゲーム製作技術板なので
技術を語れない妄想厨はお帰りください。

64 ：名前は開発中のものです。：2006/09/11(月) 19:28:57 ID:NTcklCQT

元々厨房隔離板なのにそりゃないぜよ

65 ：名前は開発中のものです。：2006/09/11(月) 20:19:25 ID:NPh7G86R

C#でフォームとは別のスレッド作ってメインループをまわしてます。
そのスレッドからDirect3Dを初期化するためにDeviceのコンストラクタで
フォームの参照かハンドルが必要なわけですが
そのまま渡すとお止まりになられます。

どうすればいいですか？

66 ：名前は開発中のものです。：2006/09/11(月) 21:48:25 ID:uDY7T58a

>>52
>システム的に空間を3次元で扱っても、煩わしさが増えただけっていうのが多いよね。
それは作り手がちゃんと詰める部分なんだよ。
じゃあ、聞くけど、それは３Ｄゲーム全般に言えることで全てのゲームにおいて
２Ｄの方がわかりやすくて面白かった？
で、ＳＲＰＧに関しては３Ｄにしておもしろくなる可能性は０だと言い切りたいの？
ここまで言えるなら君のいうこともわかるんだけど。
あくまでも「そんな気がする」程度なんでしょ？

>2Dであるからこそ、あと1マスが届くか届かないかの葛藤があったり
え？３Ｄにするとそれってなくなっちゃうの？

67 ：名前は開発中のものです。：2006/09/11(月) 21:49:23 ID:SzRE5oyo

まだやってるの？

68 ：名前は開発中のものです。：2006/09/11(月) 21:57:23 ID:uDY7T58a

>>67
気に入らないならこなくてもいいんですよｗ

69 ：名前は開発中のものです。：2006/09/11(月) 22:04:11 ID:fODc5yBf

全角英数字使う自称プログラマは、なぜこういう奴ばかりなんだろうｗ

70 ：名前は開発中のものです。：2006/09/11(月) 22:05:22 ID:uDY7T58a

>>69
アンカーも付けられないクズに言われたく無いなｗ

71 ：名前は開発中のものです。：2006/09/11(月) 22:06:00 ID:fODc5yBf

>>70
おや、誰も君とは言ってないよｗ

72 ：名前は開発中のものです。：2006/09/11(月) 22:07:54 ID:uDY7T58a

>>71
おっｗアンカーつけられるんじゃんｗ
柔軟性があるのはいいことだよ。

73 ：名前は開発中のものです。：2006/09/11(月) 22:09:17 ID:fODc5yBf

>>72
だから君に言ったんじゃないって。何故アンカー付けなきゃなのよｗ
それとも何かご自覚でも？

74 ：名前は開発中のものです。：2006/09/11(月) 22:11:49 ID:uDY7T58a

>>73
お、でも、アンカーつけてんじゃんｗ
アンカーの何がいいのよｗ

75 ：名前は開発中のものです。：2006/09/11(月) 22:14:10 ID:fODc5yBf

何言ってるかわかんねｗ
なんだよ「アンカーの何がいいのよ」って

何がよいって言われてもｗ

76 ：名前は開発中のものです。：2006/09/11(月) 22:16:58 ID:uDY7T58a

>>75
アンカーも付けられないクズに言われたく無いなｗ

77 ：名前は開発中のものです。：2006/09/11(月) 22:18:01 ID:fODc5yBf

>>76
アンカーの何がいいのよｗ

78 ：名前は開発中のものです。：2006/09/11(月) 22:35:37 ID:uDY7T58a

>>77

79 ：名前は開発中のものです。：2006/09/11(月) 22:39:54 ID:fODc5yBf

おせーんだよ、折角テンポ良かったのに
しかもこんなレスかよ、がっかりだ
20分近く考えてこれかよ、お前アフォだろ！

80 ：名前は開発中のものです。：2006/09/11(月) 22:51:09 ID:QS09L3WT

すげー盛り上がって参りました！！！！

81 ：名前は開発中のものです。：2006/09/11(月) 23:41:07 ID:CSTnIdUN

もう、アンカ～んは、こりゃ

82 ：名前は開発中のものです。：2006/09/11(月) 23:58:30 ID:8YY9owEl

こんな馬鹿にいいように釣堀にされるなんて…くやしい…！

83 ：名前は開発中のものです。：2006/09/12(火) 00:34:24 ID:FahvW97U

でも…

84 ：名前は開発中のものです。：2006/09/12(火) 00:51:15 ID:xJzpylpk

初めてなのに釣れちゃったー

85 ：名前は開発中のものです。：2006/09/12(火) 00:57:19 ID:FaiBXBLM

趣味で作るなら好きなようにやればいいじゃまいか。

トレンドだとか流行だとかコストがどうとか政治がどうとか
納期が云々、人件費があーだこーだは仕事だけでいい。

86 ：名前は開発中のものです。：2006/09/12(火) 01:28:13 ID:2yKCqHR4

>>65
そもそもDirect Graphicsがフォームとは別のスレッドでDeviceを初期化できるように設計されてない。
どうしてもスレッドを分けたいなら初期化はフォームと同じスレッドでやって、
できたDeviceのインスタンスをメインループに渡すしかない。
ただし、Device.Resetとかもフォームと別スレッドでは実行できないので
フォームのメッセージ処理でデバイスの状態を監視するなど注意深く設計する必要がある。

ちなみに別スレッドから呼んじゃいけないメソッドはヘルプに書いてある。
（プログラミングガイド＞プログラミングのヒント＞マルチスレッド処理の問題）

87 ：名前は開発中のものです。：2006/09/12(火) 06:59:37 ID:lWcblcs9

>>86のように軌道修正してくれる人も大好きですが
>>66-80のようなネタとマジのギリギリのラインでヤり合う流れも大好きです
あとDirectXも大嫌いです

88 ：名前は開発中のものです。：2006/09/12(火) 10:34:31 ID:kEfRVLLO

Form.Invokeでハンドル取り出してDeviceに渡したら動きました

89 ：名前は開発中のものです。：2006/09/12(火) 13:19:37 ID:bJAlhOwc

|дﾟ)ｿﾉﾊﾞｼﾉｷﾞ

90 ：名前は開発中のものです。：2006/09/13(水) 03:09:54 ID:ZA9WaHkU

動けばいいんじゃね

91 ：名前は開発中のものです。：2006/09/13(水) 17:11:09 ID:l7pK8U19

師曰く、
｢動けばいいってレベルでいいなら、動かなくてもいい｣

92 ：名前は開発中のものです。：2006/09/13(水) 20:48:14 ID:XgUJHN5F

3DRPGなんかで凹凸のある地面を歩かせる方法が分かりません。
自分で考えたところ、
地面をマス目で区切って、そのマス目に対応する配列を作って、
その配列に地面の高さを保持させて処理するという方法しか思いつきません。
DirectXでゲームを組んでいる場合、これくらいしか方法はないのでしょうか？

93 ：名前は開発中のものです。：2006/09/13(水) 21:12:01 ID:MZEQSGxt

下向きのベクトルと地面のポリゴンとの交点を求める。

94 ：92：2006/09/13(水) 22:09:02 ID:XgUJHN5F

>>93
なるほど！
下向きのベクトルは思いつきませんでした。
ありがとうございます。

95 ：名前は開発中のものです。：2006/09/13(水) 23:28:07 ID:UjlUEnmr

それがわからないでいて>>92を実現する方法とはいかに？

96 ：名前は開発中のものです。：2006/09/14(木) 00:03:40 ID:v5pi7Ixf

配列で細かく高さデータもっておいて、補間するんだろ。
データ量が恐ろしいことになりそうだけど。

97 ：名前は開発中のものです。：2006/09/14(木) 00:49:03 ID:Ff9nq8u9

でもそれだけじゃ、螺旋階段とかゼルダトキオカみたいなのは無理じゃん。
地面だけじゃなくて、立体的にさ。
基本的に、フィールド用ポリゴンと、小障害物オブジェクトと、
キャラクターオブジェクトがあって、
フィールド用は、３次元配列の判定メモリを使用し、
その他のは、キャラクタとの距離から、判定し、
その後に、ポリゴンとの接点を判定する。
キャラクタの場合は、点との判定で、剣とかも点で、

98 ：名前は開発中のものです。：2006/09/14(木) 02:58:37 ID:18nXvM/N

＞フィールド用は、３次元配列の判定メモリ
　
なにそれ。3D格子（3Dグリッド）のこと？
どれぐらいの詳細度で扱うのか知らんが
トキオカ風の地形を1[m^3]で区切って
それを人間の手で作るのはかなり手間なんだけど。

99 ：名前は開発中のものです。：2006/09/14(木) 03:06:07 ID:18nXvM/N

フィールドとの衝突判定なら
ハイトフィールドで十分じゃん。

100 ：名前は開発中のものです。：2006/09/14(木) 07:02:01 ID:vKnmoDkw

>>97
俺はそんなことやらんでもほとんどハイトフィールドの応用で足りると思うんだがな。
っていうかアルゴリズムの違う足場ってバグり易いから作らないほうがいいぞ。

101 ：名前は開発中のものです。：2006/09/14(木) 08:24:47 ID:IA3nRmrP

階段はオブジェクトにする。
衝突判定しないで動作はキー操作によるシーケンスで。
ってのはどう？

102 ：名前は開発中のものです。：2006/09/14(木) 21:56:26 ID:Ff9nq8u9

>>99
だからそれだと、螺旋階段とか立体ダンジョンとか、できないだろ。

103 ：名前は開発中のものです。：2006/09/14(木) 22:22:49 ID:4HfKE9vQ

オブジェクト同士の当たり判定ってザツでも良ければ何とでもなるけど
マップの判定ってちょっと悩むよな
俺はもう諦めて平面で作ることにしたけど

まぁ地道に勉強してればいつか解説本を読んでストンと腑に落ちることもあるさ
多分

104 ：名前は開発中のものです。：2006/09/14(木) 22:33:39 ID:9eIOr1K4

キャラが直前まで居たY座標も考えてやればレイが交差した床板に上るかぶつかるかくぐるか決められるよ～

105 ：名前は開発中のものです。：2006/09/14(木) 23:22:52 ID:vKnmoDkw

>>102
現在アクティブな（そのキャラにとって）ハイトフィールドを決めて「つなぎ」の部分だけ
処理すんのが一番楽だろうが。
螺旋っていったって局所でみれば普通の足場だろが。

階段なんかオブジェクトにしちまうと「抜け」で無駄に悩むぞ。
この辺、ゲームのたびにぶち当たるけど、足場はハイトフィールドの応用が一番強固でいいと思う。
やっぱなにより抜けないし、マス目細かくすることで応用が効くし。

106 ：名前は開発中のものです。：2006/09/14(木) 23:25:09 ID:UH4wYhXW

螺旋階段や立体ダンジョンなら、複数枚の縦に重なる部分が無いようなマップに切り分けておいて
しかるべき場所（高さで判定とか）でそいつらを切り替えればいいんじゃん？

107 ：名前は開発中のものです。：2006/09/14(木) 23:32:08 ID:Ff9nq8u9

>>105
螺旋階段の下に潜った場合、上の螺旋階段との壁の判定はどーやるわけ？？

108 ：名前は開発中のものです。：2006/09/15(金) 00:19:59 ID:GAaooVvp

地面にオブジェクトの影を落としたいんですが、どうやればいいのですか？
影といっても、オブジェクトの下に黒い●が出るだけでいいです
地面が平面ならオブジェクトの真下に●のテクスチャはった面を表示するだけだったんですが
凸凹だとバレバレです

109 ：名前は開発中のものです。：2006/09/15(金) 00:21:39 ID:ckWHetJA

高さに関してはハイトフィールドで螺旋階段も問題ないでしょ。
プレイヤーの腰当たりからレイ飛ばして、一番Ｙの高い位置で判断すればいいし、
隣接ポリゴンのリスト持っておいて自分の周囲ある程度のポリゴンしか判定しなければいいし。

ＸＺへの移動に関してはどっちみち別途コリジョンをもっておかないと柵とか対応できない。
法線方向見て片方からは通れるようにすれば崖とか階段の下とかも問題なす。

110 ：名前は開発中のものです。：2006/09/15(金) 00:26:20 ID:jCDKRfUj

>>108
普通に浮かせたり、傾けたり・・・
それ以上やるとゲームに影響がでるぐらい凝らなきゃならんけど？やる？ｗ

しかし、影の処理ってどれもアホかってほど重いな。
やんねーよ。こんなの。ってのでデザイナさんとも一致した。

111 ：名前は開発中のものです。：2006/09/15(金) 00:29:03 ID:T4MgT/q6

>>109
>隣接ポリゴンのリスト持っておいて自分の周囲ある程度のポリゴンしか判定しなければいいし。
だからその時点で、ハイトフィールドじゃないじゃん

112 ：98：2006/09/15(金) 00:35:02 ID:BE5Xhsow

>>102
>>107
ん？螺旋階段（建造物）もフィールド（地形）と同じ扱いなのか？
俺がレスした>>97は
「フィールド用ポリゴンと、小障害物オブジェクトがあって」
と区別してたから、螺旋階段は後者（オブジェクト）だとばかり。

113 ：名前は開発中のものです。：2006/09/15(金) 00:38:39 ID:ckWHetJA

>>111
ん？そうか？
単に判定するポリゴンを刈る為の処理のつもりなんだが。
いくらなんでも広大なフィールドの全ポリゴンを毎回判定するわけでもあるまい。

114 ：名前は開発中のものです。：2006/09/15(金) 00:40:15 ID:BE5Xhsow

>>109
それは「ハイトフィールド」じゃなくて
「ハイトフィールド上にオブジェクト置いてる」状態と桃割れ。

115 ：名前は開発中のものです。：2006/09/15(金) 00:41:36 ID:jCDKRfUj

>>114
いや、普通に、ハイトフィールドじゃん。

116 ：名前は開発中のものです。：2006/09/15(金) 00:53:55 ID:+fPG+udD

どっちでもいいやろ

117 ：98：2006/09/15(金) 00:56:09 ID:BE5Xhsow

>>115
ん？ハイトフィールドの定義から確認していいかな？
2D格子の標高データということで宜しいかな？
　
で、どういう螺旋階段をイメージしてるのか知らんけど
例えば円筒状構造物内にぐるぐる階段を設けたものでいいかな？
こういう建造物を無理矢理ハイトフィールドでやんのか？

118 ：名前は開発中のものです。：2006/09/15(金) 00:57:18 ID:jCDKRfUj

まあ、定義はどうでもいいけど、ハイトフィールドっぽい仕組みを
駆使して螺旋階段も立体交差も作れるし、これが一番安全だし、
これ以外でやるとそれなりに大変になると言っておく。

ただ、FZEROとかソニックは難しいかもしんないな。

119 ：名前は開発中のものです。：2006/09/15(金) 00:59:55 ID:9nX1gLbg

難しいってのはループのことかね
それはまた別の方法を考えるべき屋根

120 ：名前は開発中のものです。：2006/09/15(金) 00:59:55 ID:jCDKRfUj

>>117
そうそう。
できるじゃん。
よく考えてよ。
螺旋階段を辿るようにぐるっとつないでいけばいいだけじゃん。

121 ：名前は開発中のものです。：2006/09/15(金) 01:05:44 ID:9nX1gLbg

最初スーファミのF-ZEROとメガドラのソニックしか思い浮かばなくて
何の事だかわからなかったのはオジサンだけの秘密だ。

122 ：98：2006/09/15(金) 01:24:39 ID:BE5Xhsow

>>118
まさか、1[cm]単位みたいな高密度の標高データを
複数レイヤーで持てとか言うんじゃねーだろうなー。
　
格子状に配置された標高データだと表現力に自由度ないから
無理矢理密度を上げて対応してんのか？
　
俺は螺旋階段みたいな変な形状の建造物は衝突判定用モデルを用意してるよ。
この場合なら直立した中空シリンダーの中に階段のOOBBを敷き詰めて終わり。

123 ：名前は開発中のものです。：2006/09/15(金) 01:39:26 ID:BE5Xhsow

×1[cm]単位みたいな高密度の標高データを
○1[cm^2]単位みたいな高密度の格子を

124 ：名前は開発中のものです。：2006/09/15(金) 02:07:22 ID:tWOUPt7e

>>118
なんでそんな脅してまでハイトフィールドを奨める…何かに取りつかれてるのか

125 ：名前は開発中のものです。：2006/09/15(金) 06:09:31 ID:W8QvwaGa

ハイトマップなんてほんとにベタベタな地面にしか使わねーよ普通。
トンネル掘るのもめんどくせぇし、建造物はStaticMeshで当たり前。
UnrealEngineはハイトマップの使い方上手いけどな。

126 ：名前は開発中のものです。：2006/09/15(金) 06:19:06 ID:jCDKRfUj

>>122
はぁ？なんでそんなことになるの？
マジで頭悪いの？

127 ：名前は開発中のものです。：2006/09/15(金) 06:27:31 ID:jCDKRfUj

>>122
螺旋階段を辿るようにつないでいくって言ってるだろ。
脳みそ腐ってんのか？
つか、お前、人の話聞かないし、馬鹿だから余計なことばっかりやることになるんだぞｗ

128 ：名前は開発中のものです。：2006/09/15(金) 08:30:34 ID:nV4yrdwW

階段なんて衝突判定もなにもせず計算で動かせばいい
法線方向はリミットつければいい

129 ：名前は開発中のものです。：2006/09/15(金) 12:28:13 ID:nr8K/tjp

いちいちうるせぇな。
つべこべ言わずにハイトフィールド使えっつってんだろうが。
俺の言うことが聞けねぇってのか？

130 ：名前は開発中のものです。：2006/09/15(金) 14:17:30 ID:T4MgT/q6

こんなことだからmixiに負けるんだお

131 ：名前は開発中のものです。：2006/09/15(金) 16:44:30 ID:tWOUPt7e

んじゃぐだぐだになってきたところで地形関連ということでひとつ
ほとんどの3Dのゲームは壁に当たってなお直進すると壁にそって微妙に横にすべるような動きをしますよね
あれって業界内で統一されたデザインとしてわざわざあのような動きをするようにしているんでしょうか
それとも典型的な壁との衝突時の処理の副作用としてあのようになっているんでしょうか
DOOMは壁をこすりながら走って加速できるバグがありました
MMORPGとかでは進めなくなった時点で歩行をやめちゃう駄目仕様なものも結構あります
そこらへんみなさんどうしてますか？

132 ：名前は開発中のものです。：2006/09/15(金) 17:10:01 ID:fW5L3y+Q

壁に接触するたびに足が止まるとストレスになるから
わざわざそういう風に作ってあるんだろう

当たり判定壁ずりで検索すると解説してるサイトもある

133 ：名前は開発中のものです。：2006/09/15(金) 17:49:16 ID:W8QvwaGa

漏れの場合球コリジョンで判定してヒットした壁の面法線方向に
めり込んだ分（球の半径-中心から壁平面への距離）戻してるから
勝手に壁ずりする。

134 ：名前は開発中のものです。：2006/09/15(金) 20:38:46 ID:tWOUPt7e

>>133
ぐぐってでてくる壁ずり講座のが色々とあまり美しくない工夫をしてるのに対して
それだとすごい自然だなぁ
やっぱり見た目のメッシュとは別に当たり判定用のバウンディングボックスを設定するんですか

135 ：名前は開発中のものです。：2006/09/15(金) 20:44:11 ID:ghhBc9kZ

球コリジョンって書いてあるような

136 ：名前は開発中のものです。：2006/09/15(金) 21:46:10 ID:jCDKRfUj

>>134
俺は検索かけたら真っ先に>>133の方法が出てきたが・・・

137 ：名前は開発中のものです。：2006/09/15(金) 22:45:06 ID:T4MgT/q6

コリジョンである。
コリジョンっていう言葉のイメージは、
まるまるとしてて、つっかかりが無いが、ゲドゲドしたもの。
という感じである。
これを表している物は、丁度、キウイフルーツである。
あの、丸々としてるくせに、表面がジョリジョリと気持ち悪いそれである。
また、親父のジョリジョリした髭がそれである。
あの、短い髭によって摩擦が減少してるのに、ジョリジョリされると痛いあれである。
つまり、コリジョンとは、ジョリジョリが痛い親父の髭。という意味なのである。

138 ：名前は開発中のものです。：2006/09/15(金) 22:50:28 ID:lVw+0F2q

ちがうよ。コリジョンて犬のことだろ。

139 ：名前は開発中のものです。：2006/09/15(金) 23:01:55 ID:fW5L3y+Q

信号が失われたときに再送するべき範囲のことだっけ

140 ：名前は開発中のものです。：2006/09/15(金) 23:05:30 ID:zpKEoHaz

>>133
適度にブレーキがかかって具合がいいんだよな（ ´∀｀）

141 ：名前は開発中のものです。：2006/09/15(金) 23:42:45 ID:694NBURy

VIPのバカが釣りにはしゃいで喜んでいます

女子大生拉致監禁事件！？12くらい
http://ex16.2ch.net/test/read.cgi/news4vip/1158323954/

「どう見ても釣りだろ」
というと顔を真っ赤にしてレスしてくるので注意！！！

142 ：98：2006/09/16(土) 00:24:55 ID:ybUsKN1J

>>126-127
なんで火病ってるの？
　
でさ、お前の使ってるのって本当にハイトフィールドなの？
俺、>>117でハイトフィールドの定義を確認したよな？
これに対して君は>>118で「まあ、定義はどうでもいいけど」とか
はぐらかしてたけど、なんでかな？違うなら違うって言えよな。

143 ：名前は開発中のものです。：2006/09/16(土) 00:29:49 ID:ybUsKN1J

ハイトフィールド（ハイトマップ）の基本的定義は
「XZ平面の格子点上でY(高さ)データをサンプリングした2D配列」
　
この定義で螺旋階段を表現しようとすると無理があると>>122-123で言っている。
層状の地形であるから多段でハイトマップ用意することになる。
階段は放射状に配置されている格子点サンプリングでは
うまく再現できない。高密度でサンプリングしてガタガタを減らすしかない。
　
例外的に、極座標系でサンプリングするなら高密度でなくて済むが
螺旋階段だけのためにわざわざ特例的な座標変換かますってどうよ。

144 ：名前は開発中のものです。：2006/09/16(土) 00:30:35 ID:ybUsKN1J

×階段は放射状に配置されている
○階段は放射状に配置されているから

145 ：名前は開発中のものです。：2006/09/16(土) 00:33:23 ID:ybUsKN1J

ゼルダトキオカ風のアクションゲーム用のレベルデータなら
洋物FPSのそれと相違点は少ないだろ。この手のレベルエディタなら
エンドユーザでも触れるし、レベルデータも見放題。
螺旋階段は厚みのある板を折り重ねて階段を作ってたりする。

146 ：名前は開発中のものです。：2006/09/16(土) 00:40:15 ID:+w/URioF

っつーかさ、螺旋階段とか立体交差ができないからって
ハイトフィールド使えねーってのは短絡すぎね？

そういう制限があるけど、実装が簡単だからって薦めて終わりにしねえ？

147 ：名前は開発中のものです。：2006/09/16(土) 00:43:32 ID:ybUsKN1J

「ハイトフィールド使えねー」なんて誰も書いてないと思うぞ。

148 ：名前は開発中のものです。：2006/09/16(土) 00:47:30 ID:kI4OWMBC

まえ、ベクターで灰とフィールドを使った３Ｄゲーダウンした。
なるほど、高低差が表現できてるな。ってのは当たり前なんだし、
バカっぽい印象があったな。灰とフィールド。

149 ：名前は開発中のものです。：2006/09/16(土) 00:56:03 ID:LjBp93/T

>>143
無理じゃないよ。
自分の常識に勝手にとらわれてるだけじゃん。
定義はそれでいいよ。
「XZ平面の格子点上でY(高さ)データをサンプリングした2D配列」

普通に四角形つないでいくだけで螺旋できるだろ
いや、螺旋なんていうからよけいややこしくなるのか？
じゃ、上からみて円状の道が表現できればそれの連続で螺旋は表現できるよな？ＯＫ？

　　□□□
　□　　　　□
□　　　　　　□←Start
□　　　　　　□←End
　□　　　　□
　　□□□

例えば↑こんなんでどうだ？（ずれないかな？ｗ）
ちなみにこの□の１つ１つがハイトフィールド。
（格子の大きさはそれぞれで調節できる。でも、大抵は一定。ＸＺで矩形のヒットを確認した後でＹの計算に移る）
イメージわいた？ｗ
まあ、これは俺の方法だけど。（他の方法もあるかもしれんけど）

150 ：名前は開発中のものです。：2006/09/16(土) 01:08:20 ID:kI4OWMBC

>>149
それは螺旋階段じゃなくて、リングみ見えるお

151 ：名前は開発中のものです。：2006/09/16(土) 01:11:27 ID:LjBp93/T

>>150
上からみた図って言ってるだろ。
標高データはあんだからＸＺ上でつながりゃＯＫでしょ。

152 ：名前は開発中のものです。：2006/09/16(土) 01:31:05 ID:7TFzm038

何でそんなムキになってるんだ

153 ：名前は開発中のものです。：2006/09/16(土) 01:37:00 ID:LjBp93/T

だってすげー馬鹿なんだもん。
俺が専門行ってた頃のまわりもアフォはアフォだったけど、
ここまで頭固いのか馬鹿なのか知らんけど、そういうのいなかったし。
会社入ってからはアフォなのいなかったからね。ストレス溜まるよｗ

154 ：名前は開発中のものです。：2006/09/16(土) 01:51:12 ID:ybUsKN1J

>>149
螺旋階段ごときでこんなに細かくハイトフィールドを分割・配置すんのか。
これ、階段の一段につきディスプレースメントマップ一枚の間違いじゃね？ｗ

155 ：名前は開発中のものです。：2006/09/16(土) 02:00:00 ID:LjBp93/T

>>154
細かくってそんな情報どこにもないけど？
別に格子の大きさなんて大雑把に配置してもいいんじゃね？

>これ、階段の一段につきディスプレースメントマップ一枚の間違いじゃね？ｗ
何言ってるのかさっぱりわからない。

156 ：名前は開発中のものです。：2006/09/16(土) 02:08:54 ID:ybUsKN1J

>>154
いや、細かくってのは「□」の個数。
一回りするのに14個のハイトフィールドが要るんだろ？
各ハイトフィールドの解像度はどれぐらいなんだ？
それで何段ぐらいの階段を表現してる？

157 ：名前は開発中のものです。：2006/09/16(土) 02:10:06 ID:+w/URioF

>>149
> ちなみにこの□の１つ１つがハイトフィールド。
１つ１つがハイト情報ってことだろ？
それの「１つ１つがハイトフィールド」って言ってるんだから
細かく分割するって解釈されても文句言えねーよな。

っつーか、>>149 の言う螺旋階段って、１周しかできてないだろ？
それなら誰だってできること知ってるよ。
ハイトフィールドでは何周もする螺旋階段ができないって話なんだが。

158 ：名前は開発中のものです。：2006/09/16(土) 02:15:14 ID:ybUsKN1J

＞１周しかできてないだろ？
いや、それは一週分のハイトフィールドの実体さえ用意すれば
あとは繰り返し実体を参照でしかないわけで。
　
例えば「□」はAABBで、ハイトフィールドへの参照を内包みたいな。

159 ：名前は開発中のものです。：2006/09/16(土) 02:15:45 ID:+w/URioF

>>147
>>97 >>102 >>107

またスレ違いなので、そろそろ本気で止めとけ。

160 ：名前は開発中のものです。：2006/09/16(土) 02:20:36 ID:LjBp93/T

>>156-157
はぁ？マジでアフォなの？
細かさなんてそんなの作る奴が勝手に決めりゃいいじゃん。
ていうか、作る奴が決めるしかないじゃん。
自分の質問がそういうことをいってることがわからないほど頭悪いの？

>っつーか、>>149 の言う螺旋階段って、１周しかできてないだろ？
お前に関しては、死ね。
応用力なさすぎ。ゲームＰＧなんて辞めちまえよ。

161 ：名前は開発中のものです。：2006/09/16(土) 02:30:25 ID:x7V8Yxct

まあハイトフィールド厨は実際にゲーム作った事ないんだろ。
地面をハイトマップで作って建造物をメッシュで表現するのが最も一般的。
バカとハサミは使いようというか、適材適所。
スレの流れ通りの実装をするならメッシュより超絶メモリ喰うし、
モデラーにさくっとメッシュ作ってもらった方が断然良い。

応用力とか言いながら無駄な努力。
ゲームに限らずPG向いてないよ。

162 ：名前は開発中のものです。：2006/09/16(土) 02:30:43 ID:ybUsKN1J

＞細かさなんてそんなの作る奴が勝手に決めりゃいいじゃん。
　
あぁ、そうだ。主観の相違だよ。
ハイトフィールドの数だけ空間分割してるわけで、一周に14分割なんて
データ作る奴が可哀想だよ。描画用の螺旋階段の静的メッシュ一個作って
それに対応する衝突判定はハイトフィールドだよ。しかも超分割。
　
「螺旋階段ごとき、階段一段につきボックス積み重ねれば終わりだろがよ。」

163 ：名前は開発中のものです。：2006/09/16(土) 02:32:05 ID:+w/URioF

>>160
一般的なハイトフィールドで螺旋階段できないって話してる時に
応用とかあり得ねえ。そんなこと言ったらなんでもアリだろｗ

ｵﾒｰは書き込みを止めろ。全然伝えられてないしスレ違い。

164 ：名前は開発中のものです。：2006/09/16(土) 02:32:14 ID:hvflG0jI

作りたいゲームにあったアルゴリズムを使えばいい。
ハイトフィールドで苦手な螺旋階段をどうしても使いたいなら、
素直にハイトフィールド以外で妥当なアルゴリズムを使えばい。
( ﾟДﾟ)ﾏﾝﾄﾞｸｾｰから俺はだいたいオクトツリー＋コリジョン用モデルで済ませちまうけど。

そして>160の必死さに乾杯。

165 ：名前は開発中のものです。：2006/09/16(土) 03:28:26 ID:kI4OWMBC

１６０の言うのは、
ソケット７用ママンで、ソケット３７０ＣＰＵを使うという話だ。
その為には、ＰＣＩに拡張ボードのせてできるぞ！って言ってるんだ。
何でもありということなんだ。

166 ：名前は開発中のものです。：2006/09/16(土) 04:17:31 ID:fgX/VehA

3Dって倍率変えればどんなサイズでもいけるんだけど
標準的なキャラクタの大きさ（身長）って
（ゼルダとかのアクションタイプの場合）
どのくらいがいいんでしょうか？

167 ：名前は開発中のものです。：2006/09/16(土) 06:33:25 ID:x7V8Yxct

>>166
そんなもんどのくらいのスケールで処理したいのかによって変わるだろ。
座標単位÷仮想距離が小さくなるほど桁落ち誤差が酷くなってく。
座標の精度がfloatでマップの広さが数百メートルくらいなら
1.0=10cmくらいでいんじゃね？
あとはモデリングツールで扱いやすいサイズを考えるとかな。
まあどのみちデータ吐き出す時にスケールかけりゃいいだけの話なんで
作りやすいように作って問題が出たら変えりゃいいとおも。

168 ：名前は開発中のものです。：2006/09/16(土) 10:22:52 ID:LjBp93/T

>>161
はぁ？どこまで想像力ないの？
今回のレスにしたってちょっと突けば矛盾がボロボロ出てきそうな
糞レス返しやがってアフォにもほどがある。
だいたい、メッシュなんてどんだけ無駄な手間かけてんだ？ｗアフォｗ
デザイナが作ったメッシュってことは抜けの処理全部手作業で確認すんだぞｗ
しかもメッシュなんて判定が遅い。小粒なオブジェクトを散りばめたら速度的に不安が残る。

レスがみえないけど、あんまり馬鹿過ぎて話しにならないID:ybUsKN1Jはすでに
ＮＧワードなのでレス書いても無駄だからｗ

169 ：名前は開発中のものです。：2006/09/16(土) 10:30:40 ID:TjFd2Nn1

＞ID:LjBp93/T
もー少し冷静になれないものかなあ。
大人気無さ過ぎるよ。

170 ：名前は開発中のものです。：2006/09/16(土) 10:46:53 ID:u5V7+KW3

まぁ、プログラミングのレの文字も知らない単なる馬鹿なんだろ

171 ：名前は開発中のものです。：2006/09/16(土) 10:59:39 ID:YbNpH6OY

例えば街中で喧嘩をしてて仲裁されたとき
「俺の方が正しいのに何で止めるんだ！」ってさらにヒートアップしそうなタイプですか？

別にどういう結論を出しても構わないけど、
周囲がドン引きなのでできればこの辺で止めて頂けるとありがたいです

172 ：名前は開発中のものです。：2006/09/16(土) 11:39:58 ID:HePrFJJe

LjBp93/Tの人気に嫉妬

173 ：名前は開発中のものです。：2006/09/16(土) 11:55:43 ID:C7x/sWme

夏休みってまだ続いてたっけ？

174 ：名前は開発中のものです。：2006/09/16(土) 12:02:24 ID:0yBawA0+

大学はまだ休みかも

175 ：名前は開発中のものです。：2006/09/16(土) 12:33:37 ID:ZeKYkttp

いくらなんでも中学生より上ってことはねーだろｗ

176 ：名前は開発中のものです。：2006/09/16(土) 13:40:21 ID:W9eJQBmZ

口調はさておき、内容はどっちもどっちって気がするが

177 ：名前は開発中のものです。：2006/09/16(土) 14:04:54 ID:7TFzm038

どっちにしても面使ってるからねｗ
XZ情報からYを取り出すに変わりない

178 ：名前は開発中のものです。：2006/09/16(土) 15:11:15 ID:x7V8Yxct

>>168
＞ちょっと突けば矛盾がボロボロ出てきそうな
どうぞ突いてみてください。きそうなだけで出てこないでしょ？

＞メッシュなんてどんだけ無駄な手間
の具体例が
＞抜けの処理全部手作業で確認すんだぞ
とありますが、ハイトフィールドを使ってもデータに不備がないかを
確かめる作業は必要ですよね。
ハイトフィールドは自分で作るから絶対間違ってないというスタンスですか？
しかもゲーム中の見た目と実際のデータに視覚的な関連性がないので
ぱっと見て間違いに気づきにくいでしょうね。

＞しかもメッシュなんて判定が遅い
ご自分の技術力がないのを自慢されなくても結構ですよ。

＞小粒なオブジェクトを散りばめたら速度的に不安が残る
ハイトフィールドだって細かく分割して解像度上げていけば
速度的な問題はでてきますよね。メッシュだから起きる問題じゃありません。

ちなみにしつこく食い下がってるのはLjBp93/Tを改心させたいわけじゃなくて
何も知らない初心者がLjBp93/Tみたいなロートルに騙されないように
LjBp93/Tがどれだけ無茶苦茶な事を言ってるか指摘しているだけですので。

179 ：名前は開発中のものです。：2006/09/16(土) 15:25:14 ID:LjBp93/T

>>178
作って無いのバレバレ。
ハイトフィールドは普通にポリで出せるし、
何より格子状だから範囲さえあっていれば完璧に抜けがない。
それに対して、デザイナにメッシュこさえてもらったものは
そもそも抜けを確実に無くすのはほぼ不可能。実際に抜けないことをプログラムを実行させて確かめるしか無い。
範囲がちょっと広くなるだけで抜けを探すだけで膨大な時間が必要となる。
実現できるにしても数をこなすことを考えるとあまり実作業には向いていない。
１ステージチェックするだけでかなりの時間が必要になる。
ま、そうやって作ってるプロジェクトもあったから、駄目というわけではないんだろうけど。俺は奨めない。

>ハイトフィールドだって細かく分割して解像度上げていけば速度的な問題はでてきますよね。
はぁ？
メッシュを散りばめて判定するのと、複数あるハイトフィールドのどれとヒットしてるか探す処理を比較してそんなこと言ってるの？
アフォ過ぎ。比較にならない。

180 ：名前は開発中のものです。：2006/09/16(土) 15:46:25 ID:mhwk2PCU

よーく、冷静に考えるんだ。
問題は既にハイトフィールド云々という次元を遥かに凌駕している。

　これはどちらが最後に書き込みをするかっ！！！

という超超高次元な問題に遷移しているのだ。
この場合書き込みの内容は無視して構わない。
あくまでどちらが最後に書き込みをするか。この一点で勝負は決まる！

181 ：名前は開発中のものです。：2006/09/16(土) 15:50:38 ID:j5vuvrOR

煽り立てるなっつーの！

182 ：名前は開発中のものです。：2006/09/16(土) 16:08:04 ID:NbVPi73v

>>179
まぁなんだ、ツールの段階でポリゴンに隙間がなければ
コリジョンが抜けるなんて事はないんだよ。

抜けるとしたらそれはそれで興味あるアルゴリズムだな・・・

183 ：名前は開発中のものです。：2006/09/16(土) 16:11:17 ID:z4sCHZfB

隙間があったらシャドーボリュームすら作れなくなるぞ。
いったいどんな馬鹿なモデルデータを使ってるんだ？

184 ：名前は開発中のものです。：2006/09/16(土) 16:49:39 ID:LjBp93/T

>>182-183
データの問題もあるけどチェックの仕方にもよると思うね。
隣接する多角形をちゃんとくっついてるものと保障する構造を作るのが面倒だと思うけどな。
例えば、三角形Ａとそのとなりに三角形Ｂがあるんだけど、
判定してみたら誤差の問題かアルゴリズムに抜けがあるかでその両方の三角形に偶然ヒットしなかったと。
でも、モデル的にはその２つはくっついてて、境界でも必ずそのどちらかにヒットするはずなんだけど
どっかで抜けが発生してしまう。と。
俺がデザイナの作ったメッシュデータで判定をしてたときに面倒だと思ったのはこんなところだね。
しょうがないから隣接情報を三角形ごとにもたせたけど、手間だし、無駄だと思うな。

それに対してハイトフィールドは別に隣接情報を持たなくていいから楽だし、
なによりＸＺから確実にＹが決定できる安心感がいいね。

185 ：名前は開発中のものです。：2006/09/16(土) 17:04:12 ID:QxqZsR+w

アルゴリズムに抜けがあるのはPGの技量不足じゃ…

186 ：名前は開発中のものです。：2006/09/16(土) 17:12:38 ID:7x6J3Hmc

普通にH-θ比例計算でいいだろうに

187 ：名前は開発中のものです。：2006/09/16(土) 17:33:58 ID:NCgixR60

3Dオブジェクトを利用して当たり判定を行うか、
旧来の擬似3Dマップで使われるような判定を別に行うか、
大きくはこの2通りがある。

旧来の擬似3Dマップ方式でも、3D空間を格子状に分解して個々の
立方体領域全てについて地形が存在するか否かをもつ方式もあれば、
2D平面を格子状に分解して、ここの正方形領域に高さ情報を持たせたものを
複数層重ねることによって地形の当たり判定を管理する方式もある。

蒸し返されてる螺旋階段の例において、螺旋階段状でジャンプしたときに
上の階段とぶつかることについて考える。
3Dオブジェクトを利用した判定や3D空間を格子状に分解する方式では、
下の段に接地することと上の段に頭をぶつけることは、まあだいたい等価
に考えられる。特に特別扱いしなくてもいい。
高さ情報をもつ2D格子を複数層重ねる方式では、その層を場所ごと(螺旋階段
一周の端とか)で切り替えるようにしていると、上の階段に接触しない可能性が
出てくる。高さ依存で層を切り替えるとか、そういう配慮が必要だ。

何の方式にしろ、理屈の上ではたいていのことが工夫すれば(あるいはしなくても)可能だ。
ただ、世界の単純化の度合いが進めば進むほど、複雑なことをするためには世界のモデルを
拡張する必要がでてくる。
あとでシステムが拡張に次ぐ拡張に見舞われるようなことにならないためには、自分の作る
ゲームでやることに対して、どの程度の世界(今回の例では地形)の単純さが適切か考えることが
大切だな。

今回の言い合いでは、たぶんお互いが頭に思い描いているゲームの複雑さの基準がかなり異なっている。
それが単なる一時の思い違いによるものならいいんだが、この様子では、どちらの側も、話の中である程度
具体的に想定できるゲームのバリエーションが貧困なんだと思う。もっといろんなゲームをプレイするといいよ。

188 ：名前は開発中のものです。：2006/09/16(土) 17:38:28 ID:+w/URioF

>>184
この書き込みを見てやっとLjBp93/Tが思っていたよりはマトモなんだと分かったｗ
だからこそ、普通の（←これ重要）ハイトフィールドで螺旋階段とかが
そのまま（←これが重要）判定できないっていうのに異論を唱えるのが不思議。

>>187
> 今回の言い合いでは、たぶんお互いが頭に思い描いているゲームの複雑さの基準がかなり異なっている。
みんな「時オカ」を例にして話を進めてますよ。
あれくらいの規模（ポリゴンの単純さ）からすると、ハイトフィールドよりも
メッシュ判定の方が断然楽。確かに確認作業は大変なものになるけど、
それこそ「工夫」すれば楽にできるよ、な。

189 ：名前は開発中のものです。：2006/09/16(土) 17:48:21 ID:LjBp93/T

>>188
ゼルダなんてＳＦＣの頃やったきりだしｗ

190 ：名前は開発中のものです。：2006/09/16(土) 18:19:37 ID:E6j+Euzf

二つの三角形が上手く判定できないくて「面倒」ときたか……。
数値計算もロクに知らないのが露呈しただけじゃん。

191 ：名前は開発中のものです。：2006/09/16(土) 18:29:38 ID:LjBp93/T

>>190
はぁ？

192 ：名前は開発中のものです。：2006/09/16(土) 18:38:20 ID:mhwk2PCU

みなさん御唱和ください。

「楽だし、安心感がいいから、ハイトフィールド最高！！」

さぁみなさんご一緒に！！

193 ：名前は開発中のものです。：2006/09/16(土) 18:41:42 ID:LjBp93/T

>>192
無駄に苦労して抜けに苦しむ意味がわからない。
隣接情報は作るのも大変だが、それ以上に確認が大変だぞ。

194 ：名前は開発中のものです。：2006/09/16(土) 18:41:45 ID:XwJAVNiB

一見して分からないところでメッシュに隙間があって高さが判別できなくなったらそれまで正常に取れてた高さをそのまま使えばいいんでない？

195 ：名前は開発中のものです。：2006/09/16(土) 18:56:20 ID:mhwk2PCU

> ID:LjBp93/T
お前の糞スタッフが糞地形データをよこすのはわかったが、
糞スタッフまみれなのはお前だけらしいから、
全世界のPGが「ハイトフィールド最高」と唱えるまで粘着するなと言ってるわけだが…

196 ：名前は開発中のものです。：2006/09/16(土) 19:04:21 ID:NCgixR60

>>194
隙間にオブジェクトがつっこんだ事それ自体とか、そのときに取得する
「それまで正常に取れてた高さ」とかが正確ならいいんだが、単に行き当たり
ばったりな対策なら余計ひどいことになるから思いとどまったほうがいいと思う。

商用ゲームのリリースとかの社会的な影響が大きいものでもない限り、
共同制作なら締め切りの延期を頼むなりして、まじめに原因と正確な
解決法の模索をしたほうがいいと思う。

197 ：名前は開発中のものです。：2006/09/16(土) 19:09:42 ID:u5V7+KW3

ハイトフィールドってバンプマップみたいなもん？

198 ：名前は開発中のものです。：2006/09/16(土) 19:10:41 ID:XwJAVNiB

>>195
＞粘着するなと言ってるわけだが
せっかくもりあげてくれてるのに…なんでそういうこというかな
彼にはDirectΧMVPをあげていい

199 ：名前は開発中のものです。：2006/09/16(土) 19:14:39 ID:LjBp93/T

>>194
そもそもどうやって正常か異常か判断するのかと問いたいｗ

俺のそのときやった解決策は隣接情報を持つことだな。
これ以外の解決策があるかもわからんが・・・。

200 ：名前は開発中のものです。：2006/09/16(土) 19:15:01 ID:W9eJQBmZ

技術的な話が一切無いレスが、一番見苦しい

201 ：名前は開発中のものです。：2006/09/16(土) 19:40:30 ID:XwJAVNiB

自分が次のフレームで進みたいとこに鉛直にレイをとばして何らかのポリゴンと交差したら正常
メッシュの隙間をちょうど通ってなにもヒットしなかったら異常
>>194はメッシュを事前にチェックする手法じゃなくて実際にゲーム内で歩行するときにやる
次のフレームでキャラを描くY座標を求める漸次処理での話だよ

202 ：名前は開発中のものです。：2006/09/16(土) 19:47:35 ID:LjBp93/T

>>201
>メッシュの隙間をちょうど通ってなにもヒットしなかったら
だから、隣接情報がいるだろ？ｗ

203 ：名前は開発中のものです。：2006/09/16(土) 20:25:41 ID:q7N2QBcJ

点や線ではなく、面でガードすれば多い日も安心。

204 ：名前は開発中のものです。：2006/09/16(土) 20:31:20 ID:x7V8Yxct

なんかだんだん見えて来たが、ハイト厨とそれをベースに議論してる奴らって
隙間を抜けるとか隣接情報がどうのこうのとか言ってるってことは
キャラの接地判定を点座標かそこからの垂線かなんかで処理してるんだな？
それなら議論が噛み合わないのもわかる。漏れはマップとの当たり判定も
球コリジョンでやってるからな。その方が壁とか天井とか他キャラとの押し合い
とかも全部同じコリジョンで判定できるんで楽なんだよ。

三次元の世界で未だにマップチップ敷き詰めた二次元マップと変わらない
実装してる時点で、ロートルという指摘は間違っていなかったようだ。

205 ：名前は開発中のものです。：2006/09/16(土) 20:37:34 ID:LjBp93/T

>>204
球判定は解決になってねぇ気がする。
俺もヒットの範囲をでかくもつってのは対策としてやったことがあるけど
結局、ヒット後の戻す位置が不安定になるからキャラがガクガクする箇所がでたからその方法はボツった。

206 ：名前は開発中のものです。：2006/09/16(土) 20:44:04 ID:NCgixR60

ハイトマップの代替にするならバウンディングボックスだと思う。

207 ：名前は開発中のものです。：2006/09/16(土) 20:51:36 ID:mR0GXmuR

アルゴリズムに拘ったものに限って退屈でツマラナい糞ゲームだらけだからな。
処理負荷が高いだけで何の利点もない。やるだけ無駄。

208 ：名前は開発中のものです。：2006/09/16(土) 21:00:25 ID:XwJAVNiB

球コリジョンの人は床とか壁にも球コリジョンを敷き詰めるってこと？
ほんといろんなやり方があるもんだね

209 ：名前は開発中のものです。：2006/09/16(土) 21:07:57 ID:x7V8Yxct

>>208
おまえはハイト厨の仲間かｗ
>>205も＞ヒット後の戻す位置が不安定になるからキャラがガクガクする
とか言ってるけど、球と平面の交差判定と最近接点の求め方も知らないのか？
ttp://www.amazon.co.jp/exec/obidos/ASIN/493900791X
これでも読んどけハゲども。

>>206
まさかバカ正直に表示用モデルのメッシュのポリゴン１つ１つと判定するとでも？
たしかにモデラーにメッシュ作ってもらえとは言ったが、そのぐらい想像しる。

210 ：名前は開発中のものです。：2006/09/16(土) 21:12:18 ID:LjBp93/T

>>209
いや、普通に↓の状態のどっちの平面を優先するか？って方法が難しいだろ・・・

　　　　　　　＼○／

211 ：名前は開発中のものです。：2006/09/16(土) 21:21:07 ID:NCgixR60

>>209
> 平面
平面？

> 表示用モデルの
バウンディングボックスとか球コリジョンとか言ってるのに
どこから表示用モデルの話が？

212 ：名前は開発中のものです。：2006/09/16(土) 21:46:28 ID:XwJAVNiB

>>209
全部本に書いてあるだけの知識なんだったらなんでそんなに人を見下した態度になれるのか
よくわからｎ

213 ：名前は開発中のものです。：2006/09/16(土) 22:09:09 ID:x7V8Yxct

１から１０まで全部実装方法説明しないと理解してくれないのか…

>>210
あれか、ヒット検出するたびにオブジェクトの位置更新する方法なのか。
漏れはヒット検出だけ先にがーっとやって良い位置を見つけてから動かしてる。
まさか更に後ろから追突されてる場合どうすんだ？とか聞くんじゃないだろうな？

これはもう>>187の言うとおり、想定してる実装が大幅に違うので
これ以上議論する必要はないな。ずっと平行線だろう。

>>212
説明すんのめんどくせーから良書と言われてる本提示しただけだよｗ

214 ：名前は開発中のものです。：2006/09/16(土) 22:13:30 ID:+w/URioF

>>209
今はｵﾏｴの方が痛いやつだな・・
処理が重くて実装が面倒（初心者向けじゃない）な方法を出してきて
優越感に浸ってるんだからな・・・
初心者へのアドバイスとしてはハイトフィールドは正解だよ。

LjBp93/T が言ってる抜けとかガクガクのことは、心配しない方がおかしい。
どんな優れた判定でも厳密な実装をしたとしても、抜けの心配ってのは尽きない。
それを「球コリジョンの判定だから大丈夫」ってのはＰＧとして問題ありだぞ。

215 ：名前は開発中のものです。：2006/09/16(土) 22:43:30 ID:EvPmSf1c

お前らそろそろ↓こっちに移動しろよ･･･
【Collision Detection】
ttp://pc8.2ch.net/test/read.cgi/gamedev/1015484028/

216 ：名前は開発中のものです。：2006/09/16(土) 23:32:15 ID:mhwk2PCU

ハイトフィールドに関してはデータ量に比べて、
地形が無表情になると感じたので、眼中になかった。

メッシュに関しては隙間があるなんて論外だ。
そもそもそんなメッシュは生成しないか、
どうしても生成する可能性があるなら、
事前にチェックする処理を実装すべきじゃないだろうか。

メッシュの範囲内で抜ける可能性があるのは、
三角形の辺や頂点付近で、計算誤差の関係で、
どの三角形の範囲内とも判定されない場合だろう。

現状、俺の場合は地面にめり込むと即破壊なんで、
（流れに沿えなくて申し訳無いが）無視しても問題なさげだが、
いずれ地面を這いずる処理もする予定なんで、
判定のときに決定されるパラメータを基準に、
高度を決めるに相応しい三角形を決定するかな。。。

正直、１９時くらいから友人に拉致られていた。
亀レスでも一向に反省しない。

217 ：名前は開発中のものです。：2006/09/16(土) 23:49:35 ID:XwJAVNiB

＞説明すんのめんどくせーから良書と言われてる本提示しただけだよｗ
面倒くさいくらいで自暴自棄なってたらこの先生きのこれない

218 ：98：2006/09/17(日) 00:56:16 ID:95SApkAm

なんだよ、もう。
土曜日がお休みの奴らだけで話を進めてさ！

219 ：名前は開発中のものです。：2006/09/17(日) 02:17:56 ID:kab63KmG

はいはい

>>98
3D格子を立方体見立てて、地形と判定して自動生成汁

220 ：名前は開発中のものです。：2006/09/17(日) 04:11:16 ID:xi1qMqr5

ちょっとここで質問するのはどうかとも思ったんですが・・・詳しい方が多そうなので。
モーションキャプチャで作成されたBVHフォーマットのデータ集があります。
これを読み込んでスキンメッシュに適用したいのですが、キャプチャされた人の体型と、
キャラクターの体型が違うと、あちこちで破綻しますよね（歩きで足がめり込む、剣を
持つ手がズレる等）。こういうデータの問題は、3DCGのソフトとかで編集して何とかする
モノなのでしょうか。キャラの形を演技者に合わせるのでしょうか。それとも心配する
ほど誤差は出ないのでしょうか・・・
どうするのが一般的なのか教えて下さい。

221 ：名前は開発中のものです。：2006/09/17(日) 08:55:25 ID:DxO0onxt

モデリングソフトで調整しないとどうにもならないだろう。

222 ：名前は開発中のものです。：2006/09/17(日) 13:15:12 ID:VB8rm0m6

>>220
最近の3Dソフトは、体型やボーン構造が違うモデルに
モーションデータを破綻せずに転写する機能があるものがあるから、
それを使うといいかも。
といっても万能ではなくて、ある程度は微調整が必要だけど。

223 ：名前は開発中のものです。：2006/09/17(日) 14:12:34 ID:xi1qMqr5

>>221 >>222
Poserが安くてそんな機能を持ってるように見えますね・・・
人体のボーン以外のデータ（擬似カメラマン等）がどう処理されるのか謎ですが。
ちょっとCG板でも質問してみます。
ありがとうございました。

224 ：名前は開発中のものです。：2006/09/17(日) 14:33:11 ID:cEnlpKqK

そういえば、先週くらいまでPoserは古いバージョンを無料配布してたな。

225 ：名前は開発中のものです。：2006/09/17(日) 16:23:16 ID:UIgbxGdy

HLSLでモデルやら線やらを描画してるんですがそれぞれのモデルで描画方法を
切り替えるようにすればいいのかいろいろ試しているんですがいまいち綺麗になりません。
今やっている方法としてはモデルの描画タイプなるものを変数でもってそこにenumで
定義したライト有とか無とかを入れて。それに応じた関数を1つずつ作ってその中で
設定して描画という流れをとっています。ほかに何かいい方法ありませんでしょうか？

226 ：名前は開発中のものです。：2006/09/17(日) 17:31:19 ID:l4eSGZ3a

>>225
それで問題ないんじゃん？

要は描画タイプをもっとスマートに設定したいってことだと思うんだけど、
俺はモデルのファイル名とかテクスチャのファイル名で区別するようにして
ロードする所で自動的に描画タイプ（に相当するもの）を設定してるよ。

あとは、モデルデータの中に情報を埋めこめられたらそれがベストだろうし、
あまり使われない emissiveColor とかに判断するための情報入れても良いし。

227 ：名前は開発中のものです。：2006/09/17(日) 21:02:11 ID:kVaTVo9Q

>>225
綺麗に実装したいということであれば、シーングラフとうい単語について調べてみるといいかも。
簡単に言えば、描画のための属性情報をデータに埋め込むための方法のひとつ。
ただ、一般的に極端に柔軟な構造になっていて(属性一つ一つが別オブジェクトとか)逆に
わかりにくくなってたりするので、その辺は差っ引いて考えたほうが良い。

228 ：名前は開発中のものです。：2006/09/18(月) 16:38:09 ID:nebAij1L

VC＋＋６でDirectGraphicsを初期化するだけのサンプルコードって
どこかにありませんか？

229 ：名前は開発中のものです。：2006/09/18(月) 16:53:16 ID:hPW3CvLZ

>>228
ｵﾏｲは初期化だけすれば満足なのか？

サンプル見れば初期化だけじゃなく色々処理してて楽しいぞ！

230 ：名前は開発中のものです。：2006/09/18(月) 16:56:42 ID:3J7XaVed

>228
それ欲しい気持ち分かるかも。
サンプルは短いほど良い。
初期化なら初期化のみのサンプルが欲しくなるけど何故か無いんだよね。

231 ：名前は開発中のものです。：2006/09/18(月) 17:01:59 ID:hPW3CvLZ

>>230 ｵﾏｲもかｗ

ﾎﾗﾖ↓

static LPDIRECT3D9 d3d = NULL;
static LPDIRECT3DDEVICE9 d3dDevice = NULL;

　　// Direct3D生成
　　if ((d3d = Direct3DCreate9(D3D_SDK_VERSION)) == NULL) {
　　　　return E_FAIL;
　　}

　　// デバイス生成
　　D3DPRESENT_PARAMETERS d3dpp;
　　ZeroMemory(&d3dpp, sizeof(d3dpp));
　　d3dpp.Windowed = TRUE;
　　d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
　　d3dpp.BackBufferFormat = D3DFMT_UNKNOWN;
　　d3dpp.EnableAutoDepthStencil = TRUE;
　　d3dpp.AutoDepthStencilFormat = D3DFMT_D16;
　　if (FAILED( d3d->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd,
　　　　　　　　　　　　　　　　　　D3DCREATE_SOFTWARE_VERTEXPROCESSING,
　　　　　　　　　　　　　　　　　　&d3dpp, &d3dDevice) )) {
　　　　return E_FAIL;
　　}

232 ：名前は開発中のものです。：2006/09/18(月) 17:02:02 ID:YGVTfy8v

だってその後やりたいことによって初期化する内容が違うもの。

233 ：名前は開発中のものです。：2006/09/18(月) 17:23:00 ID:hyOjYwNq

つーか、今のDirectXは、VC++6.0 見捨てたんじゃなかったっけ
エラーでたような

234 ：名前は開発中のものです。：2006/09/18(月) 17:25:42 ID:hPW3CvLZ

確か VC++6.0 は見捨てられたはずなんだが、俺は最新のSDKでも
なぜか開発できてる。XPだと良かったとかあるんだっけ？

235 ：228：2006/09/18(月) 17:34:23 ID:nebAij1L

ちょｗｗｗｗｗｗｗｗｗｗｗｗ
今のDirectXは、VC++6.0 見捨てたって本当ですかｗｗｗｗｗｗｗｗｗｗ
2年ぶりぐらいにゲーム作り再会しようと思ったけど
昔VC６で書いたコードがどっか行ったからまた一から書き直そうと思ってたんですけどｗｗｗｗｗｗｗｗｗｗ

236 ：名前は開発中のものです。：2006/09/18(月) 17:48:58 ID:hPW3CvLZ

>>228
せっかく再開しようと思ったんだから、とりあえずSDK入れてみなよｗ
ちなみにサンプルコードは、昔みたいにサンプルとして用意されてるんじゃなくて
Sample Browserっつーやつで欲しいやつをコピーして使うんだよ。

コピーされたやつは.NET的なプロジェクトなんでVC6.0ではそのままでは使えなくて
自前でプロジェクト作成して追加するか、中身だけコピペして使う。

237 ：名前は開発中のものです。：2006/09/18(月) 18:11:28 ID:nebAij1L

本棚にVC#.netがあったｗｗｗｗｗｗｗｗｗｗｗｗ
とりあえずこれに移行しようｗｗｗｗｗｗｗｗｗｗｗｗｗ
version2002って書いてあるけどこれでいいのかなｗｗｗｗｗｗｗｗ
とりあえず>>231ありがとうｗｗｗｗｗｗｗｗｗｗｗ
>>236もｗｗｗｗｗｗｗｗ

238 ：名前は開発中のものです。：2006/09/18(月) 18:20:33 ID:hPW3CvLZ

>>237
ちょwwwwww
VC#じゃ俺がさらしたコード意味なくね？ｗ

それに、>>231 も >>236 も俺だwwww

239 ：名前は開発中のものです。：2006/09/18(月) 18:37:41 ID:u18krs0F

>>237
version2002って、それも古いよｗ

ttp://www.microsoft.com/japan/msdn/vstudio/express/
↑で「Visual C++ 2005 Express Edition」が（C# 2005も）
タダで配布されているから、これを使え。
ちなみに、MFCとかいくつか機能は削られてるけどね。

240 ：名前は開発中のものです。：2006/09/18(月) 19:37:28 ID:hx4aXYl5

ttp://msdn.microsoft.com/directx/XNA/gse/readme/default.aspx

241 ：名前は開発中のものです。：2006/09/18(月) 20:02:41 ID:nebAij1L

>>239
ありがとう
無料ｗｗｗｗｗｗｗｗｗｗｗｗｗ
>>240
ありがとう
英語わかんねｗｗｗｗｗｗｗｗｗｗｗ

242 ：名前は開発中のものです。：2006/09/18(月) 21:00:23 ID:hqDoqF8g

>>239
windows.hが無いって言われてPSDK入れようとしたら解凍時にエラーが・・・orz

243 ：名前は開発中のものです。：2006/09/18(月) 22:05:45 ID:wQqaLVvp

DirectXを使用したライブラリをつくろおもてるんですがCVSとかで共有して皆が
簡単に触れるようにしておいたら結構アドバイスとかもらいやすいですか？

244 ：名前は開発中のものです。：2006/09/18(月) 22:08:41 ID:CKwMW6d1

ｃｖｓってサーバーはどうすんのさ

245 ：名前は開発中のものです。：2006/09/18(月) 22:11:16 ID:TsNNBYba

ん？専用スレにでも書いとけばいいんじゃないの？

246 ：名前は開発中のものです。：2006/09/18(月) 23:09:43 ID:hyOjYwNq

D3DUSAGE_RENDERTARGETでレンダリングターゲット作った後
pd3dDevice->Resetをかけて
pd3dDevice->Presentするとエラー出るんですが
回避方法あります？

Reset前にレンダリングターゲットReleaseしてもエラーでます；；

247 ：名前は開発中のものです。：2006/09/18(月) 23:22:59 ID:cmynSM1C

→Reset
→CreateVertexBuffer/CreateTexture
→BeginScene
→EndScene
→Present
の順でもエラーがでるん？

248 ：名前は開発中のものです。：2006/09/19(火) 00:20:26 ID:U6KIFbrr

サーバーは自分のPCでやろ、おもてます。

249 ：名前は開発中のものです。：2006/09/19(火) 00:40:10 ID:t7b8fFIa

ファイルのアップローダがあるだけで十分だろ。

250 ：名前は開発中のものです。：2006/09/19(火) 00:56:56 ID:SaZdkbYW

>>243
そもそもどんなライブラリを作るの？
単なるラッパーなら誰も相手にしないと思うよ。

251 ：名前は開発中のものです。：2006/09/19(火) 00:57:12 ID:1N/W0sXJ

今からライブラリ作るなら少なくともＥＬやＤＸライブラリ以上のものを
目指さないと使ってくれる人居なさそうだねぇ。

使ってくれる人居ないと結局csvで触ってくれる人もアドバイスやら
要望やらも来なくなるし・・・

252 ：名前は開発中のものです。：2006/09/19(火) 01:06:07 ID:t7b8fFIa

まず、あれ、プログラムなんて組まないで、
どんな機能が必要でどうまとめたら上手くいくかスレ立てて考えろよ。
でも、どういうライブラリが欲しいのか方針はお前が決めろ。
みんな勝手な要望ぎしぎし詰め込んでも実際作れないだろ？
ＸＦｉｌｅが読み込めて、バンプ、環境、スキンメッシュ、フォグ、・・・対応しろとか言われても
これ、対応するだけで１年はかかりそうな勢いだぞ。

通常描画のスキンメッシュ
パンプ描画のスキンメッシュ
環境マップ使った描画のスキンメッシュ
　・
　・
　・

ってやること同じくせに量だけは多いんだ。
会社で作ったときもかなり時間使ったし、まず、仕様を絞らんとどうにもならんぞ。

逆にライブラリなんて作らないで、仕様だけまとめておいて公開しておくってのも手だ。
もちろん、どんな経緯でそういう仕様に決まったのか書いてあると改善案も出しやすい。
結構、ライブラリの仕様を決めるのも一苦労だろ？

253 ：名前は開発中のものです。：2006/09/19(火) 01:24:36 ID:BOyyTazN

>>246
SetRenderTargetを使っているなら、それを元に戻した？

254 ：名前は開発中のものです。：2006/09/19(火) 01:27:01 ID:1N/W0sXJ

しかももうじきDx10リリースだしなぁ・・・
互換を考えてもDx9フル対応くらいの勢いがほしいねぇ。

255 ：名前は開発中のものです。：2006/09/19(火) 01:36:21 ID:oOnCYiGc

>>248
DirectXラッパー…自前鯖…オナニー…
　
>>252
＞上手くいくかスレ立てて考えろよ
　
SourceForgeにプロジェクト立てる。これが正解。
オナニーが頓挫したら墓標のごとく未来永劫残す。ｶｯｺｲｰ（・∀・）

256 ：名前は開発中のものです。：2006/09/19(火) 01:45:48 ID:KfiG372I

自宅鯖でCVSの話が出た時点で既に死相が出てるな。ネタ確定。

257 ：名前は開発中のものです。：2006/09/19(火) 01:55:02 ID:t7b8fFIa

そういやDirectX10が出ちまうから少しまってろよなｗ

258 ：名前は開発中のものです。：2006/09/19(火) 01:55:43 ID:oOnCYiGc

スレ立てるなら開き直って
最高に厨臭いDirectXラッパーを作るスレ
がいいな。潔くて好感度急上昇だな。

259 ：名前は開発中のものです。：2006/09/19(火) 01:59:05 ID:t7b8fFIa

もうちょっと真面目にDirectX以外の部分のゲームでよく使うクラスとかいいかな。

260 ：名前は開発中のものです。：2006/09/19(火) 02:16:05 ID:gf5/DDGm

>259
例えば

261 ：名前は開発中のものです。：2006/09/19(火) 02:30:20 ID:E+vk7FJ4

うんこ

262 ：名前は開発中のものです。：2006/09/19(火) 07:30:08 ID:t7b8fFIa

>>260
そんな想像力もない奴と話なんぞできん。

263 ：名前は開発中のものです。：2006/09/19(火) 08:59:22 ID:1N/W0sXJ

>>256
Lunaは自宅鯖でSubversion管理されてなかったか？ｗ

264 ：名前は開発中のものです。：2006/09/19(火) 17:33:32 ID:9n1QZKMP

知恵を貸しておくれorz
HLSLで描画前にテクスチャ数を指定してシェーダが切り替わるようにしたいんだけど、
上手く切り替わらず、毎回テクスチャONの状態になってしまいます……。

エフェクトファイルは↓なんですが、合ってるかどうか見てくれませんか？
http://gamdev.org/up/img/7619.zip

265 ：名前は開発中のものです。：2006/09/19(火) 18:35:40 ID:n+W5xQne

つーか、エフェクトは特に問題なさそうなので実行してみたら
ちゃんと切り替わるじゃんＹＯ
UseTexCntの値を入力してないんじゃね？

266 ：名前は開発中のものです。：2006/09/19(火) 18:50:23 ID:n+W5xQne

いや、逆か…
値を入力しないとテクスチャＯＮにならないし、UseTexCntが１のままとかかな？

267 ：名前は開発中のものです。：2006/09/19(火) 19:47:47 ID:9n1QZKMP

確認ありがとうございます。エフェクトは合ってたのか……。
さっきGetInt()で確認したらUseTexCntの値はちゃんと描画前に0・1が切り替わっていました。
んー、何が原因なのかさっぱり分からない。orz　ソースの方をもっっとよくトレースしてみます。

268 ：名前は開発中のものです。：2006/09/19(火) 21:37:36 ID:/6g1Cemc

243です。とりあえず
第1弾　ライブラリ機能を上げさせていただきます。
・テクスチャマネージャ
・シェーダマネージャ
・ファイルシステム
・インプットシステム
・オーディオシステム
・Xファイル(スキン)
・描画系はできる限りシェーダで行う
・算術関数
・フォント
・スクリプト
・カメラ
・視垂体による描画判定
・メモリマネージャ
・2Dスプライト
・パーティクル
・プロファイラ
・LOD
・カメラ位置からの距離によるミップマップ
・オーダリングテーブル(オブジェクトのソート)

269 ：名前は開発中のものです。：2006/09/19(火) 22:56:41 ID:t7b8fFIa

>>268
乙。
じゃあ、次は優先度を・・・。

270 ：名前は開発中のものです。：2006/09/19(火) 23:18:58 ID:PUi+Z24t

>>267
もう済んでるかもしれないけど、描画直前(BeginPass()後)に
パラメータいじった場合は、CommitChanges()呼ばないとだめよ。

271 ：名前は開発中のものです。：2006/09/19(火) 23:47:57 ID:SaZdkbYW

>>264
力になれなくて残念なんだが・・・

VertexShader/PixelShaderの配列を定義して
変数で切り替えられるのを初めて知った！！
ありがとう！！そして、頑張れ！

272 ：名前は開発中のものです。：2006/09/20(水) 00:18:57 ID:vxl0rQet

268です。
第２弾　優先決めました。
・1.テクスチャマネージャ
・6.シェーダマネージャ
・17.ファイルシステム
・10.インプットシステム
・11.オーディオシステム
・5.Xファイル(スキン)
・9.描画系はできる限りシェーダで行う
・2.算術関数
・3.フォント
・18.スクリプト
・4.カメラ
・12.視垂体による描画判定
・16.メモリマネージャ
・8.2Dスプライト
・7.パーティクル
・19.プロファイラ
・13.LOD
・15.カメラ位置からの距離によるミップマップ
・14.オーダリングテーブル(オブジェクトのソート)

273 ：名前は開発中のものです。：2006/09/20(水) 00:25:00 ID:37EIjtZt

>>272
見辛い・・(´Д｀)

メモリマネージャとかファイルシステムを後回しして大丈夫か？ｗ
「描画系はできる限りシェーダで行う」なのにシェーダマネージャが
Ｘファイルよりも後だし・・パーティクルとか妙にﾊｴｰしｗ

一応確認しておくが、DirectX使ったゲーム作ったことある？

274 ：264：2006/09/20(水) 00:25:09 ID:sFU/X0hE

名前でパラメータを指定したらエラーが出たので良く確認したら、
別のエフェクトのパラメータに書き込んでましたorz

ハンドルで指定していたらエラーが出ないのね……。

275 ：名前は開発中のものです。：2006/09/20(水) 00:26:16 ID:8TG2Ez5s

・1.テクスチャマネージャ
・2.算術関数
・3.フォント
・4.カメラ
・5.Xファイル(スキン)
・6.シェーダマネージャ
・7.パーティクル
・8.2Dスプライト
・9.描画系はできる限りシェーダで行う
・10.インプットシステム
・11.オーディオシステム
・12.視垂体による描画判定
・13.LOD
・14.オーダリングテーブル(オブジェクトのソート)
・15.カメラ位置からの距離によるミップマップ
・16.メモリマネージャ
・17.ファイルシステム
・18.スクリプト
・19.プロファイラ
ソートしてやった

276 ：名前は開発中のものです。：2006/09/20(水) 00:31:44 ID:37EIjtZt

>>274
> さっきGetInt()で確認したらUseTexCntの値はちゃんと描画前に0・1が切り替わっていました。
これを信じて、そのオチはないと信じてました・・・(;´д`)

277 ：名前は開発中のものです。：2006/09/20(水) 00:38:20 ID:sFU/X0hE

ごめんなさい。
SetInt()をコピペしてGetInt()に変えて試してました・・・。
こんな単純なミスだと思わなかった。orz

278 ：名前は開発中のものです。：2006/09/20(水) 00:45:56 ID:37EIjtZt

俺ならこんな感じ
・フォント　　　　　　// デバッグが楽になる
・メモリマネージャ　　// まずコレ
・ファイルシステム　　// テクスチャ読むため（早くも飽きてくる）
・テクスチャマネージャ
・2Dスプライト　　　　// テクスチャ確認用（もう完成した気分）
・シェーダマネージャ　// モチベーション維持のため
・描画系はできる限りシェーダで行う
・Xファイル(スキン)　
・算術関数　　　　　　// （惰性で開発を続け始めるころ）
・カメラ
・インプットシステム　　// カメラを移動してみたい（もう限界）
※ここで開発終了の可能性高し※
・プロファイラ　　　　　// 以降のパフォーマンス確認のため
・LOD
・視垂体による描画判定
・オーダリングテーブル(オブジェクトのソート)
・カメラ位置からの距離によるミップマップ
・パーティクル
・スクリプト
・オーディオシステム

279 ：名前は開発中のものです。：2006/09/20(水) 00:59:57 ID:JLgKEs2/

>>275,278
なんか完成予想図がいつもどおりのラッパーだな。
完成してもゲーム作るの程遠いっつか夢がもてないｗ
これじゃ作ってもあんまり意味ないと思うんだけど・・・。

逆に考えてみね？
どんなゲームが作りたいか？
ってのをまず出して、そのためのライブラリを考えてみね？

280 ：名前は開発中のものです。：2006/09/20(水) 01:03:24 ID:8TG2Ez5s

>どんなゲームが作りたいか？
NTや95でも動くエロゲ

281 ：名前は開発中のものです。：2006/09/20(水) 01:06:03 ID:JLgKEs2/

>>280
そしたら迷わずGDI+を奨める。

282 ：名前は開発中のものです。：2006/09/20(水) 01:07:13 ID:JLgKEs2/

だめだ、うごかねぇか？＞95 NT

283 ：名前は開発中のものです。：2006/09/20(水) 01:08:33 ID:JLgKEs2/

ま、１日じっくり考えてみようや。

284 ：名前は開発中のものです。：2006/09/20(水) 01:09:08 ID:a1eP4hFR

GDI+って、.NET？
95やNTでも動いたっけ？

285 ：名前は開発中のものです。：2006/09/20(水) 01:11:59 ID:JLgKEs2/

>>284
>GDI+ はWindowsXPから使えるようになった2DグラフィックAPIである。
>XP以前でも、gdiplus.dllを入れれば利用可能である。(98以降か、NT4.0sp6以降)
95は駄目っぽい。

286 ：名前は開発中のものです。：2006/09/20(水) 01:12:42 ID:8TG2Ez5s

冗談なのにマジレスされた。

多分動かない
XPか2000か忘れたけど、デフォルトのDLLにバグがあって
修正版同梱しなきゃいけないというか
GDI＋は、あんまりいいうわさを聞かない。
というか95とかは、全部ソフトウエアレンダリングで。

287 ：名前は開発中のものです。：2006/09/20(水) 01:19:58 ID:vxl0rQet

どんなゲームが作りたいかと言われればPCゲームのトレンドがのっかるもの。
正直、上であげた機能＋αあれば2Dのゲームはまぁ2Dエフェクト用のエフェクトファイル
みたいなものを作らなければいけないだろうけど大丈夫だと思ってます。
3DでもRPGとかアクションとかを考えていったらLODとかは必須だし、シェーダもほしいし、みたいな
ことを考えていくと結構いろいろあるに越したことはないし。DX10のことを考えればDX9バージョンで
ある程度しっかりしたものがあれば移行も楽になるし、当分の間はDX10バージョンとDX9バージョン
の両方のバージョンが必要みたいなことも考えられますのであえてこういったゲームが作りたいから
この機能が必要っていう流れよりある程度のどのジャンルでも必要なものは全部入れたい(願わくば)。
実は今もちょこっと作ってて結構いろいろ修正しなくちゃいけないもののソースはあります。

288 ：名前は開発中のものです。：2006/09/20(水) 01:30:55 ID:JLgKEs2/

>>287
ちがうわボケ。
具体的なゲーム名が欲しいね。
つまりさ

枝葉の部分に熱心で全然ゲーム作れそうにないじゃん。このライブラリ。

って言いたいのよ。

289 ：名前は開発中のものです。：2006/09/20(水) 01:31:26 ID:SMchqepX

俺ならこの順番だな。
ついでにメモも。

・1.メモリマネージャ　　　　　　　　　　：メモリ管理はWindowsに任せたほうがよくないか？
・2.ファイルシステム　　　　　　　　　　：できればソース変更無しにパックしたファイルからの読み込みも対応して欲しい
・3.テクスチャマネージャ　　　　　　　　：何をマネージするん？
・4.2Dスプライト　　　　　　　　　　　　：がんばれ
・5.フォント　　　　　　　　　　　　　　：D3DXFontは使うなよ
・6.インプットシステム　　　　　　　　　：がんばれ
・7.オーディオシステム　　　　　　　　　：Oggの対応はしてないと結局外部のサウンドドライバ使う事になりそう
・8.描画系はできる限りシェーダで行う　　：がんばれ
・9.シェーダマネージャ　　　　　　　　　：がんばれ
・10.算術関数　　　　　　　　　　　　　：Sin/Cosのテーブルでも作るん？コリジョン関係？
・11.カメラ　　　　　　　　　　　　　　：がんばれ
・12.Xファイル(スキン)　　　　　　　　　：がんばれ
・13.パーティクル　　　　　　　　　　　：がんばれ
・14.視垂体による描画判定　　　　　　　：がんばれ
・15.LOD　　　　　　　　　　　　　　　　：がんばれ
・16.オーダリングテーブル(オブジェクトのソート)　：シーングラフとか最低でもオクトツリーくらいは欲しい
・17.カメラ位置からの距離によるミップマップ　　　：Direct3Dが自動的にやってる気がする。Mipmap使うより異方性フィルタの方が綺麗だけどね
・18.プロファイラ　　　　　　　　　　　　　　　　：がんばれ
・19.スクリプト　　　　　　　　　　　　　　　　　：Luaでよくね？

言っちゃなんだが列挙された機能だけ見るとLunaと大して変わらないな。

290 ：名前は開発中のものです。：2006/09/20(水) 01:45:23 ID:37EIjtZt

>>280
つJavaアプレット

>>287
DirectXそのまま使えよｗ

291 ：名前は開発中のものです。：2006/09/20(水) 02:25:42 ID:9pKZ8pjk

前スレで、
　DrawPrimitive 使って、128x128ぐらいのポリゴンを５０枚ぐらい描画してます。
１回のDrawPrimitive で、１枚だけなので、５０回DrawPrimitive を実行してます。
すると、ポリゴンがときどき変な形になるんです。
頂点がずれたように、斜めになったりとか。
そこで、一回DrawPrimitive を実行した後に、Sleep(3);　を入れてやってみたんです。
すると、速度は落ちましたが、ポリゴンが変になることは無くなった。
てことは、前回の描画が済んでいない間に描画してる？
そこで、DrawPrimitive の最後の引数に、D3DDP_WAIT とかやってみたけどダメでした。
何が原因でどーやれば直りますか？

って書いた者ですが、Win32APIで頂点用メモリ確保したたのを、
Ｄ３Ｄの頂点バッファ使ったものにしたけど、結果は同じでした。

292 ：名前は開発中のものです。：2006/09/20(水) 03:01:32 ID:8TG2Ez5s

>>289

D3DXFontってやっぱ駄目なん？

293 ：名前は開発中のものです。：2006/09/20(水) 03:36:56 ID:8TG2Ez5s

メタセコで、反射光とかを強調した設定で
Direct3D描画とOpenGL描画を比べたけど
OpenGLのほうが細かく綺麗
OpenGLってええのん？

294 ：名前は開発中のものです。：2006/09/20(水) 09:00:43 ID:SMchqepX

>>292
そのそもユーザーがインストールしてないフォントは出せないし、
影、グラデーション、縁、とかをつけようしたら結局画像で持たなきゃでしょ。

あとFF11やPSUのキャラの名前みたいに３D空間に文字を表示するのは
D3DXFontなんかじゃやってられないべ。

295 ：名前は開発中のものです。：2006/09/20(水) 12:07:45 ID:ymA1aj6X

ライブラリなんかより特殊効果エディタがほしいんだよな
タイムラインとかあってテクスチャの位置とか透明度とか大きさのアニメをクニクニいじれるの
仕様を決めたら誰か勉強がてらつくってくれる？

296 ：名前は開発中のものです。：2006/09/20(水) 12:30:13 ID:Xs5BryGe

>291
エスパーを待てないならソースを晒せ。

297 ：名前は開発中のものです。：2006/09/20(水) 12:40:17 ID:evuW5ro9

腹減ったからついでにヤキソバも晒せ

298 ：名前は開発中のものです。：2006/09/20(水) 14:44:46 ID:+KfsWgDs

>>297
http://portal.nifty.com/2006/09/18/b/

299 ：名前は開発中のものです。：2006/09/20(水) 15:19:51 ID:fb5XSQAC

>>291
ドライバ

300 ：名前は開発中のものです。：2006/09/20(水) 15:46:47 ID:+KfsWgDs

>>294
デバッグ用、エロゲっぽいメッセージ用にD3DXFont版も持ってていいと思う

301 ：名前は開発中のものです。：2006/09/20(水) 15:47:25 ID:37EIjtZt

>>291
> って書いた者ですが、Win32APIで頂点用メモリ確保したたのを、
> Ｄ３Ｄの頂点バッファ使ったものにしたけど、結果は同じでした。

当然ポリゴン５０枚分のバッファを用意して試したんだよな？

302 ：名前は開発中のものです。：2006/09/20(水) 21:35:46 ID:i8H7IqgD

やりかけのソースですがあげました。
ttp://gamdev.org/up/upload.php
7623.ziplib

303 ：名前は開発中のものです。：2006/09/20(水) 21:54:30 ID:jot8TQ3t

なんて綺麗なソースなんだｗ orz

304 ：名前は開発中のものです。：2006/09/20(水) 22:23:15 ID:SMchqepX

>>302
DirectXのバージョンはどれ？
DirectX9だけでも10以上のバージョン違いあるねん。

305 ：名前は開発中のものです。：2006/09/20(水) 23:29:38 ID:Eb3Bq3HL

・フォント　　　　　　// デバッグが楽になる
ｋｗｓｋ

306 ：名前は開発中のものです。：2006/09/20(水) 23:31:01 ID:oucXxDtX

画面にデバッグ情報を流すんじゃないか？

307 ：名前は開発中のものです。：2006/09/20(水) 23:32:10 ID:SMchqepX

俺はデバッグモードの時はシステムをコンソールにして
DOS窓にprintfでデバッグ情報表示してるなぁ。

308 ：名前は開発中のものです。：2006/09/20(水) 23:32:22 ID:8TG2Ez5s

1>.\Main\DXSystem.rc(10) : fatal error RC1015: cannot open include file 'afxres.h'.

309 ：名前は開発中のものです。：2006/09/20(水) 23:32:52 ID:8TG2Ez5s

OutputDebugString使うといいよ

310 ：名前は開発中のものです。：2006/09/20(水) 23:33:20 ID:SMchqepX

>>308
VS2005EE使ってないか？
EEはMFCやリソース関係が使えないぞ。

311 ：名前は開発中のものです。：2006/09/20(水) 23:35:18 ID:8TG2Ez5s

EEしかない＞＜

312 ：名前は開発中のものです。：2006/09/20(水) 23:44:23 ID:8TG2Ez5s

>>302の7610がクオリティ高すぎて泣いた

313 ：名前は開発中のものです。：2006/09/20(水) 23:47:03 ID:oucXxDtX

ネギ格の格は別格の格だから無問題。

314 ：名前は開発中のものです。：2006/09/20(水) 23:57:15 ID:jpdNbZbv

>>311
あれ？俺のは普通に出来るけど・・・
includeディレクトリに

C:\Program Files\Microsoft Platform SDK\Include\mfc

とか入ってないんじゃね？

315 ：名前は開発中のものです。：2006/09/21(木) 00:02:41 ID:4FMuFct9

>>314
いけた。㌧ｸｽ

316 ：名前は開発中のものです。：2006/09/21(木) 00:11:58 ID:HvKhVd8X

でどうでしょうか？
ここからいろいろ修正しなくてはいけないものの実装していけば
いくぶん楽になるのかなと思ってます。皆様どうでしょう？

317 ：名前は開発中のものです。：2006/09/21(木) 00:13:35 ID:8drzSPV5

>>302
なんか丁寧に作られてて好印象だけど、いきなりボリュームあるなあｗ
実行するとエラーで止まるし(´Д｀)

ざっとしか見てないんだが、単なるラッパーよりはマシだけど
DirectXとか３Ｄの知識がないと使えない感じがして
ライブラリーにする意味があるのか疑問。

もっと抽象化して感覚的に使えるようにしたいところだなあ。
DirectXよりも使うの大変、ってことになったら本当に意味ないし。

318 ：名前は開発中のものです。：2006/09/21(木) 00:20:37 ID:fqy8SQk8

見てみたが基本的にラッパーの域を抜けてないな。

319 ：名前は開発中のものです。：2006/09/21(木) 00:35:12 ID:eEpWsKHV

Yo!!
ラッパー舐めるなYo!!

320 ：名前は開発中のものです。：2006/09/21(木) 00:41:50 ID:NXk6nMX2

俺が昔作ったラッパーなんて
Open、Close、LoadTexture、LoadVertex、DrawPolygon、DrawSprite
の6つしか関数がなかったぜ

321 ：名前は開発中のものです。：2006/09/21(木) 00:42:14 ID:QgzW8n2H

だったら追加ﾖﾛｗ
・キャラ基本動作
・地形との当たり判定
・瞬間弾
・榴弾
・弾道弾
・誘導弾
・自動車
・キャタピラー車
・飛行機
・ヘリ

もうDirectXの範疇じゃないがｗ

322 ：名前は開発中のものです。：2006/09/21(木) 00:49:51 ID:HLxN0OV5

>>316
とりあえずココまで出来てるなら次はシェーダー対応したらどう？
固定機能からシェーダー対応って意外と手間だし、固定機能で作りこめば作りこむほど面倒になる。

基本的な部分は一通り出来てるんだしシェーダー周りを充実させたほうがいいと思われ。

323 ：名前は開発中のものです。：2006/09/21(木) 00:55:35 ID:GOD3d2R3

ラッパーの域を出るにはある程度思想を持った設計にする必要があるね。
3D初心者が最初に深い挫折を味わうシーングラフの最適化とか、
良く知られた方法（BSPツリー等）をライブラリで提供してくれるといいかも。
欲を言えば同じツリーで当たり判定の絞込みとか、環境音の遮蔽とか
一括してできるように設計してあれば間違いなく人気ライブラリになるだろう。

324 ：名前は開発中のものです。：2006/09/21(木) 00:56:43 ID:+j1lUXRe

でもシェーダーって結構高いんだよね…？
ホビープログラマーとかでも買えるの？

325 ：名前は開発中のものです。：2006/09/21(木) 01:04:24 ID:8drzSPV5

>>324
３ＤソフトのShadeか何かと勘違いしてる？
シェーダってプログラムの中の話ですよ。

326 ：名前は開発中のものです。：2006/09/21(木) 01:07:03 ID:GOD3d2R3

ってソースを見てみたが、かなり古い設計をしてるなｗ
ウィンドウサイズとかdefineしてる時点でかなりガックリ来た。
今時のライブラリなら設定管理クラスで動的に管理してくれよぅ。

327 ：名前は開発中のものです。：2006/09/21(木) 01:11:17 ID:HvKhVd8X

307さんありがとうございます。それはかなりわかりやすそうなので組み込もうと思います。
317さんのご意見もっともですね、DirectX知らないとわからない部分が多いと自分でも思います。
シェーダ周りを中心に充実させていく流れで作っていこうと思います。
ちなみにサイトでも公開していますのでそちらに最新版をおいているのでいつでもどうぞ。(URLは秘密)

328 ：名前は開発中のものです。：2006/09/21(木) 01:17:33 ID:HLxN0OV5

とりあえず既存のライブラリを凌駕するようなのが出来るのを祈ってるぜ。
見た感じ一番のライバルになりそうなのはLampでないかな？

329 ：名前は開発中のものです。：2006/09/21(木) 01:19:41 ID:8drzSPV5

>>327
DOS窓にprintfで文字出すのも悪いとは言わないけど
フルスクリーン時に全然見えないっていう欠点も忘れずに・・

後でLOG的に見るだけだったら、それこそLOGファイル見ればいいことだし。

330 ：名前は開発中のものです。：2006/09/21(木) 01:31:55 ID:8drzSPV5

>>328
Lampっつーの初めてみたけど、コレ使われてるの？
他の DXだかいうライブラリも同じ感じ？？
だったら、>>327 のやつもイイ線いってるってことなのかな。

なんでもっとシンプルに仕上げられないのか疑問だぜ・・(´Д｀) ﾎﾞｿﾘ
>>320 はシンプルすぎだがｗ

331 ：名前は開発中のものです。：2006/09/21(木) 02:00:52 ID:4FMuFct9

コメントをdoxygen等に対応させると
ドキュメント自動生成してくれるので楽よ。

332 ：291：2006/09/21(木) 06:16:52 ID:NSl3TVGi

グラボを、ラデオン９２００SEから、ゲフォ４にしたら、
かなり改善されました。
しかし、完全には無くなりません。
Ｄ３Ｄによる頂点バッファは、５０あるポリゴンごとに確保してます。
この世代のグラボでこーなるのは、仕様であったりバグであったりするものでしょーか？

333 ：名前は開発中のものです。：2006/09/21(木) 06:20:00 ID:5ruKmJ4x

俺からすればTextureManageなんてロストさえなければ作る意味がわからない。
やっぱ、実装だけはVistaまで待ったほうがいいよ。
絶対、不必要なもんばっかりだから。

334 ：291：2006/09/21(木) 06:20:02 ID:NSl3TVGi

あ、漏れのコードにちょとバグはけん

335 ：291：2006/09/21(木) 06:45:04 ID:NSl3TVGi

バグなおしたけど同じでした。
頂点バッファをかえてもダメってことは、あと考えられるのは
テクスチャもポリゴンごとに確保することぐらいしか

336 ：名前は開発中のものです。：2006/09/21(木) 06:57:59 ID:G9WJnnc7

スクリーンショット撮って該当箇所に丸付けて見せて。

337 ：名前は開発中のものです。：2006/09/21(木) 08:44:26 ID:HLxN0OV5

>>335
だからお前さんさ、
DrawPrimitiveしたあと描画完了待たないで書き換えてるんじゃねーの？

338 ：名前は開発中のものです。：2006/09/21(木) 09:14:46 ID:HLxN0OV5

>>333
DX10はVista専用だからそれにあわせて作るのもどうかと思う。
DX9で作っておけばWin98,ME,2000,XP,Vistaでの動作がサポートされるわけだし。

Vistaが普及なんて2,3年はかかるってM$の人間すら言ってるのだから
サポート環境や性能的に見てもしばらくはDX9対応のものがいいと思う。

>>329
もう1台マシン用意してリモートデバッグって手もあるぜ。
まぁprintfデバッグはライブラリよりゲームの時に使ってる。
イベント発生とかのタイミングで表示させたりと結構便利。

339 ：名前は開発中のものです。：2006/09/21(木) 15:24:12 ID:Gz5/V+Ov

>302
何となく見てみたが、
最初に見たMemoryManagerとやらの腐った実装に、突っ込まずには居られない。

340 ：名前は開発中のものです。：2006/09/21(木) 18:50:24 ID:w/U4pxaF

>>302
何となく見てみたが、
Program'm'ed だよ

341 ：名前は開発中のものです。：2006/09/21(木) 21:45:59 ID:HLxN0OV5

MemoryManagerはこれから手を入れていくんじゃないの？
Windowsなのにわざわざメモリ管理を自作する所からするとコンシューマーの人のような気がするけど。

あと自分でメモリ管理すると当然その分のメモリは確保しておく必要があるわけだけど、
現状だと>>302のライブラリは起動するだけで最低でも10MBのメモリを消費するという事は理解してる？

あとWindowsの場合new/deleteやmalloc/freeで確保したメモリを解放しないで
アプリケーションを終了させた場合でも、OSが全部勝手に解放してくれるし、
解放してないメモリの確保時のファイル名と行番号を教えてくれたりする。

最低でもコレ以上の機能はないと自分で実装する意味はないってことになるな。

342 ：名前は開発中のものです。：2006/09/21(木) 21:58:21 ID:HvKhVd8X

どうも302、以後Nと名乗ります。
MemoryManagerに関して何が目的で作ったかというとnewやdeleteなどのメモリ確保
などをゲーム中、あるシーンに入る前にジオメトリやらテクスチャやらを読み込む時に
毎回行うのと既に確保しているのから割り当てて使うのではスピードが早いので作りました。

343 ：名前は開発中のものです。：2006/09/21(木) 22:30:29 ID:/4EhidU1

N…ヌルポか！

344 ：名前は開発中のものです。：2006/09/21(木) 22:47:15 ID:5ruKmJ4x

おいおい。
ネタ提供してくれんのはありがたいと思うけど、こういうライブラリって役にたたねぇよ。
普通にLuna（既存）の方がいいじゃねぇか。
しかも、どうみてもラッパーの域をでねぇ。

>>341
>解放してないメモリの確保時のファイル名と行番号を教えてくれたりする。
え？これどうやってわかんの？
たまーに出てくるときもあるけど９９．５％は？？？？みたいなのが出てくるんだけど？

345 ：名前は開発中のものです。：2006/09/21(木) 23:11:50 ID:lwyY0NN2

出てきたばかりなんだから、長年やっているライブラリより足りないものが
あるに決まってるだろ。
C++のメモリ取得開放は遅いから(GCの方が早い)、独自メモリ管理は
やっている所もあるじゃないか。

346 ：291：2006/09/21(木) 23:13:21 ID:NSl3TVGi

>>337
描画完了を待つにはどうやるの？全裸で。じゃなくてＤＸ７で。

347 ：名前は開発中のものです。：2006/09/21(木) 23:16:30 ID:HLxN0OV5

画面更新で自動的に待つことになる。
普通は待たないですむように作る。
同じバッファの使い回しとかDX8以降は出来るが7はしらね。

348 ：名前は開発中のものです。：2006/09/21(木) 23:32:56 ID:HLxN0OV5

>>302
とりあえずここらへんを参考に
ttp://gamdev.org/w/?%5B%5B%A5%E9%A5%A4%A5%D6%A5%E9%A5%EA%5D%5D

349 ：291：2006/09/21(木) 23:57:31 ID:NSl3TVGi

テクスチャを５０で全部独自に確保させたがダメだ。
なんかダメポです。解決不能。ってか、スリープ入れると直るってことはあれですね。描画未完了？
ＤＸ８に移るしかないようです。

350 ：名前は開発中のものです。：2006/09/22(金) 00:04:13 ID:ZBffE3Vt

なんでいまさら８？
素直に９に行きなさいナ。

351 ：291：2006/09/22(金) 00:12:27 ID:FzUiG/+d

９だとGefo2が対応してないでしょ。
ビデオメモリ３２Ｍ世代の。

352 ：名前は開発中のものです。：2006/09/22(金) 00:12:35 ID:AFaA2CK2

>>345
いや、それをあえてここでやる意味がわからん。
みんなで新しいライブラリを考えようってのならわかるが、
現時点で既存より劣ってるものについて語る意味ないと思うんだけど？

ああ、別に>>302の人が駄目っていうんじゃなくて、
俺等にとってLunaと>>302のLibと違いがあるかっていうとないでしょ？
この状況ならLunaのリンク貼ってLunaについて考えるところからはじめたほうがよっぽど先へ進むじゃん。
>>302ってLunaと作りが違うわけでも新世代（？）ライブラリでもなく、あくまで既存のラッパーの域を
でてないじゃん。ちなみにLanaがいいというわけではなくてあくまで既存の代表という意味で名前は使った。
ここでの例は別にソースが公開されているなら他のライブラリでも一向に構わないと思う。

353 ：名前は開発中のものです。：2006/09/22(金) 00:16:04 ID:mkbMBLxG

>>351
え、普通に対応してるでしょ。

354 ：291：2006/09/22(金) 00:17:00 ID:FzUiG/+d

よくキャラクタごとにDrawPrimiじゃなくて、１回でやった方がいいってあれって、
それによってＣＰＵの消費時間が減るとあるけど、
頂点情報を描画用頂点バッファに入れなきゃならないから、
その頂点を入れる作業と、いきなりDrawPrimiを実行するのとでは、
ＣＰＵが消費する時間は同じ以下だと思う

355 ：名前は開発中のものです。：2006/09/22(金) 00:17:49 ID:ZhhHldQ9

>>344
DEBUG_NEW でぐぐれ。

356 ：名前は開発中のものです。：2006/09/22(金) 00:52:07 ID:AFaA2CK2

>>355
ありがとう！
ところで非MFCの場合ってどうやるの？

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF|_CRTDBG_LEAK_CHECK_DF);

これ↑でやると肝心の場所がさっぱりわからないんだけど・・・。

357 ：名前は開発中のものです。：2006/09/22(金) 00:56:34 ID:AFaA2CK2

すまんみつけた。

リンクとサイトが消滅したときのために引用。
リンク
http://daybreaks.exblog.jp/m2006-04-01/#3421733

以下引用･･･・・・・・・・・・・・・・・・

CrtSetDbgFlagの力でメモリリークを撲滅！
使い方は簡単。
まず
#define _CRTDBG_MAP_ALLOC
#include ＜stdlib.h＞
#include ＜crtdbg.h＞

その後Main関数の最初に
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

を記述するだけで、デバッグ終了時に、何番目のnewで得たメモリがリークしているか出力してくれます。
後は
_CrtSetBreakAlloc( n );
でn番目のメモリ確保にブレークポイントをセットして、それが何なのか確認してやればオッケー。
もっと早く知ってれば楽できたのにー

358 ：名前は開発中のものです。：2006/09/22(金) 03:24:51 ID:hMj4THWP

>>354
なんで突然そんなこと言い出すのか分からんが、そんなネタは散々既出で
NVIDIAなんかが計測したデータも公表している。
っていうか、頂点バッファに書き込む処理なんて無視できるほど小さい。
それよりDrawPrimitiveのオーバーヘッドが物凄くでかい。

359 ：名前は開発中のものです。：2006/09/22(金) 03:33:55 ID:bWdUmn2S

>341
手を入れていくって……
現時点でバグってるって言いたいんだが。
FILOで使わないとまともに動かない。

この設計の拙さ、コンシューマーの人というかもっと若い、中とか高ぐらいに感じる、

360 ：名前は開発中のものです。：2006/09/22(金) 06:33:42 ID:AFaA2CK2

>>358
まあ、どっちにしてもシェーダごとテクスチャごとに切り替えるしかないんだけどな。
１回でやれも糞もシェーダが違うんだから、DrawPrimitive呼ぶしかないって状況のほうが多いな。

361 ：291：2006/09/22(金) 07:03:57 ID:FzUiG/+d

>>358
ＧＰＵにレンダリングをやらせてる間は、ＣＰＵは次の処理がされるんじゃないの？
並列に処理されるんじゃないの？

362 ：名前は開発中のものです。：2006/09/22(金) 07:52:19 ID:ttaHMyE5

>>頂点バッファに書き込む処理なんて無視できるほど小さい。
PCI-Expressならともかく AGPx4とかAGPx8の時代だとかなり遅くなるお

363 ：名前は開発中のものです。：2006/09/22(金) 08:03:13 ID:n5kn1hns

AGPメモリにマッピングされている限り、
書き込み処理のアクセス速度はメインメモリと変わらない。
遅いとか言っている奴はVRAMにいちいち送信していたりと、
使い方が分かっていない>>362のようなアホだけ。

364 ：名前は開発中のものです。：2006/09/22(金) 08:10:08 ID:ttaHMyE5

>>363
すまん、VRAMを経由しない方法教えてくさい…FPSが出なくてこまってた

365 ：名前は開発中のものです。：2006/09/22(金) 08:15:02 ID:Lw2G2Q/B

USAGE_DYNAMIC

366 ：名前は開発中のものです。：2006/09/22(金) 08:41:37 ID:ZBffE3Vt

D3DLOCK_DISCARD

367 ：名前は開発中のものです。：2006/09/22(金) 08:45:04 ID:ZBffE3Vt

>>360
だから既存のWindowsのゲームもポリゴン数を
増やすことはたやすいがオブジェクト数を増やすことは非常に難しい。

368 ：名前は開発中のものです。：2006/09/22(金) 08:48:16 ID:Lw2G2Q/B

そこでマテリアルソートとかの話が絡んでくるのだが
そういう処理をやってる日本製のライブラリを(現場以外で)見たことがないのだが

369 ：名前は開発中のものです。：2006/09/22(金) 09:07:11 ID:ZBffE3Vt

マテリアルソートはテクスチャ切り替えは減るけど、
シェーダーが変わるときはやっぱりだめじゃね？

データ作る段階で１キャラ１テクスチャで作ったほうが早いような。
1024x1024とかのテクスチャも余裕でいけるんだし。

370 ：名前は開発中のものです。：2006/09/22(金) 09:30:58 ID:ZaJMS9tT

CPUに余裕のある時はそれでもいいけど、速度が出なきゃ品質落としてでも
マテリアルまとめて大量のオブジェクトを一つの頂点バッファにブチ込んだりするワケよ。
ちゅーかこの話題は最適化すべきシーンを明確にしないと荒れるから
DP呼び出しは少ない方がいいですハイそーですかで終わって欲しいんだけど…。

371 ：名前は開発中のものです。：2006/09/22(金) 09:34:03 ID:Lw2G2Q/B

>>369
揚げ足とってるみたいになっちゃうけどシェーダでソートしないとは言ってない。
つかシェーダで完全ソートすりゃテクスチャ切り替えは出てくるし
その辺何が最も高速かなんてのは状況次第で幾らでも変わる

372 ：名前は開発中のものです。：2006/09/22(金) 09:52:09 ID:FzUiG/+d

371 ：名前は開発中のものです。：2006/09/22(金) 09:34:03 ID:Lw2G2Q/B
　　状況次第で幾らでも変わる
　￣￣￣|/￣￣￣￣￣￣￣￣
　　　　 ∧＿∧
　　　　( ',:`_´：) 　　　∧＿∧
　　　／　　　＼　　（´∀｀　）ﾊﾊﾊ
.＿＿|　|　　　 .|　|＿　/ 　　　ヽ
||＼　￣￣￣￣　　／ .|　　　|　|
||＼..∧＿∧　　　(⌒＼|_＿./ ./
||.　（　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽアホか　　　　　＼| 　（　´_ゝ`）　じゃ出てくんなよ
　　|　　　　　ヽ　　　　　　　　　　＼/ 　　　ヽ.
　　|　　　　|ヽ、二⌒) 　　　　　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_＿./　/

373 ：名前は開発中のものです。：2006/09/22(金) 10:05:27 ID:ZBffE3Vt

>>371
そもそもボーン使うときはソートも何もねーしな

>>302
とりあえず現状ではまだ未完成なんだし、
なるべく早い段階でEL/DX/Lunaと並べるくらいまで作ったうえで、
独自の利点を考えていくくらいでいーんでない？

上記3つのライブラリでまともに3DサポートしてるのはLunaだけだが、
LunaにはBSPは実装されてないし、シーングラフもないから
オブジェクトのソートみたいなこともおまけ程度にしかついてないし。

ビューフラスタムでのカリングとオクトツリーのフィールド描画はあったけど。

374 ：名前は開発中のものです。：2006/09/22(金) 11:49:56 ID:DORsqBmh

おまいらは口内発射動画でも見とけ！(´Д｀*)
http://chinkame.ath.cx/uploader/src/up0014.jpg

http://chinkame.ath.cx/uploader/src/up0014.wmv

375 ：362：2006/09/22(金) 12:15:52 ID:Cod4Un3V

>>365-366
ありがとうございます。微妙に改善できました。

376 ：名前は開発中のものです。：2006/09/22(金) 13:08:43 ID:nltIXCgA

ありえねぇ

377 ：名前は開発中のものです。：2006/09/22(金) 15:01:31 ID:Tw50U/1F

簡単にお金稼ぎ！！！

以下の手順でやれば、無料でお金稼ぎができます。
企業も広告の宣伝になるから、お金をくれるわけです。
最初の１日目で 2000 円～3000 円は確実に稼げます。
実際の作業は数十分程度、１時間はかかりません。

① http://www.gendama.jp/invitation.php?frid=470908
　　　　↑このアドレスからサイトに行く。
②そこのサイトで無料会員登録（応募）します。
　（その時点で 500 ポイントが貰えます。)
　※事前に新規でヤフーなどのフリーメールアドレス
　を取っておくといいですね。
③ポイントを稼ぎます。
　懸賞の応募や無料会員登録などをする事によって
　１日目で約 20000 ポイントは GET できます。
④ 3000 ポイントから、現金や WEB マネーに交換できます。
⑤トップの右上に「交換」という所がありますので、
　そこから交換をしましょう。
　その月に初めてポイントバンクにポイントを移行した時、
　さらに別途として 1000 ポイント貰えます。

これで現金や WEB マネーを稼ぐといいですよ！！！

378 ：名前は開発中のものです。：2006/09/22(金) 16:02:59 ID:TfYxVfg6

よく解らんのですが、もうすぐDirecrX10.0?がでたら今のDirectX9.0勉強は
無駄になるってことですか？

379 ：名前は開発中のものです。：2006/09/22(金) 16:09:30 ID:iijsCJm6

>>378
無駄にはならない
関数消えたり引数変わるのはいつものこと
固定機能の関数は消えるけどシェーダとして引き継がれる
基本は変わらないよ

380 ：名前は開発中のものです。：2006/09/22(金) 16:11:29 ID:TfYxVfg6

>>379
ありがとうございます
安心しました

381 ：名前は開発中のものです。：2006/09/22(金) 21:23:26 ID:ZBffE3Vt

Vista専用のDX10が一般に普及するまで3年くらいかかるだろうしねー

382 ：名前は開発中のものです。：2006/09/22(金) 21:31:47 ID:UO4OwrjN

まぁDirectX自体が低レベルなAPIだけどな。

383 ：名前は開発中のものです。：2006/09/22(金) 21:33:11 ID:UO4OwrjN

>>382
低レベルなのはお前の頭だろｗｗｗ

384 ：名前は開発中のものです。：2006/09/22(金) 21:36:52 ID:+bp4fGt2

志村ーID！ID！

385 ：名前は開発中のものです。：2006/09/22(金) 21:45:25 ID:AFaA2CK2

>>373
だったら、Lunaを使えといいたい。

386 ：名前は開発中のものです。：2006/09/22(金) 21:50:49 ID:AFaA2CK2

>>370
さすがにそれはデザイナが作りこんだクオリティがすべて無駄になってしまうからやらないと思う。
カメラを下に向ける（あんまり広い範囲を描かない）とかそんな対応になると思う。
ちょっと近づくとキャラに関しては髪の毛、肌、服（鎧）ぐらいはシェーダが切り替わってるから
マテリアルソートは俺のところはやってない。（無駄っしょ。α物関連のソートも含めるとやる意味なさげ）
そもそもデータ出してみたら同じシェーダを設定してること事態少ない。

387 ：名前は開発中のものです。：2006/09/22(金) 23:44:07 ID:9ULI2Lw/

>>382-383
これは酷い

388 ：名前は開発中のものです。：2006/09/22(金) 23:52:23 ID:aND7GHAp

>>382-383
わろすw
とりあえず市ねw

389 ：名前は開発中のものです。：2006/09/23(土) 00:28:35 ID:GYfaIXhj

低級なAPIって言ったら通じたかね？

390 ：名前は開発中のものです。：2006/09/23(土) 00:53:34 ID:lErZFtkU

通じなかったと思うｗ

よりハードよりのAPIって言ったほうがいいんでない？

低級＝アセンブラ
高級＝JAVA

くらいの感じで。

391 ：名前は開発中のものです。：2006/09/23(土) 02:13:15 ID:6PuG3s8F

>>390
それだと彼にはただのjava信者にしか見えないだろうｗ

392 ：名前は開発中のものです。：2006/09/23(土) 02:28:49 ID:uPOLW/0M

>>291
いっぺんソースさらしてみ？

393 ：名前は開発中のものです。：2006/09/23(土) 03:06:56 ID:2edMqpIz

Nです。
タスクシステムって将来的に必要ですかね？個人的にはソース追いにくく感じるので
実装どうしようかまよってるんですが皆様どうでしょう？

394 ：名前は開発中のものです。：2006/09/23(土) 03:15:25 ID:MnwVaaoo

ここはDirectXスレなので設計論とかはこういうスレに行ってきたほうがいいよ
http://pc8.2ch.net/test/read.cgi/gamedev/1155209226/

395 ：名前は開発中のものです。：2006/09/23(土) 03:22:58 ID:vLFfZIn0

>>394
>>302～>>342

396 ：名前は開発中のものです。：2006/09/23(土) 03:54:59 ID:MnwVaaoo

流れ的にそうかもしれないがスレ違いではあることは変わりないような…
って固くるしいのは俺もあまり好きじゃないので俺的意見を書くよ

N氏の意図しているタスクシステムは必要ではなさそうに見える。
ソース追いにくく感じるような場面で使われるタスクシステムならば使う必要がない。
そのタスクシステムは、どういう設計で、どういうことに対して使うことを想定してるの？

397 ：名前は開発中のものです。：2006/09/23(土) 04:50:19 ID:As545zCT

>>N
だからシーングラフ実装しれって。ゲーム上のオブジェクトをイテレーション
できる仕組みがあればいわゆるタスクシステムなぞいらん。

まあノンプリエンプティブな擬似マルチスレッド（Fiberみたいな）が使えると
スクリプト周りとかは何かと楽だが。

398 ：名前は開発中のものです。：2006/09/23(土) 08:35:20 ID:6PuG3s8F

そもそも俺はタスクシステム（擬似タスクって言われる奴？）自体いらんと思うのだけど、
っていうかタスクシステム自体何のために必要なのかいまいち理解できない。
ソースに記述しなくて、共通パラメーターを使うことでフィールドに追加するのが楽ってのはわかるけど
そのおかげでそれ以上にすさまじい数のバグを産むことになると思う。

例えば、アクションゲームでフィールドに「移動する足場壁付きの砲台」と「キャラ」があったとして、
ワンフレームの処理や判定は足場と壁の判定をもってる「移動する足場付きの砲台」の方からやらにゃならんよね？
この順序って確定してるし、必ずその順序でなきゃバグるよね？

移動する足場壁付き砲台の処理
キャラの処理

ね。これが

キャラの処理
移動する足場壁付き砲台の処理

になると普通にバグる。
ここで優先度とか設けるんだろうけど、ここが確定してるなら面倒でもソースに書いたほうがいいと思うんだけど？
なにより圧倒的にデバッグが楽。
なんだけど、妙なタスクシステムを作る奴って何故か減らないんだよなぁ・・・。
仕事で火消しに入ってやることの８０％はまずこれのシステムを止めさせることになってるんだけどｗ
てか、経験上、火消しが必要になるほどバグを出すのって原因のほとんどがこれ。
このシステム、死んだキャラの相互の関連をすべて無くして（まずこれをチェックするのがそもそも至難の業）
タスクからとりはずすのって結構難しいんだよな。

399 ：名前は開発中のものです。：2006/09/23(土) 08:40:50 ID:vLFfZIn0

↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

これらの書き込みから、このスレでDirectX以上の議論をするのは、
時期尚早であることが証明されました。

400 ：名前は開発中のものです。：2006/09/23(土) 08:54:05 ID:2luzFxgZ

Nです。DirectX以外の実装に関してはひかえるべきでしたすいません。
シーングラフについての実装についてですが、ほとんど理解がなかったのでいろいろを
調べましたがこんな感じでいいでしょうか？
まず木構造で行われる。例えば
　　　　　　　　　描画物
　　　　　　　|
------------------
| |
2D 3D
|
----------------
| |
ライト有　　　　　ライト無
| |
----------------
|
----------------
| |
モーション有モーション有
みたいなことでしょうか？

401 ：名前は開発中のものです。：2006/09/23(土) 13:26:16 ID:CX441kPl

描画処理を完全にシーングラフ内で処理するのもいいけど、
2Dの描画はレイヤーを分離して描画したい気もする。

402 ：名前は開発中のものです。：2006/09/23(土) 15:05:16 ID:LShRrPtb

なんでシーングラフを使うのか、というのは意識しておいたほうがいいだろね。

大昔のBASICのように上か順に描画命令を並べたほうがわかりやすいのは自明で
なんでそういうモデルを使わずに一度データ構造として表すのか。オブジェクト指向
ならオブジェクトにdraw関数を付けるんじゃなかったのかよ？とかそういうところ。

それはそのデータ構造を多目的に使うためなんだと思う。
衝突判定であったり、影のためにNパスのアルゴリズムを使うためだったり、
シリアライズのためであったり。(デザパタのvisitorパターンと同じ考え方)

DirectXは過去Retained ModeとかFahrenheiteとかその部分を作っては
放棄ということを繰り返してるわけだけども、今度のXNAはどうするのだろうね。

403 ：名前は開発中のものです。：2006/09/23(土) 16:08:53 ID:6PuG3s8F

なんだシーングラフって？
何をツリーにするか？ってのは作る奴次第？

描画順は色々な要素が絡んで順番が決定するし、
座標計算は親から辿ってく必要があるし、
内部処理はその物体の持つ意味によって処理順が変わるし、
ゲームで生成、消滅するインスタンスはそもそもツリーにする意味がないしで
全くわからんですな。

404 ：名前は開発中のものです。：2006/09/23(土) 16:20:20 ID:vLFfZIn0

まぁ、只のラッピングじゃないかと指摘されて、
余計な事まで手を出し始めたってとこだな。
やるのは勝手だと思うが、
そろそろDirectXと離れてきｒたので、
別スレでやった方がいい希ガス。

405 ：名前は開発中のものです。：2006/09/23(土) 16:45:08 ID:CX441kPl

正直シーングラフはなくてもいい要素だと思う。
単純に半透明のソートだけしてくれる機能があるならそれでいいと思う。

普通にゲーム作るとして基本的には、
１．背景（地形や天球など
２．キャラ（不透明
３．キャラ（半透明＋ソート
４．パーティクルなどの加算エフェクト
５．ウィンドウとか（２D

これから大きく外れることってないと思う。
どっちみち半透明のポリゴンを完全にソートは出来ないしねぇ。
せいぜいマテリアル単位でソートするのが限界でしょ。

406 ：名前は開発中のものです。：2006/09/23(土) 17:15:05 ID:uPOLW/0M

シーングラフってのはさ、結局のところ情報管理方法だから
DirectXとは直接関係ないし、描画まで行うライブラリの中で実装
しなくても良いいんだよね。

このスレで議論するんであれば、DirectXの情報をシーングラフで管理するとか。
LPD3DXMESH とか LPDIRECT3DTEXTURE9 とかを管理してて、描画とか必要な時に
自由に使えるようにする、管理するためだけのライブラリ。

407 ：名前は開発中のものです。：2006/09/23(土) 17:53:02 ID:F7d6H2tv

シーングラフってツリーの事でしょ
ハイトマップで視錐台に収まっている部分だけ描画するのに使う程度じゃねいの

408 ：名前は開発中のものです。：2006/09/23(土) 18:10:16 ID:LShRrPtb

シーングラフはツリーに限らないよ。

つ http://en.wikipedia.org/wiki/Scene_graph

要約すると、シーングラフの実装はアプリによって千差万別。何か決まったルールが
あるわけじゃない。例えば、半透明ソートのためにオブジェクトを配列に入れれば
それはすでに単純なシーングラフだ。だから、シーングラフが必要かどうかというなら、
お前はもうシーングラフを作っている、と言えるだろうね。

409 ：名前は開発中のものです。：2006/09/23(土) 18:19:35 ID:6PuG3s8F

>>407
オクトツリーはオクトツリーで別にもってるよ。俺は。
座標計算は座標計算用のツリーでもつし、
敵セットは敵セットリスト。
味方セットは味方セットリスト。
・
・
・

って感じでもって
実体は線形のリストでもってＩＤでアクセスってしてる。
ツリーももちろん実体にアクセスするＩＤが入ってるだけ。

って感じ。

410 ：名前は開発中のものです。：2006/09/23(土) 18:39:57 ID:hn0c+x2R

ブラーとかキューブとかミラーっぽい処理とかで複雑に

411 ：名前は開発中のものです。：2006/09/23(土) 18:47:04 ID:6PuG3s8F

>>410
な。
「どうもつといい。」とかいう話じゃなくて
必要なときに必要なもんを手早くかき集めてこれるようにしておくのがベストだよね。

412 ：名前は開発中のものです。：2006/09/23(土) 18:55:18 ID:5JWF+Hio

女の子のキャラクターの髪の毛を自動で動かしたいのですが、何か良い方法ないでしょうか。
髪の毛を一本一本制御する必要は無くて、ロングヘアーに関節が２箇所ほどあるボーンが１本
通っていて、これを重力と慣性と空気抵抗を加味して、走ったときに勝手になびいたり首を
かしげた時に勝手に横方向に垂れたりするようにしたいのです。
せめて背中には勝手に髪がめり込まないように、それなりに辻褄の合った動きしたいのですが、
どういうやり方がありますか。
ポリゴン単位で当たり判定とか凄いことでなくても、だいたいでいいのですが・・・。

413 ：名前は開発中のものです。：2006/09/23(土) 20:22:45 ID:CX441kPl

ボーンにあわせたバウンディング持つ、
髪の毛の間接に適当な大きさの球を入れる。

この球と体のバウンディングを判定すればおおむねOK。
ロングヘアで腕を貫通とかの問題はあるけどな

414 ：名前は開発中のものです。：2006/09/23(土) 22:21:19 ID:5JWF+Hio

>>413
体も球にして大丈夫でしょうか。
体側は体のX方向にも複数球を設定するべき？でしょうか？
DCのジャスティス学園の委員長の髪程度の動きで良いのですが。

415 ：名前は開発中のものです。：2006/09/23(土) 22:28:51 ID:aqvKAN9/

そんな奴は知らない。

416 ：名前は開発中のものです。：2006/09/23(土) 22:31:47 ID:CX441kPl

>>414
ダレソレ

417 ：名前は開発中のものです。：2006/09/23(土) 23:32:20 ID:hn0c+x2R

ジャスティス学園は全然計算してなかったような気がする。

418 ：名前は開発中のものです。：2006/09/23(土) 23:36:07 ID:YgY24rUz

>>415-416
ヲタのヲタ叩きﾜﾛｽ

419 ：名前は開発中のものです。：2006/09/23(土) 23:43:53 ID:GYfaIXhj

君は想像力が豊かだ

420 ：名前は開発中のものです。：2006/09/23(土) 23:59:59 ID:5JWF+Hio

ジャスティス学園は計算で髪とか服のヒラヒラとかを動かしてるようでしたが・・・
別に何でもいいです、スターオーシャン３とかでも。

421 ：名前は開発中のものです。：2006/09/24(日) 00:38:40 ID:6Si9nPYM

この記事の「オリジナル物理エンジンによる挙動生成」は？
http://watch.impress.co.jp/game%2Fdocs/20060911/vp2.htm

422 ：名前は開発中のものです。：2006/09/24(日) 00:53:33 ID:WXa9HNUr

>>421
そんなの薦めてどうするんだｗ

>>412
とりあえず、めり込むとか摩擦とか抜きにして動きだけ実装してみ？
あとは角度に制限つけるだけで、それなりに見えるようになるから。

423 ：名前は開発中のものです。：2006/09/24(日) 02:18:41 ID:lOmzOYmw

>>422
う～む、角度で制限ですか・・・単にウロウロ歩き回るだけでなくて、かなり色んなポーズを取る
ので、もうちょっと何とかしたいです。
>>421のは良いですね～～、これのサンプルなんかがあれば最高なんですが。
背骨のボーンに対して焼き鳥状にカプセルを配置、髪は髪でボーンに沿うようにカプセルを配置、
お互いにめり込まないように調整、くらいが妥当ですけね・・・

424 ：名前は開発中のものです。：2006/09/24(日) 02:34:39 ID:WXa9HNUr

>>423
関節２つしかないのに大層な処理をしようとしてるな・・
っつーか、>>413 のアドバイスと同じ方法だろソレ。

425 ：名前は開発中のものです。：2006/09/24(日) 03:01:58 ID:lOmzOYmw

結局そうなりますね
関節の数ってこの場合あんまり関係なく無いですか。

426 ：名前は開発中のものです。：2006/09/24(日) 18:42:02 ID:WXa9HNUr

間接が２つしかないんだから、球や楕円とか使ってまともにコリジョンとっても
角度で制限つけても結果はあまり変わらんって話なんだけどね。

角度で制限つける方法って想像できてないでしょ？

427 ：名前は開発中のものです。：2006/09/24(日) 19:37:48 ID:D7IayF5T

ttp://www.watch.impress.co.jp/game/docs/20060911/vp2.htm

この記事の後半が参考になると思う

428 ：名前は開発中のものです。：2006/09/24(日) 19:40:17 ID:WXa9HNUr

おまえらどんだけVP2が好きなんだよｗ

429 ：名前は開発中のものです。：2006/09/24(日) 20:24:48 ID:lOmzOYmw

>>426
角度で制限って言っても・・・それなりに複雑になりませんか。
背中に背負ったコーン（を半分に切った奴）の中しかボーンが動けないようにするとか？
いい方法があるのなら教えて欲しいのですが・・・。

カプセル同士で髪が体にめり込まないようにする方法をチラっと考えていたんですが、
一方の端を固定したカプセル（頭から延びる髪の一つ目のボーン）と、動かないカプセル
（体に仕込んだカプセル）が接触した場合、髪の方のカプセルをどっち方向にどれだけ
回せば（押し返し処理）良いのかって言うのを求めるのはなかなか難しいですねぇ・・・

430 ：名前は開発中のものです。：2006/09/24(日) 20:30:44 ID:EjtbSy3J

とりあえずそういうオマケ的な部分より先にメインのゲーム部分を完成させたほうがいいと思う。

431 ：名前は開発中のものです。：2006/09/24(日) 20:38:13 ID:WXa9HNUr

>>430
もちろんソレは完成してるって前提で話をしてたつもりだが・・まさか？！

432 ：名前は開発中のものです。：2006/09/24(日) 20:53:54 ID:jk8oFInI

想像だけで意見してないで検証してみてはどうか？

433 ：名前は開発中のものです。：2006/09/24(日) 22:15:12 ID:lOmzOYmw

いや、もちろん（？）メイン部分は完成していますよ。
髪の動きが決め打ちなのが気になったので。
というか、逆にこういうのって先に検討するモノでは無いんですかね・・・

434 ：名前は開発中のものです。：2006/09/24(日) 22:28:25 ID:EjtbSy3J

あぁ完成はしてたのね。

俺はオマケ部分は完成してから作りこむようにしてる。

仕事の場合は最初から仕様に存在する事ももちろんあるが、
趣味でやるときはまず一通り動くものが出来てから考えてる。

とりあえずねじれを考えないのであれば基本的には重力の方向に移動だろう、
途中なんらかの対象にぶつかったときには衝突面の法線をみて、
移動ベクトルと法線の内積の結果と摩擦を考慮して移動させりゃいーんでないかね。

435 ：名前は開発中のものです。：2006/09/24(日) 23:28:32 ID:n7XSrkEJ

布とか髪の毛の動きを作るにはどうしたらいいでしょうか。

436 ：名前は開発中のものです。：2006/09/25(月) 00:06:39 ID:NrvaX8S3

>>435
とりあえず服を着て育毛剤を塗れ

437 ：名前は開発中のものです。：2006/09/25(月) 01:06:19 ID:NHljW9VB

>>435
デザイナにアニメーション作ってもらう。
スカートにもボーン入れる。
ちょっとした風でなびくようなのも基本的にはアニメーションをいくつか使ってランダムで再生、
大きく方向が決まるところだけはプログラムで方向だけ決めてやればいい。
基本的にデザイナにアニメーションをつけてもらうようにしたほうがそれっぽく（リアルではない）みえるようになると思う。

438 ：名前は開発中のものです。：2006/09/25(月) 03:07:33 ID:nEbV4eUB

>>435 ID:lOmzOYmwに教えてもらいなさい

439 ：名前は開発中のものです。：2006/09/25(月) 23:26:42 ID:QYE7zOPA

>>437
今流行りのImage Based Lightingみたいな志向ですね
まぁそんなもんなんでしょうね

440 ：名前は開発中のものです。：2006/09/26(火) 00:26:53 ID:t5GR+RIU

>>439
デザイナーにモーションつけてもらうのは、どちらかというと古典的ですよね？

441 ：名前は開発中のものです。：2006/09/26(火) 00:44:58 ID:rsRPRd4n

>>439
PlayStation時代からの超古典的な方法です。

442 ：名前は開発中のものです。：2006/09/26(火) 01:12:46 ID:F/nKPMBk

>>434
変形するメッシュの面単位で当たり判定っていうのは、自分の能力と学力を超えてます。ごめんなさい。
ttp://www.watch.impress.co.jp/game/docs/20060911/vp2.htm
なんだかコレが現実的な手段のように思えてきました・・・
重力の影響を受けるカプセル同士をバネで繋いで、体のカプセルにめり込んだらペナルティ法で押し返す。
というのでどうでしょう。コレが作れたらもっと髪のボーン増やしたくなる・・・服もこれで・・・

443 ：名前は開発中のものです。：2006/09/26(火) 01:22:40 ID:t5GR+RIU

>>442
好きな方法でやればいいじゃん。
VP2のやつは実際に製品になってるし安心してマネできるだろうよ。
間違ってもモゾモゾと動き続けるような実装にはしないように注意しなね。

444 ：名前は開発中のものです。：2006/09/26(火) 01:35:48 ID:F/nKPMBk

はい。それはそれで面白そうですが・・・
まあ適当にバネの力を減衰させれば良いんですよね・・・

445 ：名前は開発中のものです。：2006/09/26(火) 01:46:11 ID:rsRPRd4n

バネどうこうより静止摩擦を入れればいい。

446 ：名前は開発中のものです。：2006/09/26(火) 02:04:14 ID:Kf2gYv6b

>>440
技術畑での流行なんてヨーヨーみたいなもんです　たぶん

447 ：名前は開発中のものです。：2006/09/26(火) 02:08:15 ID:t5GR+RIU

>>446
好意的に読んでみたが、それでも意味が分からなかった('c_`;)

流行ってのは、どうでもいいのもあれば、本当に良くて流行ってるのもある。
そこは自分でちゃんと見極めないと損をするよ。

448 ：名前は開発中のものです。：2006/09/26(火) 09:59:06 ID:WPbuQpBx

なんでぼくのうぃｎ98ではだいれくとｘ10が使えナインdネスか？　　なめてるんｄねすか？

449 ：名前は開発中のものです。：2006/09/26(火) 10:51:27 ID:RUAaJjPG

>>448
なめてるんｄねすか？

450 ：名前は開発中のものです。：2006/09/26(火) 16:05:04 ID:t5GR+RIU

>>448
まあそう嘆くな。俺のうぃｎＸＰでも使えナインｄあ。

451 ：名前は開発中のものです。：2006/09/26(火) 19:47:51 ID:CLCy2jAZ

>>447
ヨーヨーとかミニ四駆って忘れた頃に流行りだすでしょ

452 ：名前は開発中のものです。：2006/09/26(火) 20:35:05 ID:8Apje/tA

リサイクルだよ。
延々と新規のネタを考え続けながら食っていけるわけねーでし

453 ：名前は開発中のものです。：2006/09/26(火) 20:57:47 ID:st98Ykji

バンダイと田宮模型のおかげだね。

454 ：名前は開発中のものです。：2006/09/27(水) 00:43:41 ID:oPt0tdFd

あの～～
今シェーダープログラムを勉強しています。
本を読みながら幾つかサンプルを見てみたのですが・・・
プログラマブル頂点シェーダーって、頂点に対するライティングも自分で実装しないといけないんですよね。
今まで見たサンプルは全部ライトの位置や色を定数で設定しておいて、シェーダー内でトランスフォームする時に
色も計算、みたいな事をやっているのですが・・・
これだと、固定機能パイプラインの時に使えていた、オブジェクトのマテリアルやライトの細かいプロパティが全部
無視されますよね・・・
SetMaterialやSetLightで出来ていた事を自作の頂点シェーダーで実現するのって、物凄く難しいんでしょうか？
スポットライトやポイントライト、それらが複数あった場合等、どうすればいいのかさっぱり判らないのですが・・・
vs1.1で、デフォルトのシェーダーと同じ動きをするサンプルって無いでしょうか。

455 ：名前は開発中のものです。：2006/09/27(水) 00:48:47 ID:JG2xorwT

>>454
普通にDirectXのサンプルをコピーすればＯＫじゃん。
とかなんでそういう頭がないんだろか？

456 ：名前は開発中のものです。：2006/09/27(水) 01:03:18 ID:oPt0tdFd

>>455
どのサンプルがそれに該当するんでしょうか。
LightingVSはvs2.0ですし、他の奴はちゃんとライティングをしてないようなのですが・・・
あ、ちなみに環境はDX9.0です。
出来ればアセンブラで書かれたやつが欲しいです。

457 ：名前は開発中のものです。：2006/09/27(水) 01:28:16 ID:JG2xorwT

>>456
BasicHLSLがいいんじゃない？
とりあえずこれを書き写してみるだけでどんなことやってるかわかるよ。
ちょっと足りないけど、何をやればいいかすぐにわかるよ。
まずはシェーダを読んで何やってるかわからないのがまずいと思うんだ。
一度わかればこっちのもの。

458 ：名前は開発中のものです。：2006/09/27(水) 01:31:11 ID:kQKFU2wr

もっと分かりやすいぴくちぇるちぇーだーって無い？

459 ：名前は開発中のものです。：2006/09/27(水) 01:36:14 ID:0+9eDEBa

DX9.;0を選んでいるのになぜVS1.1にこだわるのか。
DX10では廃止されるのになぜアセンブラのコードを求めるのか。

別に悪くはないけど気になった。
アセンブラで書いたからって別に処理速度が速くなったりはしないぞ。

460 ：名前は開発中のものです。：2006/09/27(水) 01:39:14 ID:JG2xorwT

>>459
めんどくせーよな。
何枚もにたようなもんつくらなにゃならんしポカミスバグ増えるし。
ＨＬＳＬがいいよね。

461 ：名前は開発中のものです。：2006/09/27(水) 01:51:27 ID:oPt0tdFd

>>457
ありがとうございます、BasicHLSLですか・・・まずはHLSLの勉強からですかね・・・
それにしても　覚えなくちゃいけないことは次から次へとやってきますね・・・
>>459
VS1.1に拘るのは、GeForce3あたりも動作対象にしたかったからで、アセンブラが良いと思ったのは
ネットで拾ったサンプル(アセンブラで書かれてる)に、ちゃんとしたライティングをくっつけたい
と思ったからです

462 ：名前は開発中のものです。：2006/09/27(水) 02:10:24 ID:8Db4Us8M

>>461
サンプルも見ない人がアセンブラのシェーダなんか覚えられる訳ない。
誰もハッキリくちには出さないけど、結局はそういうことだ。

HLSLはだいぶ楽にできるし一応アセンブラもできるから
これから勉強するならHLSLが妥当。もちろんVS1.1でも問題ない。

463 ：名前は開発中のものです。：2006/09/27(水) 04:48:56 ID:xvP1WVFa

いや、覚えるだけならアセンブラは簡単だと思うがw

464 ：名前は開発中のものです。：2006/09/27(水) 09:08:48 ID:0+9eDEBa

>>461
つーかさ流れ的にはVS1.1のアセンブラ＞HLSLって時代は流れてるんだから
VS1.1でアセンブラ使って作るってんなら素直にDx8のSDK使いなさいよ。

GeForce3で対応してるからとか一件いろいろなハードウェアをターゲットに
考えて作っています的な思考のやつ結構多いけど、そもそもGeForce3は何年前の
ビデオカードだと思ってるのか。すでに売ってないから入手するのも至難だろ。
世代的にも4世代も前のものだし。

どの程度のゲームを作るのかしらないが3Dがきっちりとしたもの作るなら
面倒な縛りもないDx9世代のグラフィックカード対応でいいだろ。
VS/PS2.0対応のグラボなんて2年前のノートPCにすら積んであるし、
対応ってだけなら1万円札1枚で買える程度のグラボだぞ。

あとDx8は定数レジスタが致命的に少ないから、
ポイントライトが入れられても３つ、その場合ボーン処理が出来ない、
つまり固定機能に比べても汎用面以外圧倒的に劣るって考えたほうがいいよ。

465 ：名前は開発中のものです。：2006/09/27(水) 09:22:22 ID:fX43VNtG

画面にボタンとか文字入力とかコンボイボックスは表示できますか＞

466 ：名前は開発中のものです。：2006/09/27(水) 09:39:55 ID:xvP1WVFa

それなんてトランスフォーマー？

467 ：名前は開発中のものです。：2006/09/27(水) 12:25:42 ID:oPt0tdFd

>>464
いや、その通りかもしれませんねえ
1.1しか動かないボードは切っても良いかもしれませんな

468 ：名前は開発中のものです。：2006/09/27(水) 13:01:36 ID:8Db4Us8M

>>464
いやいや俺がまだVS1.1の環境なんで簡単に切られては困る(;´д`)

でも、アセンブラじゃなくてHLSLにはしたほうがいいよ。

469 ：名前は開発中のものです。：2006/09/27(水) 13:15:14 ID:9N9aAOOu

しかしアセンブラも読めないと、厄介なことにハマることもあると思うぜ
リファレンスが充実してきたら大丈夫なのかもしれないが

470 ：名前は開発中のものです。：2006/09/27(水) 13:46:59 ID:8Db4Us8M

ピクセルシェーダで正しい結果が出なくてアセンブラで書いたことある。
シェーダのバージョンが低いほどコンパイルが完全じゃないことがあるね。

471 ：名前は開発中のものです。：2006/09/27(水) 21:15:09 ID:kQKFU2wr

アセンブラ版のなんてとりあえず載せてみた程度の物だし
Cg言語なんてのもあるくらいだしHLSLでいい。

472 ：名前は開発中のものです。：2006/09/27(水) 23:56:47 ID:0+9eDEBa

アセンブラつってもVS1.1程度のものはマニュアル見ながらでも
簡単に読める程度にしか命令数がそもそもないだろ。

これがPS2のVUとかなら死ねるが。

473 ：名前は開発中のものです。：2006/09/28(木) 01:09:42 ID:Qut+4z4R

>>472
ここはサンプルも見れないような初心者が集うところです。
少しは理解してあげてください。マニュアルなんか見ません。

いや、それは嫌味だとしても初心者にはHLSLだって怪しいのに
VSアセンブラは無理でしょ。変にそそのかさないでください。

474 ：名前は開発中のものです。：2006/09/28(木) 01:40:40 ID:EmxvHeW0

まぁVS1.1のアセンブラ使うくらいなら固定機能でやってろってこったな。

475 ：名前は開発中のものです。：2006/09/28(木) 02:20:44 ID:43BrdYyb

e:\デスクトップ\dx9animation\cd3dxobject.cpp(6): fatal error C1083: include ファイルを開けません。'DXUtil.h': No such file or directory
とか言われるんだけど、DXUtil.hって昔のヘッダか何か？

476 ：名前は開発中のものです。：2006/09/28(木) 02:26:06 ID:pbZl2D+n

もしかしたらサンプルのcommonフォルダに入ってるような奴かも…

そもそも何をビルドしようとしたの？そこらのWebに落ちてるサンプル？

477 ：名前は開発中のものです。：2006/09/28(木) 02:38:12 ID:43BrdYyb

かなり前にWebで拾ったサンプル。Commonの中にはDXUT.ｈが・・・

478 ：名前は開発中のものです。：2006/09/28(木) 02:50:11 ID:43BrdYyb

http://www.koders.com/c/fidE7D854F142664FD8BDB2EFCE54A42D2106EB47CA.aspx
こいつだったわ

479 ：名前は開発中のものです。：2006/09/28(木) 04:13:38 ID:Ks4kfiVt

マルチポストは止めろ

480 ：名前は開発中のものです。：2006/09/28(木) 12:31:29 ID:r3bgliNM

マルチポストを嫌う奴ってパソ通時代のオヤジだけだよな。
複数箇所の回答から一番有用なものを吟味するなんて今や当たり前なのに。
頭が堅くなって時代についていけなくなったんだろうね。

481 ：名前は開発中のものです。：2006/09/28(木) 12:59:07 ID:E+G8+8X8

うんにゃ違う。
マルチポストするやつは、どこか一カ所にしか返事をかないとか
返事も結果も書かないやつが多いから。

マルチポストであっても、その故を明記していれば俺は許す。

482 ：名前は開発中のものです。：2006/09/28(木) 13:09:22 ID:YQu14luC

バカにレスを与えないでください

483 ：名前は開発中のものです。：2006/09/28(木) 18:42:47 ID:nERzszfM

回答する側が人間だという想像が頭から抜け落ちている・・・。
確かにマルチポスト推奨はイマドキと言えるかも知れないｗ

484 ：名前は開発中のものです。：2006/09/28(木) 19:03:49 ID:7exZtWv4

情報処理能力の低い老害がなんか申しております

485 ：名前は開発中のものです。：2006/09/28(木) 20:08:12 ID:4xoDGQZb

マルチポストじゃなくて、セカンドオピニオンですよ！

しかし、2ch内でマルチポストしても、似たようなスレは
見てる人も同じだから意味ないよな。

486 ：名前は開発中のものです。：2006/09/28(木) 20:21:31 ID:oMbAyOJr

マルチポストによって、回答者にマイナス評価を受けるリスクを想像できないただの馬鹿。
結局は答えてもらえない確率を高くするだけ。

487 ：名前は開発中のものです。：2006/09/28(木) 20:31:19 ID:7exZtWv4

マニアは回答することでカタルシスを得るからそれはないね

488 ：名前は開発中のものです。：2006/09/28(木) 22:39:14 ID:Nlv1qsey

俺はマルチを見かけたら絶対教えない。

489 ：名前は開発中のものです。：2006/09/28(木) 22:44:09 ID:MNRQMggg

俺も別にマルチポストいいと思うけどね。
昔はみるところ決まってた（ＢＢＸ、ＢＩＯ１００、２ちゃん）から貼る必要が無かっただけで
今は俺、２ちゃんしかみてないからここはここの意見でいいんじゃない？

結局さ、難しい・マイナーな問題って本にも載らないし
載ってたとしてもわからない奴にはその情報がどこに載ってるかわからないし、
技術の伝承は掲示板でしかできないしで色んなところでログ残していくのが一番だと思うよ。

よくでる質問だからっていって話題にしないとしないままどこ探しても見つけられなくなっちゃうじゃん。

490 ：名前は開発中のものです。：2006/09/28(木) 22:48:56 ID:baBONFMD

こういう話でスレが伸びている時点で、反感をくらっているということ。
嫌がられてもやるというのなら、好きにすればいいだろう。

491 ：名前は開発中のものです。：2006/09/28(木) 23:33:48 ID:Dk3RCCMg

デスクトップ右下に出るポップアップとかスキンが使えるメッセンジャーとか、
半透明ウィンドウがあるとプログラムがスローダウンしちゃうんだけどなんかうまい方法ない？

492 ：名前は開発中のものです。：2006/09/28(木) 23:37:43 ID:cM5JOSMP

>>491
マシン買い替え

493 ：名前は開発中のものです。：2006/09/28(木) 23:41:24 ID:anfWJ5Tf

刷り込みだよね。よくよく考えると「回答してくれた人に失礼になる」理由がわからん。
「もう一方で回答が出たなら、こっちで答えなくてもいいよな？」って拗ねてんのか？

まぁ今更言ったところで、マルチポストを許さない土壌ができあがってしまっているんだけど。
ちなみに俺はマルチポストしたことないしするつもりもないよ。いろんなところで口をすっぱくして「マルチポストはいけません」って言われてたから。

自分もレスしておいてなんだけど、ゲームプログラマってこういう煽りで流され話が脱線しやすいよね。議論好きだからですか？

494 ：名前は開発中のものです。：2006/09/28(木) 23:58:14 ID:Dk3RCCMg

>>492
パワーは全然有り余ってる。60fps出てるのが3fpsとかになっちゃう。
DXUT使ってるサンプルは平気なんでソースを見てるんだが、ちょっと挫折気味。
そういえば大航海オンラインも同じ症状出てたかも。

495 ：名前は開発中のものです。：2006/09/29(金) 00:00:35 ID:oMbAyOJr

VistaでAeroを使えば解決。

496 ：名前は開発中のものです。：2006/09/29(金) 00:01:58 ID:N5SjyFNE

メッセージ処理を別スレッドにするとか？

497 ：名前は開発中のものです。：2006/09/29(金) 00:06:19 ID:ueQhqgX3

>パワーは全然有り余ってる。
スペック書かずにこう書く奴に限って（ｒｙ

498 ：名前は開発中のものです。：2006/09/29(金) 00:10:47 ID:paU00bjA

>パワーは全然有り余ってる。
たぶん電源ユニットが５００W以上。

499 ：名前は開発中のものです。：2006/09/29(金) 00:15:11 ID:+I5I2Dah

違うな、494はまだ10倍界王拳を残しているのさ

500 ：名前は開発中のものです。：2006/09/29(金) 00:19:34 ID:3ckC2oiR

CPUはAthlon64 3000+ ビデオカードはラデオンのX800 XL。
やってるのは800x600の画面クリアとfps表示の文字列数個のみだよ。
ちなみに、500Wの電源は持ってないし界王拳も使えない。

>496
なんで別スレッドにするんだ？

501 ：名前は開発中のものです。：2006/09/29(金) 00:24:29 ID:gYSr6WhV

だからAeroを使えば解決すると言っているだろう。

502 ：名前は開発中のものです。：2006/09/29(金) 00:27:16 ID:N5SjyFNE

タスクバーのポップアップでやたら処理が重くなるのは
昔からの定番みたいなもんなんだよ。

DXUTのサンプルがそうならないってほうが意外だった。

503 ：名前は開発中のものです。：2006/09/29(金) 00:30:27 ID:3ckC2oiR

原因はマルチサンプルだった。マルチサンプルをONにするとサンプルでも遅くなる。
バッファのフォーマットのせいでコピーが発生してるような気がするけど、正直わからん。

>501
すまん、一応配布予定なのでAero限定は無理だ。

504 ：名前は開発中のものです。：2006/09/29(金) 22:25:53 ID:N5SjyFNE

ところでN氏のライブラリはどうなったんだろうか

505 ：名前は開発中のものです。：2006/09/29(金) 22:55:00 ID:+W9NI1Pp

もういいって。

506 ：名前は開発中のものです。：2006/09/29(金) 23:00:27 ID:bQHZkLAr

DirectXの中で一番好きな関数はなに？

507 ：名前は開発中のものです。：2006/09/29(金) 23:22:29 ID:+I2r6/3e

CreateTeapot

508 ：名前は開発中のものです。：2006/09/30(土) 00:19:21 ID:DBE05lgj

喉が渇いた時に便利だよね。

509 ：名前は開発中のものです。：2006/09/30(土) 00:34:44 ID:sEeiZqED

CreateSakuratan

510 ：名前は開発中のものです。：2006/09/30(土) 06:08:14 ID:5xvehRtz

mikoto2xで吐いたXファイルを、シェーダーを介してボーン変形出来るようになったんすが、
どうもMikotoでの変形結果と同じにならない

調べたらMikotoのボーン変形は、関節部を潰さないようにかなり特殊な計算をしているみたいっすね
これってどうやってるのかな。シェーダーじゃ無理っすかね

511 ：名前は開発中のものです。：2006/09/30(土) 08:48:50 ID:QdcbVNXK

D3DXの高レベルAPIを使っているのなら、それをやめれば解決。
クオータニオンの補間がおかしいし、その他問題が沢山あるので使い物にならない。

512 ：510：2006/09/30(土) 10:27:47 ID:5xvehRtz

>>511
レスどうもっす
申し訳ないっすが、姿勢行列の補間は関係なさそうっす。シェーダーなんで頂点補間の部分は当然自前です

スキニングなんて誰がやっても同じ計算（ボーンごとに変形した頂点座標を、ウェイト値に基づいて再調整）に
なるわけっすが、どうやら他の算出方法もあるらしい。それをお尋ねしたい次第っす

それとも、あまり有名じゃないんすかね。検索しても全く出てこないっすし・・・
Mikotoオリジナルっぽい気がしてきましたわ。一体どうやってるんすかね

513 ：名前は開発中のものです。：2006/09/30(土) 11:13:00 ID:f6Ng8zSY

定番の方法は所詮線形補間だからな。
ちゃんとやるならそれなりに面倒なコトになるだろうけど、
線形補間でもちゃんと見えるようにデータを作るほうがいいと思う。

514 ：名前は開発中のものです。：2006/09/30(土) 12:41:48 ID:LWd9FNUh

手作業になるけど関節の間にわざと緩んだ骨を仕込むってのがあったなー。
このへんはCG屋さんに聞いてみるのも良いんじゃない？

515 ：名前は開発中のものです。：2006/09/30(土) 12:58:03 ID:ZLzDkOO3

>>510
間接部の回転角度の補間はクォータニオンで扱って初めてやれる処理なんで
行列の方（つまりxファイル形式）に落とし込んじゃうともう事実上不可能だと思う
実際にはミクロマンのひざ間接みたいな二つの骨の間を埋める小さい骨を何個かつくってる
…はず

516 ：名前は開発中のものです。：2006/09/30(土) 17:01:55 ID:1o8uqwbg

>>512
以前、mikotoの掲示板で「bdefアンカーによる影響ってどういう計算式？」
っていう質問があって、それに対してゆーり氏が
『秘密です。
　っていうのは嘘ですが、
　詳しく説明するのもアレなので、ヒントを。
　２個以上のアンカーに影響される頂点に対して、
　その頂点と互いのアンカーの面との距離で影響力を決定しています。
　アンカーの面は最低でも６つありますが、
　どの面との距離をとればいいかは想像つきますね？』
って答えてた。
結局、正確な計算式は不明。

517 ：名前は開発中のものです。：2006/09/30(土) 17:21:25 ID:ZLzDkOO3

>>516
すごくいいことを聞いた
横から㌧

518 ：510：2006/09/30(土) 18:15:01 ID:5xvehRtz

>>513-514
線形補間を詰めた方がｲｲって事っすね。ゲームですし、線形補間の方が速そうっすしね
ただあの綺麗な曲げは捨てがたく・・・

>>516
引用感謝っす。補間方法では無さそうっすが、ウェイトを決める方法っすね

>>515
なるほど、検索結果と合わせて何となく分かってきたっす
ボーンの回転中心を、頂点が結果的に円を動くような位置へと補間していけばいいんすね

おかげでなんとか出来そうです。皆さんレスありがとうございました

519 ：名前は開発中のものです。：2006/09/30(土) 19:34:59 ID:3Lp8oI6E

>518
確かにMatrixの線形補間の方がはやいけど、Quaternionで補間しても
誤差程度しか差は出ないよ。
肘、ひざ、肩とか必要な箇所だけ頂点の補間法変えればよし。

520 ：名前は開発中のものです。：2006/09/30(土) 21:05:20 ID:f6Ng8zSY

>>519
シェーダーでやるってことを考えるなら色々と最適化を考えても場所ごとに分岐はやめたほうがいい気がする。
ツール系は全部CPUで計算しちまっても問題ないがリアルタイムなゲームだと色々面倒だぞ。

521 ：名前は開発中のものです。：2006/09/30(土) 21:44:59 ID:3Lp8oI6E

>やめたほうがいい気がする。
「やってダメだった」じゃなくて「気がする」って事は
試してないって事でOK？

522 ：名前は開発中のものです。：2006/10/01(日) 01:15:18 ID:ogT2TFR+

シェーダーの方で球面線形補間を頂点ごとにやってやろうと思ったけど
クォータニオンをマトリクスへ落とすだけでほとんど命令数を使い切っちゃう感じで駄目ですた
なにか最適化する方法があるのかもしれないんだけど頭が悪いのでわかりません

そんなわけなんで骨と骨の間にそれらを半々の割合で球面線形補間した骨をあらかじめ
用意しておいて使うことにしたんだけど、そうすると今度はシェーダーへ渡すマトリクスの
数が2倍近く増えるんでレジスタ数の限界を考えてモデルの方で使えるの骨の数に
かなりきわどい制限がでてきてしまう始末

523 ：名前は開発中のものです。：2006/10/01(日) 01:24:03 ID:oVrgML5A

大抵はシェーダで2パスの処理するわけだし
2度も線形補間のコードをシェーダで通すくらいなら
CPUでやったほうがよくね？

ぶっちゃけ簡単だし

524 ：名前は開発中のものです。：2006/10/01(日) 01:49:58 ID:ogT2TFR+

確かに何回もDrawPrimitiveしなきゃならんとなると変形をすましちゃったものを
最初から用意しておいたほうが速くなる場合もあるね
そういうどーしょもない話がDirectX10だと解消されてくるわけだ

525 ：名前は開発中のものです。：2006/10/01(日) 01:52:50 ID:oVrgML5A

え、そーなの？それは知らんかった。
シャドウバッファとかやるときはどうすんだ？

526 ：名前は開発中のものです。：2006/10/01(日) 03:27:09 ID:JJz6bZ2w

ここはゲーム製作板なのに、レベル高いなぁ。

527 ：名前は開発中のものです。：2006/10/01(日) 12:46:08 ID:dPbmkgF9

シャドウバッファとかは素直に書くしかない。
CPUとGPUを比べた場合現状はGPUの特に頂点シェーダーは
よほどのことがない限り遊んでるから頂点シェーダー側で命令が増えるのは
そんなにペナルティにならないことが多い。

一般的にゲームを作っていて処理がきつくなるのはCPU負荷とピクセルシェーダー部分。
とくにDrawPrimitiveはGPUコマンド発行するだけだがこれがべらぼうにCPU負荷食う。
ここはDirectX10で緩和されると言われてるね。

>>522
確かにボーンが増えてそれを全部定数レジスタに入れようとすると結構厳しくなるね。
とくにVS1.1だとボーンなんて10本くらいがいいとこだから現実的じゃないね。

最低でもVS2.0くらいのレジスタ数は欲しいねぇ。

できればVS3.0にしてボーンのマトリックスをfp16/fp32のテクスチャにいれて、
頂点シェーダー内でボーンのマトリックスをテクスチャからサンプリングするという方法もある。
これなら3テクセルに1ボーン入るからかなりの量のボーンが使える、ハズ。

528 ：名前は開発中のものです。：2006/10/01(日) 12:54:03 ID:iXDGlJTF

モデリング時に頂点辺りの最大数を設定して最適化するしかない。

529 ：名前は開発中のものです。：2006/10/01(日) 12:57:10 ID:PqisUcBy

すいませんちょっと聞きたいことあります。
すでにDirectXで作ったゲームがあるんですが、
これをネトゲにしようかと思ってます。

そこで気になったことが１つあります。
うっかりウィンドウキーを押してしまうと最小化されてしまい、
その間にやられて死んでしまう可能性です。
人間同士の駆け引きを楽しむネトゲにしたいんで、
こういった部分は全て排除していきたいんです。

一応ウィンドウキーを無視するようにはできたんですが、
これはマナー違反みたいな意見もあるかと思いまして、
ちょっと迷っているところです。

つまり、
Ａ．ウィンドウキーを無効にしてゲームの快適さを優先
Ｂ．うっかりウィンドウキーを押して死んでしまってもＷＩＮのマナーを優先
どちらにすべきか・・・ということです。
個人的にはＡ．と思うんですが・・・。

よろしくおねがいします。

530 ：名前は開発中のものです。：2006/10/01(日) 13:02:43 ID:iXDGlJTF

余計なことはして欲しくない。
世に言うところの、小さな親切大きなお世話。
どうしてもやるんだったら、後から設定するオプション扱い。

531 ：名前は開発中のものです。：2006/10/01(日) 13:05:39 ID:PqisUcBy

>>530
なるほどオプションですか。
これならばウィンドウキーの有効・無効が自由にできますね。
そうするとデフォは普通にウィンドウキーが有効になっていて、
ネトゲに熱中しちゃう人はオプションで無効にできるから、
うっかり押しちゃって死ぬなんてことはない・・・と。

とてもいいアドバイスありがとうございました。

532 ：名前は開発中のものです。：2006/10/01(日) 13:09:47 ID:dPbmkgF9

・Windowsキーをブロックするのは確かにルール違反。
　だがやっているゲームも存在する。
　そもそもの問題としてキーフックはWindows2000以降でなければできない。

・ALT+TABをブロックするのはかなり嫌われるコトになるけどそっちをどうするのか？

・ALTキーを押したときに動作が停止しないか？

・タイトルバーをクリックしてウィンドウを移動させるときにゲームが停止しないか？

動作に関して気になるならこの辺も全部確認しとき。
ちなみに個人的にはWindowsキーやALT+TABは自己責任で
デバイスロスト状態からの復帰をきちんとサポートってのが好み。
普通はWindowsキーってそうそう押さないし。

533 ：名前は開発中のものです。：2006/10/01(日) 13:15:22 ID:bcMO92DK

>>527
頑張れば2テクセルでいけるな。
姿勢だけなら自由度6だから、6つのパラメータ有れば十分。
VSからテクスチャ参照するコストと、VS内で行列を生成するコストを
天秤にかけることになるが。

>>529
キーフックとかで無効にしてるのならやめよう。
DISCL_NOWINKEYでググるべし。

534 ：名前は開発中のものです。：2006/10/01(日) 13:18:22 ID:dPbmkgF9

>>533
姿勢で持つにしても別途移動と親からのオフセットは必要にならない？

535 ：名前は開発中のものです。：2006/10/01(日) 13:19:36 ID:PqisUcBy

>>532
>・ALT+TABをブロックするのはかなり嫌われるコトになるけどそっちをどうするのか？
これにつきましては何もしないつもりです。
ウィンドウキーは１つ押しただけでスタートメニューが出てしまうので、
こういった操作ミスによるキャラ死亡だけは避けたかったんです。
ALT+TABは2つ押すんで操作ミスはありえないと思ってます。

>・ALTキーを押したときに動作が停止しないか？
>・タイトルバーをクリックしてウィンドウを移動させるときにゲームが停止しないか？
これについては後で考えますが、
現在はフルスクリーンのみで動くようになってます。

>>533
現在はキーフックでやってますが、
これはいいのを教えてもらいました。　→DISCL_NOWINKEY
早速取り込んでみたいと思います。

ありがとうございました。

536 ：名前は開発中のものです。：2006/10/01(日) 17:20:55 ID:ogT2TFR+

>>523
DirectX10だと頂点シェーダー通った頂点をまたビデオメモリへ書き戻せるんだってさ
だから結構重たい変形処理を頂点シェーダーにやらせても次のパスではその結果を再利用できる

てか俺vs1.1で動かないといやなのにDirectX10とか何いってるんだろうね

537 ：名前は開発中のものです。：2006/10/01(日) 17:26:08 ID:iXDGlJTF

ビデオカード側が対応していないと、全部CPUでやることになるけどね。

538 ：名前は開発中のものです。：2006/10/01(日) 17:36:19 ID:dPbmkgF9

>>536
vs1.1を前提にするならそもそもレジスタが全く足りないので
ボーン処理は不可能と考えたほうがいい。

全部CPUでやるか固定機能でやるのが定番だな。

VS1.1ってGeForce3あたりだっけ？GeForce4も含まれるのかな。
どっちにしろそんな今となっては屑みたいなビデオカードをサポートすることで
クオリティを落とすというのはどうかと思うが趣味でやる分には別にいいのか。

GeForce3とかをHALでサポートするっていう前提の場合、
CPUも世代を合わせるとPen3の1000Hzあたりがターゲットってコトだよな。

日本は2D信仰が病的な程あるが、その強い影響で低スペックマシンを
前提として考える傾向が抜けないよなぁ・・・

低スペックマシンはオプションでギリギリ動くんじゃない？程度にしといて、
標準機能をは現行スペックにあわせて作ればいいのに。

539 ：名前は開発中のものです。：2006/10/01(日) 17:37:00 ID:dPbmkgF9

1000Hzじゃなくて1000MHzネ・・・

540 ：名前は開発中のものです。：2006/10/01(日) 17:41:36 ID:y/oaRnBb

>>538
↓で説教してきてください。

エロゲメーカーはいい加減低スペックPCを切り捨てろ
http://pie.bbspink.com/test/read.cgi/erog/1114845529/

541 ：名前は開発中のものです。：2006/10/01(日) 17:54:14 ID:7roD0klY

趣味でやる分には切り捨てても良い、の間違いじゃね

>>515
行列に落としても出来るっしょ
逆にXファイルにクォータニオンで持たせることも(標準テンプレ範囲で)可能

542 ：名前は開発中のものです。：2006/10/01(日) 18:02:29 ID:dPbmkgF9

いや業務でやる分にはとりあえず現行スペックにあわせて作ったうえで、
最終的には低スペックのマシンでも「表示がされなかったり動かなかったりはしない」
っていうレベルにしとけばいいわけだし。
切り捨てるっていうか基準を上にシフトさせるってコト。

そもそもvs1.1で作ったってGeForce2じゃHardwareTnLで動かんのだし。
MatroxG400じゃvsなくてもHardwareTnLで動かんわけだし、
作るときはこの辺でも全部「表示はされてゲームは動く」レベルには合わせるだろ。

まぁゲームのソースはビデオカードのサポート具合に合わせて
大量に機能毎の分岐やらシェーダー切り替えが出てくるケドナー。

543 ：名前は開発中のものです。：2006/10/01(日) 18:03:29 ID:iXDGlJTF

>>538
足りないというのは、一頂点辺りいくつのボーンを前提にして足りないといってるんだ？
固定で出来る数なら1.1で十分に対応できるんだが、いったい何の話をしているんだ？

544 ：名前は開発中のものです。：2006/10/01(日) 19:17:28 ID:dPbmkgF9

>>543
それはボーン数というかウェイト数だろう。
1回のDrawPrimitiveに使えるボーンの数が少なすぎるという話。

定数レジスタが96しかないんだからすべてをボーンに使ったって32本しか使えない。
だが実際には透視変換・ライティング・フォグ・テクスチャアニメーションなどの頂点処理で
レジスタを使わないといけないのだから１回のDrawPrimitiveで使えるボーンはせいぜい20本がいいトコだろ。

vsで凝ったことをするほど1回のDrawで使えるボーンの数が減っていくんだよ。
逆に凝ったことをやらないなら固定機能で十分なわけだ。

545 ：名前は開発中のものです。：2006/10/01(日) 19:29:57 ID:iXDGlJTF

それはGeforce系でMaxVertexBlendMatrixIndexの数を確認した上での発言か？

546 ：名前は開発中のものです。：2006/10/01(日) 19:37:58 ID:6J1M+7ut

Vistaが出るからこれからのメーカ製PCのグラフィック機能も底上げされる

といいな

547 ：名前は開発中のものです。：2006/10/01(日) 19:55:43 ID:LpXzSsQ4

底上げされても結局OSにパワー食われてしまうのでは？
と不安です。

548 ：名前は開発中のものです。：2006/10/01(日) 20:06:55 ID:4Fg07nio

どうせAeroは切れるし底上げしなきゃ喰われて死ぬしｗ

549 ：名前は開発中のものです。：2006/10/01(日) 20:13:34 ID:dPbmkgF9

>>545
とりあえずGeForce6600

固定機能ライト数： 8
ブレンドマトリックス数： 4 ← MaxVertexBlendMatrices
ブレンドマトリックスインデックス数： 0 ← MaxVertexBlendMatrixIndex

頂点シェーダー定数数： 256
頂点シェーダーバージョン： 3.0
ピクセルシェーダーバージョン： 3.0
動的フロー制御命令のネスティング： 24
静的フロー制御命令のネスティング： 4

DirectX9世代のビデオカードでは固定機能はもうサポートされてないね。
メーカーの言うとおり全部シェーダーでやれっていうことなのだろう。
DirectX8世代はサポートしてるらしいけどねぇ。

そういうメーカーやAPI側の問題も踏まえたうえでDirectX8＝vs1.1は使い物にならんと言ってわけだが。
ちょっと言い方に問題あったな。
固定機能は除外してくれ。

VS2.0ベースで作って対応してなきゃD3DCREATE_MIXED_VERTEXPROCESSINGと
SetSoftwareVertexProcessing()で分岐って感じがいいと思うけどが一般的じゃないのかねぇ。

550 ：WindowsVista：2006/10/01(日) 20:14:59 ID:QL6n0Hv/

Radeon X以下の性能のベデオカード搭載機なんてＰＣである資格はありませんですぅ＞＜

551 ：名前は開発中のものです。：2006/10/01(日) 20:41:42 ID:ogT2TFR+

くだらない煽りあいはもういいよ

>>541
＞行列に落としても出来るっしょ
どうやるか教えてください！

552 ：名前は開発中のものです。：2006/10/01(日) 21:10:25 ID:9AU5rKoE

モデル読み込めてシェーダーも知識不要でテクスチャ読み込ませるだけで作成できて
プレビューもできるようなソフトない？

553 ：名前は開発中のものです。：2006/10/01(日) 21:29:58 ID:oVrgML5A

>>536
あー、なるほど。そういう仕組みなのか。
最近新しいことについていけねーよ・・・悪い傾向だなぁ

554 ：名前は開発中のものです。：2006/10/01(日) 22:32:09 ID:IrowYbpc

5000円もしないＦＸ5200w＠2z4i4b＠ewXPよりかるいのに
底上げとかないだろ

555 ：名前は開発中のものです。：2006/10/01(日) 22:56:16 ID:lU6LhM6k

高いイメージがあるグラボも中古で探せば意外と安かったりする。

後はまぁ、規格が合うか調べる能力とか
コンピュータの蓋を外して中を弄ることについての多少の努力とか

556 ：名前は開発中のものです。：2006/10/02(月) 00:53:03 ID:OdW/jKpG

>>552
Unreal Editor
半分マジレス

557 ：名前は開発中のものです。：2006/10/02(月) 01:31:38 ID:kV9hqfDm

>>556
今出回ってるUE2はシェーダー関係一切使えない
マトモにUE3使ってエディタ外さないタイトルはUT2k7
すなわち来年

FarCryのエディタで代用できそうだけどメンドイ
誰か作れ

558 ：名前は開発中のものです。：2006/10/02(月) 02:38:01 ID:7H4MMFEr

サンプルのShadowMapをいじってまして、これはデフォルトではスポットライトみたいな
効果が出るのですが、無限遠光源の表現に改造しようとしています
とりあえずg_mShadowProj(光源から見た場合の射影行列)を正射影で作るようにしてみた
のですが、細かいシマシマが出るようになってしまいました。
何となくShadowMap.fx内のsourcevalsをいじっているあたりが怪しいと思っているのですが、
よくわかりません。
一応シャドウマップの原理は理解したつもりなんですが、ここは何だか難しい事をやってるようで。。。
どう直したら良いのか教えて下さい。

559 ：名前は開発中のものです。：2006/10/02(月) 08:59:30 ID:OdW/jKpG

>>557
をいをい…「シェーダー関係」ってHDRとか法線マップ使えないと
「一切使えない」ってことになるのか？
UEDのマテリアルエディタ触った事ある？
描画パスの勉強するには必要充分なシェーディング機能だぞ。

560 ：名前は開発中のものです。：2006/10/02(月) 09:14:15 ID:aFY/cqAR

>>558
簡単にいうと、遠近射影と正射影とでは誤差の乗り方が違うのよ。
とりあえず SHADOW_EPSILON を 100倍にしときなさい。

561 ：名前は開発中のものです。：2006/10/02(月) 10:11:45 ID:CTih6+Zy

正射影でシャドウマップを作る場合は、wで割らない方がいいのですか？

562 ：名前は開発中のものです。：2006/10/02(月) 10:36:11 ID:aFY/cqAR

>>561
正射影の場合 w は常に1だから、深度値は常に線形になる。
遠近射影の場合は、wで割ると深度値が非線形になる。(一応線形で求めることもできる。)
非線形だと、遠くの方ほど深度の変化が緩やかになるから、
そのサンプルだとたまたま、極少のバイアスでもうまくいってるんだと思う。
一方で線形は、深度値を頂点シェーダの方で求めても正しく補完されるメリットがあるみたい。
とりあえず正射影なら線形一択ね。

563 ：名前は開発中のものです。：2006/10/02(月) 10:55:48 ID:CTih6+Zy

>>562
thx!
だけどホントはｗで割る理屈が勘でしかわかってないから、線形と非線形について調べます。m(_ _)m

564 ：名前は開発中のものです。：2006/10/02(月) 11:20:01 ID:IdJRfXBf

>>560
ありがとうございます！
もっと大きな値(0.01とか)で上手く行きました。
このサンプルではライティングをピクセルシェーダーでやってるのですが、これは何か意味があるんでしょうか？
仕組み上こうするしかないんですか？

565 ：名前は開発中のものです。：2006/10/02(月) 12:52:14 ID:aFY/cqAR

>>564 スポットライトの内外判定を正確にするためね。

566 ：名前は開発中のものです。：2006/10/02(月) 13:07:48 ID:IdJRfXBf

>>565
なるほど。。。
ありがとうございました。すっきりしました。

567 ：名前は開発中のものです。：2006/10/02(月) 21:44:16 ID:CTih6+Zy

>>562
遠近射影の場合のｗの導出式はあるのでしょうか？

何となく
ｗ＝ｋＺ　（ｋは定数）

みたいな気がしているのですが、これから

Ｚ＝ｗ/ｋ

になってしまうので、変な気がするのですが…

568 ：名前は開発中のものです。：2006/10/02(月) 22:25:57 ID:aFY/cqAR

>>567
詳しくは下を見てね。
http://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/directx9_c/directx/graphics/reference/d3dx/functions/math/d3dxmatrixperspectivefovlh.asp
Zp = (Zv - near) / (far - near) * far, Wp = Zv ね。
Zv = near～far を遠近射影で変換すると
Zp = 0～far, Wp = Zv になって、
depth = Zp / Wp で、(非線形の)0.0～1.0になるわけね。
ちなみに depth = (Zv - near) / (far - near) だと(線形の)0.0～1.0ね。
シャドウマップの深度値を非線形で求めるメリットってあまりないと思うから、
後者の方でいいと思うけどね。
(PSMとかの場合はどうしても非線形になるけど)

569 ：名前は開発中のものです。：2006/10/02(月) 22:46:34 ID:CTih6+Zy

>>568
ｻﾝｸｽ！分かるようにがんばってみます。

＞depth = Zp / Wp で、(非線形の)0.0～1.0になるわけね。
の「非線形」というのは、Zp と Wp の２変数の関数になっているから
「非線形」なのですか？

＞ちなみに depth = (Zv - near) / (far - near) だと(線形の)0.0～1.0ね。
こちらは Zv の１変数だけの関数だから「線形」なのですか？

570 ：名前は開発中のものです。：2006/10/02(月) 23:38:14 ID:aFY/cqAR

>>569
グラフにしたときに
y=ax みたいに直線になる(均等に変化する)のがそこで言う線形で
y=1/x みたいに曲線になるのがそこで言う非線形ね。
深度値が線形変化だと、頂点間のパラメータ補間も線形補完だからそりがあうのね。
後は自力で頑張ってねｗ

571 ：名前は開発中のものです。：2006/10/02(月) 23:42:29 ID:CTih6+Zy

>>570
がんばります

572 ：名前は開発中のものです。：2006/10/03(火) 00:59:45 ID:DSdGAOLr

ttp://www.nomuraz.com/denpa/prog006.htm#IDPROG0034
ここを読んでクロスシミュレーションを勉強しています。
基本的な理屈は分かったのですが、これだけだと、例えば棒の上に布を被せた
場合、最終的には布が棒に完全にフィットしてしまう事になります。
もうちょっと末広がりのスカートにクロスシミュを適用させたいと思っている
のですが、広がった状態を保つのに何か良い方法はないでしょうか。

573 ：名前は開発中のものです。：2006/10/03(火) 01:18:57 ID:7Ux3dkLn

下から風を当て続ける

574 ：名前は開発中のものです。：2006/10/03(火) 01:42:04 ID:DSdGAOLr

このやり方だと下から風を当ててもスカートが膨らむ訳ではないんですよ。上下になびくだけで。

575 ：名前は開発中のものです。：2006/10/03(火) 01:45:32 ID:7Ux3dkLn

あらﾎﾞｹにﾏｼﾞﾚｽが付いてしまった・・(´Д｀lli)ゞ

>>572 の方法を見てないんだが、ベースとなるモデルでスカート広げといて
それである程度制限つけて何とかならないものかなあ？

576 ：名前は開発中のものです。：2006/10/03(火) 02:19:05 ID:vWVbEwXE

スカート着せないでスク水着せるってのはどうだろう？

577 ：名前は開発中のものです。：2006/10/03(火) 02:23:39 ID:DSdGAOLr

そうなんです、「なるべく元のメッシュの形に戻る」というのをやりたいんです。
上の方法は、隣り合う頂点同士がばねで結合してあって、各頂点が重力や風の影響を
受けて動きつつ、お互いに引っ張り合う　というような簡単な実装なんですが、
これをどう発展させれば良いのか・・・
単純に「各頂点は元居た位置に戻ろうとする」みたいなルールにすると、想像しただけで
変な動きになりそうな・・・。

578 ：名前は開発中のものです。：2006/10/03(火) 02:27:28 ID:vWVbEwXE

だよね。
巨乳やめてひんぬーにすれば乳揺れ演算の手間が省けるし萌えもアップする

579 ：名前は開発中のものです。：2006/10/03(火) 02:28:45 ID:DSdGAOLr

ちょっと、なるべく前向きに考えていきたいのですが・・・

580 ：名前は開発中のものです。：2006/10/03(火) 02:50:14 ID:aoBC2TiS

ID:DSdGAOLrよ。
スカートのシミュレーションはDirectXとは直接の関係はない。
かろうじて３Dというキーワードで関連性があるだけだ。
いい加減ここで論じてもネタになるだけだと気づけ。

真に技術的な話をしたければオマエにピッタリのスレがあるから、
↓↓↓↓↓↓↓↓↓紹介してやる↓↓↓↓↓↓↓↓↓

【おっぱい】エログラミング Ver.0【まん○】
ttp://pc8.2ch.net/test/read.cgi/gamedev/1159714969/

（本当に真面目にやってるから困るｗ

581 ：名前は開発中のものです。：2006/10/03(火) 05:15:00 ID:y9F7IyNg

>>577
＞各頂点は元居た位置に戻ろうとする
これでＯＫだよ。ペナルティ法みたく力を加算してやればいい。
けど結局重力との兼ね合いがあるからなかなか思ったようにはいかないんだよね
…と思ったけど戻ろうとする位置を重力の強さから計算して少し上にすると
そういう心配がいらないのか今思いついた

582 ：名前は開発中のものです。：2006/10/03(火) 06:57:20 ID:vgAfYw3G

あーうぜぇ。
DirectX9でプログラム組んだら、
実行ファイルといっしょにd3dx9d_27.dllもつけてくばれよ。
どうやってdll取得すりゃいいんだよ。

583 ：名前は開発中のものです。：2006/10/03(火) 07:07:35 ID:YfYGNZyI

そこで.NETですよ

584 ：名前は開発中のものです。：2006/10/03(火) 07:11:05 ID:vgAfYw3G

てか、普通、dllといっしょに配布するもんなんだろ？

585 ：名前は開発中のものです。：2006/10/03(火) 07:22:48 ID:vgAfYw3G

ってか、d3dx9「d」_27.dllってデバッグバージョンかよ。
もう、死ねｗ
デバッグビルドで配るのかよ。
これじゃ、dllどうしようもねぇよ。
ってか、製品かよｗこれｗ
担当者首吊っていいぞｗ

586 ：名前は開発中のものです。：2006/10/03(火) 07:27:40 ID:YfYGNZyI

どういう状況かわからないので詳しく

587 ：名前は開発中のものです。：2006/10/03(火) 08:35:12 ID:P7VMQaAC

DLL配布がマジでうざいので俺はOctober2004が手放せない。

588 ：名前は開発中のものです。：2006/10/03(火) 11:21:37 ID:XIIuodg5

まさにDLL HELL。MSは新しいD3DX出したらWindows Updateで配るべきだ。

589 ：名前は開発中のものです。：2006/10/03(火) 13:14:44 ID:M3DXFH7V

>>60
ドラえもんのセリフだったのか。

590 ：名前は開発中のものです。：2006/10/03(火) 23:09:52 ID:4Fizvc7m

>>585
>デバッグビルドで配るのかよ。
これって配布しちゃダメなんじゃないっけ？
(d.dllは配布NGだよな・・・)

591 ：名前は開発中のものです。：2006/10/04(水) 03:39:54 ID:4wzn7ySy

っつーか、DLL自体も配布禁止じゃねーの？
ちゃんとランタイム入れさせたら問題ないよ。

592 ：571：2006/10/04(水) 03:41:52 ID:DSlHTxnP

>>568
度々すいません。やっと計算が合いました。

Pv = ( Xv , Yv , Zv , 1 ) で、Pp、Pv を列ベクトルとすると

Pp = ( DirectXのパースペクティブ射影行列 ) * Pv

と計算をしていたから、計算が合いませんでした。。

DirectXの行列の場合は、Pp、Pv を行ベクトルとし、Pp = ( Xp , Yp , Zp , Wp ) とすると

Pp = Pv * ( DirectXのパースペクティブ射影行列 )

が正しいですよね。

普通の数学の行列とDirectXの行列の掛ける順番が、逆だった事を忘れてました。。

＞ちなみに depth = (Zv - near) / (far - near) だと(線形の)0.0～1.0ね
これは「 depth = Zp / Wp 」の式で
Wp = far　（ Wp は far で常に一定）
とした時の結果だと思うのですが、どういうときに Wp = far で
「 Wp = 一定」となるのですか？

度々ですが、よろしくお願いいたします。

593 ：571：2006/10/04(水) 03:59:49 ID:DSlHTxnP

何となく
( DirectXのパースペクティブ射影行列 )
を
( DirectXの左手座標系正射影行列 )
にすれば、上の疑問が解決しそうな気がしてきました。。

594 ：571：2006/10/04(水) 04:05:47 ID:DSlHTxnP

おさわがせしました.。。>>593で解決しました。。m(_ _)m

595 ：名前は開発中のものです。：2006/10/04(水) 06:15:19 ID:Ktl66vb4

>>591
リリースならいーんじゃなかったっけ？

596 ：名前は開発中のものです。：2006/10/04(水) 08:51:54 ID:XNeWH2d0

リリースのDLLは開発者が配布するんじゃなかったっけ？

597 ：名前は開発中のものです。：2006/10/04(水) 11:20:48 ID:OxntC239

Redistに入ってるインストーラという形なら再配布おｋ。
DLLをアプリに付けるのはアウト。

しかし、DirectX 9.0c End-User Runtimes (February 2006)とかわかりにくすぎるよな。
DirectX 9.1とか9.2にしないのはなんでなんだ？

598 ：名前は開発中のものです。：2006/10/04(水) 12:14:36 ID:2xOQlnLJ

開発者が自由に決めていいんじゃなかったっけ？

599 ：名前は開発中のものです。：2006/10/04(水) 14:54:41 ID:4wzn7ySy

みんな再配布に関する知識が適当だな・・・(;´д`)
>>597 でFAです。

バージョンは 9.0「c」の時点で怪しいよね。
内部処理の変更だけっていうなら納得もでくるけど、そうでもないし・・

600 ：名前は開発中のものです。：2006/10/04(水) 15:44:34 ID:MKHuD+QX

>>597
DX9は場繋ぎだからな
DX8のあと手をかけたのはDX10のほうで
DX9はこの間を埋めるために作られただけ
だからDLLとか変な形で配布するようになってる
9.1とか9.2とか気軽にバージョン刻んじゃうと
Vistaが遅れたらエライ目にあってしまう

601 ：名前は開発中のものです。：2006/10/04(水) 20:36:35 ID:SU/1cxSP

んで実際VIstAが遅れているため変なバージョンが乱発されたと

602 ：名前は開発中のものです。：2006/10/04(水) 21:21:29 ID:OxntC239

なるほど。しかも、DirectX10はVistaオンリーだからな・・・繋ぎのDirectX9が当分主流になる悪寒。

603 ：名前は開発中のものです。：2006/10/05(木) 21:30:05 ID:nihkvWc+

>>602
>繋ぎのDirectX9が当分主流になる悪寒。

内心そうであって欲しいと思ってる俺は悪い子です。

604 ：名前は開発中のものです。：2006/10/05(木) 21:50:19 ID:SqDbZcnZ

DirectX9主流に意義はないが、
マイナーチェンジのたびに配布DLL増やすのは辞めろといいたい。

605 ：名前は開発中のものです。：2006/10/05(木) 21:52:16 ID:UDop+ZrD

つまりソースで配布してユーザーがコンパイルする時代がDirectXにも来るということか

606 ：名前は開発中のものです。：2006/10/05(木) 22:20:45 ID:CyAerv/D

配布ってなんだよw
MS Update通せって書いとくだけだろ

607 ：名前は開発中のものです。：2006/10/05(木) 22:22:09 ID:PrJx0YGz

D3DXに関してはアップデートでは入らない。

608 ：名前は開発中のものです。：2006/10/05(木) 22:28:34 ID:ekRcqY1k

ネットにつなげない状況にある子もなんとか救ってやりたい次第。

609 ：名前は開発中のものです。：2006/10/05(木) 22:51:12 ID:/NLAzQcl

October2004あたりでビルドしておけば無問題?

610 ：名前は開発中のものです。：2006/10/06(金) 00:02:54 ID:sTGhBtZC

Managed DirectX使えばいいじゃん。
今日付けでMDX2.0ベータは使えなくなったから、MDX1.1で。

611 ：名前は開発中のものです。：2006/10/06(金) 00:21:12 ID:zAgFoh35

>>609
２年も前のSDKとか使うなよ・・

612 ：名前は開発中のものです。：2006/10/06(金) 01:25:50 ID:fUtYCWOE

2年前のSDKと今のSDKってぶっちゃけてD3DX関係しか違わないからあまり最近のにする意味もない。

613 ：名前は開発中のものです。：2006/10/06(金) 01:29:38 ID:zAgFoh35

>>612 は WindowsUpdate をしないﾀｲﾌﾟ。

614 ：名前は開発中のものです。：2006/10/06(金) 02:25:18 ID:5tz0fyrT

D3DXが大事なんだよ

615 ：名前は開発中のものです。：2006/10/06(金) 07:45:44 ID:POFlOsAD

それはない。D3DXは単なるオマケ

616 ：名前は開発中のものです。：2006/10/06(金) 07:52:39 ID:GYdEeNvt

VistaそしてDX10が出たときどうなるかだよな
MSはしばらくの間はDX9も新機能に対応させると言ってるが
どう考えても新機能が20あったら2か3しかDX9では対応しなそう

617 ：名前は開発中のものです。：2006/10/06(金) 08:43:50 ID:TKIe5Gjx

その新機能が欲しいかどうか？ってところだな。

618 ：名前は開発中のものです。：2006/10/06(金) 08:47:03 ID:fUtYCWOE

いちいちDLL添付して配布しなきゃならん時点で
ネット上での公開が激しく面倒。

619 ：名前は開発中のものです。：2006/10/06(金) 12:19:54 ID:o6y9NZtR

もういっそのことGDIを廃止してDirectXを内包してしまえばいいのに

620 ：名前は開発中のものです。：2006/10/06(金) 13:04:39 ID:BGqaNsol

>>619
坊や、Aeroって何か知ってる？

621 ：名前は開発中のものです。：2006/10/06(金) 14:28:41 ID:0Zp/+Eil

空気入りのチョコレート？
http://aero-land.jp/top

やっべ、ブーンしてる

622 ：名前は開発中のものです。：2006/10/06(金) 17:41:22 ID:xMPGWF4i

>>619
Vistaがそれだろ
廉価版はGDI系列だけど

623 ：名前は開発中のものです。：2006/10/07(土) 10:35:36 ID:Lg8HECqT

いやアロエも窓枠の中はGDIのまま
DirectX使うにはAvalonで書く必要がある

624 ：名前は開発中のものです。：2006/10/08(日) 16:58:14 ID:u5wlUUpD

このスレの200くらいまでを読んで
無駄にDirectXの話はしない
無駄に煽る
無駄に釣られる
無駄に俺語りをする
素晴らしいスレだとおもいまちた

625 ：名前は開発中のものです。：2006/10/08(日) 17:36:38 ID:J/lw30NR

どなたか、モーションキャプチャでキャラを動かした経験のある方いらっしゃいませんか。

626 ：名前は開発中のものです。：2006/10/08(日) 18:08:12 ID:t4f9uuWm

モーションキャプチャの機材の使用経験を聞きたいのか
それともネットで配布されているキャプチャデータの話を
聞きたいのかどっちなんだ？

627 ：名前は開発中のものです。：2006/10/08(日) 21:41:40 ID:J/lw30NR

機材もそうなんですが、主にキャプチャした後のデータをどうこねまわすのか、
話を伺いたいです。経験おありですか？

628 ：名前は開発中のものです。：2006/10/08(日) 23:16:37 ID:YNWehYqo

最近は知らんが、キャプチャーしたデータにはノイズが入ってそのままでは使えないから
オペレータとかに修正を依頼するのが普通だったね。
その時に、出力形式とか決めたり、適用するモデルのスケルトンを渡したり。

出来上がったデータは普通に使ったらいいじゃん。

何より、モーションキャプチャーしてる会社に聞いてみたほうが早いよ。

629 ：名前は開発中のものです。：2006/10/08(日) 23:24:43 ID:HYvBv04F

>>625
それ以前に人体のモデリングとかリグを組んだりとか、
キャプチャー以前に至る経験はあるのか？

630 ：名前は開発中のものです。：2006/10/08(日) 23:55:49 ID:J/lw30NR

>>628
修正作業はデザイナーにやってもらったんですか。実は一番知りたいのがそこだったり・・・
ノイズも問題になるでしょうけど・・・・
・100fpsで記録されてる生データを重要なキーフレームだけ取り出したい
・歩くキャラのつま先が地面にめり込んだり、デブキャラの腹に自分の腕が
　めり込むのを修正したい（可能なら自動で）
といった作業は、何て言うアプリで編集すれば良いですかね。
どのアプリもモーキャプデータの編集なんて全然考えてない・プラグインも
無いみたいなんですが・・・どうやって間引き＆ポーズ修正したか分かりませんか。

>>629
デザイナーがやるので、そういう経験は無いです（花瓶くらいなら作れるでしょうが・・・）

631 ：名前は開発中のものです。：2006/10/08(日) 23:57:10 ID:57ON1ch9

そういうのは、MotionBuilder一択じゃないの？

632 ：名前は開発中のものです。：2006/10/09(月) 00:02:29 ID:FuiQQBpr

例えばセガのスペースチャンネル５ですが、あれは一つの（と思われる）
モーキャプファイルで、スリムな主人公から相当デブなキャラまで、それなりに
辻褄が合うように動かしてます。
モーキャプデータから抽出したキーフレームが充分に少なければ、手作業で修正
する事も出来るでしょうが、スペチャンのキーフレームはかなり密度が高い上に、
殆ど全編踊りですから時間も長いです。
何か効率的に修正出来る有名な製品でもあるのかなと思いまして・・・

633 ：名前は開発中のものです。：2006/10/09(月) 00:03:08 ID:J/lw30NR

>>631
MotionBuilderですか！ありがとうございます、調べてきます。

634 ：名前は開発中のものです。：2006/10/09(月) 00:26:10 ID:g6Zja+3M

> 修正作業はデザイナーにやってもらったんですか。実は一番知りたいのがそこだったり・・・
デザイナーじゃないよ。
モーションキャプチャースタジオのオペレーターさんに
キャプチャーからデータ加工までを一括でお願いする感じ。

古い話だから今は知らんよ。

635 ：名前は開発中のものです。：2006/10/09(月) 00:33:24 ID:NQHfVOFR

633 は今ごろ、MotionBuilderの値段を見て、ビビっているかもｗ
Standard無くなっちゃたしね。

636 ：名前は開発中のものです。：2006/10/09(月) 00:59:43 ID:3eM7knO2

フルスクリーンにしたらスプライトがぼやけるんですけど
これってビデオボードの問題ですかね

637 ：名前は開発中のものです。：2006/10/09(月) 01:02:54 ID:ERqi5yh1

ぼやけるのはスプライトだけなのか？

638 ：名前は開発中のものです。：2006/10/09(月) 01:06:05 ID:FuiQQBpr

>>634
ざっくりとした加工はまとめてやってもらっても、細々したのはこっちでやりたいんですわ
運用してみて問題が出るたびに修正に出す、ていうのも大変ですし。

>>635
まあ、自分の財布から出るわけじゃないからね。

639 ：名前は開発中のものです。：2006/10/09(月) 02:05:01 ID:g6Zja+3M

>>638
そこまで決まってるんなら、なぜココで質問したのか？

640 ：名前は開発中のものです。：2006/10/09(月) 13:09:14 ID:rZ6e1XGZ

>>636
デフォルトの設定でフィルタかかってるビデオボードも結構多い

641 ：名前は開発中のものです。：2006/10/09(月) 14:25:05 ID:btmawUgC

まさか液晶使ってるってオチじゃないよな

642 ：636：2006/10/09(月) 14:43:29 ID:3eM7knO2

レスあざーす

>>637
今のところそうです
文字とかはくっきり表示されてます
>>640
そうなんですか…
GDIだったらちゃんと表示されるからそっちにしようかな
>>641
えっ液晶だとだめなの？（汗
ノーパソなんですけど…
やっぱ古いノーパソでDirectX使ったゲーム作るのは間違ってたかな・・

643 ：名前は開発中のものです。：2006/10/09(月) 15:02:44 ID:rCZTHJGt

>>642
液晶はWindowed modeは別としてフルスクリーンにすると
標準の解像度以外だとぼやけるでしょ？

ってそういう話じゃなくって？

644 ：名前は開発中のものです。：2006/10/09(月) 15:34:42 ID:t31lpLSa

CRTモニタが減っているよな実際。

645 ：名前は開発中のものです。：2006/10/09(月) 15:41:25 ID:SdlywCzM

>>642
自分でボケないようにフィルタ設定すればいいだけだよ

646 ：名前は開発中のものです。：2006/10/09(月) 16:35:44 ID:ERqi5yh1

まぁ、あれだ
平面（じゃなくてもいいけど）ブラウン管ディスプレイを一台買え
ゲーム用に中古で

647 ：名前は開発中のものです。：2006/10/09(月) 19:36:43 ID:g6Zja+3M

> 自分でボケないようにフィルタ設定すればいいだけだよ
そういう問題なのか？？

ノートとか液晶だと固定解像度だから、嫌でも引き伸ばされるはず。
まあ、液晶の解像度に合わせれば大丈夫って話なんだが。

648 ：名前は開発中のものです。：2006/10/09(月) 20:33:37 ID:L1UKMrZX

質問です。
左から右に行くほどどんどん透明になるテクスチャを表示したいんですけど
どうやるかわかりません。
スプライト->draw(～,D3DCOLOR(r,g,b,a))でaの部分をいじるとテクスチャ全体
のアルファ値が変わるのでどうすればいいんでしょうか？

649 ：名前は開発中のものです。：2006/10/09(月) 20:53:12 ID:FuiQQBpr

最初からそういうアルファ値を持ったテクスチャを用意しておけば。

650 ：名前は開発中のものです。：2006/10/09(月) 20:57:08 ID:AkqysJFv

スプライト->drawでやるならｐｎｇでそういう画像用意した方がいいんじゃね？
あるいはサーフェスをロックして書き換えるとか

651 ：名前は開発中のものです。：2006/10/09(月) 20:59:21 ID:AkqysJFv

あ、かぶったｗ
あと用意するのﾏﾝﾄﾞｸｾーけど、ＤＤＳ使うとか

652 ：名前は開発中のものです。：2006/10/09(月) 21:07:05 ID:2wqecqNX

ID3DXSpriteを使わず、普通に頂点にαをセットすればいいだけ。
そんな物に頼っているから、その程度の簡単な処理すら出来ない。

653 ：648：2006/10/09(月) 21:48:49 ID:L1UKMrZX

ddsを使ったらめっちゃ楽にできました。
ありがとうございました。

654 ：名前は開発中のものです。：2006/10/09(月) 23:00:48 ID:ujCaQUcv

>>652
無知は罪ですか？

655 ：名前は開発中のものです。：2006/10/09(月) 23:05:49 ID:EKjsv0Kz

罪ではないし、俺らにとってはどうでもいいコトだが。
仕組みの理解をしておくことは後々役に立つかも知れ無い。

656 ：名前は開発中のものです。：2006/10/09(月) 23:15:43 ID:vhVClLX6

そもそもDirectXに頼っている時点で素人がまともなゲームを作ることは論外

657 ：名前は開発中のものです。：2006/10/09(月) 23:20:09 ID:EKjsv0Kz

ではぷろふぇっしょなるな方はWindowsではGDIかOpenGLを使うのが常識ということですね。

658 ：名前は開発中のものです。：2006/10/09(月) 23:26:17 ID:btmawUgC

プロは必要に応じて最適なAPIを使い分ける

てゆうかDirectXに頼らないなら来なくていいよ>656

659 ：名前は開発中のものです。：2006/10/09(月) 23:32:49 ID:FuiQQBpr

コンピュータなんかに頼っている時点で（ｒｙ

660 ：名前は開発中のものです。：2006/10/10(火) 04:07:10 ID:VJTBF9e5

多細胞でしか生きていけない時点で（ｒｙ

661 ：名前は開発中のものです。：2006/10/10(火) 05:51:58 ID:xblaH6lZ

2chなんかに頼っている時点で（ｒｙ

662 ：名前は開発中のものです。：2006/10/10(火) 08:00:49 ID:j0PxGh8F

DirectXに頼っている時点で(ryって奴は確かにこのDirectX総合スレに来る意味無いなｗ
でも確かにD3DXに関してはもう頼れなくなったなぁ。
Oct2004まではD3DXに頼ってても何の不便も無かったのに・・・。

663 ：名前は開発中のものです。：2006/10/10(火) 11:15:17 ID:2TluMEZs

そうか、D3DX使わなきゃ不毛なdll問題起きないんだよな
そこに気づけなかった俺ヘボいぜ
調べたらD3DXCreate*Texture*()以外使ってないし、ddsのロードは別環境用に用意してあるし
面倒が一つ減ったぜヤッホイ

664 ：名前は開発中のものです。：2006/10/10(火) 11:18:19 ID:znCtx2eH

FXファイル周り、メッシュの最適化、ベクトル・行列クラスのアセンブラ化。
ここら辺が手放せないから、D3DX捨てるのは俺は無理だ。
どれも自分で書けないわけじゃないが、趣味プロだと他にやることが多すぎる。

665 ：名前は開発中のものです。：2006/10/10(火) 14:31:39 ID:2KxtSwlF

XBOXのソフト開発者に謝れ

666 ：名前は開発中のものです。：2006/10/10(火) 15:40:47 ID:VJTBF9e5

すいません

アニメーション付きのX Fileを読み込んで、複数アニメーションを切り替えて表示できる
ビューワってありますか？
DirectX Viewerではできないようなのですが！

667 ：名前は開発中のものです。：2006/10/10(火) 15:42:57 ID:0+hhpTt+

付属のViewerで普通にできる。

668 ：名前は開発中のものです。：2006/10/10(火) 15:44:45 ID:obWAIVxp

いやmviewで出来るんじゃね
それともDirectX Viewerってのは、mviewとは違うのか
mviewは少なくとも2004 Summerには入っているな

669 ：名前は開発中のものです。：2006/10/10(火) 17:17:31 ID:VJTBF9e5

最新版には入っていないようですね。
2004 summerをダウンロードしてみます。ありがとう。
早とちり氏ねよ。

670 ：名前は開発中のものです。：2006/10/10(火) 17:53:26 ID:KlJC55XH

付属のViewerでも読み込めないXファイルもあるが。
(自分で組んだプログラムでは動く)

671 ：名前は開発中のものです。：2006/10/10(火) 18:31:07 ID:VJTBF9e5

はいはい君は天才だ
DirectXを使わせたら右に出る者はいない良かったね

672 ：名前は開発中のものです。：2006/10/10(火) 18:42:02 ID:VJTBF9e5

673 ：名前は開発中のものです。：2006/10/10(火) 18:54:10 ID:2TluMEZs

ID:VJTBF9e5が不思議な挙動を見せている

674 ：名前は開発中のものです。：2006/10/10(火) 18:56:03 ID:4sC3iTHG

「今ひどい自演を見た」と書いていいものかどうか10秒くらい迷ったけど書かなかった

675 ：名前は開発中のものです。：2006/10/10(火) 19:15:44 ID:RntNEutj

しかたないので>>674の代わりに「今ひどい自演を見た」と書いてきた。

676 ：名前は開発中のものです。：2006/10/10(火) 19:16:34 ID:RntNEutj

>>675
おまえ正真正銘のバカだろｗｗｗ

677 ：名前は開発中のものです。：2006/10/10(火) 20:17:10 ID:2KxtSwlF

言って欲しいの？

678 ：名前は開発中のものです。：2006/10/10(火) 21:08:13 ID:VJTBF9e5

君の口から聞きたいんだ

679 ：名前は開発中のものです。：2006/10/11(水) 00:17:10 ID:UlzNoGLX

行列Aと行列Bがあります。
行列Aに対して行列Cをかけて、行列Aが行列Bと同じになるようにしたいです。
その場合、行列Aに対してかけるべき行列Cはどうやったら求められますか。

680 ：名前は開発中のものです。：2006/10/11(水) 00:19:37 ID:trFIvV+b

>行列Aが行列Bと同じになるようにしたい
ムリ

681 ：名前は開発中のものです。：2006/10/11(水) 00:19:54 ID:UlzNoGLX

A=B;すりゃ良いじゃん・・・という事ではなく、行列Aと行列Bの差分の、行列C
そのものが欲しいのです。
よろしくおねがいします

682 ：名前は開発中のものです。：2006/10/11(水) 00:21:06 ID:UlzNoGLX

>>680
浮動小数点の計算誤差なんかは気にしないのですが
それでもムリですか？

683 ：名前は開発中のものです。：2006/10/11(水) 00:24:19 ID:rDqWvzjU

逆行列を掛けるだけ

684 ：名前は開発中のものです。：2006/10/11(水) 00:25:36 ID:UlzNoGLX

BにAの逆行列をかければCが得られるんですね

685 ：名前は開発中のものです。：2006/10/11(水) 00:59:15 ID:xBMfHgNK

Ａ・Ｃ=Ｂ
→Inv(Ａ)・Ａ・Ｃ=Inv(Ａ)・Ｂ
∴Ｃ=Inv(Ａ)・Ｂ

でおｋ?
ようわからんけど・・・

686 ：名前は開発中のものです。：2006/10/11(水) 01:01:45 ID:1sECxPrk

いや無理なんじゃね？
逆行列は関係ない気がする。
そもそも行列で差分って何につかうんだ？

687 ：名前は開発中のものです。：2006/10/11(水) 01:02:05 ID:xBMfHgNK

たぶん間違えた。
Ａ・Ｃ=Ｂ=Ａにしたいってことか。
難しいな・・・

688 ：名前は開発中のものです。：2006/10/11(水) 01:23:10 ID:U5zzbWGT

>>685でOKじゃないの？

689 ：名前は開発中のものです。：2006/10/11(水) 01:36:32 ID:RAcYP2kE

>>679
>>685で正解。

あとは、かける順序に注意。
それから、Aの逆行列が求まらない場合はCは一意とならない。

690 ：名前は開発中のものです。：2006/10/11(水) 02:41:06 ID:UlzNoGLX

>>685-689
ありがﾄﾝ!
＞Aの逆行列が求まらない場合はCは一意とならない。
はい、それはもう・・・
いや～たすかりました

691 ：名前は開発中のものです。：2006/10/11(水) 03:42:19 ID:1ONjsgnr

>684が
「よつんばいになれば免許を返して頂けるですね」の改変に見えた俺はとっとと寝ろ

692 ：名前は開発中のものです。：2006/10/11(水) 10:18:27 ID:v2mXemUL

アッー！

693 ：名前は開発中のものです。：2006/10/14(土) 01:39:42 ID:pah3fq2S

ID3DXAnimationControllerでアニメーションをやっているのですが、
アニメーションの全長(時間)はどうやったら取得できるんでしょうか？
それから、アニメーションを構成するキーフレームがそれぞれ何秒のところにあるのか
を取得したいのですが、そういう手段はあるんでしょうか？

694 ：名前は開発中のものです。：2006/10/14(土) 07:14:00 ID:uIeEv6ah

>>693
ヒント：xファイルに書かれてる

695 ：名前は開発中のものです。：2006/10/14(土) 13:23:21 ID:sQHed/jL

そんな関数無い

696 ：名前は開発中のものです。：2006/10/14(土) 14:05:43 ID:E4qGi0KR

じゃフレームが出力できるxファイルを作る必要があるじゃん
メタセコで出来る？

697 ：名前は開発中のものです。：2006/10/14(土) 15:14:09 ID:urG12ahb

データ作った人間には何フレームあるかわかるだｒ

698 ：名前は開発中のものです。：2006/10/14(土) 18:08:41 ID:y7B7XSEr

ドラゴンボールのビームとか
ガンダムのビームとかの棒
どうやって描画してるの？
円柱モデルじゃないでそ
ビルボードは、点を中心のやつじゃないとダメだし
ぬう

699 ：名前は開発中のものです。：2006/10/14(土) 18:41:11 ID:urG12ahb

別に円柱でもそれっぽく見えればいいんだよ

700 ：名前は開発中のものです。：2006/10/14(土) 18:47:28 ID:rEq95AFn

6～8角厨

701 ：名前は開発中のものです。：2006/10/14(土) 19:46:32 ID:5CSzso0u

>>698
六角柱だけをライトなしの真っ白でレンダしてぼかすんだよ

702 ：名前は開発中のものです。：2006/10/15(日) 00:49:28 ID:5NiZDasq

>>698
＞ビルボードは、点を中心のやつじゃないとダメだし
んなわけない。

703 ：名前は開発中のものです。：2006/10/15(日) 06:01:12 ID:T/ORfnUd

>>698
Gems3に載ってるやつは？
長方形のポリゴンの端に三角形がついてるやつ

704 ：名前は開発中のものです。：2006/10/15(日) 11:47:05 ID:QPC2ckl/

>>698
「ビームの始点から終点までを結んだベクトル（以下、ビーム・ベクトル）」と
「カメラの位置からビームの端の点１つを結んだベクトル」の外積から
この２つベクトルに直角なベクトルを求める。
そのベクトルとビーム・ベクトルの外積からこの２つベクトルに直角なベクトルを求める。
このベクトルを法線ベクトルとする板ポリを描画するばＯＫ

ただ、カメラの視線ベクトルとビーム・ベクトルが平行に近いと板ポリであることが
はっきりと分かってしまうので、それの対処方法は以下の２つがある。

１つは板ポリの両端に普通のビルボードをくっつける方法（>>703が言っている方法）と、
もう１つはカメラの視線ベクトルとビーム・ベクトルが平行に近いときには普通の
ビルボードに切り替える方法がある。

705 ：名前は開発中のものです。：2006/10/15(日) 15:50:40 ID:ncIQLCOH

光り系の加算テクスチャとかパーティクルも重要

706 ：名前は開発中のものです。：2006/10/15(日) 17:38:15 ID:lHeBAk5n

アクションゲームの連続攻撃とかみたいな、ボタンの連続入力判定って
DirectInputでやる場合やっぱりバッファリングでやった方がいいんですかね？

707 ：名前は開発中のものです。：2006/10/15(日) 19:20:54 ID:nExnDBy1

連続入力のときに1/60よりも速い単位でボタン入力を受け付けるならバッファリングだろうなぁ。

708 ：名前は開発中のものです。：2006/10/15(日) 19:41:13 ID:1awBMXDQ

ゲームコントローラは割り込みデバイスではないから、バッファリングでも
Pollを呼んだときしかデータ取得してないよ。

709 ：名前は開発中のものです。：2006/10/15(日) 21:18:43 ID:lHeBAk5n

バッファリングでやってもあまり利点無いってことですかね
とりあえず直接取得でやってみます

710 ：名前は開発中のものです。：2006/10/16(月) 03:58:38 ID:4O9ZIClz

1/60で連打できる奴以内だろ

711 ：名前は開発中のものです。：2006/10/16(月) 11:47:04 ID:akp78//4

連打機

712 ：名前は開発中のものです。：2006/10/16(月) 11:47:31 ID:1DRIsy8R

>>710
連打は無理だろうが、1/60フレーム風神拳とか入力できる変態はいるよなー

>>706
アクションとか格げーだとバッファリングしたほうが楽なような気がするが。
あとで、リプレイとかつけたくなるかもしれんし。

713 ：名前は開発中のものです。：2006/10/16(月) 11:55:28 ID:idfGKmvC

そういや、VF5のアキラの膝が
K+G→１フレーム後にG離す
だったな
個人的には最風よりむずい

714 ：名前は開発中のものです。：2006/10/16(月) 12:33:55 ID:dJZ5IjFP

VF5は知らないがいまだにそのコマンドなの？
VF2でバグでそのコマンドで膝が出てたけど。

>>712
バッファリングだろうと直接データだろうと、入力の履歴は
アプリケーションに組み込むもの。
リプレイ等にDirectInputの設定は関係ないと思うが。

715 ：名前は開発中のものです。：2006/10/16(月) 12:47:06 ID:uxehlBoP

VF1からの伝統なのにVF5のとか書いてるところを見ると
十代だろうな

716 ：名前は開発中のものです。：2006/10/16(月) 14:17:08 ID:idfGKmvC

26ですが
今、VF5やってるからVF5って書いてしまっただけ

717 ：名前は開発中のものです。：2006/10/16(月) 16:54:09 ID:cOg4Ko/j

>>714
入力の履歴を保持する場合って、ボタン毎に数回分の入力時間を保持してればだいたいOKかな？

718 ：名前は開発中のものです。：2006/10/17(火) 00:01:47 ID:Pi/yMn9O

>>717
最低でも、コマンド受付可能時間×FPS数だけは記憶させないとだめだろ。

すなわち、ファイナルターンパンチ(溜め６０秒)×60FPSで記憶域3600個w

719 ：名前は開発中のものです。：2006/10/17(火) 00:03:50 ID:WKs3wEDm

VF1からの伝統なのにVF5のとか書いてるところを見ると
ちんぽが十代だろうな

720 ：名前は開発中のものです。：2006/10/17(火) 00:11:33 ID:xez2dOmh

>>719
元気そうでうらやましい… orz

721 ：名前は開発中のものです。：2006/10/17(火) 00:40:46 ID:MdWVn9/c

>最低でも、コマンド受付可能時間×FPS数だけは記憶させないとだめだろ。
正直な話、ボタンのため分をカウントしていれば、開始から発動までのバッファは要らない

「60秒押していたボタンを離した」と判定する、1フレーム分あればいい
波動拳コマンドの最長受付フレーム数が60フレームの場合ならバッファは60ほしい

これはバッファに入力を保存して、後からコマンドを検査する場合ね

722 ：名前は開発中のものです。：2006/10/17(火) 01:41:52 ID:b/Pd8rNN

>>718は語尾にwがついてるから冗談として極端な実装の例を挙げたんだろうけど、
>>721の実装は利点がよく分からんな。

>>721
> 「60秒押していたボタンを離した」と判定する、1フレーム分あればいい
その考えを押し進めると、
「押下したこと、離したこと、これらの時間間隔を記録すれば十分」ということになる。
だから、タメ時間を保持するためには、バッファの長さは60も要らなくて、2で済む。

最初に押下したときに、記録開始時刻からの時間を記録して、
次に離したときには、押下したときからの時間を記録して、
二度目に押下したときには、前に離したときからの時間を記録して、
……というように記録すればいい。

723 ：名前は開発中のものです。：2006/10/17(火) 02:35:27 ID:39vQ4qdS

入力が変化するまでの時間を記録する方式は、ワーストケースで
毎フレーム入力が変化していた場合に、結局は入力受付時間分の
バッファが必要になるという事実。

724 ：名前は開発中のものです。：2006/10/17(火) 03:45:09 ID:b/Pd8rNN

で？

725 ：名前は開発中のものです。：2006/10/17(火) 05:27:56 ID:q1fUJa/G

それでどうやってコマンド方式を判断するんだ？

726 ：名前は開発中のものです。：2006/10/17(火) 09:47:10 ID:WApPQYbc

カプコンは、ボタンを離したときもコマンド入力調べてる
SNKは、省略コマンドがある 21416→246

727 ：名前は開発中のものです。：2006/10/17(火) 11:19:02 ID:39vQ4qdS

>>726
それは省略コマンドじゃなくて、最初から246しか判定してないだけだよ。
むしろ発表されているコマンドが冗長なだけ。

ちなみにスト2のスクリューも斜め入力は必要なくて、4方向だけでいい。

728 ：名前は開発中のものです。：2006/10/17(火) 12:48:13 ID:PzA+Fa3w

つーかボタン入力制御も知らないような奴がなんでこんなところにいるんだ？
基本的な常識も知らないでゲームを作りたいとか論外なんだが。

729 ：名前は開発中のものです。：2006/10/17(火) 12:59:54 ID:Un2Q1nYv

そうだね、プロテインだね

730 ：名前は開発中のものです。：2006/10/17(火) 15:35:29 ID:ZPE2JhJ0

そう、常識だ。いや、常識だと多くの人々が思っている。
だが、実はCO2が地球温暖化の原因だという証拠は無いんだよ

731 ：名前は開発中のものです。：2006/10/17(火) 15:55:16 ID:HnFFLO9E

D3DLIGHT_DIRECTIONAL な光源で
メッシュを描画しているのですが
scale=1.0f な時白→黒な球体が描画されるのですが
scale=10.0fな時灰色になるんです

何の影響なんでしょうか？

732 ：名前は開発中のものです。：2006/10/17(火) 16:36:26 ID:g8mAqjlU

地球温暖化の影響

もしくは法線非正規化の影響

733 ：名前は開発中のものです。：2006/10/17(火) 19:01:46 ID:HnFFLO9E

㌧ｸｽ

拡大の温暖化を防ぐには
SetRenderState( D3DRS_NORMALIZENORMALS, TRUE );
すればいいのね

734 ：名前は開発中のものです。：2006/10/17(火) 20:02:50 ID:pnwQy0ug

RenderStateSet)TRUE, D3DRS_NORMALIZENORMALS(
が正解

735 ：名前は開発中のものです。：2006/10/19(木) 11:57:34 ID:KYn/6wBS

おっぱいスレで質問したけど、答えが返ってこないので、こっちにマルチします。

おっぱいをデフォメーションさせてたゆんたゆん揺らせるには
メッシュオブジェクトの乳の部分だけを属性バッファで指定して、さらにその頂点バッファにアクセスして
頂点を動かせばいいの？

↑でいいとしても、乳の部分だけの属性バッファを作る方法が分かんない。

ヒント、この辺読め、カス！だけでもいいので教えてください。

736 ：名前は開発中のものです。：2006/10/19(木) 12:57:59 ID:ux0Pyl4u

X-File?
だったら判定するためのデータ埋め込めばいいじゃない

737 ：名前は開発中のものです。：2006/10/19(木) 14:02:37 ID:Rx5m3XDA

人体にチップを埋め込まれる、の間違いだな

738 ：名前は開発中のものです。：2006/10/19(木) 23:40:34 ID:jUoY2I1o

モルダー落ち着いてモルダー

739 ：名前は開発中のものです。：2006/10/19(木) 23:53:22 ID:5SYTgZVc

モルダー、あなた疲れてるのよ

740 ：名前は開発中のものです。：2006/10/19(木) 23:59:01 ID:6/7GAxoT

おしっこモルダー

741 ：名前は開発中のものです。：2006/10/20(金) 00:03:50 ID:CFUBASIq

モルダー、あなたマジで疲れてるのよ

742 ：名前は開発中のものです。：2006/10/20(金) 03:24:19 ID:L3hW3qR3

美しい河よ、モルダーよー

743 ：名前は開発中のものです。：2006/10/20(金) 10:23:26 ID:ax2q1ay6

IndexBufferとVertexBufferの意味って何？

座標とか全部メモリにいれて
DrawIndexPrimitiveとかやればいいじゃん。

制限とか違うの？

744 ：名前は開発中のものです。：2006/10/20(金) 14:14:11 ID:/RdCkbLO

>座標とか全部メモリにいれて
>DrawIndexPrimitiveとかやればいいじゃん。

それでいいんだよ。
ちょうてんばっふぁとか
いちいちつくるのめんどうだもんね！

745 ：名前は開発中のものです。：2006/10/20(金) 16:04:45 ID:YHKhyEQt

何にでも疑問を持つのは良いことだ
次は自分の人生に意味を求めて自殺だレッツゴー

746 ：名前は開発中のものです。：2006/10/20(金) 22:38:41 ID:pRFrOnQi

>743
いくらなんでもそれはひどい・・・
もっと上手く釣れ。

747 ：名前は開発中のものです。：2006/10/21(土) 00:15:28 ID:HWb3gyzX

どうせ三途の川でくだらない釣りをしてるだけだろ。ホキでも食ってろ。

748 ：名前は開発中のものです。：2006/10/21(土) 00:54:06 ID:0t6G1cyR

質問です．
HDRフォーマット（D3DFMT_A16B16G16R16）のテクスチャをレンダリングターゲットにした場合，
D3DFMT_X8R8G8B8のターゲットに使用していた固定パイプラインの機能を
そのまま使用しても正しく描画できるのでしょうか？

描画前に一時的なターゲットとしてHDRテクスチャを咬ませただけで
アルファブレンディングが上手くできなくなってしまったのですが……．orz

749 ：名前は開発中のものです。：2006/10/21(土) 01:05:12 ID:0t6G1cyR

間違えましたorz
× D3DFMT_A16B16G16R16
○ D3DFMT_A16B16G16R16F

750 ：名前は開発中のものです。：2006/10/21(土) 01:12:03 ID:h4fJ9Plf

レンダリングは出来るんじゃない？
もっとも意味があるとは思えんが。

751 ：名前は開発中のものです。：2006/10/21(土) 01:12:46 ID:h4fJ9Plf

>>748
浮動小数点バッファもそもそもフィルタとアルファが使えない。

752 ：名前は開発中のものです。：2006/10/21(土) 01:35:28 ID:uPaMWthY

>>748
HDRレンダリングするんだったらピクセルシェーダ使うだろ？
だったら問題なしだ。自分で実装したまえ。

753 ：名前は開発中のものです。：2006/10/21(土) 01:36:21 ID:0t6G1cyR

じゃもうおとなしく描画を全てHLSLとかに移行した方がいいですね．
スプライト関係のルーチンを書き換えてきます……('A`;)

754 ：名前は開発中のものです。：2006/10/21(土) 01:40:02 ID:uPaMWthY

待て待て。
D3DFMT_A16B16G16R16F を使わない、って選択肢はないのか？

そもそも、何のために使おうとしてるんだ？？

755 ：名前は開発中のものです。：2006/10/21(土) 01:53:02 ID:0t6G1cyR

具体的にはトーン調整とかブルームとかが使いたくて．

あとHDR対応だと，いろいろ表現力が広がるみたいだし，
後々のことを考えると，今のうちに使えるようにしておいた方がいいかなと．

756 ：名前は開発中のものです。：2006/10/21(土) 02:05:17 ID:uPaMWthY

現時点でHLSLベースで作ってない上にスプライトとか使ってる状態では
FLOATバッファ使ったHDRレンダリングは早いと思うよ。

やりたいトーン調整やブルームは、擬似的に再現した方が絶対に楽。

757 ：名前は開発中のものです。：2006/10/21(土) 02:21:36 ID:h4fJ9Plf

てかスプライトにHDRなんていらんだろ

758 ：名前は開発中のものです。：2006/10/21(土) 02:24:26 ID:0t6G1cyR

あうあう．
現在自分のライブラリは3年間改造・増築を繰り返した結果，
モデルの描画がHLSL，2D・3Dスプライト(ビルボード？)が固定機能とばらばらになっていて，
おまけにライトの管理とかビューポートの管理とか，機能を細分化しすぎて，
作った本人にも詳細構造が意味不明な状態になっているので，
とりあえず固定機能の消去とかの機構削減・統合に関しては積極的に行いたいのでつ．

自分もスプライト関係は大昔に書いたコード＆機能追加しすぎて超長いので触りたくないのですが……．

759 ：名前は開発中のものです。：2006/10/21(土) 02:53:50 ID:m+1yDL9S

確かに長く書くのは億劫だよねー
答えてもらう側の苦労は自分が苦労するわけじゃないからどうでもいいよねー

760 ：名前は開発中のものです。：2006/10/21(土) 02:54:07 ID:uPaMWthY

3年間も使い続けてるのはｴﾗいと思う反面、古いプログラムにしがみ付きすぎだとも思う。

HLSLに対応した時点でｽﾌﾟﾗｲﾄ関連をまとめるべきだったね。
それは、今からでも全然遅くない。作り直すべき。

761 ：名前は開発中のものです。：2006/10/21(土) 03:04:52 ID:h4fJ9Plf

3年も弄ってるって事は仕事で使ってるとか、ネット上で公開してるとかそういう類かしら

762 ：名前は開発中のものです。：2006/10/21(土) 03:12:17 ID:0t6G1cyR

>>759
ﾑｷｰ（#｀皿´）
書き込み内容が長いと言われるのを恐れただけです．(´･ω･`)

>>760
そうそう，そう思っていま大改装中なのです．
その一環でHDRにも対応させようぜ，と．

>>761
いえ，すごく自分用です．
そのうちネット公開できればいいなとも

763 ：名前は開発中のものです。：2006/10/21(土) 03:18:21 ID:uPaMWthY

>>762
良いｷｬﾗしてるねー面倒みたくなるよ（ ´∀｀）

HDR対応にするなら、現状ではスプライト処理を廃止（ポリゴンに移行）するか、
簡単なところではスプライトはHDRレンダリング対象外ってことにするとか。

トーンマップ後のバッファに描いたらいいじゃん的な。

764 ：名前は開発中のものです。：2006/10/21(土) 04:25:01 ID:/8+zda2i

割り込んでごめんなさいです

ずっと前から疑問なんですが
デバイスにFVFを設定するのとVERTEXDECLARATIONを設定するのとでは
どういう違いがあってどういう意味があるんでしょうか

765 ：名前は開発中のものです。：2006/10/21(土) 04:47:59 ID:rSfE5bai

VERTEXDECLARATIONの方がもっと柔軟なフォーマットを指定できる。
それだけ。

766 ：名前は開発中のものです。：2006/10/21(土) 04:52:13 ID:/8+zda2i

ありがとうございました

うっ

767 ：名前は開発中のものです。：2006/10/21(土) 18:54:08 ID:uj+Vqk1i

>>746
釣りじゃないです＞＜
わからないんです＞＜
違いは、
・Lock/Unlockできるぐらいしかわからん

描画制限があるとか
演算をハードに任せるとかあるんですか？

768 ：名前は開発中のものです。：2006/10/21(土) 18:56:19 ID:uj+Vqk1i

ああ、DrawIndexPrimitiveじゃなくDrawIndexPrimitiveUpだ

うｐ系ってウンコ？

769 ：名前は開発中のものです。：2006/10/21(土) 19:03:43 ID:h4fJ9Plf

君がウンコな気がする・・・
初心者スレじゃないんだしリファレンスくらい読もうぜ。

770 ：名前は開発中のものです。：2006/10/21(土) 19:08:21 ID:h4fJ9Plf

--------------------------------------------------------------------------------
IDirect3DDevice9::DrawPrimitive メソッド
現在のデータ入力ストリームセットから、指定されたタイプのインデックスなしジオメトリプリミティブのシーケンスをレンダリングします。

--------------------------------------------------------------------------------
IDirect3DDevice9::DrawPrimitiveUP メソッド
ユーザーメモリポインタで指定されたデータを、指定されたタイプのジオメトリプリミティブのシーケンスとしてレンダリングします。

IDirect3DDevice9::DrawPrimitiveUP に渡す頂点データは、呼び出しの後も保持する必要はありません。
Microsoft Direct3D は、呼び出しから戻る前に、そのデータへのアクセスを完了します。

771 ：名前は開発中のものです。：2006/10/21(土) 19:17:21 ID:uj+Vqk1i

ツンデレを垣間見た
ｻﾝｸｽ

>呼び出しから戻る前に、そのデータへのアクセスを完了します。
つまり、Up系は、ユーザメモリをVRAMに完全にコピーしてから処理を返すから、ちょっと反応が遅いってわけなのか

ttp://twin-tail.jp/contents/vsdx8/d3d/020/index.htm
2Dは、うｐれと

ぬああ
よくわからん
じっくりマニュアル読んでくる

772 ：名前は開発中のものです。：2006/10/21(土) 20:13:47 ID:3iLjIQCs

2DだとDrawPrimitiveもDrawPrimitiveUPも
大して変わらないとか聞いたような

773 ：名前は開発中のものです。：2006/10/21(土) 20:27:22 ID:h4fJ9Plf

> Direct3DDevice9::DrawPrimitiveUP に渡す頂点データは、呼び出しの後も保持する必要はありません。
> Microsoft Direct3D は、呼び出しから戻る前に、そのデータへのアクセスを完了します。
ようするにDrawPrimitive呼ぶ度に内部で頂点バッファにコピーしてるって事だ。

２D/3Dのスプライトのような頻繁に書き換えるものならD3DPOOL_DEFAULTにD3DUSAGE_DYNAMICとD3DUSAGE_WRITEONLYをつけて頂点バッファを作れ。
そうするとAGPメモリに展開されてVRAMデータと同じ速度でレンダリングが行われつつシステムメモリと同じ速度で書き込みできる。

ロック時にD3DLOCK_DISCARDを指定すると、ドライバ内で自動的に新しいバッファを返してくるので、
更新＞描画＞更新＞描画とやっても頂点バッファロック時に描画待ちとか発生せずにアクセスできる。

774 ：名前は開発中のものです。：2006/10/21(土) 21:52:37 ID:eZHe5LjK

ぶっちゃけ２Ｄの頂点数なんてあんまり関係無いと思うよ。
なにでやってもそんなに速度に差なんてでないと予想。

２Ｄなんか
「お前、それで３Ｄモデル作れるぐらいだすつもりなのかと？
何言ってるのか？わかるか？
普通の３Ｄゲームで３Ｄモデルのポリ数をワンフレームをこさえたとしても
問題ない速度がでるのに、たかだか２Ｄゲームで何糞みたいなこと気にしてるのかと？」
問い詰めたくなる。

これが３Ｄゲームの２Ｄ部分だったとしても２Ｄのポリ数なんぞ
ほとんど影響でないと予想。
ピクセルフィルレートならわかるけどね。

775 ：名前は開発中のものです。：2006/10/21(土) 22:53:28 ID:h4fJ9Plf

２Dでも各種爆発やエフェクト系のテクスチャを1枚にまとめて、
１，２回程度のDrawPrimitiveで処理するときは数千頂点とかにはなるぞ。

まぁ変換済み頂点だからそもそもバーテックスシェーダーは経由しないけど。

あとDirectX8世代だとUP系の関数は描画完了までブロックしてたってのがある。
DirectX9で内部にバッファ作ってコピーするようになったとかならんかったとか。

まぁ今のDirectXで一番重いのはDrawPrimitive系の関数のコールだから
可能な限りDrawPrimitiveの数は減らせるように作っておいた方がいい。

776 ：名前は開発中のものです。：2006/10/21(土) 23:16:50 ID:NV8Lshdx

また知ったかを。
DrawPrimitiveは処理リストに詰めているだけで、実際にそこで処理をされるわけでは無い。
一番重くなるのはPresentをした時。

777 ：名前は開発中のものです。：2006/10/21(土) 23:22:46 ID:h4fJ9Plf

少なくともUP系は結構重いぞ。
確かにDrawPrimitiveはGPUコマンドを作成するだけだが、
Presentをしないという選択肢はありえないんだから
DirectDrawのBltみたいな気軽さでDrawPrimitive系の呼び出しは
やるもんじゃないだろ。

778 ：名前は開発中のものです。：2006/10/21(土) 23:24:21 ID:NV8Lshdx

いちいち後出しで恥の上塗りなんかしなくていいよ、みっともない。

779 ：名前は開発中のものです。：2006/10/21(土) 23:38:33 ID:ayJ9KzQY

DrawPrimitive佐賀

780 ：名前は開発中のものです。：2006/10/21(土) 23:46:13 ID:ayJ9KzQY

一番重いのは俺の体重

781 ：名前は開発中のものです。：2006/10/21(土) 23:48:22 ID:m+1yDL9S

知ったかはID:NV8Lshdxの方だと思う（俺はID:h4fJ9Plfではないが）

少なくともバッチ数によるCPU負荷のコストが尋常でないのは周知の事実だし、
commandBuffer（pushBuffer）のkick開始がPresentのタイミングと決まっているわけではない
(というか、一般的なドライバでは描画コールの度にkickは発生している)。
そもそも負荷のタイミングがどうこういう話ではなく、バッチにはコスト掛かるよってだけの話だし
見当違いも甚だしい

あと、反論があるなら>>778みたいな間抜けな勝利宣言ではない方法がお勧め

782 ：名前は開発中のものです。：2006/10/22(日) 00:13:37 ID:EaoxUskK

>一番重くなるのはPresentをした時
Presentコールしてから描画してるような言い方は止めてくれ

783 ：名前は開発中のものです。：2006/10/22(日) 00:47:09 ID:6qnIWxGe

あー、うぜ。
なんか意地になってどうしなきゃならない的なこという奴いるけど
DrawPrimitiveのコストなんて気にしないほうがいい。

これはDrawPrimitiveのコストがどうのこうのって問題じゃなくて、
まず、「仕様」ありきでしょ？って話。
で、作ってきゃわかるけど、ホントに描画が重くなってるときってこの辺最適化したって
重い動作が快適に変わることってほとんどない。

ぶっちゃけＸファイルのポリゴンのオプティマイズ関数ぐらい無駄。
テスト環境だと数字だけ上がって華やかに見えるけど、実際のゲームだとデザイナの作る物が分かれすぎてて
最適化なんてほとんどきかねーから。
これは凝ってるモデルほど最適化が効かなくのはもはや宿命。
で、快適に動くシーンってのは誰がどんな描画方法でやったって大抵はいい速度で動いちまうもんだ。
変なことしないで普通にやりやすい方法で描画しろ。

784 ：名前は開発中のものです。：2006/10/22(日) 00:50:25 ID:68ueZeB5

>>773
＞そうするとAGPメモリに展開されてVRAMデータと同じ速度でレンダリングが行われつつシステムメモリと同じ速度で書き込みできる。
大嘘もいい加減にしろ。
AGPメモリはメインメモリをビデオカード側から見えるようにマッピングするだけで、VRAMと同じ速度なんて持っていない。
ビデオカード側で頂点処理が出来るだけで、データはバスを超えて取りに行かなければならない。
頻繁に書き替えると言っても、その頻度が毎フレームとかいう状態でない限り、逆に遅くなる可能性すらある。

いつからAGPメモリがVRAMと同じ速度を持つようになったんだ？

785 ：名前は開発中のものです。：2006/10/22(日) 01:09:37 ID:5tDaX/On

>>783
DrawPrimitiveのコールで足ひっぱりのはGPUじゃなくてCPUなんだが・・・
基本的にGPUで足をひっぱるのはピクセルシェーダーだしな。

>>784
毎フレームデータ更新しないポイントスプライトがあるのかと・・・
何のためのD3DUSAGE_WRITEONLYなのかと。

実際のどこのメモリに配置されるからは完全にドライバ依存だし、
システムへの下りがない前提ならDMAでシステム＞VRAMだけですむ様にも最適化されるだろ。

786 ：名前は開発中のものです。：2006/10/22(日) 01:25:06 ID:l86FuBMq

>>776
最近のビデオカードだと、Presentですらブロックは発生しないよ。
Presentもキューに入れるだけ。
そのせいで描画に遅延が発生するという別の問題が発生している。

アクション性の高いゲームだと、その遅延が問題になるから
わざわざブロックが発生するようにLock入れたりしている。
(その方法はMSは推奨していないが)

787 ：名前は開発中のものです。：2006/10/22(日) 01:38:56 ID:EaoxUskK

データがおかしいと
GeForceが表示しなくて
RADEONが無理やり実行するって聞いた。

だいたいあってる？

788 ：名前は開発中のものです。：2006/10/22(日) 02:40:09 ID:rK8QctmW

>>777
>確かにDrawPrimitiveはGPUコマンドを作成するだけだが、
>Presentをしないという選択肢はありえないんだから

バックバッファではなくテクスチャに描画するときはDrawPrimitiveの後でPresentしないで良いんじゃない？

789 ：名前は開発中のものです。：2006/10/22(日) 04:40:10 ID:EcAvnWP5

ハードウェア的に浮動小数点のHDRレンダリングターゲットに対する
アルファブレンディングがサポートされていない環境で，
ps_2_0くらいまでのHLSLでHDRへのアルファブレンドを実現する方法はないでしょうか？

HLSLでHDRのアルファブレンディングを実装するために，
ピクセルシェーダでソースカラーとレンダリングターゲットのピクセルカラーを混ぜる方法をとろうとしたのですが，
描画先のピクセル座標はps_3_0で無いと取得できないようで……．
ちょっとps_3_0は今の時期のゲームに使うのは環境的に難しそうなので，他の方法がほしいのですが．
(おまけに自分のグラボでは古くて動いてくれない('A`；；エフェクトエディタではSuccessになったのですが)

>>763
爆発エフェクトとかに対してごちゃごちゃやってみたいので，
なんとか3Dスプライト?も使いたいのです．

790 ：名前は開発中のものです。：2006/10/22(日) 04:56:12 ID:ic1Mev2+

>>789
頑張ってますね～

HDRバッファもテクスチャとしてHLSLに渡したら参照可能かな？

791 ：名前は開発中のものです。：2006/10/22(日) 05:21:33 ID:EcAvnWP5

>>790
自分もその方法でやってみたんですけど最終的にカラー合成するとき，
HDRターゲットテクスチャ側のピクセルカラーを取ってくるのにtex2D()を使ったのですが，
座標指定が必要になるので，ピクセルシェーダの入力にVPOSを入れたのですが，
このVPOSというセマンティックはps_3_0以降でないとサポートされないようなのです．

792 ：名前は開発中のものです。：2006/10/22(日) 07:31:43 ID:l86FuBMq

>>791
普通にテクスチャ座標で指定するだけでは？
Direct3D使って2Dエフェクト実装したことないの？

793 ：名前は開発中のものです。：2006/10/22(日) 08:32:51 ID:5tDaX/On

>>788
いやいや、結局その後どこかでPresent()はするわけじゃん。

>>789
１．HDRーRT
　　モデルなどをHDRでレンダリング

２．トーンマップなどのHDR処理

３．HDR-RTからLDR-RTへのフォーマット変換転送
　　　StretchRect()

４．半透明を使用したエフェクト描画＆２D描画

５．LDR-RTからバックバッファへのフォーマット変換転送
　　　StretchRec t()

６．Present（）

ようはHDR-RTだけで処理を関係させようと思わなければいい。
パーティクル関係がHDR処理をされる必要はないんだし。

794 ：名前は開発中のものです。：2006/10/22(日) 08:47:57 ID:l86FuBMq

>>793
Presentを一切実行しないDirect3Dプログラムというのも有り得る。
EndSceneの間違いなら分かるが。

795 ：名前は開発中のものです。：2006/10/22(日) 09:01:21 ID:5tDaX/On

あぁそうか画面に描画しねーならPresentはいらねーな。
そもそもDrawPrimitiveしないならBegin-Endもいらんか。

>>776ので勘違いしてた。
Present()が重いのは基本的にそこで全描画を待つからであって、
別にPresent()でkickしてるからではないって話だったな。

まぁこのへんも全部ドライバ依存だから一律決まってるわけでもないが・・・。

796 ：名前は開発中のものです。：2006/10/22(日) 09:37:22 ID:EcAvnWP5

>>792
HLSLは正直あんまり使ったことないです．(´･ω･`)
どういう風に実装するものなんでしょ？

>>793
ふむむ，やっぱりエフェクト類は分離させた方が早いですか．
とりあえず動く状態にしたいのでそれでいってみます．

797 ：名前は開発中のものです。：2006/10/22(日) 12:54:52 ID:ic1Mev2+

>>791
描画座標をテクスチャ座標に変換してピクセルシェーダに渡すだけだよー
（テクスチャサイズか変換マトリクスをHLSLに渡す必要がある）
頂点シェーダの入力はテクスチャ座標１つでも、ピクセルシェーダは２つとか可能だからね。

基本的に、頂点シェーダが持つ特殊なデータを渡したい時はテクスチャ座標を使います。

798 ：名前は開発中のものです。：2006/10/22(日) 13:11:03 ID:ic1Mev2+

> ２．トーンマップなどのHDR処理
> ３．HDR-RTからLDR-RTへのフォーマット変換転送
> 　　　StretchRect()

トーンマップってHDR→LDRを含むよね。

っつーか、その案はすでに出してるんだけど。

799 ：名前は開発中のものです。：2006/10/22(日) 13:40:07 ID:l86FuBMq

GPGPUなんかはPresentしないね。

800 ：名前は開発中のものです。：2006/10/22(日) 13:54:46 ID:hF59/NZX

ID:NV8Lshdxの再登場はまだ？
それとも既にいるなら名乗ってくれよー

801 ：名前は開発中のものです。：2006/10/22(日) 13:57:03 ID:76l0BiyE

AfterEffectﾓﾄﾞｷのエフェクトアニメーション作成ツールを作ったときもPresentは使わなかった。
バックバッファをD3DXSaveSurfaceToFileで取り出してAVIにエクスポートするだけだったんで。

802 ：名前は開発中のものです。：2006/10/22(日) 14:09:11 ID:hF59/NZX

>>801
つまりPresentが要らない分、超爆速ってことだね!
なんてったって「一番重たくなる」Presentが要らないんだもんね!

という戯言はともかくとして
処理は別スレッドで行って、なんか適当に「エクスポート中です」とかアニメーションさせた
画面出しておいた方がツール使う人の不安ちょっと解消されるかもね
使う人がプログラマだったらそんなんむしろ邪魔だろうけどデザイナプランナが使うんならって話ね

803 ：名前は開発中のものです。：2006/10/22(日) 19:57:45 ID:l86FuBMq

>>802
801のツールが何も画面に表示してないとは書いてないし、
その表示にPresentいらないし。GDIで十分。

804 ：名前は開発中のものです。：2006/10/22(日) 22:07:46 ID:EaoxUskK

GDIは、3Dやってくれん

805 ：名前は開発中のものです。：2006/10/23(月) 00:01:56 ID:qi743vUp

3Dは別に必要ないんじゃないかと思うが

806 ：名前は開発中のものです。：2006/10/23(月) 13:14:35 ID:6CPwqHL/

GDIだと
いろんなブレンドが面倒だろ

807 ：名前は開発中のものです。：2006/10/23(月) 13:55:20 ID:XYoLA6BQ

そこでMMXが満を持して登場

808 ：名前は開発中のものです。：2006/10/23(月) 14:03:27 ID:6CPwqHL/

5年ぐらい前のコードをまた書けと

809 ：名前は開発中のものです。：2006/10/23(月) 14:20:12 ID:AlorIxAy

802の言う程度の描画ならGDIで十分、という話だと思う。
で、Presentはいらない場合もあるね、ってことだろう。
もはやなんの話だったかおぼえてないけど。

810 ：名前は開発中のものです。：2006/10/23(月) 14:24:28 ID:XYoLA6BQ

Presentが一番処理が重いんだ！とおっしゃった方が発端かと。

811 ：名前は開発中のものです。：2006/10/23(月) 16:24:59 ID:Z6chIrR/

普通に時間計ったらPresentが一番重くなるんじゃないの？描画待ちで。

それを、Present使わない稀な例を挙げて騒いでるのはなんで？？

812 ：名前は開発中のものです。：2006/10/23(月) 17:15:55 ID:XYoLA6BQ

>>811
最初にPresentが重いといった人がどういう意図でいったのか分からんが、
描画待ちをしてるからではなく、状況に依存せずに重いと言ったんじゃなかろうか。

そもそも描画が完了してる状況ならさして重くないんだし。

813 ：名前は開発中のものです。：2006/10/23(月) 17:28:47 ID:6CPwqHL/

Presentの前に通常処理をすればいいじゃない

814 ：名前は開発中のものです。：2006/10/23(月) 17:54:32 ID:6CPwqHL/

佐賀

815 ：名前は開発中のものです。：2006/10/23(月) 19:25:37 ID:jKlaZ7Jm

>>811
ほっとけ。
相手にしてもしょうがない。

816 ：名前は開発中のものです。：2006/10/23(月) 19:37:27 ID:6CPwqHL/

誰か
GeForceとRADEONの違いについて語って

817 ：名前は開発中のものです。：2006/10/23(月) 21:30:48 ID:ciin62ac

>>811
お前さんはとんでもない勘違いをしている。
Presentをしないプログラムも有り得るという話は、Presentが
重いという話の流れではなく>>777に対するレス。

818 ：名前は開発中のものです。：2006/10/23(月) 22:21:08 ID:Z6chIrR/

>>777 はある程度内部処理を想像できてるから、
UP系と非UP系＋Presentとを比較した発言をしてるよね？

それに対して「Presentしない例もある」って言ってる人は
話の根本を理解してない上に、内部処理を理解してない人まで混じってる。

「Presentしないこともあるけどね」程度で終わればいいが
そっちの話にばかり移ってるのがおかしいんだよ。

819 ：名前は開発中のものです。：2006/10/23(月) 23:31:10 ID:uPBAMZ42

んじゃそろそろクリスマスPresemtでも考えようぜ。
俺はゲームボーイアドバンス

820 ：名前は開発中のものです。：2006/10/23(月) 23:48:22 ID:9Lc6zUn4

やっべ驚くほどつまんない人が現れた

821 ：名前は開発中のものです。：2006/10/24(火) 00:39:22 ID:XXqaDRKI

>>819 勇んでボケたのに咬んだね・・・＞ｽﾍﾟﾙﾐｽ

822 ：名前は開発中のものです。：2006/10/24(火) 00:44:01 ID:29CX4dpv

>>818
話の本筋が一段落したところで
脇道にそれてわいわいやってただけなので
文脈読んでください。
おかしいのはお前の会話能力です。

823 ：名前は開発中のものです。：2006/10/24(火) 01:01:12 ID:XXqaDRKI

>>822 天才発見ｗ

824 ：名前は開発中のものです。：2006/10/24(火) 01:19:20 ID:1zYYZAzr

わいわいやってたんだ・・・

825 ：名前は開発中のものです。：2006/10/24(火) 02:59:13 ID:TWYQ8KiQ

Presentが一番重たい人に比べたら
誰だって天才だよｗ

826 ：名前は開発中のものです。：2006/10/24(火) 14:20:05 ID:8Vuprf8E

P
r
e
s
e
n
t

827 ：名前は開発中のものです。：2006/10/24(火) 19:59:24 ID:sJcOwBty

pre-sentをそのまま訳したら「先送り」になってしまうな…

828 ：名前は開発中のものです。：2006/10/25(水) 02:10:07 ID:KTdU/3F0

>>825 ﾊﾞｶがおるｗ

829 ：名前は開発中のものです。：2006/10/25(水) 02:57:23 ID:EYzF8ef7

presentが一番重たい人キター！

830 ：名前は開発中のものです。：2006/10/25(水) 04:08:53 ID:LLqUJYx8

今モーションの補間をやろうとしています。
キーフレームには各ボーンに対応するクオータニオンが設定されていて、そのキーフレーム
間のクオータニオン同士をなめらかに補間しようと考えています。
とりあえずD3DXQuaternionSquadSetupとD3DXQuaternionSquadを使って補間してみたの
ですが、この問題
http://bbx.hp.infoseek.co.jp/cgi-bin/bbx.cgi?log=40&vew=58
と同じ問題が出て困っています。このスレッドではGemsのサンプルを使うと良い、といった
事が書かれていますが、Gemsの方はGemsの方で、クオータニオンを360度一回転させると
おかしくなる等問題があります。
クオータニオンをD3DXVECTOR4にキャストしてCatmullRomで補間してみたりもしたのですが、
やっぱり一回転できない等問題が出てしまいます。

クオータニオン同士を滑らかに補間したい時は普通どうやるんでしょうか。
あんまりキーフレーム同士の角度が離れすぎないようにしてD3DXQuaternionSquadで補間する
しか無いんでしょうか？
それなりに滑らかに見えればOKで、あんまり厳密さとかは求めてないんですが・・・。

831 ：名前は開発中のものです。：2006/10/25(水) 12:15:51 ID:SFxxjz98

>>830
反転なしのslerpでsquadを実装、でだめなの？
その360度一回転ってのがよくわからないんだけど、まさか一区間で
一回転じゃないわよね。とりあえず例が無いとわからないわ。

832 ：名前は開発中のものです。：2006/10/25(水) 12:47:20 ID:5VGIVB7p

「妹と月イチでＨなことしてる♪」と女子高生タレントがblogで発言→炎上中　★2
http://news20.2ch.net/test/read.cgi/news/1161654591/

833 ：名前は開発中のものです。：2006/10/25(水) 13:37:44 ID:LLqUJYx8

>>831
ギャー！全然関係無いうっかりミスが原因でした。
仰る通り、反転無しのslerpで正しく動きます。
上の質問は忘れてください、お騒がせしました。

834 ：名前は開発中のものです。：2006/10/27(金) 17:51:49 ID:HiN9NZ19

PCで
３D技術使いまくり系で
めがっさキレイなゲームって何があります？

835 ：名前は開発中のものです。：2006/10/27(金) 18:54:51 ID:eZSZuVfp

おれのゲーム

836 ：名前は開発中のものです。：2006/10/27(金) 19:35:30 ID:HiN9NZ19

うｐ

837 ：名前は開発中のものです。：2006/10/28(土) 00:40:05 ID:lejTk6wo

DirectXSDKを最新版にしたい場合、旧バージョンアンインストール→新盤DL＆インストールって手順でOK？

838 ：名前は開発中のものです。：2006/10/28(土) 02:52:28 ID:YtJcGF1Q

>>834
今なら間違いなくCrysis
ttp://www.xasis-game.com/title/crysis/movie.shtml

既に発売してるものならProject Gotham Racing 3

839 ：名前は開発中のものです。：2006/10/28(土) 13:18:04 ID:csTaW2+P

>>837
新版DL→旧バージョンアンインストール→インストールの方がたぶんｲｶす

840 ：名前は開発中のものです。：2006/10/29(日) 21:53:43 ID:rzQT+t6V

遅レスで申し訳ないんだけど、結局、頂点をCPU側で動的に書き換える場合、
DrawPrimitive、DrawPrimitiveUP、DrawIndexedPrimitive、DrawIndexedPrimitiveUP
のどれを、どう使うのが一般的なの？

kickとかよくわからない素人なのですが、識者の方、どうかまとめてくれないでしょうか

841 ：名前は開発中のものです。：2006/10/29(日) 22:38:31 ID:K8O/95s8

>>840
てめぇで考えろよ。
正解なんてねぇよ。

842 ：名前は開発中のものです。：2006/10/29(日) 23:20:08 ID:GlgZOmB4

>>843
あ？けんかう

843 ：名前は開発中のものです。：2006/10/29(日) 23:27:52 ID:PaY4YJF2

>>842
けんかう。

844 ：名前は開発中のものです。：2006/10/29(日) 23:45:05 ID:K8O/95s8

(´･ω･`)<人に関数決めてもらわなきゃ描画も出来ネェ糞餓鬼がなめてんじゃねぇぞ！ｶｶｯﾃｺｲﾖ！ｵﾗ！

845 ：名前は開発中のものです。：2006/10/29(日) 23:54:45 ID:swLW9KaN

>>840
時と場合による。
どのような時に何がもっとも有効かはリファレンスを熟読しましょう。
その後の検証も忘れずにな。

846 ：名前は開発中のものです。：2006/10/30(月) 00:35:12 ID:o7aFQX0n

俺は、本当は誰もそんなパターンなんて出来てないし誰も理解も出来てない、と思うんだ

>どのような時に何がもっとも有効か
なんてリファレンスを見るまでもなく、そのパターンが少しは出てくるはずだが、1つも出てこないから

847 ：名前は開発中のものです。：2006/10/30(月) 01:21:58 ID:C0/Sv58N

そうか？
少なくとも俺の今のプログラムの中ではUP系関数を使う箇所はない。
DrawPrimitive系どうこうよりも、頂点バッファの作り方と使い方のほうが重要だし。

848 ：名前は開発中のものです。：2006/10/30(月) 02:28:31 ID:DnQfbB/1

みんな頂点ストリーム使ってないのか？
UPだと０番しか使えないぞ。

０で座標、１でＵＶ、２で法線、３で・・・

って使うと汎用的に使えて便利だぞ。
UPだとこういうもの作るのに向いてない。

849 ：名前は開発中のものです。：2006/10/30(月) 02:31:28 ID:d4X25+aF

他人に使う関数を決めてもらうような人間が
頂点ストリーム使ってたり知ってたりするはずがない。

850 ：名前は開発中のものです。：2006/10/30(月) 04:38:50 ID:HYgOtsaj

>>840
よく分からない奴はUP系を使うのがベスト。
VertexBufferはよく分からないで使っていると、パフォーマンスを
悪化する可能性がある。

851 ：名前は開発中のものです。：2006/10/30(月) 09:58:40 ID:qTkdSgLV

>>848
GPUの中身知ってると、そんな非効率的な実装する気にはならなくなるけどねぇ
preであれpostであれ頂点キャッシュ無駄にし過ぎ

852 ：名前は開発中のものです。：2006/10/30(月) 11:34:36 ID:auNg4VTg

>>851
どういうふうに非効率なの？
GPU Gemsでも848みたいな例が載ってた気がするけど真似しちゃまずいのか？

853 ：名前は開発中のものです。：2006/10/30(月) 12:32:10 ID:Kb3dfOrG

頂点ストリームの切替えやテクスチャの切替えはキャッシュがクリアされ
パフォーマンスの大幅な低下の原因になる。
つーかこれは普通にドキュメントに書いてあることなんだが。
この程度の日本語も理解できないのか？

854 ：名前は開発中のものです。：2006/10/30(月) 21:28:08 ID:C0/Sv58N

ストリームを複数使うのと、ストリームを切り替えるのは違うと思うだな。

855 ：名前は開発中のものです。：2006/10/31(火) 00:29:57 ID:Gz2/in6U

最近のハードだと頂点ストリームやテクスチャの切り替えでもstallは起きない。
パイプラインにステート変更コマンドが流されるだけ

つうか851の本文に答え書いてあるのになんで疑問系で返ってくるんだろう
これ以上は書かないので後は自分で頑張れ

856 ：名前は開発中のものです。：2006/10/31(火) 00:32:58 ID:6ezWOrLE

複数ストリームはドライバが内部的に１つのストリームとして展開してると思うんだが・・・

857 ：名前は開発中のものです。：2006/10/31(火) 01:54:05 ID:3fmEp8uo

>>855
あｗ逃げてやんのｗ
わかるんだｗ俺ｗ

858 ：名前は開発中のものです。：2006/10/31(火) 22:52:52 ID:XDYbMhDw

ビデオカードによって最適な実装は異なる。

859 ：名前は開発中のものです。：2006/10/31(火) 22:56:27 ID:6ezWOrLE

SetStreamSource()の呼び出しで頂点バッファが切り替えられてキャッシュが云々はわかる。

だが複数ストリームを使ったら１頂点処理するごとにキャッシュミスが発生なんて
阿呆な実装がまずありえないだろ・・・。

860 ：名前は開発中のものです。：2006/10/31(火) 23:00:46 ID:mCqyMb0n

つまり、

複数の描画方法を実装して、
ゲーム中に切り替えて比較して、
描画対象によって結果集計して、
リアルタイムに切り替えていけばいいわけですね！！！

861 ：名前は開発中のものです。：2006/11/01(水) 00:14:46 ID:o/Y9sipL

>>860
ボケなんだか微妙なラインすぎて困ってるだろｗ

実際に、実行時にテストしてから開始するソフトあったような・・
もちろん構成が変わってなければパフォーマンス一緒だから最初の一回だけだと思うが。

862 ：名前は開発中のものです。：2006/11/01(水) 02:06:17 ID:0Q6qMURg

深海からの保守

863 ：名前は開発中のものです。：2006/11/01(水) 02:09:32 ID:hxk+oCO7

ボケしかいないスレ。

864 ：名前は開発中のものです。：2006/11/02(木) 16:59:51 ID:diKduz13

DirectInput対応のゲーム等の操作を記録して、後で再生してくれるプログラムとかないですかね

865 ：864：2006/11/02(木) 17:00:23 ID:diKduz13

JOYPADの操作です

866 ：名前は開発中のものです。：2006/11/02(木) 17:29:34 ID:sljvqe49

なければ作ればいいじゃない

867 ：名前は開発中のものです。：2006/11/02(木) 17:32:43 ID:diKduz13

>>866
作り方、もしくは作り方を書いているところ教えて。
DirectXのHPとか、PG全般の解説とかは却下ｗ

868 ：名前は開発中のものです。：2006/11/02(木) 18:26:23 ID:MbI5+NQI

むしろ、なんで作れないのか聞きたいわ・・・。
ミドルウェアあたりに隠蔽されてるとか？

869 ：名前は開発中のものです。：2006/11/02(木) 19:13:06 ID:j7Di0j5Z

>>864は「DirectInput対応のゲーム」のリプレイするツールが欲しいのだろう。
ゲーム作ってるわけじゃないし、
ツール作ってくれというわけですら無い（作んねーけどｗ。
板違いだシネｗｗｗｗｗ

870 ：名前は開発中のものです。：2006/11/02(木) 19:27:12 ID:sljvqe49

キーとかは、フックすればいいけど
ジョイスティックは、フックできないんだったな
ぬう

871 ：名前は開発中のものです。：2006/11/02(木) 19:29:35 ID:Qouz5BcI

それで金になるのならどこかの外人がドングルでも作ってくれそうだな

872 ：名前は開発中のものです。：2006/11/02(木) 19:34:50 ID:l6NE8mv1

DirectInputでジョイスティックの記録取るプログラムなんて簡単に
作れるけど、そんなの記録・再生してもリプレイにはならんよ。
操作情報だけでリプレイを再生するには、最初からゲームの方を
そういう風に作ってないと駄目。

873 ：名前は開発中のものです。：2006/11/02(木) 19:39:05 ID:fFdnY76s

教えて君ってなんでこんなに偉そうなんだろうね、どいつもこいつも

874 ：名前は開発中のものです。：2006/11/02(木) 19:48:31 ID:pOKzl3XB

他人のことを自動的に回答するBOT程度にしか見てないからだろ

875 ：名前は開発中のものです。：2006/11/02(木) 19:56:53 ID:YdcE35F8

教えるほどの技術を持ってない人ばっかりだからね。
結局のところ質問に対して煽りレスしかできない低能君が
一番偉そうにしていてうざいんだよｗ

876 ：名前は開発中のものです。：2006/11/02(木) 20:01:55 ID:Qouz5BcI

>>875
キミが>>864に
「DirectInput対応のゲーム等の操作を記録して、後で再生してくれるプログラム」
を紹介すれば済む話だよ

コードじゃなくてバイナリが欲しそうな気がするから、できれば
ソフト板かどこかに誘導してから教えてあげるといいんだが

877 ：名前は開発中のものです。：2006/11/02(木) 20:35:05 ID:pOKzl3XB

つーか、誰にも教える義務も義理も無いんだから、
回答が無くても問題解決しなくても、
文句いうのはお門違いどころか図々しいだけなんだけどな。
極端に言えば対価も無しに何かを得ようなど、乞食に等しい。

878 ：名前は開発中のものです。：2006/11/02(木) 20:54:53 ID:j7Di0j5Z

いや、ちょっと便利ツール探しにきたら、
「うはｗｗ釣堀ｗｗｗｗｗらっきーｗｗｗｗｗｗｗｗ」
ってだけだから、相手するのも程々になｗ

879 ：名前は開発中のものです。：2006/11/02(木) 20:55:48 ID:83ucivUk

レスが付くことに絶望するところだろ

880 ：名前は開発中のものです。：2006/11/02(木) 22:32:09 ID:px5hsvCI

「教えてやる」っていう高圧的な態度が少なくともあって
質問者＝自分より低レベル　っていう意識ｇ

このやり取りあと何回見るんだろ・・・

881 ：名前は開発中のものです。：2006/11/02(木) 23:08:30 ID:7kYH3ckO

そこそこの技術力があれば2chなぞで技術的な質問なぞしない。
自力で文献なりwebなりあたって試行錯誤すれば解決するからな。
実際質問者のレベルが高いことあったか？

882 ：名前は開発中のものです。：2006/11/03(金) 00:01:39 ID:px5hsvCI

知るか
もう来んな

883 ：名前は開発中のものです。：2006/11/03(金) 00:26:49 ID:1gPBctES

つうか、>864は質問の仕方が悪い。
回答者にどれだけ知識があろうと必要な情報がなければ判断不能だ。
どういう状況で、お前さんはなにを試して(あるいは知っていて)、どういう結果を期待してるのか、
最低このセットは書かないと、あいまいなレスしかつけようがない。

884 ：名前は開発中のものです。：2006/11/03(金) 00:40:28 ID:/1nzuXOf

そんな自明な事を意気揚々と語るなよ
見てるこっちが恥ずかしくなるじゃないか
それじゃ釣られてるのと変わらねーよ
そこまで馬鹿にする奴に説教なんて時間の無駄じゃねーのか

低俗な奴に関わらないと気が済まないのはやっぱり低俗な奴だなｗｗｗｗｗｗｗｗ

885 ：名前は開発中のものです。：2006/11/03(金) 16:22:50 ID:ivhE0hMW

却下ｗ
↑
何様？

886 ：名前は開発中のものです。：2006/11/03(金) 17:08:44 ID:AZI7KT4b

>>885
作り方、もしくは作り方を書いているところ教えて。
DirectXのHPとか、PG全般の解説とかは却下ｗ

887 ：名前は開発中のものです。：2006/11/03(金) 17:11:48 ID:ivhE0hMW

>作り方
フックしろ

>書いてるところ教えて
http://www.google.co.jp/
ここのどこかにあった

888 ：名前は開発中のものです。：2006/11/06(月) 09:19:16 ID:hPi0h3GZ

描画時の処理が増えて一フレーム描くのにCPU100%でフル回転させてもFPS60いかなくなったんだけど
するとなぜかGetCursorPosでとれるマウスの座標に目立って遅延がでてくるようになってしまった
DI使っても改善しないしどうなってるんだろうかこれは

マビノギでも同じような現象が起こってるけど
HL2とかでは遅れなく視点を動かせるのでメインループの書き方次第なんではないかと思うんだけど…

889 ：864：2006/11/06(月) 11:44:40 ID:hv30gwX2

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

890 ：名前は開発中のものです。：2006/11/06(月) 12:27:48 ID:oOcp7ViM

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

891 ：名前は開発中のものです。：2006/11/06(月) 12:29:39 ID:clenw2Y6

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

892 ：名前は開発中のものです。：2006/11/06(月) 17:08:24 ID:+lyukF9s

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

893 ：名前は開発中のものです。：2006/11/06(月) 18:02:51 ID:rMszPwdC

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

894 ：名前は開発中のものです。：2006/11/06(月) 18:31:26 ID:clenw2Y6

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

895 ：名前は開発中のものです。：2006/11/06(月) 18:39:32 ID:hPi0h3GZ

>>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でてるときよりも
マウスの動きへの追従に関しては良かったり

896 ：名前は開発中のものです。：2006/11/06(月) 19:04:42 ID:7IobZSRQ

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

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

897 ：名前は開発中のものです。：2006/11/06(月) 19:06:31 ID:PBBf0u6D

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

898 ：名前は開発中のものです。：2006/11/06(月) 19:08:19 ID:PBBf0u6D

うそつくな俺

899 ：名前は開発中のものです。：2006/11/06(月) 19:40:52 ID:kJNIWXZq

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

900 ：名前は開発中のものです。：2006/11/06(月) 19:49:21 ID:7IobZSRQ

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

901 ：名前は開発中のものです。：2006/11/06(月) 20:45:44 ID:YCZtqO2r

PeekMessage
PM_REMOVE

902 ：名前は開発中のものです。：2006/11/06(月) 20:59:15 ID:PBBf0u6D

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

903 ：名前は開発中のものです。：2006/11/06(月) 21:14:37 ID:YF9A2o7C

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

904 ：名前は開発中のものです。：2006/11/06(月) 22:06:31 ID:M5YGVbkM

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

905 ：名前は開発中のものです。：2006/11/06(月) 23:18:23 ID:+lyukF9s

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

906 ：名前は開発中のものです。：2006/11/07(火) 01:29:54 ID:NTlv/duM

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

907 ：名前は開発中のものです。：2006/11/07(火) 03:01:33 ID:+YjGlCmW

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

908 ：名前は開発中のものです。：2006/11/07(火) 06:03:52 ID:NTlv/duM

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

909 ：名前は開発中のものです。：2006/11/07(火) 10:48:06 ID:6WoLvZ3v

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

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

910 ：名前は開発中のものです。：2006/11/07(火) 12:30:39 ID:injs5fnt

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

911 ：名前は開発中のものです。：2006/11/07(火) 12:36:51 ID:T6X3CPc6

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

912 ：名前は開発中のものです。：2006/11/07(火) 12:46:36 ID:fxAXrr+V

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

913 ：名前は開発中のものです。：2006/11/07(火) 13:54:36 ID:WJeQGxZV

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

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

914 ：名前は開発中のものです。：2006/11/07(火) 14:03:41 ID:uDTnp1xL

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

915 ：名前は開発中のものです。：2006/11/07(火) 22:02:56 ID:6WoLvZ3v

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

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

916 ：名前は開発中のものです。：2006/11/07(火) 23:10:00 ID:0/eivshj

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

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

917 ：名前は開発中のものです。：2006/11/07(火) 23:49:29 ID:LeIp7IEU

話が混乱してるね。

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

918 ：名前は開発中のものです。：2006/11/08(水) 00:04:21 ID:PzBEheVj

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

919 ：名前は開発中のものです。：2006/11/08(水) 00:14:05 ID:pix4d+V7

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

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

920 ：名前は開発中のものです。：2006/11/08(水) 00:15:41 ID:Ez0+ULCi

>>918
教えて君氏ねよ

921 ：名前は開発中のものです。：2006/11/08(水) 00:29:44 ID:lruYnhtq

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

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

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

922 ：名前は開発中のものです。：2006/11/08(水) 00:57:06 ID:Cl3R/oTn

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

923 ：名前は開発中のものです。：2006/11/08(水) 01:06:22 ID:CiKq08vx

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

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

924 ：名前は開発中のものです。：2006/11/08(水) 01:14:10 ID:lruYnhtq

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

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

925 ：名前は開発中のものです。：2006/11/08(水) 01:42:30 ID:Cl3R/oTn

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

926 ：名前は開発中のものです。：2006/11/08(水) 01:54:34 ID:4HOV88nB

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

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

927 ：名前は開発中のものです。：2006/11/08(水) 02:06:40 ID:Cl3R/oTn

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

928 ：名前は開発中のものです。：2006/11/08(水) 05:15:49 ID:4HOV88nB

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

929 ：名前は開発中のものです。：2006/11/08(水) 10:27:55 ID:paxGIPEB

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

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

930 ：名前は開発中のものです。：2006/11/08(水) 11:20:58 ID:Ez0+ULCi

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

931 ：名前は開発中のものです。：2006/11/08(水) 12:28:30 ID:lruYnhtq

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

932 ：名前は開発中のものです。：2006/11/08(水) 14:46:09 ID:jIjbRi6u

その為のStreamOut

933 ：名前は開発中のものです。：2006/11/08(水) 22:06:45 ID:RvQZC3kp

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

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

934 ：名前は開発中のものです。：2006/11/09(木) 06:28:09 ID:dA8KH0sb

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

935 ：名前は開発中のものです。：2006/11/09(木) 06:37:42 ID:EoL+7LTg

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

936 ：名前は開発中のものです。：2006/11/09(木) 16:17:05 ID:pnXhdXXR

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

937 ：名前は開発中のものです。：2006/11/09(木) 17:55:45 ID:X56FVTnt

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

938 ：名前は開発中のものです。：2006/11/09(木) 19:00:04 ID:lRUVCD7x

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

939 ：名前は開発中のものです。：2006/11/09(木) 20:16:11 ID:MOSFB80B

[Z反転、カリング]

940 ：名前は開発中のものです。：2006/11/10(金) 01:06:39 ID:BfaFVTZm

[あきらめてオナニー]

941 ：名前は開発中のものです。：2006/11/10(金) 20:06:55 ID:hiaIqhZL

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

942 ：名前は開発中のものです。：2006/11/10(金) 20:13:56 ID:VWQOMstK

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

943 ：名前は開発中のものです。：2006/11/12(日) 07:25:35 ID:dfs286Zp

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

944 ：名前は開発中のものです。：2006/11/12(日) 08:01:52 ID:pffADuxK

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

945 ：名前は開発中のものです。：2006/11/12(日) 08:33:25 ID:dfs286Zp

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

946 ：名前は開発中のものです。：2006/11/12(日) 08:52:14 ID:5TS195Vt

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

947 ：名前は開発中のものです。：2006/11/12(日) 09:40:04 ID:dfs286Zp

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

948 ：名前は開発中のものです。：2006/11/12(日) 09:40:55 ID:dfs286Zp

>>946 の間違いでつ

949 ：名前は開発中のものです。：2006/11/12(日) 09:48:34 ID:p2LxhttU

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

950 ：名前は開発中のものです。：2006/11/12(日) 18:14:36 ID:SJJfaFn1

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

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

951 ：名前は開発中のものです。：2006/11/12(日) 19:11:41 ID:CQikaQFF

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

952 ：名前は開発中のものです。：2006/11/12(日) 22:42:19 ID:6dWQ+52S

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

953 ：名前は開発中のものです。：2006/11/15(水) 02:00:13 ID:vxzOfYC6

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

954 ：名前は開発中のものです。：2006/11/15(水) 09:11:02 ID:3I9mMgDp

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

955 ：名前は開発中のものです。：2006/11/15(水) 21:38:08 ID:DxvRaGSO

質問させてください。

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

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

956 ：名前は開発中のものです。：2006/11/15(水) 21:52:08 ID:3I9mMgDp

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

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

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

957 ：名前は開発中のものです。：2006/11/15(水) 22:08:28 ID:DxvRaGSO

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

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

958 ：名前は開発中のものです。：2006/11/15(水) 22:57:25 ID:3I9mMgDp

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

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

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

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

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

959 ：名前は開発中のものです。：2006/11/15(水) 23:13:28 ID:YpYvtoj0

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

960 ：名前は開発中のものです。：2006/11/15(水) 23:22:21 ID:DxvRaGSO

>愛用の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にするしか方法が無いように思えます。
他にもっと良い方法はあるでしょうか。

961 ：名前は開発中のものです。：2006/11/15(水) 23:29:37 ID:DxvRaGSO

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

962 ：960：2006/11/15(水) 23:31:19 ID:DxvRaGSO

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

963 ：名前は開発中のものです。：2006/11/15(水) 23:39:15 ID:DxvRaGSO

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

964 ：名前は開発中のものです。：2006/11/16(木) 00:09:26 ID:j2RP45RN

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

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

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

965 ：名前は開発中のものです。：2006/11/16(木) 00:13:48 ID:j2RP45RN

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

966 ：名前は開発中のものです。：2006/11/16(木) 00:24:19 ID:SEFYYBum

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

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

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

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

967 ：名前は開発中のものです。：2006/11/16(木) 00:30:01 ID:gbtniTxU

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

968 ：名前は開発中のものです。：2006/11/16(木) 00:43:23 ID:bg7PnqAA

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

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

969 ：名前は開発中のものです。：2006/11/16(木) 00:49:19 ID:j2RP45RN

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

970 ：名前は開発中のものです。：2006/11/16(木) 00:51:19 ID:j2RP45RN

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

971 ：名前は開発中のものです。：2006/11/16(木) 00:54:53 ID:xa3CEDbM

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

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

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

972 ：名前は開発中のものです。：2006/11/16(木) 00:56:21 ID:bg7PnqAA

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

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

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

973 ：名前は開発中のものです。：2006/11/16(木) 00:58:52 ID:N/Cya+Sz

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

以上

974 ：名前は開発中のものです。：2006/11/16(木) 01:04:04 ID:j2RP45RN

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

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

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

975 ：名前は開発中のものです。：2006/11/16(木) 01:07:16 ID:bg7PnqAA

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

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

976 ：名前は開発中のものです。：2006/11/16(木) 01:14:33 ID:j2RP45RN

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

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

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

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

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

977 ：名前は開発中のものです。：2006/11/16(木) 01:15:40 ID:bg7PnqAA

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

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

978 ：名前は開発中のものです。：2006/11/16(木) 01:17:25 ID:LRTBYOXP

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

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

979 ：名前は開発中のものです。：2006/11/16(木) 01:19:01 ID:j2RP45RN

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

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

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

980 ：名前は開発中のものです。：2006/11/16(木) 01:23:06 ID:j2RP45RN

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

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

981 ：名前は開発中のものです。：2006/11/16(木) 01:24:21 ID:1aVg1Jra

j2RP45RNさんはやさしいなぁ

982 ：名前は開発中のものです。：2006/11/16(木) 01:31:20 ID:j2RP45RN

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

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

983 ：名前は開発中のものです。：2006/11/16(木) 01:35:22 ID:bg7PnqAA

>テクスチャ座標は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を通して見えるテクスチャのサイズのことです。
テクスチャアドレッシングはこの値のみに左右されます。
ドライバーが実際にテクスチャ割り当てたメモリサイズをプログラマが気にする必要はありません。

984 ：名前は開発中のものです。：2006/11/16(木) 01:39:06 ID:1aVg1Jra

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

985 ：名前は開発中のものです。：2006/11/16(木) 01:40:32 ID:SEFYYBum

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

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

986 ：名前は開発中のものです。：2006/11/16(木) 01:52:42 ID:bg7PnqAA

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

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

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

987 ：名前は開発中のものです。：2006/11/16(木) 01:54:28 ID:6gwZldY7

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

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

988 ：名前は開発中のものです。：2006/11/16(木) 01:59:06 ID:1aVg1Jra

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

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

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

989 ：名前は開発中のものです。：2006/11/16(木) 02:03:37 ID:SEFYYBum

D3DPTEXTURECAPS_NONPOW2CONDITIONAL

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

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

990 ：名前は開発中のものです。：2006/11/16(木) 02:05:00 ID:bg7PnqAA

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

991 ：名前は開発中のものです。：2006/11/16(木) 02:08:10 ID:SEFYYBum

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

992 ：名前は開発中のものです。：2006/11/16(木) 02:09:43 ID:1aVg1Jra

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

993 ：名前は開発中のものです。：2006/11/16(木) 02:09:55 ID:bg7PnqAA

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

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

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

994 ：名前は開発中のものです。：2006/11/16(木) 02:21:33 ID:SEFYYBum

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

995 ：名前は開発中のものです。：2006/11/16(木) 02:31:46 ID:SEFYYBum

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

996 ：名前は開発中のものです。：2006/11/16(木) 02:33:50 ID:bg7PnqAA

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

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

997 ：名前は開発中のものです。：2006/11/16(木) 02:36:43 ID:SEFYYBum

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

998 ：名前は開発中のものです。：2006/11/16(木) 02:43:59 ID:bg7PnqAA

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

999 ：名前は開発中のものです。：2006/11/16(木) 02:59:11 ID:gbtniTxU

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

1000 ：名前は開発中のものです。：2006/11/16(木) 03:04:04 ID:bg7PnqAA

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

1001 ：１００１：Over 1000 Thread

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