■過去ログ置き場に戻る■ 1- 前250 次250 最新50


[memo] "9999999999_00.html#R20" という感じで、URLの最後に "#RレスNo" を追加すると幸せになれます。

鬱だ氏のう DirectX (Part 15)
251 名前:デフォルトの名無しさん :2005/03/29(火) 18:19:30
>>248
あれは24bitグレースケールでやってる

252 名前:デフォルトの名無しさん :2005/03/30(水) 15:30:09
1人1回しか死ねないだろ

253 名前:デフォルトの名無しさん :2005/03/31(木) 20:44:28

おい、まだ4月じゃないだろ・・・

254 名前:デフォルトの名無しさん :2005/03/31(木) 22:08:13
明日リリースしたら、誰も信じないからだろう

255 名前:デフォルトの名無しさん :2005/04/01(金) 00:05:06
ゲイツに翻弄されっぱなしの今日この頃、皆様いかがお過ごしでしょうか。

256 名前:デフォルトの名無しさん :2005/04/01(金) 00:10:56
DirectX 9.0d(April 2005)

257 名前:デフォルトの名無しさん :2005/04/01(金) 00:11:38
>Microsoft DirectPlay は不適切となっており、新しいアプリケーションを開発する際それを使わないことを、
>Microsoft は強く推奨します。その代わり、拡張された Microsoft Windows ネットワーク テクノロジを、ゲーム開発者は使うべきです。

この「拡張された Microsoft Windows ネットワーク テクノロジ」ってなに?

258 名前:デフォルトの名無しさん :2005/04/01(金) 00:13:18
>>257
winsock

259 名前:デフォルトの名無しさん :皇紀2665/04/01(金) 00:43:01
レスのない>>258の為にage

260 名前:デフォルトの名無しさん :皇紀2665/04/01(金) 12:31:15
>>249
どこでオンにできるのですか?

261 名前:デフォルトの名無しさん :int 2ch =05/04/02(土) 11:11:18
プロジェクトのプロパティ、C/C++ > 出力ファイル のアセンブリの出力を/FAcsにしたまえ。
.objファイルと一緒にアセンブリャーコードを出力してくれるようになる。

262 名前:デフォルトの名無しさん :2005/04/03(日) 02:40:15
>>257-259
WindowsNTのことだろ?

263 名前:デフォルトの名無しさん :2005/04/04(月) 09:47:27
あれ、ゲ製板のDirectXスレ落ちた?
総合スレが落ちる程度の勢いなのか・・・

264 名前:デフォルトの名無しさん :2005/04/04(月) 10:06:31
>>263
無事1000までいきました
誰か次スレ・・・といってる間に

265 名前:デフォルトの名無しさん :2005/04/04(月) 14:16:35
>>264
勘違いだったか、ありがとん
立てても良いけど、ログないからテンプレわからないや…

266 名前:デフォルトの名無しさん :2005/04/04(月) 15:40:41
>>265
DirectX総合スレ (Part3)
http://makimo.to/2ch/pc8_gamedev/1105/1105333209.html

267 名前:デフォルトの名無しさん :2005/04/04(月) 17:51:30
>>266
俺の予想に反して、Apacheのドキュメントが見えている件について

268 名前:デフォルトの名無しさん :2005/04/04(月) 23:01:57
俺の予想に反して、次はMay2005

269 名前:デフォルトの名無しさん :2005/04/05(火) 08:23:20
>>265
テンプレ、過去ログはここで見られる

GamDevPukiWiki - DirectX総合スレ
http://gamdev.org/w/?%5B%5BDirectX%C1%ED%B9%E7%A5%B9%A5%EC%5D%5D

270 名前:デフォルトの名無しさん :2005/04/08(金) 13:11:43
最新のSDKに MFCFog サンプルが含まれていないってのは
MFCとの共存にはやっぱいろいろと問題あるってことすかね。

271 名前:デフォルトの名無しさん :2005/04/09(土) 03:21:31
>>270
つか、たかがFogにあんなサンプルいらんw
ビジュアル的におもしろいものか本当にサンプルの役割をはたしてくれるものか
どっちかにしぼれよって感じのツッコミくらったんじゃねぇの?

272 名前:デフォルトの名無しさん :2005/04/09(土) 03:25:50
Fog のサンプルって何がやりたかったんだろうな
付属のヘルプの方が簡潔にまとまってて100倍分かりやすい感じだったし

273 名前:デフォルトの名無しさん :2005/04/09(土) 08:39:47
シェーダでいろんなフォグの実装と紹介で何種類も出せば初心者には十分有益だが

274 名前:デフォルトの名無しさん :2005/04/09(土) 15:44:32
今日びのゲームは、遠景(空とか)もしっかり描かれてるから
特定の色へしか補間できないハードウェアフォグでは
うまく馴染ませにくい希ガス。

275 名前:デフォルトの名無しさん :2005/04/09(土) 20:30:44
>>274
へー(´・∀・`)
じゃあ君のやり方どんなん?

276 名前:デフォルトの名無しさん :2005/04/09(土) 23:22:17
>>274じゃないが、
フォグの色のアルファを0にするとか。現実じゃありえないけどね。

ドラクエ8の船とかラーミアのシーンみたいな。

277 名前:デフォルトの名無しさん :2005/04/10(日) 00:41:07
へー(´・∀・`)


278 名前:デフォルトの名無しさん :2005/04/10(日) 04:28:40
Reset したら DrawPrimitive が失敗する...というバグに悩まされていたが、
単に FVF を再設定し忘れてただけというアホなミスだった... orz

279 名前:デフォルトの名無しさん :2005/04/10(日) 09:45:59
開発ツールでDirect3Dを使ってます。
ツールバーにカーソルを乗せてツールチップを出だけでとフレームレートが極端に落ちます。(7FPSくらい)
メインのOnPaintのタイミングで描画、BeginScene〜EndSceneの間なにも描画せずに普段は75FPSです。
解決法ありますか?


280 名前:デフォルトの名無しさん :2005/04/10(日) 11:54:59
すごい開発ツールですな

281 名前:デフォルトの名無しさん :2005/04/10(日) 12:39:09
理解不能

282 名前:デフォルトの名無しさん :2005/04/10(日) 12:55:32
>>279
MFCつかってっからだ。

283 名前:デフォルトの名無しさん :2005/04/10(日) 18:03:20
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと
ツールチップを出だけでと


284 名前:デフォルトの名無しさん :2005/04/10(日) 20:30:06
もういいよバカどもめ。
DirectX Mailing List Archiveの"Layered windows and full-scene antialiasing"によると
XPでマルチサンプルだと起こるってさ。



285 名前:デフォルトの名無しさん :2005/04/25(月) 23:28:58
レスのない>>284のためにage


286 名前:デフォルトの名無しさん :2005/05/03(火) 16:44:02
このスレの話題でいいのか微妙ですが、
nVidia SLIたんとDirectXプログラムについて気になったことがあるので、教えてエロイ人。

1.
「計算量の多いピクセルシェーダを使って、それなりに広い範囲への描画を行う
(=ピクセル数が多く、しかもそれぞれのピクセルでのシェーダ演算量が多い)」
なんて場合、SLIを使っていると高速化されやすいんでしょうか?
SLIによってシェーダユニット数が増えた状態になると考えると、
かなり高速化されやすい問題だと思うんですが、どうなんでしょう?

2.
SLIをOFFにした状態だと、DirectX Graphicsから二枚のビデオカードをちゃんと弄れるんでしょうか?
CreateDeviceの第一引数をちゃんといじってやれば、
それぞれのビデオカードを個別にコントロールできるような気がするけど、どうなんですかね?

SLIなマシンを持っていればさくっと実験できるんですが、
持っていないのでわかりません。

287 名前:デフォルトの名無しさん :2005/05/03(火) 18:38:02
そもそもPCI Expressなんてものがあることすら知らなかった。
俺に説明は不可能。
AGPも無くなるのか・・・。

エロイ人パス。

288 名前:188 :2005/05/03(火) 22:04:21
昨日ふと思ったんだけど、>>188 の原因は DrawString or スプライトじゃなくて更新のタイミングだったのかも……

289 名前:188 :2005/05/04(水) 19:10:18
わるい。今回 Font.DrawString 使ってなかったから全然違ってたみたい。
っていうか MDX は微妙にスレ違いな気分ですが勘弁です m(_ _;)m

======

// TextMetrics はココで取得しておく
Graphics g = owner.CreateGraphics();
IntPtr hdc = g.GetHdc();
IntPtr hFont = font.ToHfont();
IntPtr bHObj = NativeFunction.SelectObject(hdc, hFont);
NativeFunction.GetTextMetrics(hdc, ref tm);
NativeFunction.SelectObject(hdc, bHObj);
NativeFunction.DeleteObject(hFont);
g.ReleaseHdc(hdc);
g.Dispose();

======

今回のは、Device.BeginScene 〜 EndScene の間、Sprite.Draw2D の直前に↑が入っていると起きました
…… これから家帰ったら、詳しい原因調べときます

290 名前:188 :2005/05/05(木) 18:33:16
判明

Graphics g = owner.CreateGraphics(); 
NativeFunction.GetTextMetrics(hdc, ref tm); 
g.Dispose(); 

この3行のコメントアウトで正常動作

……大本の原因、やっぱり判らんから、とりあえず描画に直接関わる物以外は
BeginScene 〜 EndScene 外で行うようにするよ

スレ汚しスマソ

291 名前:デフォルトの名無しさん :2005/05/08(日) 02:12:35
CreateAdditionalSwapChainでフルスクリーンとウィンドウを共存させる事は不可能?
D3DERR_INVALIDCALLで作成失敗してしまいます。

ヘルプ見ると、
「どのようなデバイスでも、サポートできるフルスクリーン スワップ チェーンは 1 つだけである。」
と書いてあるが、これはフルスクリーン一つとウィンドウでも駄目って事かな・・・。


具体的には、ツール用途でスワップチェーンを使った複数のウィンドウを表示して、
ゲーム開始時にだけフルスクリーンに切り替えたいのですが、
この場合はデバイスを作り直すしか無いのでしょうか?


292 名前:デフォルトの名無しさん :2005/05/10(火) 21:40:54
>>291
フルスクリーンとウィンドウェドの共存は無理。

そのルーティンなら、ゲーム開始時には
それまでのスワップチェーンを全て開放したあと、
フルスクリーン用のパラメータでデバイスをリセットするべし。

293 名前:デフォルトの名無しさん :2005/05/12(木) 07:10:00
D3DXUVAtlasCreateのサンプルってどこかにない? ぐぐってもでないよ

294 名前:デフォルトの名無しさん :2005/05/17(火) 21:22:04
SetDisplayModeで解像度を変更し、アプリケーションを終了すると
デスクトップに最大化しておいておいたプログラムのWindowが
SetDisplayModeで変更した大きさになったままになってしまいます。
さらに一度それを最小化してもとにもどしてみるとタスクバーを無視して
(つまりWindowの枠がタスクバーの下まで入り込む)広がってしまいます。

一応googleで検索してはみたものの解決策は見つかりませんでした。
解決策があれば教えてください。

295 名前:デフォルトの名無しさん :2005/05/17(火) 21:47:47
GetWindowPlacement

296 名前:デフォルトの名無しさん :2005/05/18(水) 02:45:44
はぁ?それだけじゃわかるわけないだろ。
小学生の時習わなかったか?
単語を言うだけじゃ会話は成立しねぇの。

297 名前:デフォルトの名無しさん :2005/05/18(水) 03:44:56
ものすごい悪質な悪戯を思いつきました
http://etc3.2ch.net/test/read.cgi/entrance/1116269436/

298 名前:294 :2005/05/18(水) 10:41:03
>>295
つまりどうしようもないと…

299 名前:デフォルトの名無しさん :2005/05/18(水) 11:07:43
EnumWindows()?

300 名前:294 :2005/05/18(水) 12:57:17
つまり起動時に全部Windowを列挙して状態を保存して
終了時に全部元に戻せと?

301 名前:デフォルトの名無しさん :2005/05/18(水) 12:58:31
それで何か不都合があるのか?

302 名前:デフォルトの名無しさん :2005/05/18(水) 16:08:32
>>300
難しそうに聞こえるかも知れんが、結構簡単に書けるよ。
ちょっとつまづくのは、ディスプレイには表示されていないけど
内部ではハンドルだけ存在するように見えるウィンドウがかなりあるから、
そいつらをどうやってふるい落とすか、くらいかな。

>>295とか>>299のキーワードで少し調査すれば資料はまあまあ見つかるからがんばれ。

303 名前:294 :2005/05/18(水) 19:46:52
>>301
いや特に不都合は無いけれどDirectXさんが
勝手にやってくれないのかなぁと思っただけです。

>>302
thx。適当に調べてやってみます。

304 名前:デフォルトの名無しさん :2005/05/24(火) 08:21:20
http://www.sankei.co.jp/news/050523/kei085.htm

