DirectX総合スレ (Part4)

**名前は開発中のものです。** · 2005/11/26(土) 01:58:58

※「鬱だ氏のうスレ」と「DirectX総合スレ」は統合され、
　ゲーム製作技術スレに戻ってきました。

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

ちなみに、言語はC++がメイン。
C# / VB.NET 使いは、専用スレの方が話がスムーズに進むと思われ。

**名前は開発中のものです。** · 2006/06/29(木) 14:00:02

>>589-592
みなさん、ありがとうございました。
早速、やってみます。

**名前は開発中のものです。** · 2006/06/29(木) 22:18:43

スキンメッシュってXファイルを使うから
わけが分からないんじゃないかとつくづく思うのだが…

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

そもそもD3DXの高レベルAPIに頼るから、わけが分からなくなるんだよ。
地道に学習しながら実装していかないかぎり、いつまで経ってもわけが分からないまま。

**名前は開発中のものです。** · 2006/06/29(木) 22:42:47

しかしモデル読み込みから自前で全部やるとＸファイル使う以上に( ﾟДﾟ)ﾏﾝﾄﾞｸｾｰ。
そもそもＸファイルもろくに出せない香具師が自前フォーマットもメッシュ/モーションファイルなんて使えるわけがない。

**名前は開発中のものです。** · 2006/06/29(木) 22:42:51

またD3DX叩きか

**名前は開発中のものです。** · 2006/07/02(日) 23:33:22

正直なところ、モデルの表示なんて文字の表示と同じレベルの
定型処理と思っていいのだろうから、高レベルAPIだけで完結するのは
一向構わないとは思うんだが、その高レベルAPIの設計がズタズタなのは
どうにかならないものかと。
ドキュメントも乏しいし、サンプルも取りあえず動かしてみますた的なもので
使い方のイロハを学べる様な手合いのものじゃないし。
そもそもAPI自体がころころ変わるし。
アニメーションコントローラとか最初扱いに困ったよ。

**名前は開発中のものです。** · 2006/07/03(月) 04:23:05

しつもーん。
3DのRPGを作っているとして、ある鎧があって
ドラえもんとケンシロウに同じ鎧を着せるような場合、楽する方法ありますか？
鎧の数が少なければ、各鎧装備中のドラえもんとケンシロウをそれぞれ
必要なだけ別のXファイルとして用意しちゃえばいいってのは考え付きますけど
鎧の数が多くなってくると、全パターンのXファイル作成（３DCG編集）となると
どう考えても挫折しそうなので・・・・

**名前は開発中のものです。** · 2006/07/03(月) 04:37:38

>>599
ありません。だから商用ゲームは作るのに金と時間が掛かるんです。

**名前は開発中のものです。** · 2006/07/03(月) 08:10:45

鎧をスキンメッシュにして、ボーンの位置に対応させて、ビヨヨーンと伸ばす。
当然鎧というよりタイツみたいになって不自然だけど。

**名前は開発中のものです。** · 2006/07/03(月) 09:35:14

止め絵ならそれでも良いが、
アニメが入るとどうしようも無いな。

ケンシロウの体格のドラえもん作れ。

**名前は開発中のものです。** · 2006/07/03(月) 11:47:38

スキンメッシュが難しい。
だが、複数のＸファイルを読み込んでアニメーションさせることには成功した。
２Ｄゲームのアニメーション手法と同じである。
ユーザー側としてこの手法に何かデメリットはあるか？

**名前は開発中のものです。** · 2006/07/03(月) 21:11:39

メモリ、ディスク容量を食う。

**名前は開発中のものです。** · 2006/07/03(月) 22:42:53

管理が激しく面倒。

**名前は開発中のものです。** · 2006/07/03(月) 23:05:45

最初はそれでも良いと思う。
あとでスキンメッシュと差し替えることが出来るように
作っておけば、さらにOK。

**名前は開発中のものです。** · 2006/07/04(火) 08:14:14

>>602
ケンシロウの体格のドラえもん
ttp://omosiro.web.infoseek.co.jp/doraemon/17.html

**名前は開発中のものです。** · 2006/07/04(火) 11:42:33

