DirectX総合スレ (Part5)

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

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

**名前は開発中のものです。** · 2006/09/16(土) 02:30:25

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

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

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

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

**名前は開発中のものです。** · 2006/09/16(土) 02:32:05

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

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

**名前は開発中のものです。** · 2006/09/16(土) 02:32:14

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

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

**名前は開発中のものです。** · 2006/09/16(土) 03:28:26

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

**名前は開発中のものです。** · 2006/09/16(土) 04:17:31

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

**名前は開発中のものです。** · 2006/09/16(土) 06:33:25

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

**名前は開発中のものです。** · 2006/09/16(土) 10:22:52

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

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

**名前は開発中のものです。** · 2006/09/16(土) 10:30:40

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

**名前は開発中のものです。** · 2006/09/16(土) 10:46:53

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

**名前は開発中のものです。** · 2006/09/16(土) 10:59:39

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

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

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

LjBp93/Tの人気に嫉妬

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

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

**名前は開発中のものです。** · 2006/09/16(土) 12:02:24

大学はまだ休みかも

**名前は開発中のものです。** · 2006/09/16(土) 12:33:37

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

**名前は開発中のものです。** · 2006/09/16(土) 13:40:21

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

**名前は開発中のものです。** · 2006/09/16(土) 14:04:54

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

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

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

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

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

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

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

**名前は開発中のものです。** · 2006/09/16(土) 15:25:14

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

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

**名前は開発中のものです。** · 2006/09/16(土) 15:46:25

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

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

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

**名前は開発中のものです。** · 2006/09/16(土) 15:50:38

煽り立てるなっつーの！

**名前は開発中のものです。** · 2006/09/16(土) 16:08:04

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

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

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

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

**名前は開発中のものです。** · 2006/09/16(土) 16:49:39

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

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

**名前は開発中のものです。** · 2006/09/16(土) 17:04:12

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

**名前は開発中のものです。** · 2006/09/16(土) 17:12:38

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

**名前は開発中のものです。** · 2006/09/16(土) 17:33:58

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

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

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

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

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

**名前は開発中のものです。** · 2006/09/16(土) 17:38:28

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

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

**名前は開発中のものです。** · 2006/09/16(土) 17:48:21

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

**名前は開発中のものです。** · 2006/09/16(土) 18:19:37

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

**名前は開発中のものです。** · 2006/09/16(土) 18:29:38

>>190
はぁ？

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

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

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

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

**名前は開発中のものです。** · 2006/09/16(土) 18:41:42

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

**名前は開発中のものです。** · 2006/09/16(土) 18:41:45

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

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

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

**名前は開発中のものです。** · 2006/09/16(土) 19:04:21

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

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

**名前は開発中のものです。** · 2006/09/16(土) 19:09:42

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

**名前は開発中のものです。** · 2006/09/16(土) 19:10:41

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

**名前は開発中のものです。** · 2006/09/16(土) 19:14:39

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

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

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

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

**名前は開発中のものです。** · 2006/09/16(土) 19:40:30

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

**名前は開発中のものです。** · 2006/09/16(土) 19:47:35

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

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

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

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

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

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

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

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

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

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

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

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

**名前は開発中のものです。** · 2006/09/16(土) 21:00:25

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

**名前は開発中のものです。** · 2006/09/16(土) 21:07:57

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

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

**名前は開発中のものです。** · 2006/09/16(土) 21:12:18

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

　　　　　　　＼○／

**名前は開発中のものです。** · 2006/09/16(土) 21:21:07

>>209
> 平面
平面？

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

**名前は開発中のものです。** · 2006/09/16(土) 21:46:28

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

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

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

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

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

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

**名前は開発中のものです。** · 2006/09/16(土) 22:13:30

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

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

**名前は開発中のものです。** · 2006/09/16(土) 22:43:30

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

**名前は開発中のものです。** · 2006/09/16(土) 23:32:15

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

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

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

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

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

**名前は開発中のものです。** · 2006/09/16(土) 23:49:35

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

98 · 2006/09/17(日) 00:56:16

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

**名前は開発中のものです。** · 2006/09/17(日) 02:17:56

はいはい

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

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

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

**名前は開発中のものです。** · 2006/09/17(日) 08:55:25

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

**名前は開発中のものです。** · 2006/09/17(日) 13:15:12

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

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

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

**名前は開発中のものです。** · 2006/09/17(日) 14:33:11

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

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

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

**名前は開発中のものです。** · 2006/09/17(日) 17:31:19

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

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

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

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

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

**名前は開発中のものです。** · 2006/09/18(月) 16:38:09

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

**名前は開発中のものです。** · 2006/09/18(月) 16:53:16

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

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

**名前は開発中のものです。** · 2006/09/18(月) 16:56:42

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

**名前は開発中のものです。** · 2006/09/18(月) 17:01:59

>>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;
　　}

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

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

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

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

**名前は開発中のものです。** · 2006/09/18(月) 17:25:42

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

**228** · 2006/09/18(月) 17:34:23

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

**名前は開発中のものです。** · 2006/09/18(月) 17:48:58

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

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

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

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

**名前は開発中のものです。** · 2006/09/18(月) 18:20:33

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

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

**名前は開発中のものです。** · 2006/09/18(月) 18:37:41

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

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

**名前は開発中のものです。** · 2006/09/18(月) 19:37:28

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

**名前は開発中のものです。** · 2006/09/18(月) 20:02:41

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

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

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

**名前は開発中のものです。** · 2006/09/18(月) 22:05:45

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

**名前は開発中のものです。** · 2006/09/18(月) 22:08:41

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

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

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

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

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

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

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

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

**名前は開発中のものです。** · 2006/09/19(火) 00:20:26

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

**名前は開発中のものです。** · 2006/09/19(火) 00:40:10

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

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

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

**名前は開発中のものです。** · 2006/09/19(火) 00:57:12

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

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

**名前は開発中のものです。** · 2006/09/19(火) 01:06:07

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

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

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

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

**名前は開発中のものです。** · 2006/09/19(火) 01:24:36

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

**名前は開発中のものです。** · 2006/09/19(火) 01:27:01

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

**名前は開発中のものです。** · 2006/09/19(火) 01:36:21

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

**名前は開発中のものです。** · 2006/09/19(火) 01:45:48

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

**名前は開発中のものです。** · 2006/09/19(火) 01:55:02

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

**名前は開発中のものです。** · 2006/09/19(火) 01:55:43

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

**名前は開発中のものです。** · 2006/09/19(火) 01:59:05

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

**名前は開発中のものです。** · 2006/09/19(火) 02:16:05

>259
例えば