以前このスレで冗談扱いされたDirectSmellが
とうとう現実となるのか?w

305 名前:デフォルトの名無しさん :2005/05/24(火) 08:46:36
ウンコの匂いを出すウィルスとかできそうだな。

306 名前:デフォルトの名無しさん :2005/05/24(火) 23:08:15
SPAMスメル

307 名前:デフォルトの名無しさん :2005/05/25(水) 00:10:30
>>305-306
以前話題になったときと全く同じ反応の仕方だな
このスレ住人の視野の狭さが覗えるよ

308 名前:デフォルトの名無しさん :2005/05/25(水) 05:50:39
実は中の人が同じだったとか

309 名前:デフォルトの名無しさん :2005/05/25(水) 21:45:56
>>307
以前話題になったときと全く同じ反応の仕方だな
このスレ住人の視野の狭さが覗えるよ

310 名前:デフォルトの名無しさん :2005/05/25(水) 22:36:38
AddDirtyRect……なんとなくカッコイイ感じがした漏れは病んでるのだろうか……
なんに使うのかは知らないが

311 名前:デフォルトの名無しさん :2005/05/25(水) 23:14:09
>>305
次は DirectTaste である、に一票。

312 名前:デフォルトの名無しさん :2005/05/26(木) 06:33:26
DirectX9のテクスチャーの使い方に関して質問します。USAGE, FVF(Format), POOLの指定の中で、特に POOL(メモリクラス)
に関して、xx_MANAGED(管理してもらえるテクスチャ) と、xx_DEFAULT(動的!)
をよく使うPOOLとして指定するのですが、その使い分けに関して、一つ疑問があります。

動的、といった場合、度のレベルから動的で、どこまでは静的な使い方などでしょうか(特に時間的な意味で...)。
例えば、起動時に画像ファイルから作ったテクスチャーをそのまま
使い続けるのは、a)静的な使い方だとして、他に

b)ポップアップメニューとかダイアログとかで、ユーザーの指定があって
初めて、画像の一部に書き込みをする場合
:: 大雑把に見て、数分ー数十分に一回の書き込み。

c)数秒ー数十秒くらいに一回、マウスイベントとかで光らせたり 色を少し変更するために、画像の一部に書き込みをする場合

d)フレーム毎、つまり、例えば 60fips/sec の場合、毎秒60回も
書き込みをする場合
Lock/Unlockとか、頂点/ピクセル シェーダ経由の書き込みで、
これだけは、動的であると、私も認めているのですが

b),c)の書き込み頻度では、コード作成を少しでも楽にすることを
考えると、できれば xx_MANAGED で作っておきたいのですが
(...ウインドウ リサイズ毎に作り直さなくてもいいため。)

ただし、xx_DYNAMICのテクスチャーは、ほぼ必然的に xx_RENDERTARGET
として使われることになり、そうすると、::GetDCがつかえないため、
不便だな、と思うのです。
( GetDC や、::GetDC は、DirectXの使いづらさを補填する、といった意味で
利用価値はある、と思っていますので。)

313 名前:デフォルトの名無しさん :2005/05/26(木) 06:54:46
MANAGEDで作ったテクスチャーは ::GetDCが使えます。
従って、GDIを使って描画ができ、後でそれをテクスチャとして
使うことができます。
但し、SetRenderTargetでレンダリングターゲットに指定できないため、
DirectXでの描画はできません。

他方、DYNAMIC(動的) であり、RENDERTARGET指定した動的な
テクスチャは、::GetDCができないため、GDIでは描画できません。

GDIはBltさえしなければ、そんなには遅くないと思うのです。
(日本語)文字描画とかは、比較的楽にできます。

DirectXなら、グラディーションのかかった2Dボタンを描画
するのは簡単ですが、GDIだと、MoveTo / LineTo で色を変えつつ
描画するのが面倒です。

(MANAGED と、DYNAMICを )
両者を、使い分けたいのですが、どうやら、排他的な制約が
あるようです。GDI描画 vs DX9描画 としてとらえた場合...

一度 DX9で描画し、Present した直後に、Win32APIのGetDC は、
フロントバッファー部に対して使えるので、それでメモリ上の
デバイスコンテキストに転送後、DirectXでテクスチャーに再設定
し、以後はそれをしばらく使う...と言うような方法は、考えても見ました
が、どうも面倒で...

314 名前:デフォルトの名無しさん :2005/05/26(木) 07:16:15
すいません、誰か返事をしてくれると思っていたのですが、
どなたも書き込んでくれないようなので、少し時間を開けたいと思い
ます。
というのは、私のPCが、どうやらだいぶ熱っぽくなってきて、
もうすぐ CPUが60度以上になって使えなくなりそうなので...
一度、Web接続を切り、しばらくPCも電源を落として、休ませよう
と思います。
(オーバーヒートで)ケースがピーピー鳴りだすのも、時間の
問題のようですので。
せっかく初めて2chanに書き込めたのに、今日は私は運が悪かった
ようにおもいます。
後でまた覗いてみます。

315 名前:デフォルトの名無しさん :2005/05/26(木) 07:32:32
一文字目から読んでないが
とにかく必死なのはよく分かった

316 名前:デフォルトの名無しさん :2005/05/26(木) 07:41:07
あ、返事してくれたヒトがいる、ありがとう。

317 名前:デフォルトの名無しさん :2005/05/26(木) 07:52:43
象形文字が上に描かれている2Dグラディーションボタンを、画像として10個くらい保持しているとします。
画像タイプは.bmp, テクスチャ作成時の指定サイズは、256x256
とします。
それらのボタン上の文字の色は、一つ一つ違い、背景色も
少しずつ違うとします。
そのようなボタンをマウスでフォーカスして背景のグラディーション
だけ、少し色を変え、象形文字部は色を変えたくないとします。

そのようなケースでは、α合成で別ポリゴンを使って加算合成
による描画というわけにはいきませんから、画像のサーフェス
自体に描画したいわけです。

画像のサーフェスを何らかの方法で描画可能な状態にし、
次に少し色の変化したグラディーションボタンを一個上から
描画し、
最後に、文字部分以外はα=0(透明)な 象形文字スプライトを
そのボタンの上に重ねたいわけです。

なおかつ、それを1秒間に60回もやるのは、面白くないため、
更新された画像としてまとめて更新し、以後は一枚の矩形として
10数個のボタンをもったフレームのようなものとして
描画するようにしたいわけです。

それ以後も、イベントのあった時だけ描画を切り分けて対応し、
描画処理を最小限に押えたいわけです。



318 名前:デフォルトの名無しさん :2005/05/26(木) 07:53:42
象形文字が上に描かれている2Dグラディーションボタンを、画像として10個くらい保持しているとします。
画像タイプは.bmp, テクスチャ作成時の指定サイズは、256x256
とします。
それらのボタン上の文字の色は、一つ一つ違い、背景色も
少しずつ違うとします。
そのようなボタンをマウスでフォーカスして背景のグラディーション
だけ、少し色を変え、象形文字部は色を変えたくないとします。

そのようなケースでは、α合成で別ポリゴンを使って加算合成
による描画というわけにはいきませんから、画像のサーフェス
自体に描画したいわけです。

画像のサーフェスを何らかの方法で描画可能な状態にし、
次に少し色の変化したグラディーションボタンを一個上から
描画し、
最後に、文字部分以外はα=0(透明)な 象形文字スプライトを
そのボタンの上に重ねたいわけです。

なおかつ、それを1秒間に60回もやるのは、面白くないため、
更新された画像としてまとめて更新し、以後は一枚の矩形として
10数個のボタンをもったフレームのようなものとして
描画するようにしたいわけです。

それ以後も、イベントのあった時だけ描画を切り分けて対応し、
描画処理を最小限に押えたいわけです。

319 名前:デフォルトの名無しさん :2005/05/26(木) 08:05:54
何故か、二重にかかれてしまいました。
Linuxから書き込んでいます。以前は、Windows(98)の方から
Webアクセスしていたのですが、"WebSiteViewer"とかいう
ワームだかウイルスにやられてしまい、一度システムを事実上ダウン
させられてしまいました。それ以後、(デュアルブートしている)
Linuxの方からWebアクセスしているのですが、文字入力
の使い勝手が良くありません。そのためか、手違いしたようです。


320 名前:デフォルトの名無しさん :2005/05/26(木) 08:46:58
>レンダー ターゲットの IDirect3DSurface9::GetDC は、ターゲットがロック可能でない限り
>(バック バッファの場合は D3DPRESENTFLAG_LOCKABLE_BACKBUFFER フラグを指定して作成されていない限り)
>失敗します。
ヘルプでは使えるみたいなことほざいてるけど。
試していないんでなんとも言えんが。

つーか、D3DPOOL_DEFAULTリソースとD3DPOOOL_MANAGEDリソースを混合して
使う場合、DEFAULTを先に確保して次にMANAGEDを確保しなきゃならないっつー
なんだかよくわからない決まりがあるんだろ?
でも実際こんな管理不可能だよな?MANAGEDをひとつでも作ったら、
次にDEFAULT作れなくなっちまうんだから。
逆に言えば、ひとつでもDEFAULTを使うようなプログラムなら、自前でロスト管理する
機構は必ず必要になる訳で、MANAGEDが使えなくて困るっつー状況にはなりにくいとも。
ツー訳でMANAGED使わない方向を俺は支持する。

321 名前:デフォルトの名無しさん :2005/05/26(木) 08:58:31
>DEFAULTを先に確保して次にMANAGEDを確保しなきゃならない
...そうなのですか? 知りませんでした。

MANAGED な管理可能テクスチャーは10数枚くらい、2D/3D用に確保し、
DYNAMIC な動的テクスチャーは、後で必要になった時に 3D用に
一つだけ後から確保しよう、とか考えていたのですが...

>MANAGEDをひとつでも作ったら、次にDEFAULT作れなくなっちまう
...仮に、DEFAULT を1つ そしてその後でMANAGEDを10枚の順序で
作成したとして、実行時にDEFAULTテクスチャーが、とりあえずしばらく
必要なくなったから、Releaseし、またしばらく後で必要になったから
再び、DEFAULTテクスチャーを作成したいと思ったとしても、
できないことになるのですか?


322 名前:デフォルトの名無しさん :2005/05/26(木) 09:10:21
ttp://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/directx9_c/directx/graphics/programmingguide/usingdirect3d/devicesandresources/applicationmanagedresources.asp
>Microsoft Direct3D とアプリケーションの両方で管理するリソースを使うときは、
>アプリケーションが管理するリソースを D3DPOOL_DEFAULT メモリに割り当ててから、
>Direct3D が管理するリソースを作成する。
>これにより、メモリマネージャは利用可能なメモリの正確なカウントを維持できる。
これが何を言いたいのかは、はっきり言ってわかりかねる。
正確なカウントを維持出来ないとしてどの程度の影響があるのか?
多少効率が落ちるだけで済むのか、メモリリークが起こるのか、
俺は不確かなんで避けることにした。

また、YOUの象形文字なんたらは
俺だったらマルチテクスチャの加算合成で処理するな。
毎フレーム無駄ってのは、例えばpresentを減らすとか。

323 名前:デフォルトの名無しさん :2005/05/26(木) 09:13:04
DEFAULT(Usage) というか、DYNAMIC(Pool)と、ほぼつながっている
動的なテクスチャーに関しては、DX9の日本語マニュアルを読んだ
限りでは、アプリケーションあたり一つが望ましいというような
ニュアンスがありました。
..すなわち、いくつも確保するような使い方ではなく、ピンポイント
で、本当に動的に作成する必要があるときだけ使う、というような
ニュアンスです。
他方、MANAGED(管理可能な)テクスチャーは、どんどん使ってください
、但し、動的には扱いづらいですから...というような。

事実、MANAGEDでは、サーフェスロックとかは(CD3DFontでもやっている
ように)できるけど、描画サーフェスとしてのロックは、
RENDERTARGETに指定できないため、できない。だから、
::GetDC してBlt転送するか、あるいは、別のポリゴンに読みこま
せる、という方法くらいしか、画像を実行時に書き換える方法が
ないのではと、思います。

DYNAMIC + DEFAULT な動的テクスチャーは、描画ターゲットに
できるが、手軽に ::GetDCでロックする、と言うわけにも
行きません。
動的なリソースは、多分、ビデオカード上のメモリに保存される
のでしょうが、既に頂点バッファーとか、インデックスバッファー
でたくさん使っているので、そうたくさんは使えない、という
イメージがあるのですが。

管理リソースなら、ビデオカードとPC上のメモリ上とを
行き来できるから、そんなに負担にはならない、と思うのです。




324 名前:デフォルトの名無しさん :2005/05/26(木) 09:21:04
>また、YOUの象形文字なんたらは
俺だったらマルチテクスチャの加算合成で処理するな

..実は、そのことなのですが、
FinalColor = [ SrcColor*Alpha + DstColor*(1-Alpha) ]