質問です。
今の３Ｄゲームのプログラミングというのは、２Ｄゲームの要領で、ただ３Ｄモデルを表示させてるだけなのでしょうか。
これだとホントウに擬似３Ｄ過ぎて、当たり判定とかがまるっきり抜けてるような。
市販の３Ｄ格闘ゲームなどの細かい当たり判定とかはどのように行っているんでしょう・・・
表示とは別に、３Ｄデータから細かい座標を割り出して衝突計算などをしているのでしょうか。

**名前は開発中のものです。** · 2006/07/04(火) 14:07:14

つバウンディングボックス、スフィア

**名前は開発中のものです。** · 2006/07/04(火) 14:35:32

アタリ用のモデルを作る

**名前は開発中のものです。** · 2006/07/04(火) 20:08:01

>>608
ＤｉｒｅｃｔＸでは当たり判定はサポートしていない。
つまり当たり判定を実装する時点でＤｉｒｅｃｔＸは卒業だ。
卒業ｵﾒ。

俺は表示用のポリゴンデータを、自作のクラスで参照して判定している。
まだ開発中なので、負荷が大きかったら別の方法にするかも試練。

**名前は開発中のものです。** · 2006/07/05(水) 02:47:09

DirectXでゲームを作ろうと思っているのですが
おすすめの参考サイトなどありますか？
サイトだけで習得は難しいならおすすめの本など教えていただけると幸いです。

**608** · 2006/07/05(水) 12:03:49

>>609
２Ｄシューティングの使う矩形の重なりの３Ｄばんですね。
これは考えていたのですが名称しらなくて、それでググってみると少し参考になるサイトが見つかったです。
ありがとうございます。

>>610
ローポリとかで作って同時に動かすって事でしょうか。
簡単なゲーム構成だと簡略処理で済ませるのがいいんでしょうけど、
アクション格闘などの、細かい接触判定が必要なものだとそうなるしかないのかな。

>>611
そんな卒業嬉しくないです・・・；；
今はゲームやシミュレータ等に汎用できるエンジンを探しているんですが、
メジャーといえるものが無いですね。不思議なぐらい。
自作出来るのはすごい羨ましいです。
どんな感じなのか見てみたいかも。

**名前は開発中のものです。** · 2006/07/05(水) 12:35:46

>>610だけど、アクションに関わらず、今まで開発に携わったことのある３Dゲームはあたりモデル作ってたよ。
3次元で作る場合もあれば床に線引いたりして作る場合もあり。
当然ローポリ。

**名前は開発中のものです。** · 2006/07/05(水) 14:34:03

http://watch.impress.co.jp/game%2Fdocs/20051207/3dwa.htm
ワンダの衝突モデルは結構細かいな

**名前は開発中のものです。** · 2006/07/05(水) 20:44:28

いや、釣りでも煽りでもなくってw

初心者が３Ｄゲームを作るスレ
http://pc8.2ch.net/test/read.cgi/gamedev/1148138668/126

あたりから、しばらく呼んでみるといいかも。

**名前は開発中のものです。** · 2006/07/08(土) 13:06:31

DirectDrawの質問があるっす。32bitのDirectDraw サーフェスに24bitのビットマップを表示するにはどうすればいいんでしょうか？まさか1 ピクセルごと24>>32ビットへ変換をかけてからサーフェスに書き込むの...？

**名前は開発中のものです。** · 2006/07/08(土) 13:44:22

それで何か問題があるのか？

**名前は開発中のものです。** · 2006/07/08(土) 13:55:19

いやもっと効率のいい方法があると信じたい...ないの？

**名前は開発中のものです。** · 2006/07/08(土) 14:28:02

>>619
というか、DirectDrawが勝手にやってくれるから気にしなくていいんじゃね？

別にそんな変換したって現行のCPUやGPUだったらどうって事ねえよ。

ナニ？Drawで１６００ｘ１２００とかの高解像度ゲームでも作る気？

**名前は開発中のものです。** · 2006/07/08(土) 15:18:56

レスども。変換しないでメモリーコピーすると表示されたビットマップの幅が3/4に縮む。CreateSurfaceで２４ビットを指定してるのにどうして３２ビットサーフェスを作ってしまうんだ DirectDraw ?

DirectDraw に限らず24ビットの絵を32ビット設定のプログラム上で表示する場合自前のコードで変換するのが普通？

**名前は開発中のものです。** · 2006/07/08(土) 17:39:34

初期化時に変換するって用途ならSurfaceに対しGetDCでデバイスコンテキストを
取得してBitBltで書き込めばいいよ。

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

