DirectX総合スレ (Part5)

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

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

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

>>448
なめてるんｄねすか？

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

>>448
まあそう嘆くな。俺のうぃｎＸＰでも使えナインｄあ。

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

>>447
ヨーヨーとかミニ四駆って忘れた頃に流行りだすでしょ

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

リサイクルだよ。
延々と新規のネタを考え続けながら食っていけるわけねーでし

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

バンダイと田宮模型のおかげだね。

**名前は開発中のものです。** · 2006/09/27(水) 00:43:41

あの～～
今シェーダープログラムを勉強しています。
本を読みながら幾つかサンプルを見てみたのですが・・・
プログラマブル頂点シェーダーって、頂点に対するライティングも自分で実装しないといけないんですよね。
今まで見たサンプルは全部ライトの位置や色を定数で設定しておいて、シェーダー内でトランスフォームする時に
色も計算、みたいな事をやっているのですが・・・
これだと、固定機能パイプラインの時に使えていた、オブジェクトのマテリアルやライトの細かいプロパティが全部
無視されますよね・・・
SetMaterialやSetLightで出来ていた事を自作の頂点シェーダーで実現するのって、物凄く難しいんでしょうか？
スポットライトやポイントライト、それらが複数あった場合等、どうすればいいのかさっぱり判らないのですが・・・
vs1.1で、デフォルトのシェーダーと同じ動きをするサンプルって無いでしょうか。

**名前は開発中のものです。** · 2006/09/27(水) 00:48:47

>>454
普通にDirectXのサンプルをコピーすればＯＫじゃん。
とかなんでそういう頭がないんだろか？

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

>>455
どのサンプルがそれに該当するんでしょうか。
LightingVSはvs2.0ですし、他の奴はちゃんとライティングをしてないようなのですが・・・
あ、ちなみに環境はDX9.0です。
出来ればアセンブラで書かれたやつが欲しいです。

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

>>456
BasicHLSLがいいんじゃない？
とりあえずこれを書き写してみるだけでどんなことやってるかわかるよ。
ちょっと足りないけど、何をやればいいかすぐにわかるよ。
まずはシェーダを読んで何やってるかわからないのがまずいと思うんだ。
一度わかればこっちのもの。

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

もっと分かりやすいぴくちぇるちぇーだーって無い？

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

DX9.;0を選んでいるのになぜVS1.1にこだわるのか。
DX10では廃止されるのになぜアセンブラのコードを求めるのか。

別に悪くはないけど気になった。
アセンブラで書いたからって別に処理速度が速くなったりはしないぞ。

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

>>459
めんどくせーよな。
何枚もにたようなもんつくらなにゃならんしポカミスバグ増えるし。
ＨＬＳＬがいいよね。

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

>>457
ありがとうございます、BasicHLSLですか・・・まずはHLSLの勉強からですかね・・・
それにしても　覚えなくちゃいけないことは次から次へとやってきますね・・・
>>459
VS1.1に拘るのは、GeForce3あたりも動作対象にしたかったからで、アセンブラが良いと思ったのは
ネットで拾ったサンプル(アセンブラで書かれてる)に、ちゃんとしたライティングをくっつけたい
と思ったからです

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

>>461
サンプルも見ない人がアセンブラのシェーダなんか覚えられる訳ない。
誰もハッキリくちには出さないけど、結局はそういうことだ。

HLSLはだいぶ楽にできるし一応アセンブラもできるから
これから勉強するならHLSLが妥当。もちろんVS1.1でも問題ない。

**名前は開発中のものです。** · 2006/09/27(水) 04:48:56

いや、覚えるだけならアセンブラは簡単だと思うがw

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

>>461
つーかさ流れ的にはVS1.1のアセンブラ＞HLSLって時代は流れてるんだから
VS1.1でアセンブラ使って作るってんなら素直にDx8のSDK使いなさいよ。

GeForce3で対応してるからとか一件いろいろなハードウェアをターゲットに
考えて作っています的な思考のやつ結構多いけど、そもそもGeForce3は何年前の
ビデオカードだと思ってるのか。すでに売ってないから入手するのも至難だろ。
世代的にも4世代も前のものだし。

どの程度のゲームを作るのかしらないが3Dがきっちりとしたもの作るなら
面倒な縛りもないDx9世代のグラフィックカード対応でいいだろ。
VS/PS2.0対応のグラボなんて2年前のノートPCにすら積んであるし、
対応ってだけなら1万円札1枚で買える程度のグラボだぞ。