としてしまうと、象形文字(テキスト入力できない文字)の文字の色
が、少しだけ変化してしまう はずなのです。

もし、象形文字がボタン10個とも、例えば黒なら、カラーキー
を D3DXCreateTextureFromFileEx(...); の10番目の引数に
0xff000000 // 黒 を指定して画像を読み込めば何とかなる
のですが、10種類のカラーキーは指定できないため、
α合成すると、少し象形文字に他の色が付いてしまいます。
...それをできれば避けたいのです。

そういう次第で、画像に直接、服数回に分けて部分描画したい
のです。

325 名前:デフォルトの名無しさん :2005/05/26(木) 09:52:17
>
無駄だと言っているのは、毎秒60フレームの描画回数のことでは
なくて、描画に必要なポリゴン数のことなのです。

もし、フレームにボタン10数個が収まったひとつのテクスチャなら、
一つの矩形ポリゴン、したがってトライアングル一枚分で描画は
終ります。頂点バッファーの大きさも少なくて済みます。
...仮にそれが、任意分割ウインドウのサブメニュー矩形だとすると、
ビュー枚数分の矩形をビューポートを切替えて描画するだけで済みます。

..もし、フレーム1枚+中身のボタン10数個*2(レンダリングパス)
を、分割ウインドウ分行うとすると、例えばアプリケーションのビューが
5分割されているとするなら、5*(1+10*2) =110 個の2D矩形を
描画しなければなりません(トライアングル数では、その2倍)。
..大した数ではないと言えば、そうかもしれませんが、αを有効に
したままであるし、2ー3回のレンダリングパスを使います。


はっきりいって、2D描画にあまり描画エネルギーを割きたくないのです。
本命は、(各任意分割ビューポート上)3Dオブジェクト群の描画
であると考えていますので、2Dコントロールは、簡単に描画を
してしまいたいのです。

仮に、ユーザーがおもしろがって、20個位にビューポートを分割しても、
サブメニューへの描画回数を少なく(各2ー3矩形くらい)に
したいのです。

326 名前:デフォルトの名無しさん :2005/05/26(木) 09:54:07
>5*(1+10*2) =110 個 ...105個でした。

327 名前:デフォルトの名無しさん :2005/05/26(木) 09:57:37
>ビュー枚数分の矩形をビューポートを切替えて描画するだけで済みます
...じつは、2Dでは、ビューポート切替えはしません。
Hole(全)クライアント座標を基準に2D頂点座標を ビューポート分保持しています。
...3Dオブジェクトは、ビューポート毎にカメラと射影行列を
切替えます(もちろん、ローカル/ワールド行列も)

328 名前:デフォルトの名無しさん :2005/05/26(木) 10:00:04
結論から言うと、PCからすれば
出来れば描画サーフェイスはロックして欲しくないんだよ。
D3Dは描画サーフェイスはロックにやさしくない。
だから、まずやらないで済ます方向で検討するのがいい。
どうしてもやりたければ>>323で挙げられたどれかでやるしかない。
俺なら別ポリゴンで間接的に描く方法を選ぶね。
VRAM的に難しいなら、D3Dをやめるよ。

>管理リソースなら、ビデオカードとPC上のメモリ上とを
>行き来できるから、そんなに負担にはならない、と思うのです。
管理リソースといえど制限は同じ。
内部的にシステムメモリとVRAM上の両方にテクスチャを作って
自動的に転送するってサービスをしてくれるだけ。
UMAならもっと効率のいい管理をしてくれるかもしれない。

>>324
意味がよくわからないが、正しいやり方をしてないっぽい。
背景色だけのテクスチャの上に文字のテクスチャを上塗りするってイメージで出来ない?







329 名前:デフォルトの名無しさん :2005/05/26(木) 10:20:34
>結論から言うと、PCからすれば
>出来れば描画サーフェイスはロックして欲しくないんだよ

..私も、そうではないか、と思います。

..但し...問題は、ロックの頻度によって事情が変わる、と言うことです。
"D3DPRESENTFLAG_LOCKABLE_BACKBUFFER"
という、使えそうにないフラグがありました。
使えない、と言うか、MSが推奨していない、と言うか...
だから、私は、これまで一度も使ったことはありません。
CopyRect系の処理に関しても、DX8-DX9では、使いません
(使えないようなデバイスしか作成していません)
例外は、文字描画のために GetDCを DX9から、あるいはDX9を介さない
で呼び、Blt だけはなるべく行わないでうまく処理することぐらいです

他方、テクスチャーのロックに関しては...
もしフレーム毎に(一秒に数10回も)ロックをするとしたら、これもやはり
適切な使い方ではないのでは、と思います。

でも、数秒 ー 数10秒に一度のロックなら、大きな負担には
ならないのでは、と思います。

330 名前:デフォルトの名無しさん :2005/05/26(木) 10:28:29
>俺なら別ポリゴンで間接的に描く方法を選ぶね

..私の方法も、一応別ポリゴンによる方法です。但し、
頂点色だけで描画できる部分と、どうしてもテクスチャー
(透明部分を持った象形文字などや、そのままイメージボタンのもの)
をセットして描画しなければ行けない部分との 組合せを
処理することになっているので、
個別描画 か 一括描画か、という問題を考えると、結局

"ボタン毎のテクスチャー矩形を、ボタンイメージ列から
それぞれテクスチャー座標を指定し、ボタンの数*フレームの数
だけ、一個ずつ ポリゴンに張り付けて描画する"

よりは、

"一つのテクスチャーにまとめておいて、(一つのポリゴンに
張り付けて)一括描画"
という方法が好ましい、と思うのです。

331 名前:デフォルトの名無しさん :2005/05/26(木) 10:45:58
どうやら、私が、ごちゃごちゃとまとまり無く書き込んだのが
行けなかったかも知れません。
...たびたびの返答に関して、感謝しています。

要は、DEFAULT(ないしはDYNAMIC)の画像データと、
MANAGED(管理リソース)の画像データとを、
お互いにやりとりする、効率のよい方法が知りたいのです。

今までの私の知識では、
一度フロントサーフェスに Present したイメージを、
"PrintScreen" 的な方法でゲットし、
管理テクスチャーを::GetDCし、やむを得ずBitBltでイメージを
転送したうえで、::ReleaseDCし、更新したテクスチャを使って
ポリゴンを描画する
、と言う方法です。
10数秒に一回しか行わないなら、全体としてのフレームレート
にも影響しませんし、
第一、アプリケーションが 終日 連続描画モードであり続ける
わけでもありません
(メニューボタンが光ったり、サブメニューを出すときとか、
3Dオブジェクトを動かすとき以外は、ワンフレーム描画です)




332 名前:デフォルトの名無しさん :2005/05/26(木) 10:50:50
余談ですが、私の使っているPCは、CPU冷却環境 が良くないためか、
夏場は1時間以上使えません。
これで、CPU使用率100%の DirectXを使ったゲームでもしようものなら、
15分で、PCが(温度が設定限度を越えたために)ピーピーなり出します。
そんなわけで、連続描画は、ゲームでは仕方が無いのかも知れませんが、
ゲームではないアプリケーションでは、なるべく控えたい、と
考えているのです。

333 名前:デフォルトの名無しさん :2005/05/26(木) 11:02:56
>328::どうしてもやりたければ>>323で挙げられたどれかでやるしかない
..それも、私です。

正直行って、はじめて 2chanのような掲示板システムに書き込んで
いるため、ハンドルネームは、名乗りたくないのです。
私は、今まで、オンラインの双方向システムに書き込んだことは、一度しかあり
ません。そのときは、チャットシステムであり、Windows98からの
アクセスでした。
掲示板に関しては、ReadOnlyでした。
正直行って、Webシステムを信頼仕切っていないのです。
...OSといい、httpアクセスの仕組みと言い、...無限のバグやウイルスといい..
...便利なのは間違いないのですが。

でも、どうしても書き込んで質問したかったので、書き込んでみました

334 名前:デフォルトの名無しさん :2005/05/26(木) 11:17:51
>328
>>324
意味がよくわからないが、正しいやり方をしてないっぽい。 背景色だけのテクスチャの上に文字のテクスチャを上塗りする
ってイメージで出来ない?

...背景色だけのテクスチャには、グラデーションボタンの
イメージが10数個並んでいますが、そのうちの一つの領域を
マウスでセレクトしたため、グラディーション色を少し明るくする必要ができました。

したがって、まず、そのボタン領域に新しいグラディーション
を、別に用意したポリゴンで Add描画します。

次に、その上から、スプライト形式に透明度を持った象形文字
のポリゴンを、αで補間して加算描画します(当然象形文字部
以外は、α=0 なので、グラディーションに象形文字を重ねた
ボタンが一個描画完了です。)

以上の手順が、私のいう "(A)一個一個、いちいち描画する"という、ポリゴン数の多い手順のことです。

その手順は、一度っ切りにして、presentした直後に、
ボタン10数個のはいったフレーム[0..n]毎、どこかの
テクスチャへ読み込み、こんどは、それを使って一括描画したい
、と言うのが、私のいう "(B)一括描画" の方法です。

(A)の方法では、フレーム枠+ボタン数*(グラデーション+象形)
を、そのメニューバーの数だけ繰り返すので、
描画矩形(トライアングルが2枚)の総数は、メニューバー=5本
とすると、 5 * ( 1 + 10*2 ) = 105 枚の矩形数です。

(B)の方法だと、 5枚 の矩形数で済みます。



335 名前:デフォルトの名無しさん :2005/05/26(木) 11:21:53
誤り >したがって、まず、そのボタン領域に新しいグラディーション
を、別に用意したポリゴンで Add描画します

正確 >したがって、まず、そのボタン領域に新しいグラディーション
を、別に用意したポリゴンで 上塗り描画します

336 名前:デフォルトの名無しさん :2005/05/26(木) 11:34:50
私の考えでは、今のところは、
テクスチャーに、3つの私的リソースクラスを用意するのです。

1) ボタンを一個一個描画するための、ボタン領域を並べたテクスチャー
2) メニューバー一本を更新描画するときに、仲介のために使う
テクスチャー
サブメニュー矩形領域とかも、置いておく
3) メニューバーを本数単位で描画するための、テクスチャー

1)は、DirectXでポリゴンに張り付けるために使用しますが、
GDIからもアクセス可能です。

2)のイメージは、BitBltの Dstであり、Srcでもあります。
DirectXからも、アクセス可能です。

3)は、最も効率の良い、メニューバー単位の描画のためのテクスチャー
ですが、何らかのイベントがあるたびに、イメージを更新する必要があります。
DirectX用のポリゴンに張り付ける前に、2)のイメージからBitBltの
Dst(転送先)になることもあります。

337 名前:デフォルトの名無しさん :2005/05/26(木) 12:02:51
xx_SYSTEMMEM や、xx_SCRATCH のようなメモリクラスを使い、
xx_DYNAMIC なメモリクラスにUpdateSurfaceする、という使い方
は、以上の2点で、問題があると思っていました。
したがって、最初から考慮外なのです。

1) ( SYSTEMMEM, SCRATCH は、)
転送がかなり遅い。おそらく、描画もスムーズでない。
ドライバ側からの管理もしてもらえない
それならGDI描画とかわらないではないか?

2) DYNAMIC な 動的テクスチャーを 転送先として、
2D描画用に作らないと行けない。それなら、直接
レンダリングターゲットにして描画してしまった方が
いいのでは?

338 名前:デフォルトの名無しさん :2005/05/26(木) 12:04:45

>は、以上の2点で、問題があると思っていました

>は、以下の2点で、問題があると思っていました

339 名前:デフォルトの名無しさん :2005/05/26(木) 20:42:03
DirectX初心者質問スレでまともに答えが返ってこなかったのでこちらでも質問させてください

諸事情でWin32APIを使うことが禁止されています
DirectInputの機能だけでマウスの現在のクライアント座標を調べる方法はありますでしょうか?

340 名前:デフォルトの名無しさん :2005/05/26(木) 22:33:15
ない

341 名前:デフォルトの名無しさん :2005/05/26(木) 22:40:02
無いのですか
ありがとうございました

342 名前:デフォルトの名無しさん :2005/05/28(土) 07:54:04
頂点バッファーや、インデックスバッファーの最適なサイズは、
どのくらいのものでしょうか?
例えば、
頂点ストライドは、 sizeof(myVERTEX_t) が40バイト、
インデックスに関しては sizeof(WORD) で 2バイト
だけをつかうとします。

頂点バッファーを、65536*sizeof(myVERTEX_t) で10本割り当て、
インデックスバッファーは 65536*sizoef(WORD)でやはり10本
割り当てます。

頂点バッファーは、いくつかのクラス(身分)で扱います。
1) 4096頂点までのサブエリア * 16 を格納するVBを一本
2) 8096頂点までのサブエリア * 8 を格納するVBを一本
3) 4096*4 頂点までのサブエリア * 4 を...(同上)
4) 4096*8 頂点までのサブエリア * 2 を...(同上)
5) 4096*16 頂点、つまりVBまるごと一本あつかう
6) VB*2本を、virtualに一本のVBとして、アプリケーションで扱う
= VB 1本*2
7) 以上のいずれかを、必要なときにサポートするリザーバーVBを数本