>>622
レスども。ダメでした。ビットマップとDCのビット数が違うので以前と同じような問題が起きます。

**名前は開発中のものです。** · 2006/07/09(日) 08:18:50

自分で変換するのが嫌なのに、24bit固定でCreateSurfaceやCreateBitmapって…

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

世の中には不思議な人も居るんだよ。

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

アンチエイリアスとダブルバッファはどちらかしか無理って聞きましたがどうなんでしょう？

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

DirectXとは直接関係ないが、
紐の端をもって振り回すような動きを動的に作りたいんだが、
こいうのってどういう計算するの？

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

そりゃ物理計算の話だろ

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

紐というか鞭かもしれない

**名前は開発中のものです。** · 2006/07/11(火) 01:13:22

ごく直接的にアプローチするなら、
紐をいくつもの接続点にバラして、
接続点の座標を配列でダダ持ちして、
末尾をテキトウに動かして、
その末尾から、接続された点の距離が一定になる様無理矢理補正して、
それは反対側の端っこまで繰り返す、

を毎フレーム繰り返す程度で、それっぽい動きになる。
重力とか欲しければ、各点の補正前に入れるか、
補正後に鉛直との成す角から求めて振り子すれば
さらにそれっぽくなる。

DirectX全然関係ないな。

**名前は開発中のものです。** · 2006/07/11(火) 23:46:53

