鬱だ氏のう DirectX (Part 7)

**名前は開発中のものです。** · 02/12/10 17:34

DirectXについてマターリと技術情報交換＆雑談するためのスレッド。
初心者用相談室では扱わないような少し高度な話題も受け持つ。

■ 過去スレ
Part 1 http://piza.2ch.net/tech/kako/966/966655286.html (プログラム板)
Part 2 http://pc3.2ch.net/test/read.cgi/tech/997101556/ (プログラム板)
Part 3 http://game.2ch.net/gamedev/kako/1005/10051/1005119775.html
Part 4 http://game.2ch.net/gamedev/kako/1016/10162/1016276254.html
Part 5 http://game.2ch.net/test/read.cgi/gamedev/1027351925/
Part 6 http://game.2ch.net/test/read.cgi/gamedev/1033920036/

**名前は開発中のものです。** · 03/02/06 23:47

>>536
なるほど。テクスチャアニメーションですか。
海岸線を割り出すのが面倒そうですが、
理論的にはできそうですね。ちょっと試してみますｗ

**名前は開発中のものです。** · 03/02/07 00:42

>>530
>そう言えば、色々な所でD3DRS_LIGHTINGは重いので自前で計算するというのを見かけるのですが。
点光源や複数光源は確かに重いですね
光源計算を自前ってシェーダーでってことでしょう
でもVertexShaderをソフトウェア処理すればもちろん重いです
まぁ点光源を使わず平行光源１～２個程度なら重くはないと思いますが…

**名前は開発中のものです。** · 03/02/07 02:13

重いか？
てか、そいつらちゃんとライトのクリッピングしてるのかな？
単純に考えて描画されない範囲はライトの計算はない。
さらにその中でライトの影響があるものに絞れるわけだから結構糞みたいなもんだと思うのだが。
そうでもない？

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 03/02/07 02:54

シェーダってなんですか？
自前で作るシェーダってどういうことですか？

**名前は開発中のものです。** · 03/02/07 03:47

>>541
http://www.google.com/search?q=%E3%82%B7%E3%82%A7%E3%83%BC%E3%83%80

**名前は開発中のものです。** · 03/02/07 05:01

DirectX8.1 SDKを使ってゲーム開発を行っているのですが、
フルスクリーンにした際にメニューバーが見えてしまうのでメニューバーを隠したい
のですが、メニューバーを隠すにはどうしたらいいですか？

**名前は開発中のものです。** · 03/02/07 05:55

>>543
SDKのサンプルを見ろ。HMENUで検索すればすぐ見つかるよ。

**あぼーん** · NG

あぼーん

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 03/02/07 13:52

>>530 >>538-539
そこそこ新しいグラボだったらそんなに重くない気がする
>>530の言ってるのがどんな方法かわからんのだが
>>538の言ってる方法は古いグラボと新しいグラボの差を広げるので
使いにくいのではないかなぁ。
光源固定の場合にはマップなど動かないオブジェクトのライティングも固定なので
最初に一回だけ計算しておいてライティング済頂点として描画、
という方法なら、状況によってはそこそこ速くなるんでない？

**530** · 03/02/08 00:16

アドバイスありがとうございます。
今使っているのは、平行光源とAMBIENT（全体の明度？）なので大丈夫そうですね。

**あぼーん** · NG

あぼーん

**530** · 03/02/08 05:53

現在製作中（とは言ってもいろいろと実験しながらですが・・・）のゲームは、
フルスクリーン動作を前提に作っているのですが。
マウスカーソルを画面上の方に持っていくとタイトルバーに常駐するアプリが、
表示はされていないのですが反応してしまいます。

市販のゲームではこう言う現象は起きないのですが、どうやって回避すれば良いのでしょうか？
詳しい方ご教授お願いします。

**530 550** · 03/02/08 06:07

連続書き込みすみません。
ちなみに、問題のアプリはコレです。

http://www.vector.co.jp/vpack/browse/pickup/pw4/pw004591.html