以上のようなかんじで、(IBも同様に)頂点バッファー/インデックス
バッファーを扱おう、と考えていたのですが、

65536というユニット数は、妥当なのでしょうか?
それとも、多すぎて、描画速度に描画速度に影響するのでしょうか?
あるいは逆に、もう少し(もう数倍くらいまでは)まとめてしまって
、つまり、n=3ー4 として, 65536*n*siziof(myVERTEX_t)
でそれぞれのVBを作ってしまっても良いのでしょうか?

343 名前:デフォルトの名無しさん :2005/05/28(土) 07:54:29
VBをサブエリアに分けたのは、そのサブエリアが、一体のオブジェクト
( より正式には、シェル(殻) ) に相当するからです。

オブジェクトあたりのトライアングル数(と言うか、頂点数)が少ない
内は、最高4096頂点 まで格納できるサブエリアとして領域を確保します。
( あらかじめ65536頂点の領域を空データで割り当て、オブジェクト生成
ごとに、Lock / Unlockしてデータを4096vtx ずつ割り当てる)
そして、数対のオブジェクトを 一本のVBにまとめ、描画のときは、
DrawIndexPrimitive の引数のうち、開始インデックスや 必要頂点総数
をオブジェクト毎に調整して 描画します。

そのようにするメリットとしては、同一の VBであるため、
SetStreamSource(...); をオブジェクト分呼ぶ必要は無く、一回で
済むことです。
私の恐れるのは、反対に、むしろSetStreamSourceで
オブジェクト分切替えて(むろんVBをオブジェクト毎に作成して)
描画した方が 処理が早くなるかも知れない?と言うケースです。

後者の場合、サブエリアをまとめるべき最適なVB長(65536より低い値)
を模索することになるのですが...
あるいは、VBは、オブジェクトごとに割り当てるものだと割り切る
ことになるのですが...

344 名前:デフォルトの名無しさん :2005/05/28(土) 08:05:37
少ない頂点数のオブジェクトでも4096頂点ものサブエリアを割り当てる理由
は、それが動的に変更されるからです。とくにIB(インデクスバッファー)
は、かなり頻繁に(数秒ー10数秒位に一回くらい)変更されます。

場合によっては、サブエリアのクラス(身分)が上昇し、別の
VBにエントリ(収まるサブエリア)を変更するケースもあります。

特に、最も頂点数の多くなるオブジェクトのケース
(ex. CatMull-Rom法 などで 再帰分割されたオブジェクト)では、
VBを跨いで使うため、一体のオブジェクト描画にもかかわらず、
2回くらいSetStreamSourceします。

345 名前:デフォルトの名無しさん :2005/05/28(土) 08:12:02
>344
かなり頻繁に変更されるのは、VB(やIB)の サブエリア内部での
"内容(データ)" であって、もちろん VBやIBを作り直すのではありません。
VB/IB を 1)部分Lock して 2)直接1頂点を書き換えたり、あるブロック
に対して更新データをmemcpy(dst, src, k); し、3)部分Unlock
...そのあとにはDrawIndexPrimitive を読んで描画し、Presentする
と言う手続きが、アプリケーションのステート次第では、数秒くらいに
一度行われる、と言うことです。


346 名前:デフォルトの名無しさん :2005/05/28(土) 09:41:46
DirectPlay使うなって書いてあるが
それは要するにWinSock使ってフルスクラッチで書けよバーヤってことか。

347 名前:デフォルトの名無しさん :2005/05/28(土) 10:29:01
GetCursorPosもScreenToClientも禁止な諸事情って何よ

348 名前:デフォルトの名無しさん :2005/05/28(土) 12:44:24
サブエリアとかなんて君のエンジンの独自仕様だろうから、なんとも分からんなあ。

頂点バッファのパフォーマンスが高ければそれに越したことはないけど
最終的なパフォーマンスに絶対的な影響をするとは限らないから、エンジンとしては
柔軟になんでも放り込める設計で、65536使えることは使えるけど、
データを作る側にどれくらいの分量にするかという指針に従わせれば?

経験的には、staticなバッファでシェーダ以外で弄らない地形で、
視野クリッピング・同属性ソート・優先度ソートを経るとして、
1描画単位は4096頂点に収まることがほとんどだけどね。



349 名前:デフォルトの名無しさん :2005/05/28(土) 13:10:28
ゲームのためのオブジェクトでしたら、確かに
最終的には少ない頂点で、なおかつ現実感溢れるLook & Feel を得る
のに、4096頂点以上使うことは、まれだと思います(あっても数個以内)

私は、モデリングソフトウエアのようなものを想定しているのです。
最初は格子(立方体:正味8頂点)で始まるオブジェクトも、
モデリングを繰り返すたびに、頂点やカーブやサーフェスを編集するため、
更に、ある程度形のまとまったオブジェクトに対し、再帰分割を
分割レベル=2、3 くらいでやった場合、ソリッド面として使われる
トライアングルは、あっと言う間に10万頂点位を必要とするレベル
までに増加します。
上記の再帰分割とは、DirectXの NパッチやRTパッチ以外の、ソフトウエア
による実装であり、Cat-Mul Rom とか、Nurbs や B-Spline 等の
その他いくつかの再帰分割手法によるものです。ゆえに、アプリケーション
側で、頂点とインデックスを管理し、生成、追加、削除する必要が
あります。

もっとも、基本プリミティブのような物体(球、立方体、コーン、円柱
、トーラス, etc...) などは、分割や変形が極端に行われない限り、
(そもそも、和規約として使われているため ) 4096頂点ですら越える
ことは無い、と見ていますが。

要は、UINT_MAX + 1 ( = 65536 ) もの要素サイズだと、ひょっとして
VertexBuffer9 や、IndexBuffer9が、保存する頂点配列が
大きすぎるために、GPUエンジンにとって負担となるのではないかなあ?
と危惧しているわけです、(GPUエンジンで内部的に使用する
キャッシュ効率 とか、メモリ同士の転送とか 、ハードウエアの実装は
あくまで、想像レベルに留まらざる終えないのですが。)

350 名前:デフォルトの名無しさん :2005/05/28(土) 14:07:15
頂点シェーダも、インデックスシェーダも、しょせん
エフェクトに過ぎないと私は考えています。
私のもつ、VS / PS に対する評価は、
ネオンのきらめく繁華街に遊びにいって、帰って来た後のむなしさ
のようなものです。
確かに、ヒト昔まえまではハイエンドのグラフィックスワークステーション
でしか、用いられなかった技術が、そしてそれ以上の技術が、
一般のプログラマーや、一般大衆に開放されたことは、多いに評価
してしかるべきだとは、おもいます。
商業上でも、おもにゲーム業界では、多いに活躍していることでしょう

でも、肝心のことは何もできない、扱わない、それが VS / PS
だと私は考えています。

SGI や MS や Nvidia などが言っている、グラフィックスパイプラインとか、
レンダリングパイプラインと言うものは、私にとっては、一本では
ありません。後3本くらいあります。
そのうちの、最初の一本がほとんどハードウエア化され、高速化されても、
しょせん "エフェクト"なのであるから、
残りの3本のパイプラインは、アプリケーション側でソフトウエア的に
実装する必要があります。

351 名前:デフォルトの名無しさん :2005/05/28(土) 14:09:19
>>350
もうちょっとちゃんと勉強しようね。

352 名前:デフォルトの名無しさん :2005/05/28(土) 14:10:20
間違えました。
X> 頂点シェーダも、インデックスシェーダも
O> 頂点シェーダも、ピクセルシェーダも

353 名前:デフォルトの名無しさん :2005/05/28(土) 14:13:38
つうかVertexBuffer使わなきゃ万事OKじゃん。


354 名前:デフォルトの名無しさん :2005/05/28(土) 14:43:01
decl[]で宣言し、D3DXMESHでやる、ということですか?

D3DXMESHは、トライアングルを扱うのに、あるいは xファイルを
扱うのに、最適化されたオブジェクトです。

トライアングルに関して、隣接構造を持っていますが、それは
(少なくとも、私の扱う分野においては)不完全な隣接構造です
もちろん、継承元の親クラスのソースコードは公開されてませんから
想像でモノを言っていますが、すくなくとも位相変形ができない
(幾何変形は、コーディングしだいでできるが、位相変形を扱うと苦しい)
と言う意味で、不完全な隣接構造です。

頂点バッファーを扱わず、さらに、メッシュを扱わない場合、
GPUにとって最適な頂点格納を扱えるオブジェクトを考えた場合、
(動的な)頂点バッファーとインデックスバッファーのセットを
扱うことしか、私は方法を知りません。
むろん、GPUマシンコードや、CPUのマシンコードを バイナリコーディング
で扱うことは、今のところ断念しています。
それは、単に時間との戦い、と言う問題を含むだけで、主要な問題
ではないし、とりあえずいくつかのプラットフォームに対応できれば
いいからです。

355 名前:デフォルトの名無しさん :2005/05/28(土) 15:38:06
HAL(ハードウエアアクセラレーションレイヤー)というものは、
ビデオチップ/ボードを供給する企業の業界団体を束ね、その中の
非営利的かつ研究的な人的集団を一つ作り、
その集団が構築するべきだった、と考えています。
そうすれば、
少なくとも、ビデオボードには依存しないコードが簡単に書けるし、
API群も統一されるわけですし、アセンブリコードも書くことが
できるわけです。
残念だな、と思います。

356 名前:デフォルトの名無しさん :2005/05/28(土) 15:43:47
バカキター

357 名前:デフォルトの名無しさん :2005/05/28(土) 15:46:15
まぁあまり相手にしないのが吉だな。そのうち去るだろ。

358 名前:デフォルトの名無しさん :2005/05/28(土) 16:49:32
>356
いやしくも人を公的な場所で非難するなら、怨みを残すような
捨てゼリフだけ吐くのではなく、
どのようなところがこれこれの理由で"バカ"なのだと、むしろ
はっきりと述べる、あるいは述べる用意をした上でするべきだと
おもいます。
...正直、あまり気にはしていませんが。
明示的にかつ具体的に中傷された方が、私としてはありがたいし、
むしろ、その人に感謝するであろうし、中傷された方としても反省し視点を
変えるきっかけになるのです。

そのような記述を用意した上で、私のことをもう一度バカよばわり
してくれませんか?

359 名前:デフォルトの名無しさん :2005/05/28(土) 16:53:26
>>358
えらそうなこと言う前にもうちょっと勉強しろ。なぜ馬鹿呼ばわりされるか考えろ。

360 名前:デフォルトの名無しさん :2005/05/28(土) 17:01:10
359へ
>あなたが、私のもつ知識の全てを上回る知識をもってして、
私を諌める、あるいは非難しているとは、どうも考えられません。
あなたが、私が尊敬したくなるほど、学びたくなる程の知識や技術を
もっているとも、考えられません。
むしろ、ある種の偏見に固まった論理的思考のセットをもってして、
私に悪い感情をもった、と解釈しています。

また、私は、偉そうなことを言っているのではなく、単に
私の見方を披露しているのであって、それにたいする論理的な反論を
(あるいは、できれば共感を)期待しているのです。

それなら、それでもいいし、もしそうでなく、あなたが私を非難するに
だけの人物であるなら、何をどのように勉強するべきかを、
述べてくれませんか?


361 名前:デフォルトの名無しさん :2005/05/28(土) 17:10:30
>>360
で、おまえは誰?355?
もしそうなら、客観的に見て馬鹿って言われても仕方ない意見しか書いてないのだが。

362 名前:デフォルトの名無しさん :2005/05/28(土) 17:11:38
>>360
内容に対して文章が冗長
もっと短くまとめろ、読み飛ばされていることに気づけボケ

つーか意見を発するならblogなりを立ち上げるのが最善
コメント,アクセス数が全てを物語ってくれるはずw

363 名前:デフォルトの名無しさん :2005/05/28(土) 17:16:34
ちゅーかモデリングソフト想定してるなら、
ハードの能力を使う場合と使わない場合と両方作ったほうがいいよ。
ハードによって結果が変わっちゃうなんて駄目商品以外なにものでもないからね。

ゲームみたいに直でハードのメモリにおいちゃわないで、
システムメモリにいつもおいておいて、ユーザーから変更があったらまずシステムメモリにおいてある
頂点を変更して、それからビデオメモリに流すようにしなきゃ駄目だよ。
DirectXが関係するところはビデオメモリに流すところだけ。
つまり、アプリケーション側の処理にはなんの影響も与えない。
これはゲームでも同じだと思うんだけどね。

つまりDirectXの使用可・不可を切りかえられるようにすれば万事OK。

364 名前:デフォルトの名無しさん :2005/05/28(土) 17:24:42
バカ過ぎて笑える