あとDx8は定数レジスタが致命的に少ないから、
ポイントライトが入れられても３つ、その場合ボーン処理が出来ない、
つまり固定機能に比べても汎用面以外圧倒的に劣るって考えたほうがいいよ。

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

画面にボタンとか文字入力とかコンボイボックスは表示できますか＞

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

それなんてトランスフォーマー？

**名前は開発中のものです。** · 2006/09/27(水) 12:25:42

>>464
いや、その通りかもしれませんねえ
1.1しか動かないボードは切っても良いかもしれませんな

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

>>464
いやいや俺がまだVS1.1の環境なんで簡単に切られては困る(;´д`)

でも、アセンブラじゃなくてHLSLにはしたほうがいいよ。

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

しかしアセンブラも読めないと、厄介なことにハマることもあると思うぜ
リファレンスが充実してきたら大丈夫なのかもしれないが

**名前は開発中のものです。** · 2006/09/27(水) 13:46:59

ピクセルシェーダで正しい結果が出なくてアセンブラで書いたことある。
シェーダのバージョンが低いほどコンパイルが完全じゃないことがあるね。

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

アセンブラ版のなんてとりあえず載せてみた程度の物だし
Cg言語なんてのもあるくらいだしHLSLでいい。

**名前は開発中のものです。** · 2006/09/27(水) 23:56:47

アセンブラつってもVS1.1程度のものはマニュアル見ながらでも
簡単に読める程度にしか命令数がそもそもないだろ。

これがPS2のVUとかなら死ねるが。

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

>>472
ここはサンプルも見れないような初心者が集うところです。
少しは理解してあげてください。マニュアルなんか見ません。

いや、それは嫌味だとしても初心者にはHLSLだって怪しいのに
VSアセンブラは無理でしょ。変にそそのかさないでください。

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

まぁVS1.1のアセンブラ使うくらいなら固定機能でやってろってこったな。

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

e:\デスクトップ\dx9animation\cd3dxobject.cpp(6): fatal error C1083: include ファイルを開けません。'DXUtil.h': No such file or directory
とか言われるんだけど、DXUtil.hって昔のヘッダか何か？

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

もしかしたらサンプルのcommonフォルダに入ってるような奴かも…

そもそも何をビルドしようとしたの？そこらのWebに落ちてるサンプル？

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

かなり前にWebで拾ったサンプル。Commonの中にはDXUT.ｈが・・・

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

http://www.koders.com/c/fidE7D854F142664FD8BDB2EFCE54A42D2106EB47CA.aspx
こいつだったわ

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

マルチポストは止めろ

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

マルチポストを嫌う奴ってパソ通時代のオヤジだけだよな。
複数箇所の回答から一番有用なものを吟味するなんて今や当たり前なのに。
頭が堅くなって時代についていけなくなったんだろうね。

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

うんにゃ違う。
マルチポストするやつは、どこか一カ所にしか返事をかないとか
返事も結果も書かないやつが多いから。

マルチポストであっても、その故を明記していれば俺は許す。

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

バカにレスを与えないでください

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

回答する側が人間だという想像が頭から抜け落ちている・・・。
確かにマルチポスト推奨はイマドキと言えるかも知れないｗ

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

情報処理能力の低い老害がなんか申しております

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

マルチポストじゃなくて、セカンドオピニオンですよ！

しかし、2ch内でマルチポストしても、似たようなスレは
見てる人も同じだから意味ないよな。

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

マルチポストによって、回答者にマイナス評価を受けるリスクを想像できないただの馬鹿。
結局は答えてもらえない確率を高くするだけ。

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

マニアは回答することでカタルシスを得るからそれはないね

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

俺はマルチを見かけたら絶対教えない。

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

俺も別にマルチポストいいと思うけどね。
昔はみるところ決まってた（ＢＢＸ、ＢＩＯ１００、２ちゃん）から貼る必要が無かっただけで
今は俺、２ちゃんしかみてないからここはここの意見でいいんじゃない？

結局さ、難しい・マイナーな問題って本にも載らないし
載ってたとしてもわからない奴にはその情報がどこに載ってるかわからないし、
技術の伝承は掲示板でしかできないしで色んなところでログ残していくのが一番だと思うよ。

よくでる質問だからっていって話題にしないとしないままどこ探しても見つけられなくなっちゃうじゃん。

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

こういう話でスレが伸びている時点で、反感をくらっているということ。
嫌がられてもやるというのなら、好きにすればいいだろう。

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

デスクトップ右下に出るポップアップとかスキンが使えるメッセンジャーとか、
半透明ウィンドウがあるとプログラムがスローダウンしちゃうんだけどなんかうまい方法ない？

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

>>491
マシン買い替え

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

刷り込みだよね。よくよく考えると「回答してくれた人に失礼になる」理由がわからん。
「もう一方で回答が出たなら、こっちで答えなくてもいいよな？」って拗ねてんのか？

まぁ今更言ったところで、マルチポストを許さない土壌ができあがってしまっているんだけど。
ちなみに俺はマルチポストしたことないしするつもりもないよ。いろんなところで口をすっぱくして「マルチポストはいけません」って言われてたから。

自分もレスしておいてなんだけど、ゲームプログラマってこういう煽りで流され話が脱線しやすいよね。議論好きだからですか？

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

>>492
パワーは全然有り余ってる。60fps出てるのが3fpsとかになっちゃう。
DXUT使ってるサンプルは平気なんでソースを見てるんだが、ちょっと挫折気味。
そういえば大航海オンラインも同じ症状出てたかも。

**名前は開発中のものです。** · 2006/09/29(金) 00:00:35

VistaでAeroを使えば解決。

**名前は開発中のものです。** · 2006/09/29(金) 00:01:58

メッセージ処理を別スレッドにするとか？

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

>パワーは全然有り余ってる。
スペック書かずにこう書く奴に限って（ｒｙ

**名前は開発中のものです。** · 2006/09/29(金) 00:10:47

>パワーは全然有り余ってる。
たぶん電源ユニットが５００W以上。

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

違うな、494はまだ10倍界王拳を残しているのさ

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

CPUはAthlon64 3000+ ビデオカードはラデオンのX800 XL。
やってるのは800x600の画面クリアとfps表示の文字列数個のみだよ。
ちなみに、500Wの電源は持ってないし界王拳も使えない。

>496
なんで別スレッドにするんだ？

**名前は開発中のものです。** · 2006/09/29(金) 00:24:29

だからAeroを使えば解決すると言っているだろう。

**名前は開発中のものです。** · 2006/09/29(金) 00:27:16

タスクバーのポップアップでやたら処理が重くなるのは
昔からの定番みたいなもんなんだよ。

DXUTのサンプルがそうならないってほうが意外だった。

**名前は開発中のものです。** · 2006/09/29(金) 00:30:27

原因はマルチサンプルだった。マルチサンプルをONにするとサンプルでも遅くなる。
バッファのフォーマットのせいでコピーが発生してるような気がするけど、正直わからん。

>501
すまん、一応配布予定なのでAero限定は無理だ。

**名前は開発中のものです。** · 2006/09/29(金) 22:25:53

ところでN氏のライブラリはどうなったんだろうか

**名前は開発中のものです。** · 2006/09/29(金) 22:55:00

もういいって。

**名前は開発中のものです。** · 2006/09/29(金) 23:00:27

DirectXの中で一番好きな関数はなに？

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

CreateTeapot

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

喉が渇いた時に便利だよね。

**名前は開発中のものです。** · 2006/09/30(土) 00:34:44

CreateSakuratan

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

mikoto2xで吐いたXファイルを、シェーダーを介してボーン変形出来るようになったんすが、
どうもMikotoでの変形結果と同じにならない

調べたらMikotoのボーン変形は、関節部を潰さないようにかなり特殊な計算をしているみたいっすね
これってどうやってるのかな。シェーダーじゃ無理っすかね

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

D3DXの高レベルAPIを使っているのなら、それをやめれば解決。
クオータニオンの補間がおかしいし、その他問題が沢山あるので使い物にならない。

**510** · 2006/09/30(土) 10:27:47

>>511
レスどうもっす
申し訳ないっすが、姿勢行列の補間は関係なさそうっす。シェーダーなんで頂点補間の部分は当然自前です

スキニングなんて誰がやっても同じ計算（ボーンごとに変形した頂点座標を、ウェイト値に基づいて再調整）に
なるわけっすが、どうやら他の算出方法もあるらしい。それをお尋ねしたい次第っす

それとも、あまり有名じゃないんすかね。検索しても全く出てこないっすし・・・
Mikotoオリジナルっぽい気がしてきましたわ。一体どうやってるんすかね

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

定番の方法は所詮線形補間だからな。
ちゃんとやるならそれなりに面倒なコトになるだろうけど、
線形補間でもちゃんと見えるようにデータを作るほうがいいと思う。

**名前は開発中のものです。** · 2006/09/30(土) 12:41:48

手作業になるけど関節の間にわざと緩んだ骨を仕込むってのがあったなー。
このへんはCG屋さんに聞いてみるのも良いんじゃない？

**名前は開発中のものです。** · 2006/09/30(土) 12:58:03

>>510
間接部の回転角度の補間はクォータニオンで扱って初めてやれる処理なんで
行列の方（つまりxファイル形式）に落とし込んじゃうともう事実上不可能だと思う
実際にはミクロマンのひざ間接みたいな二つの骨の間を埋める小さい骨を何個かつくってる
…はず

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

>>512
以前、mikotoの掲示板で「bdefアンカーによる影響ってどういう計算式？」
っていう質問があって、それに対してゆーり氏が
『秘密です。
　っていうのは嘘ですが、
　詳しく説明するのもアレなので、ヒントを。
　２個以上のアンカーに影響される頂点に対して、
　その頂点と互いのアンカーの面との距離で影響力を決定しています。
　アンカーの面は最低でも６つありますが、
　どの面との距離をとればいいかは想像つきますね？』
って答えてた。
結局、正確な計算式は不明。

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

>>516
すごくいいことを聞いた
横から㌧

**510** · 2006/09/30(土) 18:15:01

>>513-514
線形補間を詰めた方がｲｲって事っすね。ゲームですし、線形補間の方が速そうっすしね
ただあの綺麗な曲げは捨てがたく・・・

>>516
引用感謝っす。補間方法では無さそうっすが、ウェイトを決める方法っすね

>>515
なるほど、検索結果と合わせて何となく分かってきたっす
ボーンの回転中心を、頂点が結果的に円を動くような位置へと補間していけばいいんすね

おかげでなんとか出来そうです。皆さんレスありがとうございました

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

>518
確かにMatrixの線形補間の方がはやいけど、Quaternionで補間しても
誤差程度しか差は出ないよ。
肘、ひざ、肩とか必要な箇所だけ頂点の補間法変えればよし。

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

>>519
シェーダーでやるってことを考えるなら色々と最適化を考えても場所ごとに分岐はやめたほうがいい気がする。
ツール系は全部CPUで計算しちまっても問題ないがリアルタイムなゲームだと色々面倒だぞ。

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

>やめたほうがいい気がする。
「やってダメだった」じゃなくて「気がする」って事は
試してないって事でOK？

**名前は開発中のものです。** · 2006/10/01(日) 01:15:18

シェーダーの方で球面線形補間を頂点ごとにやってやろうと思ったけど
クォータニオンをマトリクスへ落とすだけでほとんど命令数を使い切っちゃう感じで駄目ですた
なにか最適化する方法があるのかもしれないんだけど頭が悪いのでわかりません

そんなわけなんで骨と骨の間にそれらを半々の割合で球面線形補間した骨をあらかじめ
用意しておいて使うことにしたんだけど、そうすると今度はシェーダーへ渡すマトリクスの
数が2倍近く増えるんでレジスタ数の限界を考えてモデルの方で使えるの骨の数に
かなりきわどい制限がでてきてしまう始末

**名前は開発中のものです。** · 2006/10/01(日) 01:24:03

大抵はシェーダで2パスの処理するわけだし
2度も線形補間のコードをシェーダで通すくらいなら
CPUでやったほうがよくね？

ぶっちゃけ簡単だし

**名前は開発中のものです。** · 2006/10/01(日) 01:49:58

確かに何回もDrawPrimitiveしなきゃならんとなると変形をすましちゃったものを
最初から用意しておいたほうが速くなる場合もあるね
そういうどーしょもない話がDirectX10だと解消されてくるわけだ

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

え、そーなの？それは知らんかった。
シャドウバッファとかやるときはどうすんだ？

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

ここはゲーム製作板なのに、レベル高いなぁ。

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

シャドウバッファとかは素直に書くしかない。
CPUとGPUを比べた場合現状はGPUの特に頂点シェーダーは
よほどのことがない限り遊んでるから頂点シェーダー側で命令が増えるのは
そんなにペナルティにならないことが多い。

一般的にゲームを作っていて処理がきつくなるのはCPU負荷とピクセルシェーダー部分。
とくにDrawPrimitiveはGPUコマンド発行するだけだがこれがべらぼうにCPU負荷食う。
ここはDirectX10で緩和されると言われてるね。

>>522
確かにボーンが増えてそれを全部定数レジスタに入れようとすると結構厳しくなるね。
とくにVS1.1だとボーンなんて10本くらいがいいとこだから現実的じゃないね。

最低でもVS2.0くらいのレジスタ数は欲しいねぇ。

できればVS3.0にしてボーンのマトリックスをfp16/fp32のテクスチャにいれて、
頂点シェーダー内でボーンのマトリックスをテクスチャからサンプリングするという方法もある。
これなら3テクセルに1ボーン入るからかなりの量のボーンが使える、ハズ。

**名前は開発中のものです。** · 2006/10/01(日) 12:54:03

モデリング時に頂点辺りの最大数を設定して最適化するしかない。

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

すいませんちょっと聞きたいことあります。
すでにDirectXで作ったゲームがあるんですが、
これをネトゲにしようかと思ってます。

そこで気になったことが１つあります。
うっかりウィンドウキーを押してしまうと最小化されてしまい、
その間にやられて死んでしまう可能性です。
人間同士の駆け引きを楽しむネトゲにしたいんで、
こういった部分は全て排除していきたいんです。

一応ウィンドウキーを無視するようにはできたんですが、
これはマナー違反みたいな意見もあるかと思いまして、
ちょっと迷っているところです。

つまり、
Ａ．ウィンドウキーを無効にしてゲームの快適さを優先
Ｂ．うっかりウィンドウキーを押して死んでしまってもＷＩＮのマナーを優先
どちらにすべきか・・・ということです。
個人的にはＡ．と思うんですが・・・。

よろしくおねがいします。

**名前は開発中のものです。** · 2006/10/01(日) 13:02:43

余計なことはして欲しくない。
世に言うところの、小さな親切大きなお世話。
どうしてもやるんだったら、後から設定するオプション扱い。

**名前は開発中のものです。** · 2006/10/01(日) 13:05:39

>>530
なるほどオプションですか。
これならばウィンドウキーの有効・無効が自由にできますね。
そうするとデフォは普通にウィンドウキーが有効になっていて、
ネトゲに熱中しちゃう人はオプションで無効にできるから、
うっかり押しちゃって死ぬなんてことはない・・・と。

とてもいいアドバイスありがとうございました。

**名前は開発中のものです。** · 2006/10/01(日) 13:09:47

・Windowsキーをブロックするのは確かにルール違反。
　だがやっているゲームも存在する。
　そもそもの問題としてキーフックはWindows2000以降でなければできない。

・ALT+TABをブロックするのはかなり嫌われるコトになるけどそっちをどうするのか？

・ALTキーを押したときに動作が停止しないか？

・タイトルバーをクリックしてウィンドウを移動させるときにゲームが停止しないか？

動作に関して気になるならこの辺も全部確認しとき。
ちなみに個人的にはWindowsキーやALT+TABは自己責任で
デバイスロスト状態からの復帰をきちんとサポートってのが好み。
普通はWindowsキーってそうそう押さないし。

**名前は開発中のものです。** · 2006/10/01(日) 13:15:22

>>527
頑張れば2テクセルでいけるな。
姿勢だけなら自由度6だから、6つのパラメータ有れば十分。
VSからテクスチャ参照するコストと、VS内で行列を生成するコストを
天秤にかけることになるが。

>>529
キーフックとかで無効にしてるのならやめよう。
DISCL_NOWINKEYでググるべし。

**名前は開発中のものです。** · 2006/10/01(日) 13:18:22

>>533
姿勢で持つにしても別途移動と親からのオフセットは必要にならない？

**名前は開発中のものです。** · 2006/10/01(日) 13:19:36

>>532
>・ALT+TABをブロックするのはかなり嫌われるコトになるけどそっちをどうするのか？
これにつきましては何もしないつもりです。
ウィンドウキーは１つ押しただけでスタートメニューが出てしまうので、
こういった操作ミスによるキャラ死亡だけは避けたかったんです。
ALT+TABは2つ押すんで操作ミスはありえないと思ってます。

>・ALTキーを押したときに動作が停止しないか？
>・タイトルバーをクリックしてウィンドウを移動させるときにゲームが停止しないか？
これについては後で考えますが、
現在はフルスクリーンのみで動くようになってます。

>>533
現在はキーフックでやってますが、
これはいいのを教えてもらいました。　→DISCL_NOWINKEY
早速取り込んでみたいと思います。

ありがとうございました。

**名前は開発中のものです。** · 2006/10/01(日) 17:20:55

>>523
DirectX10だと頂点シェーダー通った頂点をまたビデオメモリへ書き戻せるんだってさ
だから結構重たい変形処理を頂点シェーダーにやらせても次のパスではその結果を再利用できる

てか俺vs1.1で動かないといやなのにDirectX10とか何いってるんだろうね

**名前は開発中のものです。** · 2006/10/01(日) 17:26:08

ビデオカード側が対応していないと、全部CPUでやることになるけどね。

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

>>536
vs1.1を前提にするならそもそもレジスタが全く足りないので
ボーン処理は不可能と考えたほうがいい。

全部CPUでやるか固定機能でやるのが定番だな。

VS1.1ってGeForce3あたりだっけ？GeForce4も含まれるのかな。
どっちにしろそんな今となっては屑みたいなビデオカードをサポートすることで
クオリティを落とすというのはどうかと思うが趣味でやる分には別にいいのか。

GeForce3とかをHALでサポートするっていう前提の場合、
CPUも世代を合わせるとPen3の1000Hzあたりがターゲットってコトだよな。

日本は2D信仰が病的な程あるが、その強い影響で低スペックマシンを
前提として考える傾向が抜けないよなぁ・・・

低スペックマシンはオプションでギリギリ動くんじゃない？程度にしといて、
標準機能をは現行スペックにあわせて作ればいいのに。

**名前は開発中のものです。** · 2006/10/01(日) 17:37:00

1000Hzじゃなくて1000MHzネ・・・

**名前は開発中のものです。** · 2006/10/01(日) 17:41:36

>>538
↓で説教してきてください。

エロゲメーカーはいい加減低スペックPCを切り捨てろ
http://pie.bbspink.com/test/read.cgi/erog/1114845529/

**名前は開発中のものです。** · 2006/10/01(日) 17:54:14

趣味でやる分には切り捨てても良い、の間違いじゃね

>>515
行列に落としても出来るっしょ
逆にXファイルにクォータニオンで持たせることも(標準テンプレ範囲で)可能

**名前は開発中のものです。** · 2006/10/01(日) 18:02:29

いや業務でやる分にはとりあえず現行スペックにあわせて作ったうえで、
最終的には低スペックのマシンでも「表示がされなかったり動かなかったりはしない」
っていうレベルにしとけばいいわけだし。
切り捨てるっていうか基準を上にシフトさせるってコト。

そもそもvs1.1で作ったってGeForce2じゃHardwareTnLで動かんのだし。
MatroxG400じゃvsなくてもHardwareTnLで動かんわけだし、
作るときはこの辺でも全部「表示はされてゲームは動く」レベルには合わせるだろ。

まぁゲームのソースはビデオカードのサポート具合に合わせて
大量に機能毎の分岐やらシェーダー切り替えが出てくるケドナー。

**名前は開発中のものです。** · 2006/10/01(日) 18:03:29

>>538
足りないというのは、一頂点辺りいくつのボーンを前提にして足りないといってるんだ？
固定で出来る数なら1.1で十分に対応できるんだが、いったい何の話をしているんだ？

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

>>543
それはボーン数というかウェイト数だろう。
1回のDrawPrimitiveに使えるボーンの数が少なすぎるという話。

定数レジスタが96しかないんだからすべてをボーンに使ったって32本しか使えない。
だが実際には透視変換・ライティング・フォグ・テクスチャアニメーションなどの頂点処理で
レジスタを使わないといけないのだから１回のDrawPrimitiveで使えるボーンはせいぜい20本がいいトコだろ。

vsで凝ったことをするほど1回のDrawで使えるボーンの数が減っていくんだよ。
逆に凝ったことをやらないなら固定機能で十分なわけだ。

**名前は開発中のものです。** · 2006/10/01(日) 19:29:57

それはGeforce系でMaxVertexBlendMatrixIndexの数を確認した上での発言か？

**名前は開発中のものです。** · 2006/10/01(日) 19:37:58

Vistaが出るからこれからのメーカ製PCのグラフィック機能も底上げされる

といいな

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

底上げされても結局OSにパワー食われてしまうのでは？
と不安です。

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

どうせAeroは切れるし底上げしなきゃ喰われて死ぬしｗ