**名前は開発中のものです。** · 03/02/08 07:55

タイトルバー無くせば？

**名前は開発中のものです。** · 03/02/08 08:29

一旦終了させれば？

**名前は開発中のものです。** · 03/02/08 08:30

ウィンドウスタイル　=　WS_POPUP

分からないところが出る度にこうやって聞きにくるつもりかな？
自分で調べる力がないとゲームを作る上で大きな障害になるぞ。

**Newbie** · 03/02/08 10:54

ありがとうございました。解決しました。
WS_POPUPでは無理だったので、ウィンドウを生成する直前で

long nStyle = GetWindowLong ( hWnd, GWL_STYLE );
nStyle &= ~WS_BORDER;
SetWindowLong ( hWnd, GWL_STYLE, nStyle );
SetWindowPos(hWnd, NULL, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_FRAMECHANGED);

としたところ、上手くいきました。

>>554
googleでいろいろ検索しているのですが、情報があまりにも少なかったり
いろいろな方法があったりと、ここで聞くと最良の方法がわかりそうで
ついつい質問してしまいます。
頑張って質問は３日に一回くらいにします。

と言うかコテハンにします（･∀･　）

**名前は開発中のものです。** · 03/02/08 14:25

>>555
ウィンドウ位置　=　CW_USEDEFAULT

これまで書かなきゃいかんかったのかな。
あと行数多い上にWS_BORDERは必要ないぞ。
前の質問も見てみたけど、ポインタの意味も理解できてないようだから
ttp://www.kumei.ne.jp/c_lang/
ここを紹介しておく。よ～く理解を深めてからDirectXを始めるといい。

**Newbie** · 03/02/08 18:29

いろいろ試したところ、
SetWindowPos(hWnd, NULL, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_FRAMECHANGED);
だけでいけるようです。

WS_POPUP等は真っ先に試したのですがだめでした。
どうやら、Direct3Dデバイスを初期化した後にクライアント領域を上書きする
必要があるようです。

**名前は開発中のものです。** · 03/02/08 19:03

WS_EX_TOPMOSTとかSetCapture関数とかは？

**名前は開発中のものです。** · 03/02/08 19:35

>>557
？？？　ちょっとソース見せてみ。

**Newbie** · 03/02/09 02:21

>>559
こんな感じです。一応ウィンドウモードに切り替えることも考慮してます。

RECT rect;
SetRect(&rect, 0, 0, WIDTH, HEIGHT);
DWORD style = (FULLSCREEN) ? WS_POPUP :(WS_CAPTION|WS_SYSMENU|WS_BORDER|WS_MINIMIZEBOX);
AdjustWindowRect(&rect, style, FALSE);
int width = rect.right - rect.left;
int height = rect.bottom - rect.top;

WNDCLASS wc;
ZeroMemory(&wc, sizeof(WNDCLASS));
wc.hbrBackground= (HBRUSH)GetStockObject(BLACK_BRUSH);
wc.hCursor = LoadCursor(NULL,IDC_ARROW);
wc.hInstance = hInst;
wc.lpfnWndProc= MsgProc;
wc.lpszClassName= CAPTION;
if(RegisterClass(&wc) == 0) return 0;

HWND hWnd = CreateWindow(CAPTION,CAPTION,style,CW_USEDEFAULT,CW_USEDEFAULT,width,height,NULL,NULL,hInst,NULL);
if(hWnd == NULL) return 0;

if(FAILED(InitD3D(hWnd))){return 0;}

if(FULLSCREEN)
{
SetWindowPos(hWnd, NULL, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_FRAMECHANGED);
}
ImmAssociateContext(hWnd,0);
ShowWindow(hWnd, SW_SHOW);
UpdateWindow(hWnd);

**名前は開発中のものです。** · 03/02/09 07:50

>>560
環境は？ＤＸバージョン、ＯＳとグラフィックカード、メモリ容量も書いて。

**名前は開発中のものです。** · 03/02/09 09:18