>少なくとも、ビデオボードには依存しないコードが簡単に書けるし、
>API群も統一されるわけですし、アセンブリコードも書くことが
>できるわけです。
>残念だな、と思います。

>少なくとも、ビデオボードには依存しないコードが簡単に書けるし、
>API群も統一されるわけですし、アセンブリコードも書くことが
>できるわけです。
>残念だな、と思います。

>少なくとも、ビデオボードには依存しないコードが簡単に書けるし、
>API群も統一されるわけですし、アセンブリコードも書くことが
>できるわけです。
>残念だな、と思います。

365 名前:デフォルトの名無しさん :2005/05/28(土) 17:25:45
文体が同じ罠

366 名前:デフォルトの名無しさん :2005/05/28(土) 17:39:04
中途半端な知識だけでDirectXのコーディング経験がいかにも少なそう。
まずはいろいろと実践して確認してみたら?

367 名前:デフォルトの名無しさん :2005/05/28(土) 17:42:13
とりあえずモデリングソフトに>>342みたいな手法はかなりナンセンスだと思う。

368 名前:デフォルトの名無しさん :2005/05/28(土) 17:45:53
>>367
同意。
こんなちゃちな最適化は意味をもたない。
ハードのパワーごり押しのほうがいい。
変な最適化によって高スペックのマシンを使ったときに
パフォーマンスが落ちてしまっては元も子もない。

369 名前:デフォルトの名無しさん :2005/05/28(土) 17:57:23
>364氏 および 不特定多数の人へ
わたしは、以前、デバイスドライバ(のコード)の構成と言うものは、
分類の一方法として、
大きく分けて2つにわかれる、ということを学びました。

1)物理的デバイスに依存する(dependent)ドライバ
2)物理的デバイスに依存しない(independent)ドライバ

ビデオカードに対するデバイスドライバに関して言えば、
前者(Device dependent driver)は
NVIDIAとかATIといった会社が供給するカードないしはチップの、
デバイス単体に対して直接インターフェイスをもつドライバです。
端的に言えば、デバイスに対し、ネイティブなマシン語コード
レベルでアクセス可能です

後者(Device independent driver)は、一例をあげると、皆さん
ご存知のDirectXにおけるHALの部分です。
直接のインターフェイスは、通常、各デバイスの依存ドライバ
に対してもっています。複数のインターフェイスを持っている、と言う
ことになります。
DirectXのHAL(ハードウエアの機能を複数のビデオカードデバイスを
ヒト括りにするために抽象化した仮想物理デバイスというのが私の解釈)
は、Microsoftという会社が供給するものであって
したがって、すべての物理デバイス(ビデオカード/チップ)に必ずしも
対応する必要はなく、純粋に経済的な理由で、どこには対応し、どこは
DISCARD(?)する、と、決めてしまっています。
更に言えば、Windows系のOS上で動くプロセスから呼ばれることを
強制している HAL であり、その意味では、デバイス非依存ドライバ
あるいは、それを司るAPIセットとしての機能は、Microsoftと言う会社
の営利的判断に制約されたものなのだ、と私は考えます。


370 名前:デフォルトの名無しさん :2005/05/28(土) 17:57:41

Windows系のOSで、GPUを扱うプログラムを組むのなら、DirectXが
最善で、他の特殊ケースとしては、ビデオカードをNVIDIAのモノや、
ATIのモノに一種類決めた上で、専属のAPI(実質的には、アセンブリ
レベルでのアクセス)を使う、と言う方法位しか、選択肢はありません
(後者の場合は、UNIX系のOSでも、動くと思います。)

以上の状況(私が勝手に解釈しているだけかもしれませんけど)を
踏まえて、純正なHAL(純正なデバイス非依存ドライバ部)が
OSやカードやCPUなどに依存しないような形で提供されていたらな、
と私はため息を付いて、それを言葉にしたのです。

371 名前:デフォルトの名無しさん :2005/05/28(土) 18:06:52
思いこみの激しい長文厨はスルーが吉

372 名前:デフォルトの名無しさん :2005/05/28(土) 18:22:36
>>371
読んでないが、もしかして312から延々語ってるのは同一人物ジャマイカ
スルーされても

373 名前:デフォルトの名無しさん :2005/05/28(土) 18:42:11
>純正なHAL(純正なデバイス非依存ドライバ部)が 
>OSやカードやCPUなどに依存しないような形で提供されていたらな、 
>と私はため息を付いて、それを言葉にしたのです

マジレスすると OpenGL がそれに近い
DirectX 使う以上 Windows 限定にキメ打ちしないと手間がかかりすぎる

374 名前:デフォルトの名無しさん :2005/05/28(土) 18:45:11
>>369
>>363も読んでよ。
モデリングソフトならハード使わなくてもキチンとした結果だけ欲しいって場面あるでしょ?
それにDirectXに依存する部分なんて最後の描画だけで
君の考えてるような悩みは普通に設計してればおこらないんだよ。
現に使用中にOpenGLとDirectXを切りかえることができるモデリングソフトも結構あるでしょ。

375 名前:デフォルトの名無しさん :2005/05/28(土) 18:46:00
>>373
OpenGL使ったことないでしょ?
環境依存に関してはOpenGLの方が大変。(使ったことがある人ならわかる)

376 名前:デフォルトの名無しさん :2005/05/28(土) 18:51:49
ID 非表示だと誰が誰だか分からんな

377 名前:デフォルトの名無しさん :2005/05/28(土) 19:04:47
わたしは、DirectXに関して、死のうとは思いませんでしたが、
このスレッドのタイトルに似たような(核爆発のような)気持ち
を味わったことは、一度や2度ではありません。その副次的利益と
言うか、苦しみつつも、バージョンアップに悩まされつつも
とにかくDirectXを使うことに執着した結果、次のことが判明したのです。
.
...OpenGL切替えコードを実装したときのことです
"OpenGLって、なんて、わかりやすくて、かんたんなんだろう?"

DirectXと比較していったのです。
最初扱ってみて、知識が不足していて困ったこともいくつかあります。
1)wgl系の関数で、初期化をする手順
2)右手座標系(私はそれを、正当なる座標系と呼んでいますが)なこと
3)マトリックスを扱う構造体が無く、gldouble[k]とかglfloat[k]
でやること、テクスチャーに関しても、3次元配列っぽいものを使う
4)テクスチャー座標に関しても、左下が原点であること

対して困ったと言う程でもないですが、初回にてこずったのは、
おもにそんなケースです。

たぶん、DirectXに苦労しつつも、(数バージョンに渡って)
使い続けてきた人達は、私と同じ感想を持つのでは、と思っています。
ただし、条件つきですが。

378 名前:デフォルトの名無しさん :2005/05/28(土) 19:09:01
インターネット初期の香りがするスレはここですか

379 名前:デフォルトの名無しさん :2005/05/28(土) 19:12:22
< DirectX環境から OpenGL環境に移って、Happyになれる条件 >

a)Unix系OSでOpenGLを扱うことは、また別の問題である。
それは、むしろ、kernelとか、ウインドウマネージャーとか、と
どうつき合うかの問題が大半だからである。

b)少なくとも一度位は、一連の座標変換とか、スキャンコンバージョンとか、
(できれば、ソフトウエアZバッファーリングとか、)、あるいは、
さまざまな観点からのシェーディング処理を、あるいは
テクスチャー座標を扱う処理を、自前で実装してみたことがある事。
...実装したこと無いないとしても、論理的にはきちんと理解していること

3)大学教養過程レベルか、もしくは高校受験クラスの数学を
ある程度自分で納得して扱えること

そんなところが、幸せになれる条件かと、私は思います
条件に当てはまらない人は、それなりに苦痛を感じるかも
知れません、が、必ずしもOpenGL環境移行を阻むほどのものでも
無いと、思います。

380 名前:デフォルトの名無しさん :2005/05/28(土) 19:21:02
>>379
ちげーよ。
OpenGLで一番ムカツクのは環境依存だ。
バカタレ。

381 名前:デフォルトの名無しさん :2005/05/28(土) 19:26:40
>374さんへ、
DirectXを敢えて使うのは、それが、ハードウエア直アクセスに
ある程度近い効果を持つからです(それでいて、ある程度は
環境依存性の問題を解消できる)。

その代わり、DirectXの提供するデータ構造や処理経路を使うことが、
ある程度暗黙の了解となります。
その例が、頂点バッファー、インデクスバッファー
さらにはメッシュオブジェクト
処理経路に関しては、頂点シェーダとピクセルシェーダを幹と
した処理経路(レンダリングパイプライン)に会わせることになります

ですが、DirectXは、どちらかと言うと、ゲーム系のアプリケーション
を作成するのにいろいろな意味で(偏って)最適化されたAPIセット
である、と私は見ます。

そのような設計しそうによって作られたAPIセットを使い、
そのような分野とは、ある種相容れないデータ構造を扱いたいとき、
まず悩むのは、どこまでが許容されるのか、という、見切り
ラインをどこにひいたらいいか?ということです。
具体的にいうなら、頂点バッファー/インデックスバッファーは
どのようなアラインメントやユニット数で複数のメモリデバイスを
言ったり来たりするのか、ということです。
そのような実装についての解説は、DirectX9Helpには、どこにも
ありません。なぜなら、ゲーム系のオブジェクトを扱うのなら、
頂点バッファーの内容は変更されないで固定されているほうが
ふさわしいからです。


382 名前:デフォルトの名無しさん :2005/05/28(土) 19:27:04
で、結論なんだけど
頂点はソフトウェアで管理して。
IDirect3DDevice9::DrawIndexedPrimitiveUP使ってさ。


383 名前:デフォルトの名無しさん :2005/05/28(土) 19:31:20
UP系は、遅い、と言うイメージを持っています(用途にもよるでしょうが)
ソフトウエア管理、と言うのは、レンダリングパイプラインにセットする
ということに関しては、ハードウエアで扱える方がベターだと考えて
います。ただし、最適なユニット数がしりたいな、ということです。
むろん、MIXEDで頂点を作っているため、ある状況では、ソフトウエア
に切替えたりもします。
大量の頂点を持つ3Dオブジェクトを高速にレンダリングしたいなら、
できるだけ、DirectXの処理系統に従う、というのが王道だという
にんしきは、もちろんもっています。只、その範囲で、どこまで
逸脱することが可能なのか、という観点なのです。

384 名前:デフォルトの名無しさん :2005/05/28(土) 19:33:40
最も、最近の傾向はピクセル処理に傾いている、というのも
認識はしています。
ビデオチップ部のトランジスタ部が、ピクセル処理部にたくさん
リソースを傾けている、ということも。

385 名前:デフォルトの名無しさん :2005/05/28(土) 19:34:01
ここはひどいインターネットですね

386 名前:デフォルトの名無しさん :2005/05/28(土) 19:43:16
天然なのか新手の荒らしなのか

387 名前:デフォルトの名無しさん :2005/05/28(土) 19:51:57
>>383
マジレスするとドライバで勝手にやってんじゃねーの?
って気がするけどね。
アプリ側でどんなに頑張っても触れないんじゃない?
パイプラインとかいってるぐらいだからハードが自分に最適な動きをするために
パイプラインに送る命令しか俺等にいじらせないわけだし。

388 名前:デフォルトの名無しさん :2005/05/28(土) 19:56:31
前はDrawPrimitiveの一発で描画されてた気がするけど
頂点ストリームとか入ってきてからDrawPrimitive前後にあるBeginとEndが怪しいと思うようになった。
結局、どんなデータ構造で持つとか渡すとか問題があるようには思えない。

389 名前:デフォルトの名無しさん :2005/05/28(土) 20:02:47
UP系が遅いってのはそれこそ先入観だね。
たいして変わりゃしないよ。

390 名前:デフォルトの名無しさん :2005/05/28(土) 20:05:15
>386さんへ
BBSの(特に2chに関しての)暗黙の了解を、私が良く認識していない
せいだとおもいます、
荒らしとは、どのようなケースをいうのですか?
(自分では、そうではないつもりでいますが)

>388さんへ、教えてください
描画されるオブジェクトを(特に、その頂点データを)どのように保持していますか?
1)メッシュ(D3DXMESHのような)
2)自分で作ったクラス、ないしはstructure
3)頂点バッファー系
4)その他

391 名前:デフォルトの名無しさん :2005/05/28(土) 20:10:14
環境依存に不満をもつのなら、TRON をお勧めするよ

