PCで描画と内部処理の非同期処理ってどうやんの？

**（;´д⊂ヽ** · 02/04/29 16:14

PCならではの可変フレームレートで、かつ安定したキー入力とか演算の微分処理とか
実装したいんですが、具体的に、どういう風な構造にすればいいのか全然わかりません助けて

キー入力とかタイミングに厳しい処理を別スレッドで回すとして
描画担当スレッドはどーすればいいんでしょう？
（描画途中で別スレッドにより内部変数が書き換えられるケースが出てきますよね？）

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

みんな頑張ってるから

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

書き換えられたくないタイミングをマスクするしかおもいつかんのだが。

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

多重に持てば良いんじゃないの

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

単発スレ立てんなボケ。

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

ローカルルールをよく読めやGW厨

お約束
　3.簡単な質問やあいまいな（問題点の良く分からない）質問は汎用Ｑ＆Ａスレッドへ

**（;´д⊂ヽ** · 02/04/29 17:23

すんません。単発つーか、結構深いテーマな気がしたんで
本でも扱ってないし

２Dゲーみたく、スプライトレジスタみたいのだとマスクとか多重化も
簡単なんだけど、３Dゲーでクラスだと色々面倒でねぇ

可変フレームレートつってもリフレッシュレートの関係で上限は120と
しても問題ないわけで、なんか上手く処理できんものんかと思ったわけです

ゲーム内ではよくある、1フレーム前の位置参照するような場合でも
前フレームが何ミリ秒前なのか可変だと困ると思うのです
仮に計算で逆算するにしても、ソウルキャリバーの剣の軌道なんかの
多段数の前フレーム参照は難しいかなと思うのです

そんな訳で僕の中では、上限120FPSで、処理落ちするときだけ描画を飛ばす
ような完全非同期ではない方法が正解だと思うのですが、ご意見聞きたいなぁと

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

>>7
それでいいんじゃない。
はい終了。

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

でも海外のFPSとかで、ロケット砲なんかのビルボードな煙軌道なんかは、そうでもない気がする

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

内部にカウンタ持ってるか、数フレーム前まで位置を保存しときゃ済む話だろ

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

ジサクジエン乙カレ。
>>1=3=7=9

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

3Dゲームに限らず、殆どのゲームは描画で多くの時間を費やしてる。
描画についていけないならデータ更新する、という>>7の方法でよい。
yaneSDKあたりにそれ関係の記事があったと思うので興味があればどうぞ。

それと、3Dゲームだと描画速度がFPS30位でも結構滑らかに見えてしまうので、
データ更新速度はFPS120ほど高くなくてもよいと思うよ。

質問内容がアレだったこともあるので、削除依頼は出しておいたほうが吉かと。
ログには残しておきたい内容だけれどねぇ。

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

>>7みたいに　1/120秒の内部ﾙｰﾌﾟはゲームによっては処理が重いかもしれん
だからといって1/60秒単位で変数を更新した場合、60FPSより早い描画だと、描画側が困っちゃうよね

ミサイルの先端はどんどん進むのに、後端（保存された数フレーム前情報）は1/60単位でしか更新されないと
煙の全長長くなっちゃうよね
（気付かないだろうけど、マシン毎になんか結果がことなるプログラムって気持ち悪い）

じゃぁミサイルの先端位置から後端の位置が計算できるか　つーとそうでない場合もあるし

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

PCの場合スペック自慢つーかベンチ代りだったりするので
FPSが60頭打ちじゃ、手抜き！とか叩かれる。技術力もないみたいだし

キャラは同じ位置のままで再描画だけして、Over60FPS表示にしる！
どーせ人間の目では60fps以上区別つかないって言うしー
でも、中には区別できる人もいる罠

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

Windowsアプリだと、描画はプライマリスレッド以外関与するなって鉄則があると思うんだけど
これはゲームにも当てはまるのか。
WindowのGUIをプライマリスレッドで管理し、
Direct3Dの描画をワーカースレッドで管理なんてOK？
軽く試してみたら、微妙に不具合が起きたのだけど。

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

>>14
実際に自分で簡単なサンプル作ってみればわかるが、
意外に誰でも区別できるぞ。
しかも、見るだけよりも操作するとはっきりわかる。

**（;´д⊂ヽ** · 02/04/29 18:58

どうすればいいんでしょう
残影とか軌道が残るモノさえなければ、何にも考えなくていい気はするけど

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

残影とか軌道が残るモノをなくす。

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

残像オブジェクトに賞味期限もたせて、毎回チェック。
期限切れはあぼ～ん。

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

可変フレームレートな環境(つまるところPC)で
内部計算と入力処理と描画処理をうまいこと回すっていうのは面白いネタだと
思うがなー。OS側の制約がうざいけど。

>>15
SetCooperativeLevel に DDSCL_MULTITHREADED というフラグがある

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