DX9だと、どんなウィンドウの設定にしてもキレイにフルスクリーンになるみたいよ。
あとはアホな組み方してもCPU使用率が100%にならないんだけど」ウチだけ？
デフォルトでPresentにSleepが入るようになったんかな。
自前で制御してるからいらんのだが、無効にするやり方がわからん・・・
まぁ特に害は無いから良いんだけど。

**名前は開発中のものです。** · 03/02/09 10:05

>>562
それだけで9に移行したくなった、へたれグラマがここに…

**名前は開発中のものです。** · 03/02/09 16:56

GFTi4200 + Athlon2200+XPでも遅いな。遅すぎる。もっと早くなれ。

**名前は開発中のものです。** · 03/02/09 17:05

アルゴリズムが悪いとかじゃなくて？

**名前は開発中のものです。** · 03/02/09 17:12

そうかな。
アニメーションする700ポリぐらいのXファイルを10個ばかり連続して描いたら遅くなるんだが。

**名前は開発中のものです。** · 03/02/09 19:51

アルゴリズム（＝お前の書いたソース）が悪いな、それは。

**名前は開発中のものです。** · 03/02/09 20:10

俺もそう断言しとく。

**Newbie** · 03/02/09 20:28

>>561
環境は、
DirectX8, OS Win2000pro , CPU P4 1.6Ghz, RAM ddr512MB, VideoCard Radeon9000pro, VRAM 128MB です。

>>562
９に移行したくなりますた。
でも、とりあえず８で基本押さえて一本完成させてからにします。

検索しても見つからなかったので、ここで質問させて下さい。
現在建物との当たり判定は、自キャラから一定距離以内のモデルの全面検索（一応いろいろ絞り込んでますが）
で取っているのですが。
フレーム毎に頂点バッファをロックして頂点座標を取得するのと、
マップを作るときに予め頂点座標のみ取得しておき、それを使うのではどちらが良いのでしょうか。
ロックアンロックは重いというのをちらほら見かけたし、予め格納するなら結構無駄にメモリを食いそうで悩んでます。

**名前は開発中のものです。** · 03/02/09 20:30

何も考えずにそうやったらそれくらいで頭打ちになるよ。
テクスチャ等の切り替え回数を減らすとか工夫しないと。

**名前は開発中のものです。** · 03/02/09 21:08

>>569
Windows98SE　AthlonXP1500+DDR512MB+GFMX400(VRAM64MB)　DirectX8.1では
正常に表示されるんだがな。win2000では無理って事か。ふむふむ・・・。

＞フレーム毎に頂点バッファをロックして頂点座標を取得するのと、
＞マップを作るときに予め頂点座標のみ取得しておき、
＞それを使うのではどちらが良いのでしょうか。

どちらがいいでしょうか、ってそりゃソフトの使い道や環境によって自分で決めれば
いいことだろう。必ずこっち、という解答があるわけではない。
>>569の環境だとグラフィックカードがよさげなのでバッファロックも特に問題なさそう
だが、速度重視ならソフトでバッファを持てばいい。建物（直方体）ならそれほどメモリ
を食わないので普通ゲームを作る場合はこちらの方法で速度を上げる。
あと分かってないみたいだが当たり判定というのはあらかじめバウンでィングボックス（もしくは球）
を作ってそれを使い衝突判定をする。いちいち全部の頂点・面を判定に使用するのは
地形接触判定以外ではやらない。オブジェクトごとにそんな事をしていたらロック無しでも
アホみたいに遅くなる。バウンディングボックスという言葉は分かるよな？

**名前は開発中のものです。** · 03/02/09 21:08

>>569
よほど複雑だったり数が多くなければ、後者ならそんなにメモリ食わないと思うけど。
計算してみた？

**Newbie** · 03/02/09 22:08

アドバイスありがとうございます。
>>570
計算してみます・・・