392 名前:デフォルトの名無しさん :2005/05/28(土) 20:13:16
>389さんへ
BBXとかいう掲示板を、いぜんロムったことがあります。
DirectXに関する話題を扱っているようですが、
2ch と違って読むのが辛いです(スレッドの表示方式に関して)
でも、読んだり、検索したことがありましたが、しきりに
"DrawPrimitiveUP"という識別子が 話題として使われていました
(と言う、印象を持ちました。)
そして、その理由は、おそらく、彼らが(彼女らが)、おもに
2D系のゲームを作りたい人が多いからだな、と、私は推測
してしまったのです。
2D系のゲームなら、必ずしも1フレーム毎に全画面書き換える
必要はない、パーシャル(部分的)描画で対応した方がむしろ、
パフォーマンス的にも利益になるケースが多い(ようだ)。
例えば、例をあげると、WindowsのOS自体も、ロングホーンに
なるまでは、以前として2D描画である。
メニューバーのメニューがマウスフォーカスを持つとき、描画
されるのはボタンの周りのライン一周か2週分である。
全体のボタンを再描画するより効率的だからである。
3Dでは、多くの場合、そのようには行かない。


393 名前:デフォルトの名無しさん :2005/05/28(土) 20:14:18
>>390
モデリングソフト作ってるんでしょ?
だったら2つ用意するしかないでしょ。

1つはシステムメモリ側にアプリケーションで触る頂点データ(これは自作のクラスもしくは構造体のが都合がいい)。
もう1つはビデオメモリにおく頂点データ(これはあくまで描画用、描画するときにシステムメモリのデータをコピーするだけ)。

ゲームではビデオメモリにおいて終わりだね。(頂点バッファ)
モデリングソフトはデータを変更されるたびに システムメモリ→ビデオメモリ をいちいちやらないとね。

394 名前:デフォルトの名無しさん :2005/05/28(土) 20:24:28
>387さんへ
ドライバーで勝手にやっていることは前提条件としても、
十分に公開されているやりかたがあるケースと、無いケースが
あるとおもうのです。
公開されているケースとしては、テクスチャーの幅と高さを
2の累乗で作ってくださいとか、以前なら 256x256のテクスチャが
一番(ドライバにとって)効率がいいですよ、とかいうものです。
無いケース(あるいは、なかなか気が付きにくいケース)にかんして、
このスレッドでだれか答えて欲しいものです

395 名前:デフォルトの名無しさん :2005/05/28(土) 20:31:00
>393さんへ
もしかしたら、私は、"動的な"頂点バッファーとか、DYNAMIC
な使いかた、という意味を吐き違えているのかも知れません
ですが、
今のところの方針としては(WRITEONLYでないとかなりおそくなる
、とのお言葉があったとしても)、
3Dオブジェクトは 常に動的なVB/IBで管理し、幾何変形(端的に
いうと頂点バッファーやインデクスバッファーのLock/UnLock /数秒間隔 ) と位相変形(これは、V-E(hf)-Lの内部データ
も扱うため、それらにかんしては必然的にシステムメモリ)を、
終止DYNAMICなリソースへのアクセスとして扱うのがいい、
と考えているのです。

396 名前:デフォルトの名無しさん :2005/05/28(土) 20:34:52
>>394
いまのところそういうのは無いと思うけど?
汎用性を重視すると3D関連のそういうのは全部消えるんだよw
選択肢としてとっちゃ駄目なのが多い。

三角形のストリップ化もいまとなっては扱い難いだけだしな。
DrawPrimitiveの回数を減らそうなんて余計な手間考えるのも無駄だし。
テクスチャなんて無駄にまとめたって速いかどうかなんてわかんね。
テクスチャ切り替えだってやんなきゃそもそもシェーダつかえないじゃん。
マテリアルでまとめて描画なんてシェーダ使ってたらやってらんない。
と、まあ、最適化の類はだいたい消えたけどね。(俺はもうやってないけど?まだみんなやってるの?)

それともZバッファ使ったときの前から描画とかそういう初歩的なものが知りたいの?

397 名前:デフォルトの名無しさん :2005/05/28(土) 20:35:13
つまり、確かにLock / Unlockは、最速のフレームレートを
えようと思えば、できるだけ避けた方がいいのでしょうが、
それよりも、大量のデータ転送を伴う処理(あるメモリリソース
エリアから、別のメモリーリソースエリアへの大量転送)
は、もっと避けなければならない処理だ、という認識からです

398 名前:デフォルトの名無しさん :2005/05/28(土) 20:36:05
>>395
モデリングソフトつくってるんじゃないの?
ビデオメモリがロストしたらユーザのデータもろともあの世逝き?

399 名前:デフォルトの名無しさん :2005/05/28(土) 20:37:40
>396さんへ
あんまり気にするな、実装してみて、まずそうだったら
またやりなおせ、と言う趣旨に受け取ってよろしいですか?

400 名前:デフォルトの名無しさん :2005/05/28(土) 20:37:43
…結局何がしたいんだ?
うんちく述べてるだけで、何したいんだかサッパリ分からん。

401 名前:デフォルトの名無しさん :2005/05/28(土) 20:41:27
いまってそういう最適化の類って気にする必要ないし、できないもん。
適当にクリッピングして遅いなら、もう駄目だよ。
打つ手無し。

402 名前:デフォルトの名無しさん :2005/05/28(土) 20:41:57
>400さんへ
1)頂点バッファーとインデックスバッファーを動的なリソースとして
結構たくさん確保したい
2)頂点バッファー一本あたりに、複数のオブジェクトセットを
詰め込みたい、オブジェクト毎に頂点バッファー一本割り当てる
のでなく
3)頂点バッファー一本, インデックスバッファー一本の
これ以上バイト数増やすとまずいんでない?という
ある程度の目安が知りたい!!
私の予想(根拠は特に無いけれど)としては、UINT_MAX + 1
つまり、64k(65536)サイズあたりが、境界線ではないかと
予想しているが、果して正しいのかどうか?!!

...気になるのは、気にそんなところです。

403 名前:デフォルトの名無しさん :2005/05/28(土) 20:48:18
>>402
つーか、それは描画毎に頂点バッファを再確保することが前提なの?

404 名前:デフォルトの名無しさん :2005/05/28(土) 20:52:25
もし、描画毎に再確保するなら再確保するから遅いと思う。
描画前に再確保しないなら、ビュークリップされないから遅いと思う。

405 名前:デフォルトの名無しさん :2005/05/28(土) 21:01:21
>398さんへ
どっかのOSみたいに、30秒くらいに一回、システムメモリ領域に
、ないしはさらにハードディスクへ(一時的ファイルとして)書き込む、
と言う方法をとりあえず考えています。
30秒は、フレームレートから見ると、かなり長い時間間隔なので、
あまり問題は無いと思います。

それと、頂点バッファーに置くのは、あくまで、表示用データ
(私は、DisplayListとかよんでいますが)であって、以下のものです
Surface(ループ上の面)... Solid描画用
Curve(エッジを表示するためのラインのリスト) ...稜線描画用
Point(編集用頂点ないしはコントロールポイント) ... 頂点描画用
...上記のものには、マテリアル系のデータが含まれます
他方私が再優先に扱いたいデータ構造である、
Vertex, Edge(+ halfEdge*2), Loop の位相構造に関しては
常にシステムメモリ側で管理します。というのは、描画用の
プリミティブを構成するものではないからです。隣接関係を
記述するデータだからです。Solidモデラーと呼ばれるモデラー
が必要とするデータ構造です

最悪の場合、ROSTして、その日に編集していたオブジェクトデータが
全て失われたとしても、少なくとも位相構造データは最終的な編集の
終りまで確保され、なおかつ、マテリアル系データの一部に関しては、
確かに失われますが、やむ終えない、という方針です
もちろんそれは、バグでしか無く、いずれ何らかの方法で解決しないと
行けないでしょうが、
OpenGLなら、immモードでないかぎりそうなら無いから、OpenGLでいこう、
とは、あっさり割り切れないのです、私。

406 名前:デフォルトの名無しさん :2005/05/28(土) 21:04:50
なんかえらい勘違いしてるな

407 名前:デフォルトの名無しさん :2005/05/28(土) 21:06:30
又バカ発言キター

>私の予想(根拠は特に無いけれど)としては、UINT_MAX + 1
>つまり、64k(65536)サイズあたりが、境界線ではないかと
>予想しているが、果して正しいのかどうか?!!

408 名前:デフォルトの名無しさん :2005/05/28(土) 21:16:20
>403さんへ
頂点バッファーを作成する処理は、まだ一つも3Dワールド空間に
オブジェクトが置いてない段階で行います。
ちょうど、D3DXDevice9とかいう名前の"デバイス"インターフェイス
を作成した直後にです。5本から10本位ずつ
C++風にいってみれば、バッファー管理クラスのインスタンスを割り当てる
過程で、コンストラクタ呼びだし時におこなわれます
( 私は現在、main(int, char**) をつかい、C言語を使って実装して
います。以前はC++でしたが、現在は明示的なthisポインタとか、
->lpVtbl-> を使って、デバイスの諸関数を呼び出しています
でも、実質的に Winmain(...) や、_wWinmain, _tWinmain と
殆んどかわりありません。)

オブジェクトをユーザーが指定したとき、頂点バッファーをロックして
必要な頂点データを、インデクスバッファーに対してはインデクスデータ
を随時書き込みます。

リサイズとかリセットの処理は、フレームワークの処理と同様の
経路を実行できるようにしてあります

409 名前:デフォルトの名無しさん :2005/05/28(土) 21:28:04
私は、一見すると、いろいろと保守にかかわることをべらべらしゃべる
ように写っているのかも知れません。
でも、白状しますが、本当に重要なことは、一つも述べていません
し、いままでの状況を判断すると、多分述べないでしょう。
2chは、これだけのスレッドを抱えていて、ものすごい印象を以前は
持っていたのですが、
"もったいないものだ..."
というのが、現在の心境です。外国のスレッドと比較して、どうしてこうも
ことなるのでしょう?

410 名前:デフォルトの名無しさん :2005/05/28(土) 21:29:50
ある程度の一般論を言うが

・普通そういうレベルの最適化はほとんど効果がない
・もっと効果が明確に出る高速化手法がいくらでもある。
 (OcTreeなどを利用した視錐台クリッピング、Zソートして手前から描画など)
・DrawPrimitiveの最適値は環境によって違うしMS公式では1000ポリとかなんとか書いてあった事がある
・DrawPrimitiveUPは結構速い。


411 名前:デフォルトの名無しさん :2005/05/28(土) 21:32:16
まさにスレタイどおりの展開だな

412 名前:デフォルトの名無しさん :2005/05/28(土) 21:37:16
>410さんへ
ありがとうございます
3000個の頂点、ということですか?
私が考えていたより、かなり少ないユニットなのですね
メモリ間データ転送とか、キャッシュを扱う上で、そういう数値に
なるのでしょうか...?
ところで、もしよろしければ、データの出処を教えてくれませんか?
(できれば、そのデータが発表されたときのおおよその日付も)
私も、GoogleやAltavistaで 何度か懸命に探したのですが、とうとう
見付けることができませんでした。

413 名前:デフォルトの名無しさん :2005/05/28(土) 21:44:49
>>412
効果がもっとも薄い最適化にそんなに必要に拘る理由はないだろw
もう、いじっていうか意味はないんだよね・・・w

414 名前:デフォルトの名無しさん :2005/05/28(土) 21:45:10
だから何頂点までなら〜とか
何バイトまでなら〜とか
そんな検証殆ど意味ないんだって。
どうしてもやりたいんならコンフィグダイアログボックスに
VertexBufferキャパのスライダでも付けとけ。
それか常に時間計って動的に容量を変えるとか。
しかし、そんなもん付けたって
素で組んだのと大して変わらなくてm9(^Д^)プギャー

415 名前:デフォルトの名無しさん :2005/05/28(土) 21:46:51
でも、疑問に思うのですが、現在のある程度ハイパフォーマンス
をもつビデオカードを使った場合、頂点処理は、そんなに負担では
ない、あまり遊ばせない方がいいからピクセルシェーダをもっと
使った方がいい、という記述を、本でみました。
また、スペックからみると頂点数では、フレームあたり
400万頂点か、その2倍位(一秒あたりには、その60倍として)
はほぼ問題なく扱える、と私には読めました
つまり、4000回もDraw処理を繰り返すのですか?
それとも、メッシュオブジェクトとかは、頂点バッファーとか
とは、まったく別の経路で処理されるのですか?

そのように処理してなおかつベストだというのなら、
Draw系の処理は、かなりの回数呼んでいい、と言う解釈
になってしまうのですが。

416 名前:デフォルトの名無しさん :2005/05/28(土) 21:53:00
>
ディスプレイリスト管理クラスのstructureの使いかたおよび、
メンバ変数や、メンバ関数(に相当する関数)が、
私のこだわっている判断材料のいかんによって、がらっと
代わってしまうからです
最適化自体とはとらえていません、クラスの設計上の問題
としてとらえています
でも、いままでの印象からわたしの得たものは、大勢は
別の最適化に注意を払っているのだな、という仮説です

417 名前:デフォルトの名無しさん :2005/05/28(土) 21:54:24
>>412
すまん、1000頂点と書いてあった。
http://www.microsoft.com/japan/msdn/directx/techart/directx9devfaq.asp
あとメモリ間データ転送、キャッシュだけではない。
他にも色んな要素が絡んでこういう数値が出てくるんだろ。

