■過去ログ置き場に戻る■
1-
前250
次250
最新50
[memo]
"9999999999_00.html#R20"
という感じで、URLの最後に "#R
レスNo
" を追加すると幸せになれます。
【C++】 DirectX初心者質問スレ Part10 【C】
751
名前:
デフォルトの名無しさん
:2006/09/17(日) 01:10:27
DirectX9でサーフェイス作成してサーフェイスに画像ファイルを読んで
バッファに転送して画像を表示しています。
このサーフェイスのRGBの値は変更出来るのですが、アルファ値が変更出来ません。
どうしたらいいでしょうか?
752
名前:
デフォルトの名無しさん
:2006/09/17(日) 01:34:07
サーフェスのフォーマットにアルファは含まれているか。
アルファ書き込みモードはONになっているか。
753
名前:
デフォルトの名無しさん
:2006/09/17(日) 02:06:35
>>752
サーフェイスもバックバッファも全部アルファありにしてみたんですがダメでした
テクスチャのアルファは普通に変更出来るんですが、サーフェイス作成の方は
出来ないです。
なにか設定が足りないんでしょうか…
754
名前:
デフォルトの名無しさん
:2006/09/17(日) 03:25:25
質問に便乗。
LockRectで取得したピクセル列の並びがよく分からない。
ピクセルを4バイトずつ進めても上手く書き込めない。
アルファ値だけおかしい。
755
名前:
デフォルトの名無しさん
:2006/09/17(日) 03:32:31
サーフェスのフォーマットは?
756
名前:
デフォルトの名無しさん
:2006/09/17(日) 10:22:37
>>751
何をしたいのかわからんがサーフェイス間転送ってそのまんまコピーしかできないぜ。
DirectX7みたいなカラーキーの処理は無理。
そもそもStretchRectできるサーフェイスってD3DPOOL_DEFAULTのみなんだし
ロックできないんじゃねーの?
757
名前:
デフォルトの名無しさん
:2006/09/17(日) 10:30:49
メッシュについての質問なんですが、
下記の工程1の場合に比べ、工程2で描画した方が、なぜか描画のFPSが飛躍的
にあがります。これは、どのようなことが原因なのでしょうか。
ちなみに作成したメッシュは立方体*36であり、立方体の6面、それぞれに対して
テクスチャを貼り付けてるので、アトリビュートの値は、それぞれバラバラで
整理されていません。
よろしくお願いします。
工程1:
D3DXCreateMeshFVFで空のメッシュを作る
↓
頂点、インデックス、アトリビュートをロックして情報を入れる
↓
描画する
工程2:
D3DXCreateMeshFVFで空のメッシュを作る
↓
頂点、インデックス、アトリビュートをロックして情報を入れる
↓
D3DXSaveMeshToXでXファイルを作成する
↓
メッシュを解放
↓
作成したXファイルをD3DXLoadMeshFromXで読み込み、新しくメッシュを作る
↓
新しく作ったメッシュで描画する
758
名前:
デフォルトの名無しさん
:2006/09/17(日) 10:33:47
>>757
1と2でメッシュがどう変わってるのか調べればいいじゃないか。
759
名前:
デフォルトの名無しさん
:2006/09/17(日) 10:39:23
頂点をハードでもってるか、ソフトでもってるかの違いだけだったりしてw
760
名前:
デフォルトの名無しさん
:2006/09/17(日) 11:11:36
Optimize
761
名前:
デフォルトの名無しさん
:2006/09/17(日) 11:12:56
>>758
今、調べてみたんですが、
作成したXファイルをD3DXLoadMeshFromXで読み込んだ方のメッシュは、
なんか、最適化されてるみたいです。
バラバラになってるはずのアトリビュートの値が整頓されており、
対応するようにインデックスの値も最適化されていました。
最適化を行うOptimize関数は、プログラムに書いていないので、
D3DXLoadMeshFromX関数によって、xファイルから読み込む時に最適化されてる
ようです。
D3DXLoadMeshFromX関数って、勝手に最適化するんですか?
ヘルプには、単にXファイルを読み込む関数としか書いてないんですが・・
情報お願いします
762
名前:
デフォルトの名無しさん
:2006/09/17(日) 11:16:58
ホントに最適化のせいなんかなー。
頂点作るときにハードかソフトかの設定が影響してんじゃねーの?
763
名前:
デフォルトの名無しさん
:2006/09/17(日) 11:17:44
メッシュの中身をデバッガで見れば分かることで(ry
764
名前:
デフォルトの名無しさん
:2006/09/17(日) 11:18:36
ところで立方体*36は全部同じ頂点バッファに突っ込んでる状態?
765
名前:
757
:2006/09/17(日) 11:33:59
>>762
>>763
デバッグでメッシュの中身を見た結果が
>>761
です。
ちゃんと、整頓されてました。
>>764
D3DXCreateMeshFVF関数を呼び出して、メッシュを作る時に
頂点の数を引数に指定するわけですから、この関数の内部で頂点バッファ
が作られ、その頂点バッファに
pMesh->LockVertexBuffer(0, (void **)&pV);
でロックして全部頂点を突っ込んでます。
766
名前:
デフォルトの名無しさん
:2006/09/17(日) 17:19:39
>>761
断言はできないけど、D3DXSaveMeshToX で最適化してるんじゃね?
出力されたXファイルの中身を確認してみなよ。
767
名前:
757
:2006/09/17(日) 19:19:21
>>766
D3DXLoadMeshFromX関数が、やっぱり最適化してました
これで、一つ疑問が解けました。
ありがとうございました
768
名前:
デフォルトの名無しさん
:2006/09/18(月) 02:19:09
そこまで来たら、ついでにSave&Loadを使わない方でも
Optimizeしてみて比較するのが真のプログラマ。
769
名前:
デフォルトの名無しさん
:2006/09/18(月) 09:11:00
>>768
それはDX10で無駄になるのでやめるべきだろう
770
名前:
デフォルトの名無しさん
:2006/09/18(月) 09:45:05
Xファイルなんて右も左もわからない初心者が3Dモデルをロードするだけのものじゃん。
ブラックボックスの仕様に悩まされるなんて馬鹿らしいと思わないの?
771
名前:
デフォルトの名無しさん
:2006/09/18(月) 09:48:56
全然ブラックボックスでも何でもない。
D3DXの高レベルAPIが癌なだけ。
772
名前:
デフォルトの名無しさん
:2006/09/18(月) 11:37:31
IAnimationControlerとか気まぐれで仕様変えるヤツを
使わなきゃ癌ってほどひどくはないだろ。
普通のXファイルを普通にアニメーションさせるぶんには問題ない。
テクスチャUVを複数もてないのがネックといわれていた頃もあったけど、
今じゃそんなの使わないし・・・デカールは1つありゃ十分だ。
デカール以外のテクスチャ座標は全部シェーダー内で作るしな。
773
名前:
デフォルトの名無しさん
:2006/09/18(月) 11:49:44
あほみたいに初心者レスなんだけど、2D処理する場合
昔のDirectDrawとDirectX Graphicsって結構違うの?
774
名前:
デフォルトの名無しさん
:2006/09/18(月) 12:06:42
>>773
ずいぶん違う。
昔のは回転とかしようと思うだけでアフォかってほど手間がかかる。
しかも、激遅。
今のは今ので3D絡んで面倒だけど楽は楽。
775
名前:
デフォルトの名無しさん
:2006/09/18(月) 12:10:35
>>774
ありがとう。
初期化処理とか手続きとかAPI名とかも変わってるの?
776
名前:
デフォルトの名無しさん
:2006/09/18(月) 12:11:57
もう、実はホント速い処理いらないし、
とりあえず画像が表示できて回転も拡縮もできてちょっと速度あればいいんだけど
ってときはDirectXじゃなくてGDI+を勧めるけどな。
仕事でツールが必要になって最近使ってみたけど、これで十分ってときはあるはずだわ。
DirectX初期化するの馬鹿らしいときは使える。
http://park17.wakwak.com/~dragoon/mfctop.htm
http://park17.wakwak.com/~dragoon/gdiplus5.htm
777
名前:
デフォルトの名無しさん
:2006/09/18(月) 12:12:50
>>775
そりゃもちろん。
いまのがずっと楽。
778
名前:
デフォルトの名無しさん
:2006/09/18(月) 12:22:42
D3DXはスキンメッシュの読み込みにもバグがあって使い物にならない。
779
名前:
デフォルトの名無しさん
:2006/09/18(月) 12:35:41
>>778
詳しく
780
名前:
デフォルトの名無しさん
:2006/09/18(月) 13:07:44
むかしどっかのスレに書いたから探してこい。
781
名前:
デフォルトの名無しさん
:2006/09/18(月) 13:15:28
>>780
無理。いま、IE7入れたからバグりまくってて検索する気になれない。
つか、たまに日本語入力できなくなって鬱。
なんでいま、2ちゃんぐらいしかやってない。
とりあえず
警告<IE7はいれるな!>
いつもはこんな人柱やんないんだけど、仕事でしょうがないからいれたらこのザマ。
782
名前:
デフォルトの名無しさん
:2006/09/18(月) 13:16:40
>>781
WMP11といいIE7といい
ほんとM$社はアルファも良い所で公開するよな
783
名前:
デフォルトの名無しさん
:2006/09/18(月) 13:17:52
>>782
いままで作ったもんが普通にずれるのはこれからの標準になっちゃうのか
これはバグなのかとりあえずはっきりしてほしい。>MS
784
名前:
デフォルトの名無しさん
:2006/09/18(月) 14:07:19
359 :名前は開発中のものです。:2006/08/24(木) 12:13:30 ID:sJxsspLQ
ちなみにD3DXのXファイル読み込み関数は、
頂点ウエイトが入っているときのインデックスの展開にバグがある。
頂点とウエイトと法線のデータの展開時に、
頂点と法線が別々のインデックスで管理されているはずなのに、
頂点側の並びに合わせて、インデックスで重複を省けるはずの法線データを無駄に増やさないと、
正常に展開できずにウエイトの付き方に異常が起こりメッシュに穴が開いたりする。
これは最新云々関係なく昔からのD3DX側のバグ。
はっきりいってD3DXのXファイル関係の高レベルAPIは使い物にならない。
エクスポートされたデータそのものに異常はないので、
Xファイルの読み込みぐらい自分で作ればいいだけの話。
785
名前:
デフォルトの名無しさん
:2006/09/18(月) 14:37:55
なら問題ねぇや。
法線自体もたないXファイルしか使ってないし。
面の角度に合わせて法線を重み付けして計算しないと
分割数の多いほうに法線が寄るから法線は自分で計算してる。
786
名前:
デフォルトの名無しさん
:2006/09/18(月) 14:41:58
それは単に変なモデリングソフトを使っているせいだろ。
787
名前:
デフォルトの名無しさん
:2006/09/18(月) 15:16:12
>>776
ナイス情報!
職業柄DirectXばかり見てきたが、GDI+だけでもいろいろ出来そうだね。
Javaみたいに手軽なのが便利だな。
788
名前:
デフォルトの名無しさん
:2006/09/18(月) 15:33:44
実際問題高レベル描画はGDI+使った方が格段に楽だと思うわけだが、
そのGDI+自身がDirectXで走ってたりすることはあるのかしら。
教えて詳しい人。
789
名前:
デフォルトの名無しさん
:2006/09/18(月) 16:10:52
>>785
いや意外に多いよ。
D3DXの法線計算も面法線を単純に合成して正規化してる
だけだからポリゴン分割数多いほうに法線が寄る。
790
名前:
デフォルトの名無しさん
:2006/09/18(月) 16:40:16
>>783
IE6では見れたのにFirefoxやOperaで見れなかったなら
作ったもんが異常
これまでのどのブラウザでも見れたのにIE7だけズレるならバグ
791
名前:
デフォルトの名無しさん
:2006/09/18(月) 17:38:36
>>790
だってすでにテストが面倒だからIEしか対応してねーしw
ActiveXあること前提だし。
792
名前:
デフォルトの名無しさん
:2006/09/18(月) 17:45:26
>>788
それはない
一般道と高速道みたいに通り道が違う
793
名前:
デフォルトの名無しさん
:2006/09/18(月) 17:57:40
>>792
いや、正直よくわからんって感じ。
クラスの関数一覧みるとインターフェースにそれっぽいのあるし。
回転がハード使ってるとしか思えないほど速い(と思う)。
普通に1ピクセルずつ画像を処理するよか速い気がする。
794
名前:
デフォルトの名無しさん
:2006/09/18(月) 17:58:32
DirectXは関係ないとしてもグラボのハード機能は使ってるんじゃね?
795
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:11:05
>>794
そういうことってあるのかな?
796
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:15:53
>>795
あるんじゃね?
昔も今もハードを制御してるのはOSなんだし。
797
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:17:04
GDI+はぜんぜんビデオカード側が対応していないので、
ことごとくソフトエミュレートになっている。
GDI+のベンチマークソフトが使われるようになればメーカー側も考えるだろう。
798
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:17:31
DirectX入れてなくても動くって事は?
799
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:19:28
GDI+がグラフィックボードを利用してるかどうか確かめる方法ある?
800
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:22:22
>>785
法線がない状態で曲面とか角をどうやって判断するつもりなんだ?
せめてスムージング情報をモデリング時に引っ張ってこないと復元できないぞ。
801
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:29:34
>>789
そのこと俺もずっと前に言ってみたが、理解してる人はほとんどいなかった。
あと、D3DXのバウンディング球も重心求めてるだけで、最小包含球ではないね。
802
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:34:01
そもそもグラボっていうのはグラフィックアクセラレータって言って・・
って遡らないと話は通用しないのかな?
Window自体の描画だってグラボ使ってるんだからGDI+だって使ってるだろう、
っていう単なる推測なんだが。
まさかポリゴン描画だけがグラボの仕事だとか思ってないよな?
> GDI+がグラフィックボードを利用してるかどうか確かめる方法ある?
グラボから伸びてるケーブルがディスプレイにささってるから。
803
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:39:52
>>802
αブレンドとか回転とか、GDI+で追加されたものが、
専用のアクセラレーションで機能しないということ。
表示されていれば利用しているとか、幼稚園児かお前は?
804
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:43:00
>>803
逆に聞きたいんだが、なんでグラボのハード機能を使ってないって思ってるの?
OSがハードを制御してるしハードは描画に特化してる、使わないって考える方が
すごく不自然なんだが・・・
805
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:51:29
>>804
いや、用は3Dアクセラレーターが使ってあるかどうかって話なのよ。
806
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:53:12
自前で計算したときよりもGDI+を使った方が遙かに速度が遅いから。
ちなみに3Dアクセラレーションを使った場合は桁違いに速い。
807
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:54:30
>>805
んー3Dの話は全然してきてないんだよね・・・GDI+って2Dじゃん。
DirectX=3D とか グラボ=3D とか 変な認識があるのかもね。
808
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:56:33
で、その3Dアクセラレーターが使ってあるとグラボによって
そのサポート状態が違うわけよ。
で、できないグラボで3Dアクセラレーターを使ってしまうと、
それを無理やりエミュレーションする場合があって、その場合今度は糞重たい(実用にならない)
だから、ハード(グラボ)の特有の機能を警戒してるわけ。
809
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:57:21
>>806
おお!それは有力な検証結果ですな。
じゃあ描画自体は自前でやってる可能性もあるかも。
回転させたときに描画が速いっていうのが気になるが・・
810
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:58:49
>>807
ちがうんだよ。
2Dでも3Dの機能を使って2Dの描画をしてる場合があるんだよ。
特に回転なんてソフトでやったら糞重たい、重たいどころの話じゃない。
3Dの機能を使うことと3Dの描画しかしないことは等価じゃないのよ。
3Dの機能を使って、2Dの描画をやってる場合を考えてるのよ。
811
名前:
デフォルトの名無しさん
:2006/09/18(月) 18:59:58
>>807
DirectDrawが打ち止めになった理由が分かってないだろ。
2Dでαブレンドや回転のアクセラレーションをハード側に載せるのが無駄だから、
全部3Dでやれということになったんだよ。
その為、メーカ側が2D用の拡張アクセラレーションをわざわざ作らなくなった。
GDI+でアクセラレーションが欲しければVistaを使うしかない。
その為のAero。
812
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:01:20
>>808
やっぱ「グラフィイクアクセラレータ」の話からしないとダメなのか?
今で言うグラボが出た当時はね、OSの描画全般を早くこなすために
アクセラレートする目的のハードだった訳よ。もちろん普通の描画に使うのね。
それが、「最近ではハード使わない」っていうのは考えにくい。
通常のウィンドウ描画にハード使ってるんだったら、GDI+にだって
もちろん使ってる可能性は高い。むしろ使わない理由が見当たらない。
813
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:02:21
ちなみにAero環境下ならGDI+のAPIは、ブレンドだろうが回転だろうが、
ほとんどブロック転送と変わらない速度で動く。
814
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:05:06
>>812
だからそれはGDI用のアクセラレーションを使っているだけで、
GDI+用の拡張部分には対応していないから、
対応していない部分はCPUが計算しているという話。
一切使っていないわけではない。
815
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:06:11
>>810
あなたは俺と同じ認識みたいだよね。
GDI+という2D描画にもハードの機能を使うことが考えられるって意味で。
>>811
それでOSが描画にハード機能を使ってないって説明になってるの?
ウィンドウを自前で書いてるとでも??
816
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:07:12
で、GDI用(GDI+ではない)ってのは回転なんてサポートしてない(と思われる)わけよ。
817
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:08:39
>>815
だから、俺等のいうハードの機能っては3Dアクセラレーターのことなの。
で、それをもし使っているなら各グラボごとにサポート状況が違うはずなのよ。
818
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:10:14
結論
GDI+の拡張部分をアクセラレーションがある状態で使いたければAeroを使え。
XP以前なら遅くても我慢しろ。
819
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:11:57
>>817
>>810
の言ってることもよく見てみなよ。
3D描画機能を2D描画に使うこともあるって書いてあるでしょ。
そもそも、回転とかアルファブレンドとかGDI+で設計してるのに
「ハードが対応してないから自前でやるしかないか・・」って話ないでしょ?
最大公約数なハードができることを設計してると思わない?
ちなみにGDIの時代は単なる矩形転送だけをハード利用してたから
回転とかアルファブレンディングに対応しなかっただけでしょ。
いや順番を正すと、GDIの設計がそうだからハードが対応しなかったってこと。
820
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:16:14
>>819
どのライブラリ使ってもそのへんの機能を使うにはまずデバイスの初期化が必要でな。
俺は使ってないとおもう。
821
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:16:26
ちなみにAeroは、Direct3Dに対応したデバイスドライバが必須。
結局GDI+は3Dアクセラレーションの機能に間借りする形で存在することになった。
822
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:26:28
>>820
もーーーーーーーWindows起動時に初期化しとけ。OSなんだからw
アプリで初期化が必要なのはOSに宣言するためってことも考えられる。
そもそも「DirectX使わないとハード使えない」って勘違いしてる人に向けて
いろいろ書き込みしてきたんだけどさ、話がそれすぎてるしOSの実装なんか
分かりっこないんだから、誰も断言はできない訳よ。
っつーことで最後に一言。「スレ違い」(´Д`)
823
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:30:23
>DirectX使わないとハード使えない
だれだよそいつは?
824
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:31:07
>>822
無理っしょ。
いままでことごとく無理だったのに、いきなり動きはじめるわけないだろ。
解像度切り替えで全てのりソースが噴き飛ぶショボイ設計なんだからw
825
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:32:19
Direct3Dを使わないと現在のドライバ対応では、
回転やαブレンドなどのアクセラレーションは使えない。
拡大縮小などは大抵のドライバが対応している。
826
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:36:31
昔はビデオカードのうたい文句にDVD再生支援機能とかあったが、
おおすげえと思った後、実はただの拡大縮小機能だった悲しみを覚えている。
827
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:40:43
おまれらの意見を総合すると
ようはDirectX使うな、と。
828
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:44:35
使いたくなければ使わなければいい。
829
名前:
デフォルトの名無しさん
:2006/09/18(月) 19:59:54
GDI+ (gdiplus)
http://bbs.gamdev.org/test/read.cgi/gamedev/1067070424/
830
名前:
デフォルトの名無しさん
:2006/09/18(月) 20:51:59
>>829
荒らされてるじゃんw
831
名前:
デフォルトの名無しさん
:2006/09/18(月) 21:40:41
こういう場合、半角英数の方を信じることにしている
832
名前:
デフォルトの名無しさん
:2006/09/18(月) 23:41:37
一匹変なのがいるなw
833
名前:
デフォルトの名無しさん
:2006/09/19(火) 00:29:21
>>832
のこと? (w
834
名前:
デフォルトの名無しさん
:2006/09/24(日) 05:26:27
タイトルバーつかんで移動すると
Messageの処理が帰ってこないので
メインループ動かないんですが、スレッド化以外で
これを回避する方法ありますか?
835
名前:
デフォルトの名無しさん
:2006/09/24(日) 05:38:41
タイマー
836
名前:
デフォルトの名無しさん
:2006/09/24(日) 06:55:51
だけどWM_TIMERも、タイトルバーをクリックしっぱなしで
全く動かさない状態だと来ないんだよな。
そこで俺が考えた代替案。
WM_TIMERを送信するスレッドを作るw
837
名前:
デフォルトの名無しさん
:2006/09/24(日) 10:01:22
>>834
でつ
( ろ WM_でタイトルバーつかんでるの拾ってその間はPAUSE
838
名前:
デフォルトの名無しさん
:2006/09/24(日) 11:54:10
そもそもマルチスレッドを使わない理由は?
839
名前:
デフォルトの名無しさん
:2006/09/24(日) 12:37:00
面倒くさいとか、面倒くさいとか、面倒くさいとか。
840
名前:
デフォルトの名無しさん
:2006/09/24(日) 13:57:22
GDI+の専用スレある?
841
名前:
デフォルトの名無しさん
:2006/09/24(日) 18:24:10
やはりスレッドにすべきなのか
842
名前:
デフォルトの名無しさん
:2006/09/24(日) 18:32:17
じゃあWMでタイトルバーつかんだの検地したら
以降システムメッセージを無視する→ループが動く&マウスの位置にあわせてウインドウ移動
タイトルバーいじるの終わったようなら元に戻す
843
名前:
デフォルトの名無しさん
:2006/09/24(日) 18:40:24
ゲームでマルチスレッドって今当たり前なのかな?
折角なら俺も使いたいところだ
とりあえずDirectX側のパフォーマンスは少し落ちるらしいけど
844
名前:
デフォルトの名無しさん
:2006/09/24(日) 18:46:32
必要なら使えばいいじゃん。
ゲームでマルチスレッドって、PCなら10年前から実装したけど。
アクションゲームなら必須。もちろん無くてもできる。
845
名前:
デフォルトの名無しさん
:2006/09/24(日) 18:46:50
スレッドは普通使わない
846
名前:
デフォルトの名無しさん
:2006/09/24(日) 19:09:07
>>845
は異世界の住人なので、こちらの世界の事ではないというところに注意してください。
847
名前:
デフォルトの名無しさん
:2006/09/24(日) 19:19:26
(゚Д゚)ハァ
848
名前:
デフォルトの名無しさん
:2006/09/24(日) 19:29:06
俺も別にゲームはマルチスレッドにはしないな。
使うのはネットワーク処理と、ファイル読み込みくらい。
まぁどっちもゲーム部分ではない。
849
名前:
デフォルトの名無しさん
:2006/09/24(日) 19:36:16
ウインドウメッセージのために余計な処理を考えるくらいなら、
マルチスレッドにした方が遙かに楽。
850
名前:
デフォルトの名無しさん
:2006/09/24(日) 19:42:32
せめて描画と入力関係は別のスレッドに分けろよ。
取りこぼしとか最悪だぞ。
851
名前:
デフォルトの名無しさん
:2006/09/24(日) 19:48:28
タイピングソフトならまだしもアクション程度で取りこぼしとか別にいい気がするんだが。
コマ落ちするゲームは話が別だが。
852
名前:
デフォルトの名無しさん
:2006/09/24(日) 19:48:54
>>851
はあ?
853
名前:
843
:2006/09/24(日) 19:56:49
みんなレスサンクス
やっぱりまだ、色んな流儀があるようで
今まではシングルでやってきたけど、入力を取りこぼしたことは無いかなぁ
854
名前:
デフォルトの名無しさん
:2006/09/24(日) 20:01:08
すまん、取りこぼしって言葉は間違えだな。
シングルスレッドだと描画がカクカクになったら入力も同調するだろ?
それを回避するには、入力だけでも別スレッドで処理しないと駄目ってことを
言いたかっただけだ。要するに入力のフレーム落ちね。
855
名前:
デフォルトの名無しさん
:2006/09/24(日) 20:22:39
よし、FPS制御について語ろうぜ
856
名前:
デフォルトの名無しさん
:2006/09/24(日) 20:39:15
FPSの話はもめるんで嫌ですw
857
名前:
デフォルトの名無しさん
:2006/09/24(日) 20:46:19
directxなんて使わなくてもゲーム作れるよー
directxのゲームは動かないことが多くていやです
858
名前:
デフォルトの名無しさん
:2006/09/24(日) 20:55:04
>>854
いつの時代の話をしてるんだ? 1描画=1入力なのかw?
859
名前:
デフォルトの名無しさん
:2006/09/24(日) 20:59:39
わかっているけど2Dゲームの考えが捨てきれない
860
名前:
デフォルトの名無しさん
:2006/09/24(日) 22:04:49
1フレームの描画に時間がかかるようなケースだとスレッド使うしか対策無くね?
そこまでスペックが低い場合は切り捨てるっていうのも手だけどさ
861
名前:
デフォルトの名無しさん
:2006/09/24(日) 22:15:20
無駄な苦労がしたければシングルスレッドでやればいいんだよ。
ただしそれで問題が出てもグダグダ言うな。
862
名前:
デフォルトの名無しさん
:2006/09/24(日) 22:17:18
シングルスレッドで問題が出るって言うほうが信じられん
863
名前:
デフォルトの名無しさん
:2006/09/24(日) 22:19:55
ほんの少し前の書き込みすら読めない、能無しの
>>862
には一生分からないから安心しろ。
864
名前:
デフォルトの名無しさん
:2006/09/24(日) 22:29:21
てst
865
名前:
デフォルトの名無しさん
:2006/09/24(日) 22:35:48
1フレームの描画に時間かかるっていうが、
仮にえらい重い処理が入って1秒落ちたら60フレーム分キーデータバッファリングしとくのか?
866
名前:
デフォルトの名無しさん
:2006/09/24(日) 22:39:02
モデルデータの読み込みとか展開なんかをしている間、
ブロックしっぱなしにするつもりなんだろうか?
867
名前:
デフォルトの名無しさん
:2006/09/24(日) 22:41:06
重いデータのやりとりもない、入力も適当でいい、
処理中はブロックされても気にしない、
そんなプログラムを作っている人間にとってマルチスレッドは不要。
868
名前:
デフォルトの名無しさん
:2006/09/24(日) 22:43:26
>>886
,887
それ別スレッドにするのは読み込みであって入力じゃない気がするんだけど
869
名前:
デフォルトの名無しさん
:2006/09/24(日) 22:49:42
小規模なミニゲームみたいなのしか作っていないのなら、
マルチスレッドの必要性なんて分からなくて当然。
気にするな、それが普通だと思っておけばいいんだよ。
870
名前:
デフォルトの名無しさん
:2006/09/24(日) 22:56:05
なんらかの区切り毎に、モデルデータをまとめて読み込むゲームの方が多くね
動的に展開する必要があるのって、メモリ容量が不定なPCゲー?
いや別にどっち使っても良いけど
871
名前:
デフォルトの名無しさん
:2006/09/24(日) 23:00:26
さすがにサウンドは別スレッドにするなぁ
それ以外はゲームループ内で全部やっちゃうけど
872
名前:
デフォルトの名無しさん
:2006/09/24(日) 23:00:27
作ったことがない奴がいくら気をもんだって分からないんだから、気にしなくていい。
873
名前:
デフォルトの名無しさん
:2006/09/24(日) 23:04:41
自己紹介が続いてますなw
874
名前:
デフォルトの名無しさん
:2006/09/24(日) 23:21:22
>>867
別スレッドで重いデータを読み込んでも、結局間に合わないならブロッキングが起きるっしょ。
それどころか間に合わない場合の同期とか、処理落ち管理が面倒なだけな様な。
シングルなら、やる気ならその辺の制御は厳密に出来るっつーか。
データ読み込みで処理止めるような実装する奴はいないっしょ。それが必要なら、だが。
どっちかっていうと、楽したいから別スレッドに丸投げするもんだと思うんだけどな。
875
名前:
デフォルトの名無しさん
:2006/09/24(日) 23:25:33
ゲーム中にリアルタイムでデータ読み込みとかは普通にやるが、
読み込みスレッドを別にするだけで入力だけ分けたりはしないけどなぁ。
ここで入力を別スレッドって言ってるやつは、
描画/演算/入力
って分け方なわけでしょ。
876
名前:
デフォルトの名無しさん
:2006/09/25(月) 00:00:50
そこまですると全体的なスループットは逆に低下しそうだな。
結局どこかで同期しなきゃならないわけだし
877
名前:
デフォルトの名無しさん
:2006/09/25(月) 00:53:25
マルチスレッドにするメリットって?
878
名前:
デフォルトの名無しさん
:2006/09/25(月) 01:07:16
他の処理はともかくファイルの非同期読み込みや
サウンドのストリームはさすがにシングルスレッドじゃ無謀だろw
ネットワークはWinSockならWindowメッセージにイベントとして
データのやり取りを受け取るように出来るからスレッドを別にしなくても
ゲーム次第ではシングルスレッドでも出来るな。
非同期I/Oもあるし。
879
名前:
デフォルトの名無しさん
:2006/09/25(月) 01:26:02
マルチスレッドはサウンドのストリーム再生にしか使ってないので、質問。
ファイルの読み込みを別スレッドでって言うけど、
読み込みなんてファイルのデータが必要なときにやるわけだから、
別スレッドで読み込んだって、どうせ読み終わるまで次の処理に行けない。
ってことは、先読みで別スレッドに読み込み処理をさせておくの?
データが必要なときに、読み込みスレッドが読み込みを終えてなかった場合はどうするの?
そんな心配をするくらいなら、いわゆる Now Loading の画面中に先読みしとけばいいんじゃないの?
こんな俺に、ファイル読み込みを別スレッドでやるメリットというか、
むしろ方法を教えてください。
880
名前:
デフォルトの名無しさん
:2006/09/25(月) 01:26:09
>ネットワークはWinSockならWindowメッセージにイベントとして
>データのやり取りを受け取るように出来るからスレッドを別にしなくても
>ゲーム次第ではシングルスレッドでも出来るな。
どんだけキューに積むつもりやねんとw
まあ、自分で書いても、この種の処理は大抵自前のキューに積みまくることにはなるんだけどさ。
881
名前:
デフォルトの名無しさん
:2006/09/25(月) 01:35:08
バタンキュー
882
名前:
デフォルトの名無しさん
:2006/09/25(月) 02:01:15
>>879
データが必要になるずっと前からロードを開始しとくんだよ。
それでも間に合わなかったら、もっと前からロードを開始。
NowLoadingで良いという人はそれでもいいんじゃん。
コンシューマ畑にはそんなやつはいないと信じてるが。
883
名前:
デフォルトの名無しさん
:2006/09/25(月) 02:02:47
>>876
同期が必要ならマルチスレッドなんか意味ないよ。
大人しくシングルスレッで頑張ってなw
884
名前:
デフォルトの名無しさん
:2006/09/25(月) 02:11:54
シングルスレッ!
実際問題、マルチスレッドは楽するために使うもんだ。
問題が複雑化するなら使うな以上のことは何も無い気がス。
といいながらひとつ質問。
ウインドウのメッセージループ本体と描画&更新のメインループを
別スレッドで回すのは典型的だとは思うんだが、デバイスロスト時の
復元とかはどっちのスレッ!にやらせてる?
俺は今まで何も考えずにウインドウ側にやらせてたんだが、
これをメインループ側に押し付ければ、D3Dのライブラリは
シングルスレッ!の方で済んだりするのか?
マルチスレッ!版とパフォーマンスの違いがどの程度あるのか
知らんのだけど、誰かお母さんみたいに優しく教えてくれないか。
885
名前:
デフォルトの名無しさん
:2006/09/25(月) 02:12:59
キー入力が同期しなくてもいいってそれはそれですげーな。
886
名前:
デフォルトの名無しさん
:2006/09/25(月) 02:28:24
お母さん「好きな方でやりなさい」
アイツ「どっちを選ぶかは・・・自由だ!!!」
887
名前:
デフォルトの名無しさん
:2006/09/25(月) 02:32:23
メカ物でNowLoadingは重要だよな。
本当に読んでいるかは別として
888
名前:
デフォルトの名無しさん
:2006/09/25(月) 02:35:07
>>884
スマンが、デバイスロスト関連の処理はやったことないんだ(;´д`)
なんせマルチスレッドで組んだの、DirectX3〜5の時だったもんでな。
でも、やるとしたら描画の方のスレッドだろうな。
ロストして困るのは描画だし、DirectGraphicにアクセスするスレッドだから。
ちなみに描画はメッセージ処理するメインループ側だよ。
キー入力とゲーム処理を別スレッ!でやらせてた。
889
名前:
デフォルトの名無しさん
:2006/09/25(月) 02:45:50
>キー入力とゲーム処理を別スレッ!でやらせてた。
それはそれで凄くね?
J2MEのアプリとかだとキー入力が全部イベントだから
そんな感じの迂遠なコードになるんだけど、D3DInputなら
普通に更新側で回した方が楽な方が。
WM_KEYDOWNとかから直接回収してたのん?
デバイスロストしてても描画はスルーされるだけだから、
復元は本体側スレッ!でやるのが典型なのかもね。
ただ、Present失敗->復元はその場でできるのだろうけど、
アダプタの切り替えとかはウインドウ側でやらないと、
毎度毎度ウインドウ位置の問い合わせとかしないとならなくなりそうだ。
誰が書いても最終的には同じ処理になるんだろうが、地味に面倒だなあ。
DXUTに全部書いてあるんだろうか。
アダプタ変更とかはメッセージループ側でやってた記憶があるが。
890
名前:
デフォルトの名無しさん
:2006/09/25(月) 03:02:21
>>889
当時のグラボは、パンチスルーすらも無いのがあるくらい低能で
とにかく描画が遅かったんだよね。だから、描画とそれ以外を分ける必要があった。
具体的にどうやってたかは覚えてないんだがw、キーボードにも対応してたから
メッセージを直接取ってたんだろうね。D3DInputは普通にね。
>普通に更新側で回した方が楽な方が。
更新側ってのが何を指してるのか分からんが、ゲーム処理は入力と同じスレッド
だから、そっちが更新側とも言える。描画更新という意味だったら別だね。
描画は同期を取ってないから必然的にトリプルバッファになったかな。
座標とか描画に必要なものだけをトリプルで管理してた。
入力→ゲーム処理で更新するもの、したもの、描画中のもの。
891
名前:
デフォルトの名無しさん
:2006/09/25(月) 03:07:59
OK、描画コンテキストの生成が別スレで、
更新周りは切り離してたわけだね。
今のGPU事情考えたらまず無いタイプの実装だとは思うけど、
当時はそうするメリットがあったってことなのかな。
実感は追いつかないけど、なんとなく想像はつく気がする。
とりあえずお疲れ様でした。
892
名前:
デフォルトの名無しさん
:2006/09/25(月) 03:14:40
> 今のGPU事情考えたらまず無いタイプの実装だとは思うけど、
何か特別な制限がない限り今でも同じ実装をすると思う。
PCってのは実行環境がまちまちだから、スペック低いのから高いのまで
同じ「ゲーム感覚」で遊べるようにしたいんだよね。
それには最低限、入力処理は別スレッドで同じタイミングで、って。
> とりあえずお疲れ様でした。
ありーん( ´∀`)
893
名前:
デフォルトの名無しさん
:2006/09/25(月) 03:32:46
フレーム落ち対策で、更新側と描画命令生成側とを分離するのは
割とよくやる手ではあるよね。
ただ、それをスレッドで分けてまでやる価値があるかについては
賛否分かれるところな気がする。
ひとつには単純にタイミングの問題、描画周りはGPU側の応答つーか
端的には垂直同期の縛りがある以上スケジュール応答性に縛りがあるし、
それに足並みを揃えて同期をとる以上、更新側もプッシュバッファ的に
描画前準備情報を積んでおいて、描画側は詰まれた情報を元に描画命令を生成って
流れになると思うんだけど、そのオーバーヘッドはあまり小さく無い気がするし、
作りとしては少々大掛かりになっちゃうよね。
俺は単純に前フレームで経過したデルタ時間を更新側に渡す手をよく使うわ。
フレームを厳密に見たいとか、ゲームの質によっては許容できない場合もあるのだろうし、
誤差周りがついて回るので、これはこれで設計に気を配るところは多いんだけど、
PCゲーでかつ3D物だったりする場合、内部更新が60FPS固定で描画を分離〜のスタイルより
作りやすいのは確かだし、人間が感知できるレベルでの違いらしい違いもほとんど現れないし、
スループットも概ね上。
まあ、この辺は好き好きなのかな。
894
名前:
デフォルトの名無しさん
:2006/09/25(月) 03:43:09
> 流れになると思うんだけど、そのオーバーヘッドはあまり小さく無い気がするし、
> 作りとしては少々大掛かりになっちゃうよね。
結局はそれなんだよね。面倒って。
あとオーバーヘッドは小さくはないが、描画の重さからすると微量なんだ。
もちろん描画が軽ければ別スレッドにする意味なんかなくなるよね。
> 俺は単純に前フレームで経過したデルタ時間を更新側に渡す手をよく使うわ。
今勉強用に作ってるやつとか、ちょっとしたデモだったら同じ方法使う。
アクションゲームだと無理が出てくるけどね。ネット対戦対応とか。
でも作りやすいのは確か。フレーム落ちにも対応できるし。普段だったらコレ。
895
名前:
デフォルトの名無しさん
:2006/09/25(月) 05:25:19
最近はハイパースレッドやデュアルコアなCPUなんで
スレッド使ったほうが処理効率上がるモナ
896
名前:
デフォルトの名無しさん
:2006/09/25(月) 09:55:01
>> 俺は単純に前フレームで経過したデルタ時間を更新側に渡す手をよく使うわ。
ELがその方法とってるよね。
あとは基本的に60固定で組んでおいて、落ちたときに差分の時間見て演算部分だけ複数回回すっていう方法もあるね。
>>895
それはどっちかというとOggのデコードみたいなCPU使う部分をスレッド化した方がよさそうな気もする。
897
名前:
デフォルトの名無しさん
:2006/09/26(火) 23:09:22
なんか変な使い方してる奴いるな。
内部処理と描画を別スレッドでってなんかメリットあんのか?
しかも、描画が遅いときって別スレにしても結局CPUもある程度負荷かかってるような気がするんだが・・・
確実に負荷も分離できるもんなのか?
スレッドってぐらいだから1描画につき何回か内部処理を実行してるんだろうけど、
描画が1回されてる間、内部処理をそう何回もできるほど内部処理って負荷すくねぇかな?
当り判定で枝狩り処理してみたり、開発終盤になると意外と重くなるような気がするんだが・・・(どんなゲームでも何故か)
マルチスレッド使うときって、先読みのロードとか曲やムービーの再生とか、そんなもんじゃねぇの?
ここまで読んだけど他はあんまりメリット感じないなぁ。
898
名前:
デフォルトの名無しさん
:2006/09/26(火) 23:36:23
>>897
スゲー古い話で、グラボが貧弱だから描画が遅いって言ってるのにね。
そんな当時のゲームなんで、内部処理は本当に軽いものなんだよ。
> マルチスレッド使うときって、先読みのロードとか曲やムービーの再生とか、そんなもんじゃねぇの?
ロードとかBGM再生でも使うに決まってるじゃん。
899
名前:
デフォルトの名無しさん
:2006/09/26(火) 23:38:10
Athlon64X2のマルチコア環境で衝突判定とフレームの計算を二分割して、
2スレッドで処理したらFPSが1.4倍ぐらいになった。
キャラクターを増やすとさらに差が開く。
900
名前:
デフォルトの名無しさん
:2006/09/26(火) 23:39:01
シームレス
901
名前:
デフォルトの名無しさん
:2006/09/26(火) 23:40:11
いかに処理を分散させるかが重要だな
>>897
は、ちと勘違い
902
名前:
デフォルトの名無しさん
:2006/09/26(火) 23:44:41
今のうちにスレッドを効率的に処理する方法を覚えておかないと、
今後化石と呼ばれるようになるぞ。
もうすぐ4コアがやってくるような時代だし。
903
名前:
デフォルトの名無しさん
:2006/09/26(火) 23:47:19
セガサターンを思い出した
904
名前:
デフォルトの名無しさん
:2006/09/26(火) 23:53:22
とりあえずキーワードは volatileな。
905
名前:
デフォルトの名無しさん
:2006/09/27(水) 00:24:48
いや、volatile厨はこのスレまで出張ってこなくていいから。
906
名前:
デフォルトの名無しさん
:2006/09/27(水) 00:27:20
> いや、volatile厨はこのスレまで出張ってこなくていいから。
マルチスレッドでvolatile指定しなくてどうするよ?w
別スレのvolatile厨の話と混乱してるなキサマ(´Д`)
907
名前:
デフォルトの名無しさん
:2006/09/27(水) 00:38:01
>>902
CPUが複数あるのとアプリケーションのスレッドが複数あるのとどう関係があるのか全くわからない。
908
名前:
デフォルトの名無しさん
:2006/09/27(水) 00:44:02
>>907
アプリがマルチスレッドだと、複数CPUにスレッドを割り振ってくれるんですよ。
909
名前:
デフォルトの名無しさん
:2006/09/27(水) 00:53:52
別にゲームって組み込みじゃないからvolatileいらんのでは
910
名前:
デフォルトの名無しさん
:2006/09/27(水) 00:58:37
volatileを指定しないと、最適化がかかって、
別スレッドからの値の変更が認識できなくなる場合がある。
この辺りの話は常識だと思うんだが。
911
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:09:13
>>908
それってそれぞれのスレッド同士が完全に分離してない場合でもその方が速いの?
例えば、キャラのボイスにしたって再生の命令を送ること自体は内部処理のスレッドになるわけじゃん?
終了を待つ処理があったとしたら、それを待つのも内部処理のスレッドなわけじゃん?
こんな状態で別スレッドって本当に速いの?
912
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:15:12
負荷のかかる処理を出来るだけ均等に分けて待ち時間を減らす必用がある。
いかに効率的に処理させるかどうかはプログラマの腕次第。
旧時代の化石プログラマには無理な作業。
913
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:17:47
>>911
別スレッドで終了を待ってたら(同期を取るっていうことね)
マルチスレッドの意味無いよね。もちろん速くもならない。
914
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:21:44
ループでぐるぐる直列で回している作業は、
きちんと考えればお互いのデータが依存していない範囲を分析して分散出来るんだが、
頭が硬いと、こういう処理を想像することすら出来ない。
915
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:23:57
何故オタは他人の人格否定から始まるのだろうか
916
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:26:29
どこに人格批判なんてあるんだ?
917
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:27:57
>>916
あ?わかんねーのかよww馬鹿だろ、おめー?
918
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:29:44
>>914
既にあるプログラムをマルチスレッドに分散するのは至難の技だよ(;´д`)
やはり最初からマルチスレッド前提で組み始めないと
どこでデッドロックするか分からなくて怖い。
919
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:30:55
もしかして今までの自分を否定されてしまうような、
なにかショッキングな事に気がついてしまったのか。
920
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:31:13
>旧時代の化石プログラマには無理な作業。
これとか?
サターンは旧時代のハードだがマルチコアじゃないのかと。
てかもっと昔にもマルチコアのハードなかったっけ・・・?
921
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:32:59
>>920
どこにも人格に対する言及は含まれていないように見える。
922
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:33:03
>>915
「頭が硬いと、」ってところに反応したのかも知れないが
普通に「頭が硬い人は〜できない」って意味じゃねーか?
923
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:34:21
能力 != 人格
924
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:39:27
だけど真面目な話、これからはマルチスレッドは必須だから
ちゃんと注意点・問題点と利点などを理解しておくといいよ。
最初は簡単で確認もしやすいファイルロードを別スレッドでやってみるとかね。
テクスチャファイルだけだったら停止することもないだろうし
問題があったら見た目にも分かりやすいし入門にいいんじゃん?
925
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:45:43
そういやファイルI/Oのスレッドって裏でずっと回してる?
それとも読み込み時にスレッド立てて完了したらスレッド閉じてる?
926
名前:
デフォルトの名無しさん
:2006/09/27(水) 01:59:39
>>925
人それぞれだと思うけど、最近よく聞く「スレッドプール」でやる人は
読み込み時にスレッド起動して完了したらプールに返すんじゃないかな。
ファイルはBGMストリームにも使われるから、アプリ起動中ほとんど使ってる
って考えだったら、専用のスレッドにしてずっと回してればいいと思う。
もちろん暇な時はsleepしてね。
927
名前:
デフォルトの名無しさん
:2006/09/27(水) 02:17:35
マルチスレッドプログラミング相談室 その5
ttp://pc8.2ch.net/test/read.cgi/tech/1157814833/l50
volatile厨っつーのが出て静かになった感があるけど
過去ログみたら少しは勉強になるんじゃないかな。
928
名前:
デフォルトの名無しさん
:2006/09/27(水) 02:29:44
>既にあるプログラムをマルチスレッドに分散するのは至難の技だよ(;´д`)
簡単かと思って迂闊に手を染めると大抵ドツボだな。
一度徹底的に解体して再構成する羽目になる。
見合った成果が得られるかは状況次第だけど、
このところのCPU事情鑑みるに、DirectX的には美味しいかもだな。
命中判定部分だけ切り離したりしたコードが高速に動いてくれるのを見るのは楽しそうだ。
929
名前:
デフォルトの名無しさん
:2006/09/27(水) 02:35:37
深夜になると盛り上がるな。このスレ。
930
名前:
デフォルトの名無しさん
:2006/09/27(水) 03:15:57
>>920
セガサターンはマルチプロセッサ。論理的には一緒だが。
サターンでも最後期のバージョンはマルチコアらしいが未確認。
たんにマルチプロセッサなだけなら、全然珍しくない。
旧世代のマルチプロセッサシステムは、マルチスレッド的な使い方よりも
マルチプロセス的な使い方だから、OSがCPU時間を勝手に割り振って
くれるような今のマルチスレッドとは全然違う。
931
名前:
デフォルトの名無しさん
:2006/09/27(水) 03:43:19
単なる複数プロセッサ搭載マシンとSMPで組まれたシステムを一緒にしてはいかんよな、うん
932
名前:
デフォルトの名無しさん
:2006/09/27(水) 06:46:30
どっちにしてもOSにまかせたほうが楽そうな話だけどな。
こんなの自分で管理してホントに速くなるのかね?
933
名前:
デフォルトの名無しさん
:2006/09/27(水) 07:51:57
処理手順が思いつかず、そういう疑問を抱く
>>932
には無理。
934
名前:
デフォルトの名無しさん
:2006/09/27(水) 08:23:24
スレ伸びすぎ
つかマルチスレッド自体は相当前からあるだろうに、
なんで「最近出てきた新しい技術!」みたいな奴がいるんだろ
935
名前:
デフォルトの名無しさん
:2006/09/27(水) 11:42:01
質問失礼します。
A1R5G5B5のテクスチャーをTRIANGLELISTで2Dとして描画しています。
頂点のアルファを変更し、半透明にしようとしたのですが、全く効果がありません。
(不透明になります。ただし、テクスチャーA1R5G5B5のピクセルの抜き色は反映されています。)
頂点色 D3DCOLOR_ARGB(128, 255, 255, 255) 0x80FFFFFF の時に半透明になるようにしたいです。
アルファブレンディングの設定は以下のようにしています。
dev->SetRenderState(D3DRS_ALPHABLENDENABLE, true);
dev->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA);
dev->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_SRCALPHA);
ドライバーは最新です。
(他のソフトで半透明になるのを確認しました)
環境は以下の通りです。
DirectX 2005 April
VS2003
Win2000
リモート
DirectX 9.0c
Win2000
原因が分かる方、よろしくお願いします。
936
名前:
デフォルトの名無しさん
:2006/09/27(水) 13:46:17
考えるまでもなくテクスチャのα値を参照するようになっているからだろ。
それに何か疑問点があるのか?
937
名前:
デフォルトの名無しさん
:2006/09/27(水) 13:48:42
>>936
それをどうやったら頂点カラーを参照するようになるか?って質問だろ。
オマエは初心者に厳しいなw
938
名前:
デフォルトの名無しさん
:2006/09/27(水) 14:06:26
SetTextureStageState()のAlphaOP
939
名前:
935
:2006/09/27(水) 14:32:09
返答ありがとうございます。
SetTextureStageStateに関しては嫌な予感がします。
今会社なので試せませんが、夜見直して結果を書き込みます。
ありがとうございます。
940
名前:
デフォルトの名無しさん
:2006/09/27(水) 14:54:36
wave読み込むmmio〜なAPIで、
ファイル(mmioOpen)でなくメモリから読み込むやつってあります?
941
名前:
デフォルトの名無しさん
:2006/09/27(水) 17:04:45
mmioOpen自体にメモリから読み込む機能があるので頑張ってください。
とってもとっても応援してます。
942
名前:
デフォルトの名無しさん
:2006/09/27(水) 20:05:29
「デバイスの消失」についての質問です。
SDKに書いてあるようにデバイスが消失したらD3DPOOL_DEFAULTで取得した
頂点バッファとかを解放する必要があると書いてあるわけなんですけど
これって、わざわざ、↓の工程をしないといけないのですか?
せっかく、頂点バッファを取得して、そこに頂点のデータを代入しても
デバイスが消失したら、その頂点バッファを使えなくなってしまい、
代入した頂点データがパーになってしまうということですよね?
皆さんは、どのような対策をしてるんでしょうか?
代入する頂点データとかを別の場所に保存してるんですか?
よろしくおねがいします。
工程:
デバイス消失
↓
D3DPOOL_DEFAULTで取得した頂点バッファを解放
↓
Resetできるなら、Resetメソッドで復帰
↓
また、頂点バッファを取得しなおす
943
名前:
デフォルトの名無しさん
:2006/09/27(水) 20:30:41
元に戻せばいいだけの話なのに何が問題なんだ?
944
名前:
デフォルトの名無しさん
:2006/09/27(水) 21:00:58
>>942
データを元に戻すのが面倒だったらアプリ終了しちゃえ。
「デバイスロストしたので終了します」って。マジでそれで十分だ。
945
名前:
942
:2006/09/27(水) 21:33:05
>>943
元に戻すためには、頂点バッファに入れた情報を別の場所で
保持し続けなければいけないわけで、もったいないと思うから。
946
名前:
デフォルトの名無しさん
:2006/09/27(水) 21:40:32
ハァ、何がもったいないんだ?
必用な処理にもったいないも糞もないだろ。
947
名前:
デフォルトの名無しさん
:2006/09/27(水) 21:42:37
面倒というなら分かるけど、そういう風になっているからしょうがない。
D3DPOOL_MANAGEDを使うか、DirectX10を待つしかない。
948
名前:
デフォルトの名無しさん
:2006/09/27(水) 21:49:54
>>946
>>947
頂点も数が多くなれば、それを保持するのも
もったいないと思ったわけですが、
D3DPOOL_DEFAULTフラグを使う時は節約することは
できないようですね。
ありがとうございました
949
名前:
デフォルトの名無しさん
:2006/09/27(水) 21:57:59
裏で保存する処理が行われていれば、どんなにメモリが無駄遣いされても絶対気にしないくせに、
面倒な作業だと思うと、途端にもったいないとか言い出す。
950
名前:
デフォルトの名無しさん
:2006/09/27(水) 22:03:29
裏でバンバンメモリの確保開放が行われてるのに
断片化を嫌がって初期化時以外は一切mallocやnewをしない方針の人。
昔はよくいたよね。
951
名前:
デフォルトの名無しさん
:2006/09/27(水) 22:41:00
>>950
別に同じヒープから確保されているとは限らないじゃん。
952
名前:
デフォルトの名無しさん
:2006/09/27(水) 22:44:11
メモリプールだ
953
名前:
デフォルトの名無しさん
:2006/09/27(水) 22:45:22
最近はOSがやってくれてるから
わざわざアプリ側でそんなことをする必要がない
954
名前:
デフォルトの名無しさん
:2006/09/27(水) 22:52:03
俺、メモリまわりの勉強ってやったことないんだけどさ。
今、自分のプログラムで何にどのくらいメモリを使っているか?
ってどうやったらわかるの?
あ、タスクマネージャーでわかるようなのじゃなくて
どのクラスがどれくらい食ってるとかそういう情報まで調べようと思ったら
一般的な方法としてはどういうのがあるの?
955
名前:
デフォルトの名無しさん
:2006/09/27(水) 22:54:23
malloc/free自分でこしらえたら?
956
名前:
デフォルトの名無しさん
:2006/09/27(水) 22:55:08
とりあえずスレタイを読むと良いと思う。
957
名前:
デフォルトの名無しさん
:2006/09/27(水) 22:55:30
>>955
もう、newとdeleteでかなり組んでるので勘弁してくださいw
958
名前:
デフォルトの名無しさん
:2006/09/27(水) 22:56:55
>>957
オーバーライドするだけだから変更箇所は少ない
959
名前:
デフォルトの名無しさん
:2006/09/27(水) 23:02:08
>>958
オーバーライドする方法は昔試みたけどSTLかなんかで妥協した覚えが・・・
960
名前:
デフォルトの名無しさん
:2006/09/27(水) 23:07:00
>>959
じゃあ今回も妥協しなさい・・・妥協?挫折?
961
名前:
デフォルトの名無しさん
:2006/09/27(水) 23:07:48
>>960
なんかエラーがたくさんでんねん。
962
名前:
ヶロス
:2006/09/27(水) 23:08:13
用語わからんw
963
名前:
デフォルトの名無しさん
:2006/09/27(水) 23:19:30
>>954
メモリの残り容量取得する関数があるから
自分のアプリだけ立ち上げてテストして見れ
964
名前:
デフォルトの名無しさん
:2006/09/27(水) 23:50:29
それだったらタスクマネージャーで見たらええやん
965
名前:
デフォルトの名無しさん
:2006/09/27(水) 23:55:31
そういえばそうだ
966
名前:
デフォルトの名無しさん
:2006/09/27(水) 23:57:23
そろそろ次スレの季節
俺無理だった。他の人ヨロ
967
名前:
デフォルトの名無しさん
:2006/09/28(木) 00:27:05
>>941
kwsk
MMIOINFOの説明が無いしポインタっぽい指定も無い><
968
名前:
デフォルトの名無しさん
:2006/09/28(木) 00:57:27
ウィンドウで描画してる間、別のコンソール画面で情報を表示したいのですが、具体的な手段が分かりません。
教授願います。
969
名前:
935
:2006/09/28(木) 01:10:05
>>938
解決しました。
ありがとうございました。
970
名前:
デフォルトの名無しさん
:2006/09/28(木) 01:12:53
>>968
デバッグモードでアウトプットウィンドウで見たらいいんじゃん?
971
名前:
デフォルトの名無しさん
:2006/09/28(木) 01:14:47
>>968
リッチテキストのウインドウでも作って、好きなように出力すれば?
972
名前:
デフォルトの名無しさん
:2006/09/28(木) 01:27:47
>>970
,971
ありがとうございます。
とりあえずprintfで出力できるコンソールウィンドウを考えています。
973
名前:
デフォルトの名無しさん
:2006/09/28(木) 01:37:03
>>972
デバッグんときはシステムを/consoleでビルドして、
リリースんときは/windowsでビルドしろ。
int main( void )
974
名前:
デフォルトの名無しさん
:2006/09/28(木) 01:38:51
送っちまった・・・
#ifdef _DEBUG
int main( void )
{
return WinMain( ... );
}
#endif
とかやれば問題ねぇ
975
名前:
デフォルトの名無しさん
:2006/09/28(木) 01:42:06
そういうのパッと見わけがわからないからやめてくれない?
976
名前:
デフォルトの名無しさん
:2006/09/28(木) 01:58:23
Windows厨は、黙ってOutputDebugString(TRACE)
977
名前:
デフォルトの名無しさん
:2006/09/28(木) 02:03:34
>>973
ありがとうございます
コンソールウィンドウは出せましたが、今度は描画してるウィンドウがなくなりました。
描画しつつコンソールに文字出力というのは無理なのでしょうか?
978
名前:
デフォルトの名無しさん
:2006/09/28(木) 02:05:13
んじゃ
>>975
の要望にもこたえる方法
::AllocConsole();
hConsole = ::GetStdHandle( STD_OUTPUT_HANDLE );
void Printf( const char *pStr,... )
{
Uint32 WriteSize;
char Temp[1024] = "";
vsprintf( Temp, pStr, (char*)(&pStr + 1) );
::WriteFile( hConsole, Temp, (int)strlen(Temp), &WriteSize, 0 );
}
979
名前:
デフォルトの名無しさん
:2006/09/28(木) 02:06:34
>>977
コンソールアプリでもCreateWindowで普通にウィンドウ作れるわけだが・・・
UpdateWindow()とかShowWindow()とかしてないだけじゃない?
980
名前:
デフォルトの名無しさん
:2006/09/28(木) 02:26:01
e:\デスクトップ\dx9animation\cd3dxobject.cpp(6): fatal error C1083: include ファイルを開けません。'DXUtil.h': No such file or directory
とか言われるんだけど、DXUtil.hって昔のヘッダか何か?
981
名前:
デフォルトの名無しさん
:2006/09/28(木) 06:44:30
SamplesのCommonの下にある、サンプル類が共通で使用してるファイル。
DirectX本編側に組み込まれてるわけじゃないから、自前で組み込んでなければ
それは出るだろうさ。
982
名前:
デフォルトの名無しさん
:2006/09/28(木) 11:48:25
教えてエロい人
スキンメッシュアニメーションと、ボーンアニメーションっていっしょ?
肌と骨で違う感じするけど、どうなん?
DirectX使って再生する場合って、それぞれまったく違う
プログラムが必要でつか?
983
名前:
デフォルトの名無しさん
:2006/09/28(木) 12:18:44
>>982
一緒
984
名前:
982
:2006/09/28(木) 12:21:32
>>983
ありがとうごぜいます。
これで安心してプログラムくめまつ。
せっかくだから俺はボーンアニメーション使って
エロい同人ゲーム造るぜ。
985
名前:
デフォルトの名無しさん
:2006/09/28(木) 13:16:10
Vistaが来るぞ、気をつけろぉ!
986
名前:
デフォルトの名無しさん
:2006/09/28(木) 15:54:10
DirectXを初期化するとdoubleの割り算の結果が変わるのはなぜ?
987
名前:
デフォルトの名無しさん
:2006/09/28(木) 16:03:32
>986
つD3DCREATE_FPU_PRESERVE
988
名前:
デフォルトの名無しさん
:2006/09/28(木) 19:06:08
>987
ありがとうございます。
お手数ですがもう一つお願いします。
このパラメータDirectX8以降に対応してるっぽいけど、
DirectX7だと_controlfpしかないですかね?
使って戻してがかなり不便・・・
989
名前:
デフォルトの名無しさん
:2006/09/28(木) 19:41:59
>988
自分で調べろよ
DDSCL_FPUPRESERVE
990
名前:
デフォルトの名無しさん
:2006/09/28(木) 22:28:43
>>989
度々ありがとうございます。
>自分で調べろよ
ここで聞くことは調べてることになると思いますが違いますかね?
調べるということは情報を得るということですから、
このスレで情報を得ようとすることは調べてることと同じと思います。
それにこのやりとりを他の人が見ることで、
その人もここで調べることができるわけですから、
決して無駄ではないはずです。
991
名前:
デフォルトの名無しさん
:2006/09/28(木) 22:33:31
これがゆとりの成果。
992
名前:
デフォルトの名無しさん
:2006/09/28(木) 22:38:57
初めて超理論展開を体験した
993
名前:
デフォルトの名無しさん
:2006/09/28(木) 22:51:41
宇宙の真理がここにある
994
名前:
デフォルトの名無しさん
:2006/09/28(木) 22:59:49
銀河の歴史に新たな1ページ
995
名前:
デフォルトの名無しさん
:2006/09/28(木) 23:06:08
宇宙の授けた光の答え
996
名前:
デフォルトの名無しさん
:2006/09/28(木) 23:10:20
次スレないの? じゃあ完結おめでとう?
997
名前:
デフォルトの名無しさん
:2006/09/28(木) 23:14:14
何度でも蘇える!
998
名前:
デフォルトの名無しさん
:2006/09/28(木) 23:25:52
>>990
日本語ドキュメント1つ読むコトすらできないの?
ってコトだ。
999
名前:
デフォルトの名無しさん
:2006/09/28(木) 23:27:42
>>990
天然なんだねw
自分で調べろって言われるってことは、ぐぐればすぐわかることを質問してるからだろ?
1000
名前:
デフォルトの名無しさん
:2006/09/28(木) 23:34:11
そして時は動き出す。
■過去ログ置き場に戻る■
1-
前250
次250
最新50
DAT2HTML
0.33f Converted.