>>571
バウンディングボックスは最初考えていたのですが、家の中に入ったり家の中の
階段を上ったりするので。家の中をどうするかを考える時点で挫折しますた・・・
全面検索だと、この辺は簡単にいけるのですが。

>>572
建物はかなりローポリで作ってテクスチャでごまかしてます。
今のところ小さい家で、頂点数118（GetNumVerticesで取った値）
２階建ての家で390くらいなので、恐らくこれから追加するモデルも500は越えないと思います。

人やモンスター等、複雑な形状になる物体には周りにエフェクト貼り付け用の透明な六角柱を用意して
それと当たり判定を取る予定です。

**名前は開発中のものです。** · 03/02/09 22:34

>>573
＞バウンディングボックスは最初考えていたのですが、家の中に入ったり家の中の
＞階段を上ったりするので。家の中をどうするかを考える時点で挫折しますた・・・
＞全面検索だと、この辺は簡単にいけるのですが。

クリッピングもできないみたいだな・・・。ポインタもよく分からないのだから
この辺が限界か。ま、頑張れ。

**Newbie** · 03/02/09 23:10

>>574
クリッピングはバウンディングボックス使ってスクリーン座標から８頂点全部
はみ出したら描画しないようにしているのですが、ダメなのでしょうか・・・

**名前は開発中のものです。** · 03/02/09 23:25

>>575
笑　家のモデルはたしか頂点数118の単一モデルだったよな？
家の中もそのモデル内に作ってあるとすればお前の仕様だと家に入ると家の内部を
いちいち全て描画することになる。
家の外装と内装（部屋、廊下、ドア、階段、壁）をそれぞれ
家のオブジェクト内に存在する子オブジェクトとして持てば描画範囲からあたり判定、
個別の仕様変更にも耐える設計となる。無論自作エディタも必要になってくるがな。
まぁ、ちいちゃい箱庭作って遊んでる程度なら気にしなくてもいいよｗ。

**名前は開発中のものです。** · 03/02/09 23:35

>>Newbie
こんなことを言ってしまうと元も子もないが、はっきり言ってどうでもいい。
メモリを鬼のように食おうが泣けるほど重かろうが、とにかくまず動くものを。
今のおまいの話は完成後（ここ肝心）に速度その他に疑問をもったら聞きに来ればいい。
迷わず進めでFA。

**Newbie** · 03/02/09 23:37

>>576
なるほど、かなり参考になります。
そうなった場合、いかにバウンディングボックスを作るかが問題になりますね。
まだLightWaveではき出したXファイルをメッシュ単位で描画している程度なので、
そのレベルまでの道のりは遠そうです・・・

連続投稿規制はじめて食らいますた・（ノД｀）・゜

**Newbie** · 03/02/09 23:39

>>577
はい、とりあえずいろいろ割り切って進めてみます。

**名前は開発中のものです。** · 03/02/10 00:15

>>573
>>バウンディングボックスは最初考えていたのですが、家の中に入ったり家の
>>中の階段を上ったりするので
普通は別にコリジョン用のモデルを準備しとく
家ならさらにローポリで単純な形のモデル
表示しないのでテクスチャ、マテリアル、頂点カラーも不要
メモリも表示用モデルに比べれば小さくてすむし

**名前は開発中のものです。** · 03/02/10 00:20

>>577
いいこというねぇ。
とりあえず動くものができてからだよね。

**DirectPlay** · 03/02/10 02:44

ＤｉｒｅｃｔＰｌａｙで、ロビーサーバーを使用しない接続で、
「セッションの場所」という、接続を検出する先のホストを入力するためのダイアログボックスが、
自動的に起動してしまうのですが、これは、ロビーに対応しないでは抑制するのは不可能なのでしょうか？

また、擬似的でもなんでもいいので、見えなくする、とか、なんでも方法を知っている方がいらっしゃいましたらご教授くださいまし。。

**名前は開発中のものです。** · 03/02/10 02:54

点の可視判定をどう実装しようか迷ってます。
カメラ座標系の行列mCamera,透視座標系の行列mPersを
DirectXにある演算でD3DXMATRIXとして作って
点の座標をD3DVECTOR3型のpointで宣言して