400万頂点…ピクセルより多い頂点数で何を描画するんだ?w

418 名前:デフォルトの名無しさん :2005/05/28(土) 21:57:01
>>415
つーか、もう誰もその辺を最適化かまして速くしようなんて人いないよ。
シェーダが絡んでくると信じられないぐらい複雑になっちゃうし。
現実的じゃないね。
大体、ドライバ側・ハード側で何をどういう処理してるかだって理解してないのに
なんでそんなところにこだわろうと思ってるのかね。

メッシュオブジェクトってなんだと思ってんだよw

419 名前:デフォルトの名無しさん :2005/05/28(土) 22:01:07
パフォーマンス云々とか考えすぎて、何も作れないって手合いだな。
ベストが得られるまで議論するっていう理想主義者。
現実的解決は妥協で日和だっていう原理主義者ね。

420 名前:デフォルトの名無しさん :2005/05/28(土) 22:02:42
>>419
つーか、自分の考えた方法を否定されたくなくて無駄なこと駄弁ってるだけだろコイツw
もう、なんも考える必要ないからさっさと作れって感じw

421 名前:デフォルトの名無しさん :2005/05/28(土) 22:05:40
こういう奴の方がただの無能よりたち悪いよな。
こんなトンチンカンな話延々とされてもなー

422 名前:デフォルトの名無しさん :2005/05/28(土) 22:06:27
>417
ディスプレイあたりのピクセルの数 =1000*1000 =100万
大雑把な例
確かに、うっかりしていましたが、知らないわけではありません
理論値から計算すると、そう(400万頂点)なります。
でも、逆にいえば、それは、現行に置いて頂点処理にかなり余裕がありすぎる、ということ
でもあります
ついでにいえば、ビューフラスタム外部にある、最終的には描画
されずにカリングされたりする頂点も、途中までは処理される、と
いうことです。
...いずれにしても、400万とか100万頂点は現実的ではない、とは
認めます。ですが、数10万頂点頂点くらいなら、実際生成される
ケースはあり得ます
(もちろん、一ピクセルとしても認識されないようなトライアングル
も多数含めて )

423 名前:デフォルトの名無しさん :2005/05/28(土) 22:07:00
>>421
折角、最適化なんて無駄なこと考えなくていいような時代になったのに変な奴いるねー。

424 名前:デフォルトの名無しさん :2005/05/28(土) 22:07:49
>>422
お前はもうしゃべんなくていいよw

425 名前:デフォルトの名無しさん :2005/05/28(土) 22:09:45
>>416とかを見ても明らかにダメっぽい。
最適値がなんでクラスの設計上の問題になっちゃうの?

426 名前:デフォルトの名無しさん :2005/05/28(土) 22:10:08
で、数百回 Drawがフレームあたりに呼ばれるとして、
それでも、多いんだな?という印象です。
数10回くらいなら、納得できるのですが(少ないに越したことは
ないとも思いますが)
DirectX は、ソフトウエアOpenGLとは異なり、そんなに
たくさんの描画処理関数を Begin / End ブロック内では
呼ばないものだ、まとめて描画するのがいいのだ、
とは、私がヘルプを読んで得た印象です


427 名前:デフォルトの名無しさん :2005/05/28(土) 22:11:13
バカの印象なんてどうでもいいよ…

428 名前:デフォルトの名無しさん :2005/05/28(土) 22:14:34
>417
"パフォーマンス チューニング" にかんして、
読んでみました。
情報の提供、どうもありがとうございます
これからは、microsoftのホームページももうちょっと
さがしてみようとおもいます。おさわがせしました。

429 名前:デフォルトの名無しさん :2005/05/28(土) 22:16:50
ここまでスレ荒らして作ってるのが2Dシューティングだったら死なすw

430 名前:デフォルトの名無しさん :2005/05/28(土) 22:21:00
まあ、なんていうか

 早すぎる最適化は諸悪の根源

の典型的な例、というか

 Try & Error

を理解した方が良い、というか

431 名前:デフォルトの名無しさん :2005/05/28(土) 22:21:57
まあ毎フレ400万頂点なんてアホなこと言ってないで
さっさと八分木なりLODなりの効果の偉大さを理解しろと

432 名前:デフォルトの名無しさん :2005/05/28(土) 22:24:50
>>429
スプライト1個につき4頂点の計算で毎フレ100万個の弾幕かよ!?スゲーヨ!!w

433 名前:デフォルトの名無しさん :2005/05/28(土) 22:26:38
ところで、彼は結局なにが言いたかったの?
っていうか 「UINT_MAX + 1 = 65536」 ってどんな環境よ

434 名前:デフォルトの名無しさん :2005/05/28(土) 22:31:24
>>432
凄いなそれは

人間的には、弾は一画面に 1000 個が限界だ orz

435 名前:デフォルトの名無しさん :2005/05/28(土) 22:33:35
虫姫基板の限界が物理的に2000発くらいなんだってね。
まあ2000発も打たれたらたまったもんじゃないが…

嵐も過ぎ去ったところでマターリ

436 名前:デフォルトの名無しさん :2005/05/29(日) 02:18:24
右手座標系と左手座標系ってどっちが多く使われてますか?
これから勉強始めるので、多く使われてる座標系で学ぼうと思いまして…

437 名前:デフォルトの名無しさん :2005/05/29(日) 02:32:57
>>436
…?DirectXスレでその質問の意図不明
というより、左手⇔右手系変換など基礎中の基礎だしどっちも勉強しとけ

438 名前:デフォルトの名無しさん :2005/05/29(日) 02:45:09
左手右手の逆転よりもXYZが違ってるのとかモデリングソフトによって色々だなw
法線もひっくり返さなきゃなんねーし面倒だったなw