つーか残像とか軌跡とかも１つのインスタンスとして保持すればいいんじゃないの？
せっかく描画とそれ以外に処理を分けているんだから、
描画の具合が内部処理に影響を与える仕様にはするべきではない。
内部処理から描画ルーチンへのデータの流れは一方通行にするべき。

21 · 02/04/29 19:26

>>19そのまんまでした。
>>19に同意。

21 · 02/04/29 19:30

>>20
ヘルプに書いてあった。

＞この設計は、暗にマルチスレッドアプリケーションを意図している。
＞特に、アプリケーションはウィンドウメッセージ処理スレッドを
＞Direct3D スレッドから完全に分離しなければならない。
＞1 つのスレッドでモード変更を行いながら、
＞別のスレッドで Direct3D の呼び出しを行うアプリケーションは、
＞デッドロックの危険性がある。
＞
＞このような理由から、Direct3D では、Reset、CreateDevice、TestCoorperativeLevel、
＞または IDirect3DDevice8 の最後の Release の各メソッドは、
＞ウィンドウメッセージを処理するスレッドと同じスレッドからのみ呼び出すことができるように設計されている。

つまりこれさえ気をつければ、Windowスレッドとの兼ね合いを気にする必要はない訳だね。

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

なるほど賞味期限にすればいいのかも
でも、描画と内部、別スレッドで回すっても、クラス多用だと変数の二重化が面倒だよなぁ
保存する変数がいろいろ散らばってるもんなぁ
行列だったり、オイラー、Quaternion、ブレンド係数だったり

その辺、どー書くのがスマート？

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

ローカルでしか使わないデータはローカルで管理。
みんなが使うデータは管理するクラスをひとつ作ってそいつが管理。

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

描画スレがデータに影響与えない設計にすべきだろ。
描画開始時に必要なデータをバッファにコピーしてきて、それから描画するとかな。
BeginCopyでデータをロックして読み出し開始、EndCopyでロック解除するみたいな。
（注：そんなAPIありません。自作でねｗ）
データが多いと大変だけど…設計次第。

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

例えば、インターフェイスを使う場合
キャラclassには、標準として
Render系インターフェイスとFrame系インターフェイスと
別けて実装すればスッキリすると思う。

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

Quake系のソースとか読んだ人いないの？
どうやってるんだろ?
ちなみに俺は持ってるけど読んでません

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

どうしても別処理したいなら
描画は１フレームごとのタイマー割りこみで処理する。
内部処理側は１フレーム分の描画オブジェクトのセットが完成したら
渡す。

でも内部処理と描画を分けるのは賢くないので、waitvに描画処理を
埋め込む事を推奨する。

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

>>28
市販のゲームは、描画にかかった時間を計って、その分データを更新するって
方法が一般的じゃない？速いマシンではいくらでも速くなるように作らないとね。

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

まともにやろうと思えばWindowsシステムじゃせいぜい100～200FPSで限界が来る。
まともじゃない方法ならそれ以上だせるが、そっちのほうが手抜きだな。

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

>>7
＞単発つーか、結構深いテーマな気がしたんで
その結果がこれかよ…

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

スーファミ等のエミュレータが綺麗に処理していると思うんだけど
ソース公開しているのもあるよね。誰か調べたことのある人いる？

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

CAPCOMのエミュレーターはトリプルバッファとかでやってたな

リフレッシュ論争だけど、60FPSのゲームをリフレッシュレート85とかにしてれば
どうやってもガタツクよね？

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

ゲームにおけるマルチスレッドの運用って感じで
このスレもまだまだ存在意義があると思うな。
んで質問。スレッド間通信で最もゲーム向きなもん(軽い)て何？
やっぱりメッセージかな？

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

>>32
質問スレって初歩的な事しかわかんないじゃん
玄人は読んでる人少ないし

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

一般的かどうかはともかく、俺の場合。

1)内部描画コマンドを定義する
2)ゲームのメインループとは別に描画スレッドを回す
3)メインループはタイマで毎秒60回ぶん回して、描画コマンドをキューに突っ込む
4)描画スレッドはキューに入っている描画コマンドを元に画面を作る

という感じ。
もちろん、描いてる途中で描画コマンドキューが書き換わったり、描画コマンドキュー
が構築されていないうちに描画されないようにするための工夫は必要。
(キューの多重化とか排他制御とか)

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

>>37
60回以上描き換えることがあっても、
内部処理は60回超えないってこと？
遅い場合は有利だけど、速い場合は利点はないってことでよいのかな？

37 · 02/05/02 01:16

>>38
自分のやり方の場合、そうなります＜60回/sec超えない

前フレームの処理にかかった時間を元に今フレームでの移動速度を補正
させつつ全力でぶん回す、というやり方もやったことはあるけど、個人的に
あまりエレガントだとは思えなかったので・・・。

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

あれ、>>37のやりかたで60回以上描きかえることがあるの？
描画コマンドが60回までしか発生しないから、描きかえも60回まででは？