pointDst=point*mCamera*mPers;
としたときに、その点がx[-1,1] y[-1,1] z[0,1]の
中に入っていなかったらその点は見えないと言えるのでしょうか？

実際には、８Ｘ８の６４ボックスのエリアからなる街を効率よく
レンダリングするために、４分木にして可視判定を行っていこうと
おもっています。上記のことで正しいならば、実行半径と軸にして
それを行おうと思っているのですがどうなんでしょうか？

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 03/02/10 18:45

>>582
オレがいじってたのはDirectX5のトキなのだが、
そんときはダイアログ無しでアプリ側から「TCP/IPでホストになる」とか
「123.45.56.78に接続」とかできたよ。当然今のバージョンでもできるはず。
でもやりかたほとんど覚えてない。
ダイアログから得られる情報を使って次の接続処理をしていると思うのだが、
その情報を自前で生成して接続する...ってカンジだったよーな...
スマソ。いろいろ調べてみてくれ

**名前は開発中のものです。** · 03/02/10 20:30

NT系で動いたDirectPlayのソースが9x系で動かないです。

クラサバからピアのセッションを張るときに
コールバック内からいろんな処理やったのがまずかったのかも

クラサバとピアのセッションって同時に張れますよね？

もう一度ちゃんとしたコードで書き直そうと思っているんですが
原因も知りたいので、知ってる人いたら教えて欲しいです。

リファレンスにある
「DirectPlay では、Windows 2000 上で動作するときに I/O 完了ポートを使用する。」
↑これよくわかんないんですが関係ありますか？

**名前は開発中のものです。** · 03/02/10 22:00

>>586
どこでエラー起こってるか書いてみ

**586** · 03/02/10 22:36

エラーというより反応がないんです。

9xのコールバックがマルチスレッドじゃないとしたら
そんな動きかな？って感じでした。

**名前は開発中のものです。** · 03/02/10 23:24

DirectPlayよくしらんが、コールバックではフラグを立てるとか
Eventをシグナルするとかメッセージを投げるとかそれくらいに
しといたほうがいい気がする。

**名前は開発中のものです。** · 03/02/11 01:27

質問です。
DirectPlay8の PeerToPeerで
接続している　プレイヤーすべてのDPNIDは取得できるのですが
起動させている自分自身のDPNIDはどうやって特定するのでしょうか？

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 03/02/11 06:28

>>569
その環境でその負荷は、ありえないよ。
コリジョンつっても、数が全然少ない。
（とりあえず、CPU使用率確認すべし。表示とアニメだけなら、
CPU使用率５％以下の筈。全部HWなら）

多分、小さい頂点バッファを沢山描画してると思うんだが？
ストールしまくるよ。

**Newbie** · 03/02/11 13:29

>>580
アドバイスありがとうございます。
なるほど。参考になりますた。

>>583
D3DXVec3Projectという便利なモノがあります。
範囲はD3DVIEWPORT8で宣言した値で決まります。

>>592
566さんへのレスでしょうか？
俺の方は今のところ可視範囲を家で埋め尽くしても全然軽いです。
この先アニメーション付きの人物とか追加していくと不安ですが・・・

**あぼーん** · NG

あぼーん

**1/2** · 03/02/11 18:44

Win2000SP3 DirectX8.1 GeForce2MX VC++6.0SP5

640*480の画面いっぱいに同サイズのbmpファイルを表示させようとしてるんですが、
ぼやけてしまうのはなぜでしょうか？(表示はできてるんですが)

#define FVF_CUSTOM (D3DFVF_XYZRHW | D3DFVF_DIFFUSE | D3DFVF_TEX1)
struct CUSTOMVERTEX
{
    FLOAT x, y, z, rhw;
    DWORD color;
    FLOAT tu, tv;
};

～～～～～～～～～～～～～～～～～～～

**名前は開発中のものです。** · 03/02/11 18:44