439 名前:デフォルトの名無しさん :2005/05/29(日) 15:00:57
Handle H = _Tex(3D"Wire);

 昨日、ここのスレッドの 328..428 で書き込みをしたものです。

先日、諸兄方から、多大なるお叱りを頂、また、度重なる非難を
浴びたことに関し、いろいろと自分でも考えてみました。

思慮が足りなかった....
それが、私の得た結論です。具体的には、PS / VS を根幹にして行われて
いる、DirectX9(or etc..)の使用方法に関して、"エフェクト!"とさげすんだ
(..つもりでは さらさらなかったのだが、どうやらほぼ間違いないようだ)
ことに関して、誤りたいと思います。

せめて、"華麗なる"エフェクト と、正直に言うべきだった...
そして、こんな私は、現行の3DCG(スリーディーシーディー)のメジャー
な状況に対して、心の中で 3D"2D"(スリーディーツーディー)などと
毒づくこともります。
でも、自分はといえば、いまだに、"ワイヤーフレーム命" とたびたび勘違いされ
るほどの、WireFrame-Mode 支持派 なのです。だから、冒頭に示したように、
ハンドルネームをここでは、3D"Wire"(スリーディーワイヤー)と名乗ることに
いたします。


440 名前:デフォルトの名無しさん :2005/05/29(日) 15:02:45
もう書かなくていいって

441 名前:デフォルトの名無しさん :2005/05/29(日) 15:03:11
H=3D"Wire"
>439
X>ことに関して、誤りたいと思います。
O>ことに関して、謝りたいと思います。

442 名前:デフォルトの名無しさん :2005/05/29(日) 15:03:42
>>439
変わった芸風の人だな。w
ちなみにワイヤーフレーム命ならOpenGLのほうがちょっとだけ幸せかもしれん。

443 名前:デフォルトの名無しさん :2005/05/29(日) 15:05:51
DirectXも、ZBIASがまともならなぁ

444 名前:デフォルトの名無しさん :2005/05/29(日) 15:07:13
3D"Wire"

先日、オクトリ・ツリーや、Zソート、LOD(レベルオブディテイル)
などの事について、再三聞かされました。正直、私としては、
オクトリツリーとかの効果に関して、疑問を感じてたため、あまり積極的に
使おうとは、今まで思っていなかったのに、ちょっと考えを改めようと
思ったからです。

ちょっと、Octreeの構造体の一例を挙げ、感想を伺いたいと思いましたので
...しばらくお待ちください、入手してきます。

445 名前:デフォルトの名無しさん :2005/05/29(日) 15:35:28
いやいいよ、マジで

446 名前:デフォルトの名無しさん :2005/05/29(日) 15:53:47
こんな奴と仕事したくねぇなぁ

447 名前:デフォルトの名無しさん :2005/05/29(日) 16:02:45
どこの機械翻訳システムを使ってんだ?

448 名前:デフォルトの名無しさん :2005/05/29(日) 16:26:51
読点を入れすぎて文章が読みにくくなる典型。

449 名前:デフォルトの名無しさん :2005/05/29(日) 17:30:03
お前らいい加減スルーすべし

>>444
適当に鳥かコテつけてくれんかね?
あぼーん設定したいから


450 名前:デフォルトの名無しさん :2005/05/29(日) 18:11:41
そうだな、3D"Wire" (は、恥ずかしい)を名前欄に書いてくれればOK
あぼ〜ん可能に

451 名前:デフォルトの名無しさん :2005/05/29(日) 18:44:18
>3D"Wire"
仕事してる人?もう引退した?何か文体がものものしいというか、
60年ぶりに発見された日本兵のような印象を受けるのだが(;´∀`)

452 名前:デフォルトの名無しさん :2005/05/29(日) 18:45:55
>3D"Wire" 
っていうか自分の独り言は自分のブログでも作って、そっちに書きなさいな
ここは公共の場

453 名前:デフォルトの名無しさん :2005/05/29(日) 19:41:47
別にこんな死んでるスレがどうなろうと構わないので
好きに暴れてくれて良いよ>Wire

ここで暴言吐いてる奴らも、本心では君のことが大好きなんだよ

454 名前:デフォルトの名無しさん :2005/05/29(日) 20:13:51
ほら、こいつアレだよ。

「軍人は有能か無能か、
 そして働き者か怠け者か、
 これらによって4種に分類できる。

 有能な怠け者は司令官に、
 有能な働き者は参謀にせよ。
 無能な怠け者は…
 そうだな、連絡将校ぐらいならできるだろう。
 無能な働き者?
 それは処刑するしかあるまい。」
 (フォン・ゼークト)

無能なくせにセコセコセコセコと無駄な質問ばっかしやがってw
無駄なウンチクばっかり覚えてきても1つもプログラムに生きて無いじゃん。
もう、ばっちり無能な働き者だよw

455 名前:デフォルトの名無しさん :2005/05/29(日) 20:21:50
>>453
同意だな。

456 名前:デフォルトの名無しさん :2005/05/29(日) 20:59:20
自演スキルを取得しました

457 名前:デフォルトの名無しさん :2005/05/29(日) 21:06:54
いや、無能だしそんなスキル覚えられないよ

458 名前:デフォルトの名無しさん :2005/05/29(日) 22:35:36
3D"Wire"
私は、そんな 三下のザコのような"せこい" ことはしません、
そう...
一行書き込みばかりの、論理思考のできないあなたのような、ね

以後 "DirectX"といった虎の威を借りたスレッド名で人をまどわせ、
貴重な 公共リソースをこれ以上ブロックしないでください

>453さんへありがとう、でも、荒らしているのではない。
私は、もうすこしまともなスレッドだけをみることにします(以後書き込みません)

459 名前:デフォルトの名無しさん :2005/05/29(日) 22:46:24
>>458
> 私は、もうすこしまともなスレッドだけをみることにします(以後書き込みません)

乙。絶対戻ってくるなよ。

460 名前:デフォルトの名無しさん :2005/05/29(日) 22:57:01
>>459
ああ、やっとアホが消えたな。
なにせ>>402を速いとか一瞬でも考えるあたり素質全く無いからな。
ホント、この邪魔なのどう処分したものかと思ったが案外あっさり消えてくれたな。

461 名前:デフォルトの名無しさん :2005/05/29(日) 23:05:21
> 私は、もうすこしまともなスレッドだけをみることにします(以後書き込みません)

まあ、お前は2chのどのスレに行ってもバカにされるだろうよ。
コミュニケーション能力というものが絶望的に欠落しているからな。

462 名前:デフォルトの名無しさん :2005/05/29(日) 23:34:08
平行線を辿る事が分かっているのにどうしてレスするかなあ

463 名前:デフォルトの名無しさん :2005/05/29(日) 23:40:09
ゲ制作板の総合スレはどうなったの?
誰も建てないの?

464 名前:デフォルトの名無しさん :2005/05/30(月) 00:51:04
>>463
よろぴこ

465 名前::2005/05/30(月) 03:27:45
非常に不快だ。
2ch'erって、なんで初心者を「バカ」だの「アホ」だの寄ってたかって卑下するんだろうね。
どこでもいいからUSのサイトにいってみ?こんなコミュニケーションありえねーよ。
いやな民族だ。さいてーにBITCHYだよお前ら。
その腐った精神は更年期障害を抱えたババァそのものだぜ?


466 名前:デフォルトの名無しさん :2005/05/30(月) 04:38:40
2chで褒められたら、皮肉か褒め殺しかと不安になるから
けなされた方が心配なくてよいよ

467 名前:デフォルトの名無しさん :2005/05/30(月) 07:35:53
>>465
自分でそういいながら腐ったとかさいてーとか更年期障害を抱えたババァだの
もうこれは「オマエモナー」の出番としか思えない。

468 名前:デフォルトの名無しさん :2005/05/30(月) 07:40:14
実際は大部分の人は
非難どころかレス自体しないよ。
俺もバカというレスは一度もしたことないし。

469 名前:デフォルトの名無しさん :2005/05/30(月) 08:09:25
>>468
>実際は大部分の人は
調べたわけでもないのにこういう嘘吐いちゃうところとか
もう馬鹿とかアホとかいわなくても十分同類項で結べると思うよ。
まあ、俺には50歩チンポの違いでも君には大きな違いかもわからんがねw

470 名前:デフォルトの名無しさん :2005/05/30(月) 08:53:18
>>469
現実ここは過疎化してるじゃん。
理由は何でだろう?
DirectXプログラマーが減って需要が少なくなったからか?
そういえばゲ製作板も過疎が激しいな。
理由は何でだろう?
よく考えてみるといいよ。

471 名前:デフォルトの名無しさん :2005/05/30(月) 09:00:59
今回のは初心者だから叩かれた訳じゃないからな。

472 名前:デフォルトの名無しさん :2005/05/30(月) 17:33:17
こんどはBBXで暴れてるよ。
二重投稿ならまだしも三重投稿しちゃうなんて
やっぱりバカなんだと思う。

473 名前:デフォルトの名無しさん :2005/05/30(月) 17:53:35
ワラタ
ありゃひでーな

474 名前:デフォルトの名無しさん :2005/05/30(月) 18:22:50
UINT_MAX + 1 = 65536で鳴らした俺様3D"Wire"は、濡れ衣を着せられ2chねらーにバカに
された。2chを脱出し、BBXにもぐった。しかし、BBXでくすぶっているような俺達
じゃあない。

475 名前:デフォルトの名無しさん :2005/05/30(月) 20:01:25
>>472 爆笑

476 名前:デフォルトの名無しさん :2005/05/31(火) 00:10:06
余裕のスルーを食らってて面白い

477 名前:デフォルトの名無しさん :2005/05/31(火) 01:55:02
>>470
そもそもゲーム業界自体の衰退が原因だろ。
ゲームそのものに魅力がなくなってるから作ろうという奴も少ない。
各HPの掲示板への書き込みもほとんどないし、更新もほとんど無くなった。
それにある程度ゲームが組めるようになるまでの入門書だって発売されてるし
こんなところで無駄な質問なんてしてる奴はやること見えてないよ。
著しくレベルが低い奴が多数。答えて意味のあるレベルじゃない。

478 名前:デフォルトの名無しさん :2005/05/31(火) 02:00:09
つーか、いいかげんゲーム以外の3Dアプリがブレークしないかなぁ。
VRMLとかは大外しだったけど、まだまだアイデアあるだろ。

479 名前:デフォルトの名無しさん :2005/05/31(火) 05:07:07
2Dシューティングが絶望的に衰退したのに2Dシューティングばかり作ってる趣味人の中で
何言ってんだ。


480 名前:デフォルトの名無しさん :2005/05/31(火) 07:27:34
しかしBBXも完全に終わってるな。

481 名前:デフォルトの名無しさん :2005/05/31(火) 07:50:12
>>480
つーか、まともに会話できるレベルから怪しいの多いな。

482 名前:デフォルトの名無しさん :2005/05/31(火) 09:39:19
この スレは 面白い!

483 名前:デフォルトの名無しさん :2005/05/31(火) 10:05:30
AOEは面白かった。なにが面白かったと言うと、まるでフル3Dのような
気がしたからだ(すべてビルボードだと知ったのは、しばらく後のこと)。
AOMにはがっかりさせられた。期待を裏切られた。
デモムービーを見たときから予感はあったのだが、実際遊んでみて
やはり戦闘シーンなど、甲虫(ゴキブリ?)の戦いの用に汚いイメージがあった。

なぜだろう?なぜビルボードを使ったDirectX7までのゲームの方が、
DirectX8/X9の機能をフル装備したゲームよりこれほど印象が深かったのだろう?

どうでもいいけど、プログラミングに長けていない専門家がアプリケーション
インターフェイスをつくると、なぜMFCコマンドボタンをああも並べたがる
のだろう?(彼らは専門的知識には非常に詳しいだけに、大きなマイナスである)
以前DESIGNEBASEというリコーのソリッドモデラーカーネルのソースコード
(カーネル部はdllまでの非公開だが)をダウンロードし、ソースを読む
よりもまず動かしてみたかったため、VC++で動くサンプルを動かしてみてあぜんとした。
MFCボタンだらけのインターフェイスに。

私はその頃、まだWindowsAPIのWinMain()やWndProc()の事もろくに知らなかった。
VC++6.0を学割で購入する以前は、学割で購入したVB++5.0を使っていた
だから、MFCを駆使してVBライクなボタンだらけのインターフェイスを
コードによって作るのがVC++によるプログラミングだと思い込んでいた。

そのDESIGNEBASEのサンプルを見て、目が醒めた。
ボタンを必要以上に張ってはならない。
その点、AOEのインターフェイスは優れていたと、私は思う。

484 名前:デフォルトの名無しさん :2005/05/31(火) 10:36:38
  ∧_∧  
⊂(#・д・)  釣り基地ばっかりやってられないっすお!
 /   ノ∪  
 し―-J |l| |   
         人ペタンッ!!
      (_) 
     )(__)(
    ⌒)   (⌒
      ⌒Y⌒

485 名前:デフォルトの名無しさん :2005/05/31(火) 10:42:24
なぜ、わたしは一度限りでチャットで遊ばなくなったのだろう?
やっているときは、想像以上に楽しかったのだ。好意的な印象がおおかったし。

だが、チャットの接続を切り、あらためて第3者の立場でロムって見ると、
こいつら(チャットで書き込んでいる連中)が、ひどくちっぽけに思えた。
そして、そんなちっぽけな連中(それはあくまでその時の私の主観に過ぎない
のだが)といっしょになって遊ぼうとしている自分までがみじめな気がした。
それいらい、チャットはやっていない。あそこはぬるま湯につかっている感覚をおぼえるから。
小学校のクラスルームのような印象がした。

BBSは?
Made in Japan だからかもしれないが、思ったよりも不快だ。
まるで、学生時代にひとりでとなりのクラスに攻め込んでいった
時のような、数十人のザコを蹴散らしにいったような、あと味の悪い感覚があった。
だが、今なお魅力的である。なぜなのだ?
ひとつには、その規模。Capacity。知名度。一言でいえばメジャーであることか。
メジャー自体に組みすることは嫌いだが、人間が多く集まることが魅力的なのだ。
村社会の寄せ集めであることが、大きな欠点ではあるが、今なお潜在的ななにかがある気がする。

486 名前:デフォルトの名無しさん :2005/05/31(火) 12:12:00
なんだこいつ

487 名前:デフォルトの名無しさん :2005/05/31(火) 16:42:03
またなんか頭のネジがゆるんでそうなのが来てるなあ。
全部読み飛ばしたけど。

488 名前:デフォルトの名無しさん :2005/05/31(火) 23:13:34
上の耳年増外人でしょ

489 名前:デフォルトの名無しさん :2005/05/31(火) 23:16:50
どうも一連の長文は全部同一人物が書いてるように見えるな

490 名前:デフォルトの名無しさん :2005/05/31(火) 23:51:10
しかも>>485の文章には致命的なミスが含まれてるので、
何を言いたかったのかが全く汲み取れない情けない文章になってる。

ねじ緩んでるどころか三丁目まで吹っ飛んでる。

491 名前:デフォルトの名無しさん :2005/06/01(水) 08:38:25
二次方程式の解法の適用
(問題の式) x^2 + 21 = 10x

(その1)デカルト以降の解法
(ここでは敢えて因数分解ではなく、デカルト以降の代数学を用いる。すなわち
x = (-b +/- sqrt(b^2 - 4*a*c)) / 2*a を使う。)
問題の式を移行して x^2 - 10x + 21 = 0
以後公式を使って自動処理すると、x = 3, x = 7 がすぐに求まる。
公式の使い方と平方根をマスターすれば、小学一年生でも解ける。
(-(-10) +/- sqrt(10^2 - 4*1*21)) / 2*1 = (10 +/- sqrt(100-84))/2 =
(10 +/- sqrt(16))/2 = (10 +/- 4) / 2 = 3, 7

(その2)アル フワーリズミの解法(ある解析学の本から抜粋)
根の個数を半分にすると5になる。これをそれ自身に掛けると25になる。
これをそれ自身と掛けると25になる。これから平方と結びついた21を引く
と、残りは4である。その根を求めると2である。これをもとの根から引き
去ると残りは3である。これが求めていた平方の根であり、平方は9である。
根の数に新しい根を加えてもよく、和は7になりこれも求めていた平方の根で
あり、平方自身は49になる。

平均的な現代の人は、この解法で任意の二次方程式を解くことができるの
でしょうか?
この解法は確かに 記号式で表現された解の公式をそのまま文字表現しただけです。
だが、記号式という道具を与えられない場合、論理思考能力が無ければ
二次方程式すら解くことができないでしょう。

以上は知的道具の使用がもたらす損失(論理思考能力の欠如)の一例を挙げてみました。
幾何学は難しいと感じたプトレマイオス一世が「幾何学を学ぶ近道はないか」
とユークリッドに尋ねたのは、私はあながち無理もないことだと思います。
デカルト以前には代数学と幾何学は別個に扱われていたから、幾何的な問題を証明する
(証明文を構築する)のは現代人が考えるよりも難しかったからです。

492 名前::2005/06/01(水) 11:55:06
3D空間を、高速に描画するための解法

(その1)頂点バッファをUINT_MAX+1(==65536)と取る方法
DrawPrimitiveは、呼び出す回数が少ない方が、高速と考えられます。
だから、出来るだけ大きなバッファを、取るべきだと考えます。

(その2)オクトリツリーの方法
私は、この方法に疑問を、感じていました。
何で、この方法が高速に、描画できるか、分からないからです。
私が、分からないものは、使いたくありません。

493 名前:デフォルトの名無しさん :2005/06/01(水) 12:25:00
UINT_MAX+1 == 65536 派の人、登場w

494 名前:デフォルトの名無しさん :2005/06/01(水) 13:02:20
..........
これでわたしは確信が持てました。

私は、もう(ここには)書き込まないと言った自分の誓いをやぶり、
あえてここに再三書き込みました。それは、私にたいして悪口雑言を重ねる連中
が、私が想像するとおりの人種であるのか?もうすこし決断を伸ばす必要が
ある、と思い留まったからです。

私はおっちょこちょいなところがあり、BBSをBSSと打鍵してしまったり、
UINT_MAX を INT_MAXと間違えて使いながら一週間ぐらいソースコードに
放置していることも、ないわけではありません。
ですが、そのようなことを取り上げて非難を繰り返すことのメリットは
わたしには全然理解できません。

わたしは、あなたたちにも期待したかったのです。
BBSに、2chには、今でも期待していますが。
(私を攻撃しつづける)あななたたちは、少なくとも、私の期待した人物では
談じてあり得ない、と言うことはこれで確信しました。
たとえ(何人集まっても何ひとつ大きなことができない)三下のザコ集団であっても、
知的な部分においてはそうではないかもしれないな?
という私の期待はもろくも外れたわけです。

私は、この連中を諌め聞かせる能力が足りなかったことを恥、
以後、本当にこのスレッドには書き込みません。
お騒がせしました。以後仲良くマターリお過ごしください。

495 名前:デフォルトの名無しさん :2005/06/01(水) 13:05:12
16bit の環境を未だに強いられているのって……哀れ

496 名前:デフォルトの名無しさん :2005/06/01(水) 13:09:36
>>494
> 以後、本当にこのスレッドには書き込みません。

今度こそ約束守れよ。

497 名前:デフォルトの名無しさん :2005/06/01(水) 13:12:03
すでに約束を破っているわけで、誰も>>494のことは信用していない。
アホの上に嘘つきだし。

498 名前:デフォルトの名無しさん :2005/06/01(水) 13:19:37
>>495
UINT_MAX + 1 は普通 0 だろ?
16 ビットとかいう話はあまり問題じゃないよ。

499 名前:デフォルトの名無しさん :2005/06/01(水) 13:28:27
>>498
というか long long a = UINT_MAX + 1; は 0 じゃないですから、型に制限される話かと

500 名前:デフォルトの名無しさん :2005/06/01(水) 13:29:07
((long long)UINT_MAX) + 1 で


■過去ログ置き場に戻る■ 1- 前250 次250 最新50
DAT2HTML 0.33f Converted.