>>630
根元の定点だけ決めて後は高校物理の「バネの公式」使っちゃうけどな。
振り子じゃないから角度がいらない。F=-kx(xは距離：つまり距離に応じて強い力が働く）
例えば鞭だったとして

↓定点
○―○―○―○―○―○―○―○―○―○―○―○―○―○―○
Ａ　　Ｂ　　Ｃ　　Ｄ・・・

って感じでやってＡ→Ｂ→Ｃ→Ｄ・・・の順番で計算。
式はF=maを使って運動方程式を使う。
バネなんで

ma = -kx

ってなって加速度がaだから

a = -(k/m)*x

で式たてる(k/m)は定数になるのでテキトーに少数いれとく。
あとは速度は一定時間ごとに加速が足されて、座標は一定時間毎に速度が足される式で近似。
なんで１フレームの座標sの計算は

v += a
s += v

（vは速度、aは加速度）って感じ。ってやったら変になったｗ

**名前は開発中のものです。** · 2006/07/11(火) 23:47:55

あ、重量入れ忘れたｗ

まあ、

F = F1 + F2 + F3 + F4 + ・・・

だから、勘弁してよｗ

**名前は開発中のものです。** · 2006/07/13(木) 00:26:07

LunaLibraryとかを見ると
IDirect3DDevice9の管理、生成を行うクラスを作って
他のクラスからはGetメソッドを使ってデバイスへの参照を返すっていう形になっていますが
関数呼び出しのオーバーヘッド分無駄が多い気がします。
速度重視の場合、デバイスはグローバル変数で宣言し直接参照するほうがいいんでしょうか。

**名前は開発中のものです。** · 2006/07/13(木) 00:49:50

ヒント：インライン展開

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

>速度重視

いつも思うんだが、ゲームプログラムは最速目指さなきゃならんって信仰は
いったい誰が植えつけてるんだ？
しかもコスト的にどーでもいいところからこそ攻めようとするし。

>>633
関数呼び出しのオーバーヘッドなんて、stdcallでもたかが知れてるぞ。
ループの中でバリバリ呼び出す関数なら別だが、更新フレーム中
ほんの数回しか呼び出さない関数でそんなの気にしても無駄。
それにGetterメソッドなんて>>634の言うとおり大抵インライン展開されてゼロコスト。
毛髪の心配した方がまだ建設的。
あきらめてユニセフに募金しろ。

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

>>633
関数呼び出しのオーバーヘッドなんて問題になるわけねーだろｗ
しねよｗ
「気がします」とか直感にしても感性腐り過ぎだろｗ

**名前は開発中のものです。** · 2006/07/13(木) 07:39:20

>>633
試しにGetメソッドとグローバル変数とでどのぐらい差があるか調べてみればいい

**名前は開発中のものです。** · 2006/07/13(木) 19:14:31

>635も>635で大事な話をいくつか聞き逃してそうだけどな

**名前は開発中のものです。** · 2006/07/13(木) 20:08:24

日本ユニセフって、ユニセフと別組織なんだよな。

**名前は開発中のものです。** · 2006/07/13(木) 21:41:50

>>638
詳しく

**名前は開発中のものです。** · 2006/07/13(木) 23:06:34

>>640
多数のビルボードを表示するような重いゲームでは、
それらの描画にかかるGPUの負荷だけでなく、
管理にかかるCPUの負担も大きくなります。

ゲームプログラミングにおける速度信仰はそう一般化して否定できるほど
バカバカしいものではないと思います。

**名前は開発中のものです。** · 2006/07/13(木) 23:16:20

まだＳＴＧ作るの？
いい加減他のゲームも作れよｗ

**名前は開発中のものです。** · 2006/07/14(金) 00:14:38

>>641
多数のビルボードって何十万枚も描画するつもりなのか？
レンダリングのコストに比べればはっきり言って馬鹿にして無視できるコストにしかならない。

**名前は開発中のものです。** · 2006/07/14(金) 00:45:10

マジレスするとGet()メソッドなんかよりDrawPrimitive()のコールの方が圧倒的に重い。
ビルボードなんて毎フレームバッファ再生成してDrawPrimitiveは数コールしかしないだろうから関係ないが。

**名前は開発中のものです。** · 2006/07/14(金) 08:39:01

いくつかの変数だけLPSTR型なのは嫌がらせでつか
新しいSDKだと変わってるのかな

**名前は開発中のものです。** · 2006/07/14(金) 13:30:34

ぶっちゃけDirectXって放ったらかしになってるメッソドとか
誰が管理してるんだかわからなくなってる機能とか
ごろごろしてるよね。
お前らどうやって勉強してやがるんですか。

**名前は開発中のものです。** · 2006/07/14(金) 19:42:10

勉強か
まーがんばって

**名前は開発中のものです。** · 2006/07/14(金) 22:14:54

>>643
エフェクトで贅沢したら普通に何万は行くぞ

**名前は開発中のものです。** · 2006/07/14(金) 23:00:01

それを別々のビルボードにバラバラに描くつもりなのか？
アホにも程がある。
そもそも贅沢しようというエフェクトをビルボードだけでやるという前提が無能の極み。

**名前は開発中のものです。** · 2006/07/14(金) 23:39:13

まぁカッカすんな。
少し頭冷やせや。

**名前は開発中のものです。** · 2006/07/15(土) 00:13:42

何をどう実装しようと勝手だけど、負荷の重い処理に挙げられてるのが
線形負荷のロジックって時点で釣り確定だな。
衝突判定の類でも持ち出してくれてれば、まだ食いつき甲斐があるものを。

**名前は開発中のものです。** · 2006/07/15(土) 00:18:23

たくさんビルボード使う場合には、描画以外の部分の
速度も重要になりうる、ということは確かなわけだな。

たくさんビルボード使う場合そのものを回避することが
できるか否かはまた別の話として。

**名前は開発中のものです。** · 2006/07/15(土) 00:47:33

線形負荷でもデータが10倍ならかかる時間も10倍ですよ

**名前は開発中のものです。** · 2006/07/15(土) 00:54:28

キャッシュの問題とかもあるから10倍じゃすまない事も多々あるけどな

**名前は開発中のものです。** · 2006/07/15(土) 02:28:56

>>652
>たくさんビルボード使う場合には、描画以外の部分の速度も重要になりうる、ということは確かなわけだな。
なにそれ。
数字だしてよ。

**名前は開発中のものです。** · 2006/07/15(土) 02:37:22

＞たくさんビルボード使う場合そのものを回避することが
＞できるか否かはまた別の話として。

この考えが間違っているんだよ。
誤差程度にしか影響のない部分を直すより、ビルボードの数を減らす事を考えた方が速度的に圧倒的に優位。
それを別の話にしようとする時点で、問題解決能力の欠如が如実に表れている。

**名前は開発中のものです。** · 2006/07/15(土) 03:02:03

>>655
ビルボードの管理で処理速度が問題になるのはどんくらいの
オーダーでの話なのかとかその処理時間とか、ちゃんと計算
してみせろ、到底問題になるとは思えんぞ、という話だな。

>>656
引用部は、単に話が二つあるってだけの意味なんだよ。
> 誤差程度にしか影響のない
かどうかが問題となってるところ(>643と>648)なんで、
その話を先にきっちり済ませたほうがいいと思うよ。
片付けないまま話をどんどん転がしてくのは悪い癖だと思う。

レッテル貼りより、「実際問題になるのかどうか数字だしてみそ」
とか、簡単な指摘をしてやった方が健全な話し合いだと思うなあ。
話が早く済むし。

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

と自分で数字を出せない>>657がのたまっております

**名前は開発中のものです。** · 2006/07/15(土) 08:06:53

>>658
なぁ。
どう考えたって関数呼び出しのコストなんてウンコみたいなもんの削減に力入れてるのなんて
馬鹿にしかみえないもんなぁ。
しかも、たった数万でこの騒ぎｗ
>>657←ウンコはお前だし、はじめに言い出したのもお前なんだから、お前が数字出して問題あるコストである証明をしてみせろよ。
でなけりゃ>>657は嘘吐き＆ホラ吹き野郎決定。

**名前は開発中のものです。** · 2006/07/15(土) 08:08:13

読んだら違う奴じゃん。

Ｘ>>657
○>>652

**名前は開発中のものです。** · 2006/07/15(土) 08:13:05

何種類か作ってみればいいじゃん。それで一番軽いの採用すれば？
実験体作るのいやだから、どんな種類がいいか人に意見聞いといて
自分と意見違うからごねるって？？なら、最初から自分の信じた道を進めばいいじゃん。

誰がどう見ても効率の悪い話なのに、それしか信じられない人なんてほっとけばいいじゃん。

プログラム書けても、中身小学生ですか？
と、フルスクリーン切り替えウィンドウが出ただけで大喜びの暇人が申しております。

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

数字なんてチップベンダのスライドで良いじゃん。

http://www.atmarkit.co.jp/fdotnet/directxworld/directxworld01/directxworld01_03.html

シーンがCPU律速なら、これの影響をモロに受けるってだけの話でしょ。

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

>>661
ゆとりの賜物

**名前は開発中のものです。** · 2006/07/15(土) 12:40:31

多対一で袋叩きにしてるときの揚げ足取り、
レッテル貼りがいつでも通用すると思ってるあたりが

**名前は開発中のものです。** · 2006/07/15(土) 12:40:51

フルスクリーン切り替えも真面目にやると、普通にDirectXのサンプルになってくね。
いやまあ、サンプルがそう作ってあるのは当然なんだし、そうじゃなきゃサンプルとして困るわけだけど、
全画面化切り替えとデバイスのロスト->復元に、あんなにいっぱいフックかまさなきゃいけないだなんて
思っても見なかったんだ。

これも勉強だと思って真面目に書いたら２日くらい使った。
もうぬるぽ。

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

>>656
重いなら減らせばいいって考えは一番低脳。
そんなことは考えるまでもなくわかってる事だし、

ビルボードのエフェクトが重いというなら
何処が実際にボトルネックになっているかをきちんと調べることが大切。

重いからポリゴン減らせばいいとかアホでもできる。

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

ポリゴン数を減らしてつつフェクトの質を落とさないように考える部分なのに、
ビルボードに限定していることとい、まともに3Dを扱えていない事が丸分かりになってるな。

**名前は開発中のものです。** · 2006/07/15(土) 17:10:48

質を落とさないように工夫して、って言ったところで結局はごまかしなんだから
ポリゴン数やビルボードの枚数減らせば不自然な状況ができるわな。

昔は爆発とかは一枚の大きなビルボードで表現されていたが、
今は複数枚重ね合わせるのが一般的。

**名前は開発中のものです。** · 2006/07/15(土) 17:48:25

ビルボードの処理で負荷かかるのは大抵CPUかPSだろう。
フィルレートが足りないなら縮小バッファを使うとか出来るし、
CPUが厳しいなら最適化できる場所があるかどうかまずは調べるだろ。

ビルボードでエフェクト出した＞重かった＞じゃぁ減らせばいいや
これじゃ進歩がない。

最近のGPUでVSが吊るなんて事はそうそうないしポリゴン数
減らして軽くなるって状況はあまりないとは思うけどね。

**名前は開発中のものです。** · 2006/07/15(土) 17:52:56

多数を重ねる必要のある処理をビルボードでやろうとする時点で選択が間違っている。
馬鹿の一つ覚えは結構だが、UVを適切に設定してまとめて描くだけで、
ビルボードでごちゃごちゃやるより遥かに速度が改善する。

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

いくらなんでもビルボード1枚描く毎にDrawPrimitiveするヤツは今さら居ないだろ。

普通はデカイ頂点バッファをDYNAMIC|WRITEONLYで作成して
DISCARDロックして一括で転送してからDrawPrimitiveするだろ。

1枚ずつDrawPrimitive呼んでたらあっちゅーまにCPUが吊る。

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

それじゃ奥行きがないから壁際で不自然になるだろ。

**名前は開発中のものです。** · 2006/07/15(土) 18:19:58

>>672
えっ？冗談？ネタ？なんで全ての深度を同じに考えるわけ？

**名前は開発中のものです。** · 2006/07/15(土) 20:08:08

ビルボード一枚ならZ値全部同じになりますよね

**名前は開発中のものです。** · 2006/07/15(土) 20:25:58

念のため訂正。ピクセルシェーダ使えば場所によってZ値変えられるな。
でもペラペラの板一枚なことにはかわりない

**名前は開発中のものです。** · 2006/07/15(土) 20:45:41

てかZ値はいくらでも変えられるだろ・・・
ビルボードだから変えられないってのもおかしかろう。

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

大爆発を小爆発の重ね合わせで表現する時に、
テクスチャに小爆発を重ね合わせたあと一枚のビルボードとして
表示って話だろ？これで一個一個の小爆発の奥行きの違いを考慮した
描画ができるっていうんなら本気で教えてほしい

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

>>677
も、も、もしかして>>671を理解できてない？そうだよね？

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

志村ー書き込み時間書き込み時間！

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

ビルボードを常に投影面と平行にしておくとか。
さすがに用途が限られすぎるか。

**名前は開発中のものです。** · 2006/07/15(土) 22:27:38

672は671へのレスだと思ってたら
6秒でレスすんのは無理あるなｗ

**名前は開発中のものです。** · 2006/07/15(土) 22:31:32

ビルボードに法線マップ適応して、凸面表現してるゲームがあったな。
ディスプレイメントマップ使えばできるんじゃないのか？

**名前は開発中のものです。** · 2006/07/15(土) 22:56:50

法線突っ込んでライト適用するだけでも
煙とかならかなりそれっぽく見えるよ。

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

ワンダがやってた奴だな。
実際に入れてみたら気持ち悪いほど立体感が出て吹いた。
爆発の中心にライトを置いたりすると、とてもいい感じ。

**名前は開発中のものです。** · 2006/07/16(日) 08:22:59

>>615
いまさらコレ読んでるけどすげーなあｗ
理屈は分かるけど俺には到底実装できねえ
と言うかマンパワーだな、擬似HDRのところとか

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

確かにシーン分けてHDRって考えは思いつかなかったな。
PS2でHDRやったときは高輝度部分をαに仕込んでポストエフェクトで実装してた。

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

普通そんなもんじゃね？
ワンダのはちゃんと明暗順応までやってんのが偉い。
効果的だったかは微妙だと思うけど…。

**603** · 2006/07/17(月) 11:02:29

>>604-606
ありがとうございます。
とりあえずこの方法でやってみます。

**名前は開発中のものです。** · 2006/07/17(月) 11:38:59

本当にありがとうございます。

**名前は開発中のものです。** · 2006/07/17(月) 13:31:52

warning LNK4089: 'd3dx9_30.dll' へのすべての参照は /OPT:REF によって廃棄されます。
と警告がでました。どうすれば消せますか？

**名前は開発中のものです。** · 2006/07/17(月) 13:43:01

ほっといておｋ

**名前は開発中のものです。** · 2006/07/17(月) 21:01:12

xファイルを，テキスト，バイナリ，圧縮それぞれ相互変換させるプログラムを作成してます．
DirectXのAPI使ってます．

テキスト，バイナリファイルの書き出しは可能なのですが，圧縮ファイルの書き出しがうまくいきませぬ．
APIリファレンスによると，
CreateSaveObject(LPCSTR szFileName,DXFILEFORMAT dwFileFormat,LPDIRECTXFILESAVEOBJECT* ppSaveObj)
関数を使用して，第２引数をァイルフォーマットの値を論理和，つまり，テキスト圧縮なら3, バイナリ圧縮なら2を与えているのですが，
通常のテキストファイル，バイナリファイルが書き出されてしまいます．原因がまったくわかりません．