m_vtx[0].x = -0.5f;m_vtx[0].y = -0.5f;m_vtx[0].z = 0.0f;
m_vtx[1].x = 639.5f;m_vtx[1].y = -0.5f;m_vtx[1].z = 0.0f;
m_vtx[2].x = 639.5f;m_vtx[2].y = 479.5f;m_vtx[2].z = 0.0f;
m_vtx[3].x = -0.5f;m_vtx[3].y = 479.5f;m_vtx[3].z = 0.0f;
m_vtx[0].rhw = 0.5f;m_vtx[0].color = 0xffffffff;
m_vtx[1].rhw = 0.5f;m_vtx[1].color = 0xffffffff;
m_vtx[2].rhw = 0.5f;m_vtx[2].color = 0xffffffff;
m_vtx[3].rhw = 0.5f;m_vtx[3].color = 0xffffffff;
m_vtx[0].tu = 0.0f;m_vtx[0].tv = 0.0f;
m_vtx[1].tu = 1.0f;m_vtx[1].tv = 0.0f;
m_vtx[2].tu = 1.0f;m_vtx[2].tv = 1.0f;
m_vtx[3].tu = 0.0f;m_vtx[3].tv = 1.0f;

～～～～～～～～～～～～～～～～～～～

m_pd3dDevice->SetVertexShader(FVF_CUSTOM);
m_pd3dDevice->SetTexture(0, m_pTexture);
m_pd3dDevice->DrawPrimitiveUP(D3DPT_TRIANGLEFAN, 2, m_vtx, sizeof(CUSTOMVERTEX));

**3/2** · 03/02/11 18:46

他の環境ないので試せませんが、ビデオカードの仕様だったら泣いてさしあげます

**名前は開発中のものです。** · 03/02/11 19:03

640x480のテクスチャって作れたっけ？
1024x512のが拡大縮小されてる余寒。

**名前は開発中のものです。** · 03/02/11 19:19

>>598
内部的には1024*512作ってるので、どうしてもぼやけてしまうんでしょうか？

**名前は開発中のものです。** · 03/02/11 19:37

うは、そりゃボケるべ。
1024x512の、640x480の部分(たとえば左上)にBMPを転送して、
テクスチャの頂点位置を調節しろ。

_ · 03/02/11 19:40

>>596

for(i=0;i<4;i++)
{
m_vtx[i].x-=0.5f;
m_vtx[i].y-=0.5f;
}

たぶん、描画前これを入れるとうまく行くと思う。

_ · 03/02/11 19:42

すまん。すでに、0.5f引いてたのね…

**595** · 03/02/11 19:57

>>600
だよね、640*480なんてありえないよね。
D3DXCreateTextureFromFileでおかしな大きさのテクスチャでも作れてたから、
それをそのまんま使ってた。
512*512で試したらボケもなく表示されました。
お騒がせしました。

ああ、ボケてるのは画像じゃなくて自分の頭だ……
メシ食って歯磨いてオナニして風呂入って寝よう。

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 03/02/11 21:53

>>595
D3DXのテクスチャ作成サポート関数で画像をロードすると、
デフォルトではサイズを2の階乗に合わせてフィルタリングを行います。
読み込みの際にフィルタリング設定でD3DX_FILTER_NONEを設定して、
頂点のuvに(imgが640*480 テクスチャが1024*512として)
u = 0.625; v = 0.9375;
と入れれば正常に描画できると思いますよ。

>メシ食って歯磨いてオナニして風呂入って寝よう。
メシ食ったら風呂場で歯磨いてオナニすればよかろう…
って人生も最適化始めたら人間おしまいよね(笑)

**名前は開発中のものです。** · 03/02/12 03:03

DirectInput8を使用しているのですが、ジョイスティックを接続して、
ジョイスティックからの入力を受け取ろうとプログラムを実行すると、
ある特定のキーが押しっぱなしになった状態で起動しまうと何件か
報告されました。

自分の環境ではないので(自分の環境では大丈夫でした)、デバッグを
することが難しいのですが、どのへんがあやしそうかを教えてください。
ちなみに、起動時に何もキーなどは押していないそうです。

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 03/02/12 03:34

>>606
「ある特定のキー」ってのが十字キーなら、少し遊びを持たせてみるとか。

**名前は開発中のものです。** · 03/02/12 03:38

>>606
> どのへんがあやしそうかを教えてください。

方向キー押しっぱなしなら一回以上キャリブレーションを行う。
homeキーに割り当てる、という手もある。で、怪しいと思ったときにユーザが押す。
いや、これはどの解説書にも書いてあることだから
98％すでにキャリブレーションを行っていると思いますが…。

あとはユーザの環境に問題があるケース。
ジョイスティック関連は自分の環境をアプリケーションのせいにする輩が
非常に多いことで有名なので…。
「パッド付属のユーティリティで正しく設定しろ」以上の対処法は無い。

**名前は開発中のものです。** · 03/02/12 04:30

コントロールパネルで　パッドの設定が正しくできてないぐらいしか
おもいつかん

**DirectX 9.1 to be introduced at GDC 2003** · 03/02/12 07:32

http://www.theinquirer.net/?article=7721

**DirectX9.1!!** · 03/02/12 11:28

DirectX9.1!!

**名前は開発中のものです。** · 03/02/12 11:38

コンパネで調整してもニュートラル位置が安定しないパッドはあったよ。
十字キーを押した状態を1.0の強さとすれば、押してなくとも 0.3くらい偏ってるような糞パッド。
入力の遊びを大きくとるしかない。

**名前は開発中のものです。** · 03/02/12 14:43

糞というか、サウンドカードのゲームポートを使用するコントローラの
場合は細かく位置を特定することが不可能なんでしょうがないかと。
（サイドワインダーのようなデジタル接続の物は別）

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 03/02/12 16:10

>>613
いくつかプレステのパッドをつなぐコンバータを持ってるが、
海外の輸入物はほんとに駄目なものが多いよ。
ニュートラルでも動く動く。即効ゴミ行きさ。

少々高くても日本でパッケージされている程のものはまず大丈夫の模様。

**616** · 03/02/12 16:11

俺のはUSB接続の物の話ね

**名前は開発中のものです。** · 03/02/12 17:32

スマートジョイパッドがダメダメなのを確認しますた（他の安物も同じだった）
ひょっとして変換機じゃなくてPSコントローラのほうがダメなんじゃないかと

**名前は開発中のものです。** · 03/02/12 17:46

>>618
どうだろうね。
PSのコントローラー自体が判定シビアなんじゃない？
デュアルショックで試したけど、思いっきり倒して元に戻すと±0.1位残ることもある。
（もちろんうまくやれば0になる。）
だから俺は>>613のように遊びを作って調整してる。

**あぼーん** · NG

あぼーん

**616** · 03/02/13 00:07

うちにスマートジョイパッド3が二つばかりあるけど、
十字キーはデフォルトで特に問題なし。
アナログは確かに少しずれてる。ブルブルするってことはさすがにない。
キャリブレートすると十字キーの方に影響出るから結局やってないや。
いやまあアナログは使わないから別にいいけど。

**名前は開発中のものです。** · 03/02/13 01:56

スマートジョイパッド3＋ＤＵＡＬＳＨＯＣＫ２（ＰＳ２のコントローラー）使ってますが、十字キー
大丈夫です。スティックはずれてますが、デッドゾーン指定すれば問題ないみたいです。

クラスを3段階に定義しており、
#include"cb.h"
class CA{
CB cb;
};

#include "cc.h"
class CB{
CC cc;
};

class CC{
};

とインクルードファイルを3つに分けているのですが、ビルドすると
error C2011 class型の再定義と出てしまうのですが、これは何なのでしょうか？

**名前は開発中のものです。** · 03/02/13 04:29

>>622
なんだかよくわかんない。
どこかでinclude間違ってんじゃない？

**名前は開発中のものです。** · 03/02/13 06:58

>>622
漏れ全く同じ使い方してる。プリプロセッサに再定義させない指定してるけど。
cc.hなら例えば

#ifndef __CC_H__
#define __CC_H__
～ヘッダの内容～
#endif

多分これで回避できると思う。

**名前は開発中のものです。** · 03/02/13 18:55

アドバイスどうもです。解決しました。
クラスＣＢのメソッドを収容してあるファイル
cb.cpp
の最初に
#include"cc.h"
と書いてしまったため、まさしく再定義されたようでした。

**名前は開発中のものです。** · 03/02/13 21:57

DirectX 8と9、両方のDirectPlayに携わった方、よろしければ質問お願いします。

DirectPlay8から9にかけて、たとえばDirect3DからDirectGraphicsに
移行したときの様な、大幅な変更はありましたでしょうか。
また、少々無理してでも9の方を学ぶべき、理由などございますでしょうか。

障害として、9のsdkを入れると、動かなくなるアプリがある事情がありまして…。
初歩的な質問で恐縮ですが、よろしくお願いします。

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 03/02/14 00:25

DirectInput8でキャリブレーションをする関数を教えてください。
キャリブレーションで調べても全然見つからない…
他のキーワードかなんかあるんですか？

**名前は開発中のものです。** · 03/02/14 00:29

VC++ & DirectInput8を使っていて、
パッドの数を取得して、
0～複数を自動で認識したいんですが、
流れとしてはどうやるんでしょうか？

とりあえず、パッド一個を動かす事はできています。

VB+DirectX7の時は
Set EnumDevice = DInput.GetDIEnumDevices(DIDEVTYPE_JOYSTICK, DIEDFL_ALLDEVICES)
で、EnumDev.GetCountに何個パッドがあるか出てきて、

Set PadDeviceInfo(i) = EnumDev.GetItem(i + 1)
Set PadDevice(i) = DInput.CreateDevice(PadDeviceInfo(i).GetGuidInstance)
で、一個ずつ割り当てていったんですが・・・

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 03/02/14 01:37

>>628
そんな関数無かったと思うけど…
ジョイスティックのセンタ合わせなどはその製品のドライバ、ツールがやるべきことで
アプリケーションの仕事ではないでしょう。

それとも絶対座標軸で正確な中心を取る方法とかいう話ですか？
どうしてもというなら相対座標で受け取れば、なんとかなる場合もあるんじゃないでしょうか？

>>629
……一つ作成できてるなら、それと同じ方法を繰り返すだけでよくないですか？
列挙した時にGUIDが入った構造体が与えられるので、それに使って作成していけばよいはずです。

マニュアルのようにインターフェイスをグローバルで与えたくなければ、
列挙する時にLPVOID型の転送用の引数がありますので、
そこにインターフェイスを与えればよいと思いますよ。

**629** · 03/02/14 01:59

>>631
回答＼(・∀・)／　ｱﾘｶﾞﾄﾝ

使用するコールバック関数がイマイチ分かってませんでした。
取得に成功したら、DIENUM_STOPを返してて、次に行かないようになってました。
忠告されるまでLPVOID型の引数を無視してました。(笑)
これを使ってもう少しいいように作ってみます。

ためになりました。

**626** · 03/02/14 02:04

くぅ、小粋なPlayBoyはいらっしゃらないのか（´Д⊂
もう一度上げさせてください

**名前は開発中のものです。** · 03/02/14 02:39

>>633
わずかな機能追加とバグフィクスが変更の中心です。
大きな変更はありません。

**あぼーん** · NG

あぼーん

**名前は開発中のものです。** · 03/02/14 03:02

>>634
ありがとうございます！おかげで心おきなく8Playの猛勉強開始できます。
これで安心して眠れます…本当に感謝です。

今日はきっとあなたの日ですよ(*´Д`)ノ◆ﾊﾟｯ