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

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

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

みんな頑張ってるから

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

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

単発スレ立てんなボケ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソースコードと実装のエレガントさをとるか、やってることのクールさをとるか。

>>40
あー、言葉足らずですみませんでした。
もちろん1フレーム描いたら、描画コマンドキューが更新（表裏切り替え)
されるまでは描画もしません(_o_)

やっぱ>>7にもどって　内部120回ﾙｰﾌﾟとかが行けてる？

>>43
120回なんか回したって意味ないんだから
60回上限にして、その分アイドルに回した方が
全然いいと思うがナ。

>>44
ウィンドウモードのことを考慮してるんじゃない？
フルスクリーン60Hz限定のゲームならいいんだけどね
更新60Hzでディスプレイ75Hzだと相当がたつく

>更新60Hzでディスプレイ75Hzだと相当がたつく

これって2Dモノはよくわかるけど、3Dだとわかる？
それ以前にWindows特有の処理落ちみたいのがあるし、FPSとか場面毎のポリゴン数によって
処理落ちしたりして、何が原因だかよくわからないんだよねー

ダブルバッファをスマートに書くのはテンプレート使えばいいんじゃない？
描画と完全に分けるならトリプルバッファが必要だと思うけど。
でも、そんな面倒な構造にする必要あるかね？

>>44
PCでやる以上、それは割り切るしかないと思う。
タイマで計って廻した所で、完全にVSyncと同期させるのは無理だし〜

あのーここってリフレッシュレート論争と大差ないんですけど・・・・

>>46
60fps固定で処理してると、3Dでもガタつくよ。
モーションが飛ぶんじゃなくて、速度が不安定になるというか、ブレる感じ。

内部処理を固定するなら、描画処理は１フレーム分遅延させるのがベスト。
描画処理の方が速く回る場合は、補間させて滑らかな動き。

新リフレッシュレート論争スレの予感。

過去スレより
http://piza.2ch.net/tech/kako/972/972165437.html
>命題：「『1フレーム後に、変数v がa増加する』をどのように実装するか？」
>
>◆A宗:「v += a * dt」
>v-syncに同期。リフレッシュレートは任意。
>
>◆B宗1派:「v += a」
>タイマーに同期。一定間隔で値を更新する。
>
>◆B宗2派:「v += a」
>v-syncに同期。何らかの方法でリフレッシュレートを固定する。

私は一時A宗に傾きかけたが、結局B宗に戻りつつあるような気がする。

ゲームクリエイターズバイブルに描画と内部処理の分け方の話があったね。

>>50
そのスレ読んでないけど、内部処理と描画処理を分けるこのスレの趣旨とは
微妙に違うぞ。
このスレは内部処理はB宗で描画だけA宗にするって話。
それがいいか悪いかはともかく、どうやって実装するのかというスレ。

実のところ話していることは同じだという罠

内部処理では座標などの値を過去フレームと次回フレームの２つを持っておく。
描画スレッドでは描画開始時間と内部処理の過去フレームの時間から補完？

　float t = (render_time - old_time -) * (60 / 1000);
　D3DXVec3Lerp(&currnt[i], &prev[i], &next[i], t);

てのを全部に対してやるだけだったらそれなりにエレガントかも。

>>54
それだと、キーフレームアニメーションなんかやると
アニメーションの終端を突破したりしないか？
IF文で終端で止めにすればいいという問題でもない
（アニメーションAが終わったらアニメーションBにスイッチする場合とか）

>>55
たいした問題じゃない。

>>54はスレッドを分けなくてもできるね。
排他制御しないぶん楽。

毎ループ数値積分してるやつはどうなるの？

内部処理回数が決まってないと　リプレイの実装が面倒でないか？
車ゲーのリプレイは適当でいいけど

まぁ、最低60回は回すように組んでおくとして、数値微分なんかの
�凾狽ｪ小さすぎて問題になることなんてあるだろうか？

ない。

丸め誤差にさえ気をつけていれば大丈夫

FPS制御用にワーカースレッドを使ったクラスを作ったが
普通の関数バージョンに比べて遅くなった。
つーかフレームのコールにPostMessage使ってるし当然か。
なんだか設計思想が間違ってたようで激しく鬱。

>>62
PostMessageはまずいでしょ…ガタガタになっちゃう。
ま、誰しも一度は通る失敗だけどね。

>>63
でもさ、それ以外思い浮かばんのよね。
それ以外だと、メッセージループに
if( pFPS30->BeCalled() ){
RenderMain();
}
を埋め込む以外なくなる。

グローバル変数だ！

volatile bool g_BeCalled より
PostMessage(arg->hWnd, WM_PAINT, 0, 0)を
選ぶ62たんはWindowsプログラマの鏡！

俺のプログラムだと、
FPS用のスレッドでパフォーマンスタイマーの
ビジーループをぐるぐる回して処理している為
たとえ内部処理、描画処理を1FPSに設定しても
CPU占有率が100%になってしまう。
何かスマートな実装方法は無いかえ？

HALT

>>68
Sleep系とパフォーマンスタイマーの併用ってこと？
パフォーマンスタイマーから大まかなSleep時間を
求めて眠らすとか？
それとも精度には不安があるがSleep系のみで管理とか？
ビジーループを使わず、タイマーを使う良い方法が
あったら教えて欲しい。

精度に不安って他にプログラム走らせてない場合も不安定なんだろうか。

＞パフォーマンスタイマーから大まかなSleep時間を
＞求めて眠らすとか？
MsgWaitForMultipleObjectsを使ってこの案を実践したら
60FPSでCPU使用率100%だったのが0%まで落とす事に成功しました。
なんだか上手くいき過ぎて怖い。^^
でも試して上手くいった時は快感！だったりする。

>>70
60FPSの場合、精度は16msec程度必要。
まあSleep系は悪くても誤差10msecらしいから
一応大丈夫といえばそうらしい。

>>70
Windowsで、他にプログラムを走らせない状況を作るのは不可能。

ゲームで使うタイマーって、タイマーだけ別スレッドにするの？

俺はいちいちスレッド分けずに書いてるのだが…（FPS可変）
やっぱり描画とその他って分けるべき？

このスレは分けて書くためのスレなので、そういう質問は不適切。

ちなみに描画と内部処理を同期させてるゲームの場合、壁にぶつかる瞬間にわざと
負荷をかけてフレームレートを落とすと壁をすり抜けたりする。
かつて、リアルタイムで解像度が切り換えられるゲームがあったけど、解像度切り
換えで１秒くらい時間が飛ぶから、それで壁を突き抜けたりミサイルをすり抜けた
りなんてことができたよ。

>>75
えー、それはつくりがヘボイだけでは。

>>75
�冲 が 3.25なら、 1, 1, 1, 0.25でループ回す

でも弾が壁抜けるのはやり方がヘボイ。
前回と今回の座標でレイとばせ。

>>73-74
いや別ける必要はないと思う。
俺の場合、ビジーループのCPU負荷を下げたいと
模作した結果、こんな形になってしまったが
メリットは無かった。
>>71のMsgWaitForMultipleObjectsを
メインメッセージプロシャージャーに組み込む方法をとるか
FPS制御クラスにSleep系を組み込むようにする設計にすれば
スレッドを作らなくても同じことが出来るはず。

あ、でもプライマリスレッドをスリープさせちまうのはヤバいか？
>>79は撤回。やっぱスレッドは必要かも。

ああそれに俺の場合そもそもアプローチの方向が違うなぁ。
>>1その他の方向性は、CPUパワーに余裕がある場合FPSを増やす可変方式なのに対し
俺の場合、安定したFPSでCPUパワーに余裕がある場合眠らせるって形だからなぁ。
やねおうら氏のスーパープログラマーへの道にも、Sleepを用いたFPS制御を話題に挙げていた回があったが
あれは、プライマリとは別にゲーム用メインスレッドを作っているから可能な方法だな。　

FF11は30fps固定でくると思う人いる？

>>82
ネットゲームは通信速度が一定じゃないからfps固定はできないんじゃ？

>>83
「固定」の意味もイマイチ不明だけど、「通信速度が一定じゃないから」ってのも違う気がする

通信速度が一定しない所為でフレームレートが固定「できない」
なんていうヘタレな実装をしている市販3Dゲーが思いつかないが。

85は>>83へのレスね。というか、かぶりまくりだった。ｽﾏｿ。

>>82
通信速度は関係ないと思うが、
ゲームの性質上FPS固定ってのはありえんと思う。
画面上に人がイパーイでたりするからね。

FPS固定でもラグったら飛ばさないといけないよな。
結局やることはFPS非固定と対して代わらないような。

というか非固定で作っておいて、
固定にするくらい出ないとだめか。

>>85
DIABLOとかやったことないの？
魔法使いまくるとフレームレート落ちるよ。

>>90
DIABLOやったことないので質問するが、それは描画処理が増大して
モタついてるということではないのか。

例えば、FPS系のメジャー所では通信速度はフレームレートに
影響しない。Lagの激しい奴はパケットロスということで
前フレームの移動パラメータを使って補間アニメーションする。

あ、FPS系てところは
First Person Shooting系 と読み替えてくれ。

通信前提で作ればローカル(一人)プレイ版も簡単に作れると思うんだけど
普通に作っちゃうとローカルプレイ版が先にできちゃって
後から通信対応させるのにスゲエ苦労して一ヶ月泊り込んじゃったよ
っていう人いますか

83≒90？
ネットゲーは毎フレームデータのやり取りしてると思ってるのかな？
Doomならそうだったけど、今はそんなことしてるゲームは少ないよ。
元々アーケード用に作ったゲームを移植のついでにネットワーク対戦に
対応させるときはやったりするけど（某DC用のゲームとか）

ぐああダメだぁ〜！！
Direct3Dを使ったプログラムで、>>71で作った
スレッドを用いたFPSのクラスを使うと
モーダルダイアログを呼んだ瞬間に（::DialogBoxIndirectParam）
固まってしまう。
モーダルダイアログは親ウインドウと同じスレッドです。
FPSのスレッドをサスペンドにすると固まる、
スレッドを終らせてからダイアログを呼ぶと固まらない、
デバック出力用APIを1行加えると固まらない、
FPSクラスのフレームの呼び出しがメッセージだと固まる、
FPSクラスのフレームの呼び出しをファンクションコールにすると固まらない、
D3Dで描画しないと固まらない、
これって何が原因だかわかります？

ダイアログ自前これ最強。
スキン対応も簡単だからいいだろ。

今DirectX7で開発してる人は割合少ない肝

>>95
それは、Win32とかマルチスレッドプログラミングの参考書を
一冊手に入れて目を通したほうがいいような気もする。

>>95
んなの聞いたことない。
ぼんミスでバグってるだけだろ。

マルチスッドレはデバッグが面倒だよね。

マルチスレッドといえばそうなんですけど、
FPSのスレッドがしていることは、
一定時間Sleepして::PostMessageでユーザー定義メッセージを
ウインドウに送っているだけです。
それ以外、変数を操作したりWindowsのシステムにアクセスしたりとかは
何もしていません。
Window、Direct3D、その他もろもろは同一スレッドなんで
実質シングルスレッドと殆ど変わりません。
キーを押された→WM_KEYDOWNメッセージハンドラで、
FPSスレッド停止しダイアログ呼び出し、こんな感じです。
このFPSスレッド停止をSuspendにするとダメ、DestroyにするとOKなんですよね。
まあダイアログをモードレスして作り直してどうなるか試してみます。

>>101
まぁ内心では気付いてるだろうと思うが、
そういうあいまいな文章による状況説明では他人に問題点を指摘してもらうのは難しい。
（orバグを作った本人の状況分析だけを頼りに問題点を見つけ出すのは難しい）
ソース見せられるなら添削してもらうこともできるだろうが
それが無理なら「頑張ってね」としか言えんよ、実際。

とりあえずDirectXとか余計なものから一つ一つ外してみたらどうか。

>>102
その通りですね。
なんだかすいません。

Windowsがリアルタイムゲームに向かない理由、それは突如、原因不明な
ブロッキングに悩むからだと思うんだけど、ちょっとだまされたと思って
以下の設定してみてください。
「ﾏｲｺﾝﾋﾟｭｰﾀ」->「ﾌﾟﾛﾊﾟﾃｨ」->「ﾃﾞﾊﾞｲｽﾏﾈｰｼﾞｬ」->「ﾃﾞｨｽｸﾄﾞﾗｲﾌﾞ」の設定で
オプションに DMA という項目があります。
Windowsの出荷状態では、ここはOFFなのですが、これをONにしてWindowsを
再起動してみてください。謎のブロッキングがかなり解消されますよ！

仮に解消されなくてもファイルアクセスなどがぐんと速くなるので損することは
ないと思います。（ただ一部のハードではこのDMAは無効になってるかもです）

60FPS以上のゲームで「ガクン！」というのがなくなると思いますよ、お勧め。

じゃ、眠いので僕は寝ます。おやすみ〜

>>104
そんなこと自慢されてもなぁ。XPじゃ最初から有効にされてるし。
プロセスとスレッドの優先度を最大まで上げる方が効果あるよ。
絶対に苦情くるけど。

>>105
104のどこが自慢っぽく見えるのか、俺には不思議。
性格ゆがんでない？

>>104
普通やん．
別に画期的なネタでもないわ．

＞普通やん．
MSの公示では、普通じゃないだろ >>FD,HD-DMA
DMA無効になってるのが普通。

問題は、ドライバの設定を変えた時に再起動させること。
自分のマシンだけリブートすればいい問題ではないので。

有名なネタではあるが。

>>105
いちいちくだらねえことつっこむなよ。
＞プロセスとスレッドの優先度を最大まで上げる方が効果あるよ。
これこそわかりきってることを自慢すんなよ。障学生が。

PC房ってやつですか

>>104
それって98/95あたりの話じゃ、、、

をーーーーーーー！見事安定した！マジかよ。
ガタ落ちゼロになった。
ちなみに俺の環境はWin98.
今までの苦労、水の泡。

なんでディフォルトでDMA-ONじゃないのだ？＞＞MS

というか、配布するソフトでも是非、DMA-ONの状態にしたいのだが、
アプリケーションからそれを操作する方法ってないのか？

昔はDMAをオンにすると不安定になるハードが結構あったからねえ、、、
マザボのチップセットと相まって、かなりヤバイことになってた。
だからデフォルトOFFなんだと思う。
Socket7の頃の話だけどね。

Win2000の場合はデバイスマネージャーの
IDE ATA/ATAPIコントローラーの
プライマリIDEチャネルとセカンダリIDEチャネルで設定出来る。

>>112
ＤＭＡオフでガタつくゲームってのも、問題アリだと思うが。

>ＤＭＡオフでガタつくゲームってのも、問題アリだと思うが。
CPUが高速なHDのデータコピーを汗かきながらI/Oへ書き込むので
全てのアプリで停止するのだよ。特に最近のHDは高速だから、
DMAなしではやってられない。
0.3秒くらいCPUがHDの転送に専念することもしばしば。

>>116
ゲーム中はＨＤへアクセスしないようにするべし。

自アプリがやらなくても他アプリがやったり
ライトバックキャッシュのフラッシュや
ページアウトでアクセスが発生しちまいますな

>>118
そうゆう話じゃないと思われ。
他のゲームはガタつかないのに自分のゲームはガタつく！ってのが問題。

>>119
>他のゲームはガタつかないのに自分のゲームはガタつく

そんなこと誰か書いたっけ？

誰も書いてない

人に頼ってちゃダメだよ。
自分から行動を起こさなきゃ。

>ゲーム中はＨＤへアクセスしないようにするべし。
んー、学生さんかのぉ？
Windowsやlinuxなどのような高度なOSでは、
例えば malloc() などのヒープもアプリケーション実行開始直後は
物理メモリに存在しないことしばしばなのじゃよ。
new を呼んだ瞬間、物理メモリが存在しなかったら、そこでHDアクセス。
スタックがオーバーしたら、HDアクセス。
他のアプリが使用していたメモリをHDへ書き戻す作業であることが
ほとんどなのじゃがな。

ゲームなど連続描画がシビアな環境では
Windows上だとガタガタに見えてしまうのも、そこが原因だったりするんじゃ。

>>123
>Windows上だとガタガタに見えてしまうのも

見えませんが？

>>101解決？しました。
FPSを表示するのにFPSの抽出を60FPSとかにすると
更新が激しくて見づらいので、2FPS等で抽出させる
別のFPS制御クラスを作っていたんだけど、
ダイアログを表示する際にこいつは関係ないと思って
サスペンドしていなかった為に、デッドロックが起こっていたようです。
結果論であり、デッドロックの理由はわかりませんが。

::CreateWaitableTimerという便利そうなAPIを発見したんで
こりゃ使えると思ってFPS制御クラスに組み込んだら、
こいつしっかりCPU時間を消費しやがんの。
使えね〜、精度も低いしサ。

>>123
そういうことをやっているかどうかは知らんけど、
やっていたとしても、それは単に物理メモリが少ない場合の
回避処置でしか無いと思うんだけど。
そりゃメモリが足りなくてスワップしまくりな環境なら
ゲームもカクつくよ。

-------風俗の総合商社・ＭＴＴどこでも-------

〇デリバリーヘルス〇デートクラブ〇女性専用ホストクラブ〇
〇ハードＳＭ奴隷クラブ〇レズビアン倶楽部〇ホモ・オカマ倶楽部
〇変態痴女と遊ぶ会〇痴漢・覗き趣味の会〇変態同好会・各種！
●楽しく遊べます！　090-8002-8356番
-----------美男・美女会員など多数在籍中-----------
　 http://www.mttdocomo.jp/
-----女性アルバイト随時募集・高収入（日払い）月100万円可能-----
-----レズビアン・スタッフ●ホモスタッフ●女性専用ホストスタッフ同募-----
http://www.mttdocomo.jp/

>やっていたとしても、それは単に物理メモリが少ない場合の
>回避処置でしか無いと思うんだけど。
WinXPだとか、物理メモリあっても初アクセスまではアプリ用にメモリをcommit
しないというのに、何を逝ってるのかな？
１０秒後に初めてアクセスした変数がメモリにまだcommitされてないページだった
らHDアクセス決定じゃん。

>>127
コミットされていないページ＝スワップアウトされてHDに退避させられているページ
じゃないんじゃないの？
単に仮想メモリが物理メモリにマップされてないだけで。
MSDNでVirtualAllocのページ見てみ。
つーかイチイチメモリ確保の度にHDDアクセスする訳ないじゃん。
常識的にアホ仕様だろそれじゃ。

その話題はスレ違いっぽいので他でやってくれんか

たとえば
http://pc.2ch.net/test/read.cgi/tech/1017072275/

　

>>128

>コミットされていないページ＝スワップアウトされてHDに退避させられているページ じゃないんじゃないの？
↓
コミットされていないページ＝まだ存在していないページ

>つーかイチイチメモリ確保の度にHDDアクセスする訳ないじゃん。
Windows はダーティなページを極力メモリに保持し続ける方針で設計されている為、
いざページをコミットしようとすると、すぐに使えるメモリが足りなくて、結果的にページアウトが発生してしまう。
当然未使用メモリがある場合は、 HD へのアクセスは無い。

だからスレ違いだっての。日本語わからないのか？

>>132
まぁ言いたいことは分かるが
あまり騒ぐと自治厨氏ねとか不本意な罵りを浴びるぞ。

別に俺はここでこの話題をしてもいいと思うが…
3、4レスのためだけに別スレに移動なんてしてたら、
話の一貫性がなくなってしまうだろう。

だって知識が乏しい連中ばっかなんだもん

では貴殿の知識を開陳せよ。
他人を蔑むだけのカキコって、技術レベルに関係なくなんかむかつく。

可変フレームレートってどういういうものでしょう。
60FPS出るように作って、処理が遅れたら処理落ちすれば
いいだけなのでは、、、？

3Dのゲームなら３０FPSくらいが普通でしょうか。

>137
v' += v * dt みたいな感じかな…。

具体的な実現方法は何パターンかあると思います。
どっかのｽﾚでそんな議論してたと思った。役に立たなくてｽﾏｿ

漏れら極楽人道のageブラザーズ！
良スレっぽいものは強制的にageてやるからな！
￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 ∧＿∧ 　 ∧＿∧ 　　　age
　（・∀・∩）（∩・∀・）　　　　age
　（つ　　丿 （ 　　⊂）　age
　 （　ヽノ　　 ヽ/　　）　　　age
　 し（＿）　　 （＿）Ｊ

あぼーん

　　　　　＿＿＿＿_＿
　　　 ／＿　　　　　　|
　 　 /.　＼￣￣￣￣|
　　/　　／　 ―　― |
　　|　 /　　 （･）　（･）|
　 ||| (6　　　　　　>　|
　| | |　　　　 ┏━┓|　　 ／￣￣￣￣￣￣￣￣
| | | | 　　　　┃д┃|　 ＜　正直、ageてすまん
|| | | | 　＼　┃　 ┃/　 　 ＼＿＿＿＿＿＿＿＿
| || |　|　　　￣　￣|

あぼーん

自分の考えだと時間でDTだして変数にかけるのは駄目。
当たり判定なんかで絶対死ぬ。
面倒臭くて作ってられない。
よしんば自分は制御できても他の人はできないでしょ。
ネトゲはしかたないけど。
別に必要がないならフレーム飛ばしで対応が一番楽。

あぼーん

厳密にやろうとしなければOKでしょ。
ピンボールゲームとかビリヤードとかだとそれじゃまずいんだけどさ。

保守

GDAlgorithms-listあたりの議論では、内部フレームレートは固定で、
時間軸で補間描画するのが主流っぽく見えた。
ただ、これもコンストレインツとかいろいろ面倒ごとが絡んできそうだけど。

>>144
物理シュミレーションで
短い期間に衝突が起こりまくるとかかな？
でも固定フレームだとすり抜けが心配になるんだよね。

うちは、内部処理フレームレート固定、描画処理は追いつかなければ飛ばす方向でやってます。

>>149
固定フレームレートでのすり抜けの問題は、非固定でも同じかと。
結局、補完して判定したり、繰り返し判定しないといけないのは変わらないのでは

うちは、ゲームループや他のワーカースレッドではDirect3Dの命令を一切コールせずに、
独自のプリミティブ命令を描画スレッド(っていうかサーバ)に発行する形。
描画スレッドはプリミティブ命令をバッファリングして適当なタイミングで画面を構成する。

ワーカースレッドは発行したプリミティブ命令が正しく描画されたかは関与しないので、
ゲームループに描画サイクルが間に合わない場合はフレームがスキップされるし、
ゲームループが遅すぎる場合はコマ送りになる。

Ｈなサイトを発見したでつよ。ここ、すごい。
http://plaza16.mbn.or.jp/~satchel/omanko_marumie/
美少女のワレメ…(*´∀`*)ハァハァ
美人お姉さんのオマ○コ…(*´Д`*)ハァハァ

>>152
だから固定フレームレートだろ？

http://www.k-514.com/sample/sample.html
拾ったサンプルムービー集めたよ

固定フレームレートですり抜けが起きるか起きないかは
実装する前に予測できるじゃん

コリジョンは厳密にやろうとすればするほど奥が深い分野だよ。
とくにリアルタイム性が必要になると(論文ネタになる、というかなったくらいだし)。

まぁ、厳密性が求められないなら、>>156のように割り切って実装するのが吉。

あれ？コリジョンスレどこいった？

>>158
ここ？

【Collision Detection】
http://pc2.2ch.net/test/read.cgi/gamedev/1015484028/

ガイジンのいろんな開発者から話聞く限り、あっちもA宗なんか使ってないよ？
状態遷移はB宗、表示は補間でリフレッシュレートに同期とか、
状態遷移の粒度を思いっきり上げるとか、そういうのが主流。
コンシューマやアーケードはやっぱり60fps決め打ち。
PAL圏で速度変わろうがｼﾗﾈ（ﾟ�听） PS2やXboxになろうがファミコン時代と何も変わってないのさ。
とにかく、状態遷移の粒度が変わるとどんなタイミングで何が起こるかわからんので皆嫌がる。
サンプルプログラムレベルならともかく、中規模以上のゲームでA宗って例は知らんね俺は。

だいたい日本人だけが困ってる問題じゃない。
同じ環境でコード書いてる限り、ガイジンだけが特効薬持ってたりするわけないじゃん。

あと最近のDirectXはSetDisplayModeで素直にリフレッシュレート変わったりとか、
ほとんどの液晶ディスプレイは60Hz固定だったりとか、
いろんなリフレッシュレートに対応するメリットがかなり薄れてる。
プライオリティとしては、むしろ先に解像度決め打ちを廃絶するべきだな。

本当にA宗使ってないの？
最近出たPCの3DゲームでA宗じゃないの教えて欲しい。

>>160
なんで解像度なんだよ？
リフレッシュレートの話しておきながらｗ

>>161
普通にBが良いと思うよ。

Aだとフレームレートで細かい挙動が変わっちゃうでしょ。

その結果

> とにかく、状態遷移の粒度が変わるとどんなタイミングで何が起こるかわからんので皆嫌がる。

となる。

まぁ、問題にならないような状況なら好きにすればいいんじゃね？

A宗だとリプレイも実装できないし。

A宗でリプレイ実装できないやつは地沼

しかし解像度依存をなんとかせにゃならんのは同意
低解像度にすると画面中インターフェースで埋め尽くされるのとかアホすぎ
だが拡縮に耐えられるデザインをするのは難しい

> A宗でリプレイ実装できないやつは地沼
詳しく

PCでB宗だとリフレッシュを変更せねばならずユーザーに嫌われる件について。

B宗のなかでもリフレッシュレート変更がいらないものにして対処

B宗1派とか
> 状態遷移はB宗、表示は補間でリフレッシュレートに同期
> 状態遷移の粒度を思いっきり上げる
これとか

>>164
フレームごとに時間を記録しておけばおｋ
再生時のフレームスキップの処理は必須

質問です。

◆A宗:「v += a * dt」
v-syncに同期。リフレッシュレートは任意。

◆B宗1派:「v += a」
タイマーに同期。一定間隔で値を更新する。

◆B宗2派:「v += a」
v-syncに同期。何らかの方法でリフレッシュレートを固定する。

「一定間隔で値を更新する。」 と「何らかの方法でリフレッシュレートを固定する。」って
まったく同じ意味じゃないですか？

参考サイト
フレーム制御
ttp://www.c3.club.kyutech.ac.jp/~sukiyaki/flame.html

大丈夫か？

なんでそうなる。前者は計算、後者は描画の話だらーが。

>>170
読みづらいたとえですまないが
たとえばユーザーCとユーザーDの使ってるリフレッシュレートがそれぞれ70、100のとき…
A宗(C)　　　　　　　秒間70回値を更新する。描画も秒間70回
A宗(D)　　　　　　　秒間100回値を更新する。描画も秒間100回
B宗1派、例い(C、D)　秒間200回値を更新する。(描画は適当に)
B宗1派、例ろ(C、D)　秒間60回値を更新する。〃
B宗2派(C、D)　　秒間60回値を更新する。描画も秒間60回。リフレッシュレートは60に無理やり固定

>>173のユーザーCとDの例を使ってひきつづき書いてみる。
>>169の方法だと、ユーザーCのリプレイをユーザーDが再生するときには
秒間70回値更新で描画は適当(ユーザーDの環境に合わせたもの)、
ユーザーDのリプレイをユーザーCが再生するときには
秒間100回値更新で描画は適当(ユーザーCの環境に合わせたもの)、
となるのでは。
>>160にならい、状態遷移の粒度がユーザーの環境によって変化するのがA宗、とするならば、
>>169のはA宗のリプレイ再生方法でなく、B宗1派のリプレイ再生方法なのでは。
というわけで>>164-166へループ。

>>174の最後2行、間違えました。申し訳ない。A宗で合ってますね。
A宗が状態遷移と描画を同じ周期で行わなければならないなんて決まりはないし、フレームスキップしてあたりまえだし。

・状態遷移の粒度がユーザーの環境によって変化するか
　（v += a * dt か、v += a か）
・状態遷移の同期をタイマーでとるかv-syncでとるか
・ディスプレイのリフレッシュレートを、ユーザーの環境と関係ない固有の値で固定するか
・状態遷移と描画を同じ周期で行うか
がごっちゃになって混乱してました。

＞A宗が状態遷移と描画を同じ周期で行わなければならないなんて決まりはないし、フレームスキップしてあたりまえだし。
　
あるいは、A宗は過激派と穏健派に分かれるということではないか。
A宗過激派・・・全てリフレッシュレートに同期。画面更新だけでなく数値積分のタイムステップも何もかもリフレッシュレートに同期。
A宗穏健派・・・（ティアリングの無い）滑らかな社会を実現するために画面更新はリフレッシュレートに同期させよう。

A宗過激派・・・全てリフレッシュレートに同期。画面更新だけでなく数値積分のタイムステップも何もかもリフレッシュレート基準。
A宗穏健派・・・（ティアリングの無い）滑らかなスクロールを実現するために画面更新はリフレッシュレートに同期させよう。

話をずらしてすまないんだけど

xnew = xold + v;

ってやる場合、新しい位置用のメモリ領域と、旧位置用のメモリ領域が必要になるよな？
これを描画するとき、リフレッシュレートスレの結論から

x = xold + (xnew-xold) * Δt / T (T = 1フレームぶんの時間)

とかやってた。

でもって、スレッド分けの最大の利点は画面更新計算の間でも位置更新の計算が出来るってことだと思うんだ。
すると、描画用のメモリ領域と、位置更新計算用のメモリ領域を分ける必要があるよな？一緒にしちゃうととんでもないよな？

つーとメモリ領域は、新旧 * 描画用、位置更新用 の計４領域？必要になるってことか。すげーな。
位置更新用のメモリ領域は、描画直前に更新が発生してたら描画用のメモリ領域にコピーされる？

コピー中に位置更新が発生しないように同期オブジェクトを一つかませば出来るような気がするんだけどどう？？
おれ、はっきり言ってバイトと卒論で趣味プログラムしてる暇ないんだけど、だれか試してみてくんない？

>>176-177
あー。以前STGスレで自分はA宗であると告ったら
その過激派のほうだと思われたらしく
リプレイの件でチクチク突っつかれた。
　
俺は、A宗を名乗る上での必要条件は
・ティアリング排斥
・スムーズスクロール至上主義
だと思っている。
　
>>178
＞描画用のメモリ領域と、位置更新計算用のメモリ領域を分ける必要があるよな？
＞一緒にしちゃうととんでもないよな？
　
なぜそう思う。
深刻なアーティファクトが出るかどうかは状況による。
作れば一見してわかる話だ。

＞コピー中に〜中略〜だれか試してみてくんない？
趣味プログラミングの醍醐味のひとつは
試行の自由を与えられることなのであり
その権利を行使せず無為に悩むは損かと。

つかリプレイとぜんぜん関係ない話してるし。ﾜﾘ。

>>172
同意。
ゲームワールドの状態遷移を再現できるかどうかの話と
A宗B宗は無関係。

s/ゲームワールド/各オブジェクト/

>179

描画用と更新用を一つにしちゃうと、描画の位置計算中に描画の素になるデータを書き換えられちゃわないかな？
と思ったんだけど、どうだろう。

描画が終わるまで待つんだったら、そもそもスレッド分ける意味がないと思うし。

>趣味プログラミングの醍醐味のひとつは試行の自由を与えられることなのでありその権利を行使せず無為に悩むは損かと。

う。２月まで覚えてられるかな・・・自信ねー。○|￣|＿

>>179
当初の定義は、
・数値積分のタイムステップを環境依存させるかで A宗 B宗1派 を分けている
・描画をどうするかでは分けていない
この定義だと、A宗は>>177のいう過激派しか認められないことになる。

>>179がA宗穏健派として状態遷移タイムステップをv-sync非依存にしているとしたら、
描画をリフレッシュレート同期にしていても関係なく、当初の定義だとB宗1派に明確に分類される。

A宗B宗の定義は、もう実用にはならないんじゃないか？
元々の定義は描画にはふれず状態遷移のみにふれているため、
>>179が過激派と思われたように意図を伝えられないことがある。

代案としては…。>>175の4要素16派に分類すれば多少マシだが、あのままでは煩雑だ。
話題になるのは16派のうちせいぜい4つくらいだし、
B宗1派とB宗2派のように一つのゲームに両方採用(設定変更)できるものも。

> 当初の定義だとB宗1派に明確に分類される。

リフレッシュレートに関する論争スレでは
B宗2派とは別名、60Hz原理教のような扱いだったと思う。
彼らの経典によれば
リフレッシュレートとは即ち60Hzのことであり
60Hzができない環境は窓から放り投げろ。と。

> A宗B宗の定義は、もう実用にはならないんじゃないか？
　
Yep

そもそもＡ宗って描画が落ちようがＣＰＵ処理が落ちようが、
ゲームの処理速度を安定させるものだと思うんだけど。

Ｂ宗のＣＰＵ処理固定主義とは根本的に違くない？

>>185
ＣＰＵ処理落ちたらゲームの処理速度は一定してないんじゃ？
Ａ宗は見掛けの速度をなるべく一定にするやり方でしょ

あー、そうそう。
見掛けの速度を安定させるってことを言いたかった。

んでＢ宗って描画が落ちた場合はフレームスキップとかできるけど、
ＣＰＵが落ちた場合処理落ちするしかないよね？

だから何が起きても見掛けの速度を一定にしたい場合は
Ａ宗しかないんじゃないかなって。

なんか、変な方向にすすんでない？

A宗で書くのはつらい。

でもB宗でも見かけの速度を一定にしたい。
だから A 宗でぐるぐる回して、B宗スレッドにイベントを送信することでA宗でもB宗の記述方式ができるようにしたい。

で、そのさいの同期処理ってどーやるの？って話じゃないの？このスレって。

>>188
いろいろあってゲームループ総合スレになってるらしい。

ん？
たとえば、メインのゲームループは1/60sec決め打ちで回して、
メインのゲーム進行処理、キー入力、リプレイのロギングみたいなのは、
１/60で回ってるゲームループに同期させる。

で、絵とか音の表示やアニメは、イベントとして適当なバッファにキューイングして、
仮想フレームレート相当の時間経過とかVsyncをトリガに、ループ内か別スレッドで、
キューしておいたイベントを見ながら前回描画の経過時間を考慮しつつ
補間しながら絵を描けば、それで済む話じゃないの。

元々、ゲーム専用機のVsync同期は、Vsync割り込みを高速タイマの代用に
していただけだし、なんでそこまでVsyncにゲームの進行速度まで依存させ
たがる人がいるのかﾜｶﾗｿよ。

CPUパワーは資源だから。
でいいんじゃないかな。

>>190
VSyncの意味がわかってないようで・・・

>Vsync割り込みを高速タイマの代用にしていただけ

馬鹿に限って偉そうにダラダラ語りたがる好例。

191 ：名前は開発中のものです。：04/12/17 22:48:03 ID:6ejKXcKZ
〜〜〜〜〜〜〜〜　36日経過。ｽﾚ深度186　〜〜〜〜〜〜〜〜〜
192 ：名前は開発中のものです。：05/01/23 20:29:14 ID:Air0xk8V
193 ：名前は開発中のものです。：05/01/23 20:34:37 ID:JtLG4rmH

>>194 = >>190 だなｗ

ほんとに馬鹿だな
2chブラウザで更新チェック仕掛けとけばどんなに深くても一瞬なんだが

どれだけVBlank中に苦労したか・・・ヽ(｀Д´)ノ

>190
モレは2Dシューティング作ってたが、内部で画面の更新をする周期と
ゲームのタイミングは完全に同じじゃないと困る。
完全に同期してないと、移動キャラが一ドット進まなかったり
２ドット進んだりする。自機を移動させると
かくん…かくん…という感じでほんの少しぎこちなくなる…

FF7とか3Dのゲームならもともと30FPSとかでもそれなりに見えるし、
関係ないんだろうけど

>>198
それは、画面の更新の2倍速以上の周期でゲームループをまわせば良いんじゃないの

>>195
私はあなたの主張を全力かつ必死で否定します。
何故なら私は>>190の手法に懐疑的な立場を取る人だからです。
　
>>190は状態遷移の時間ステップは1/60[s]で行うことで良いと言います。
しかし60[Hz]近傍の画面更新周波数を採用する場合に
ゲームによっては許容が困難なアーティファクトを呈します。
　
ひとつは状態遷移と画面更新の共鳴によってもたらされます。
>>190は補間すると言います。これは時間tを媒介変数とする3次
パラメトリック曲線パッチに物体軌道を追従させることと推定されます。
しかしこれはプレイヤーの感じる周期的な違和感を抑制はするものの
完全に除去することが難しいことを>>190は知るべきです。

s/時間tを媒介変数とする//
s/3次//

アーティファクトてw

アーティファクト

一度言ってみたかったのです。私も必死なのです。

アーティファクトも知らないお漬物がいるな。
CGプログラマ方面ではよく使われる言葉だから、覚えておきなさい。

>>205
で、アーティファクトってなんなんだい？
俺CGプログラマじゃないからわからんよ

一応ぐぐればわかる類の単語ではあるな
http://216.239.63.104/search?q=cache:yWVXkJ9vKzwJ:www.radiumsoftware.com/0401.html+%E3%82%A2%E3%83%BC%E3%83%86%E3%82%A3%E3%83%95%E3%82%A1%E3%82%AF%E3%83%88%E3%80%80CG%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0&hl=ja&lr=lang_ja

artifact
《名-1》アーチファクト,技能(art)によって作り出したもの,人工物,加工品,工芸品,芸術品,所産,
作り事,《名-2》作為,人為的な結果[影響],《名-3》〔技術上の原因による〕不自然な結果,例えば,
不適切な統計処理の結果現れたパターンなど,《名-4》《コ》不可逆圧縮に伴う悪い副作用,動画
のブロックノイズなど,通例,複数形で

モアレとかマッハバンドとかがいい例じゃないかね。

レスが無いからって自演しなくてもいいだろ・・・

誰に言ってるんだ

PCでもやっぱり内部処理と描画処理は切り分けた方が動作効率良いんですか？

http://pc5.2ch.net/test/read.cgi/prog/1108481342/175
http://pc5.2ch.net/test/read.cgi/prog/1108481342/176-177
http://pc5.2ch.net/test/read.cgi/prog/1108481342/253-254

描画と処理順序に関係する話題なのでなんとなく転載。
でもスレ違い気味。というより、家庭用機のハードウェアの話だし、板違いだよなあ…。

そのネタ、シューティングスレともこのスレとも関係ないよ。

一言で言うと、元スレの175は
PSとかDCとかで起きてる、ハードウェアの描画パイプラインによる遅延を、
スプライト機能がないせいだ（フレームバッファのせいだ）と勘違いしている。
昔はこういうオヤジがよくいて更正に困った。

176-177はまったくの的外れ。

せっかくだから
s/オヤジ/スプライトオヤジ/

内部fps120描画fps60ってのを試しにやってみて
FPS更新処理をABAさんとこのソースのまんまでやってみたが
描画一回に対する更新フレーム数の分布がこんな感じになった。
1frame=159, 2frame=3351, 3frame=144, 4frame=1, 5frame=4
そりゃ2frameが多いのは当たり前なんですが、
どうもリフレッシュレートと内部フレームが重なりかける瞬間、
見るからに、1frame→3frame→1frame→3frame→…
って感じで振動(？)してしまうらしい。何故こうなるんだろ

XNAをまたれよ

待てない

保守

VistaでついにWindowモードで垂直同期待ちできるようになったらしいぞ！

んあ、前からできたよ。

>>220
どうやってやるの？

>>219
というか、ほとんどが液晶モニタの現代ではそもそも「垂直同期」なんて発生しようがないわけだがｗ

>>222
んなわけない。
ビデオカードからモニタに送る信号は走査線の順だし、
同期信号はアナログモニタを考慮したタイミングになっている。

>>222
アホ

９条は改憲してはならない。日本の為にならない。
日本人ではない朝鮮総連や民団でさえ、日本を心配して改憲への反対運動を行ってくれている。
私は日本人だが、「改憲すべき」などという者は、日本人として彼らに恥ずかしいと思います。

Ｑ．中国から身を守る為、戦争に対する抑止力が必要では？
Ａ．前提から間違っています。そもそも、中国は日本に派兵しようと思えばいつでもできました。
　　なぜなら、日本は９条があるため、空母や長距離ミサイル等「他国を攻撃する手段」がない。
　　つまり、日本に戦争を仕掛けても、命令をだした幹部の命や本国の資産は絶対に安全なのです。
　　にも関わらず、中国は、今まで攻めずにいてくれたのです。

Ｑ．日米安保も絶対ではないのでは？
Ａ．いえ、絶対です。
　　知り合いの韓国人の評論家もそう言っていますし、私も同じ考えです。
　　そして日米安保が絶対なら、日本を攻める国はなく、改憲の必要はありません。
　　米国と戦争をしたい国はないからです。

Ｑ．９条が本当に平和憲法なら、世界中で（日本以外に）１国も持とうとしないのはなぜか
Ａ．誤解を恐れずに言うなら、日本以外のすべての国が誤っているとも言えます。
　　「敵国に反撃できる手段を持つ国は攻められづらい」というのは、誤った負の考え方です。
　　（もっとも韓国や中国の軍に関しては、日本の右傾化阻止の為でもあるので例外ですが）
　　さらに日本の場合、隣国が韓国・中国・ロシアと、GDP上位の安定した国ばかりです。

【改憲】ゼンガクレン老闘士、国民投票法案廃案訴え 国会前集結 「ゲバ棒が杖になっても」
ttp://news21.2ch.net/test/read.cgi/dqnplus/1174412397/l50
【広島】憲法９条遵守を訴え　武器を持たない妖怪「ねずみ男」に扮した男が全国行脚
ttp://news22.2ch.net/test/read.cgi/newsplus/1175835543/l50

>>221
DirectX9以降はPresent時に適切なオプションを与えるだけで
窓モードでもティアリング無しで描画できるわけだが。

>>226
知らんかった

ティアリングが無い分、描画は遅れるんだよな

536　名前は開発中のものです。　[sage]　2007/07/27(金) 13:37:27 ID:XlcDZqW/
そう言えば同じ氏の本でバーチャファイターみたいな3D格闘本が近所に入荷されてた。
他のサンプル系のように1ヶ月くらいでまた返品されるだろうけどｗ

いきなり、冒頭で「60フレームが…」って固定fpsの話になってた。
PCなら可変フレームにしようぜって思ったよ。
一通りの内容は書かれてるようだけど、古い考え方が散見されるので注意ねｗ

3D格闘ゲームプログラミング
ttp://www.amazon.co.jp/dp/4797341807/

539　名前は開発中のものです。　[]　2007/07/28(土) 04:23:00 ID:HcOV0dC3
可変FPSだといろいろと弊害が('A`)

リプレイとか、どうすんだろ
FPSとか可変で、リプレイやってるよね・・・

スレ違いならいいところ教えてほしい

540 名前は開発中のものです。　[sage]　2007/07/28(土) 04:36:40 ID:yAMlpWBw
処理は固定で表示を可変にするんじゃないのか？

541 名前は開発中のものです。　[sage]　2007/07/28(土) 13:27:46 ID:0aIeWbas
実時間でタイムラインきればいいじゃないか。
ゲーム開始後、何msでパンチｒ入力開始っていう具合に。

542 名前は開発中のものです。　[sage]　2007/07/28(土) 14:49:45 ID:KJFTrgS8
グラフィックと内部処理を同期した場合、高スペックPCで記録したリプレイを
低スペックPCで再生すると大変なことに……

単純にスキップすればいい場合（オブジェクトの座標がすべて保存されてるなど）なら
問題にならないし、普通はFPSに上限を設けるのでせいぜい2倍遅い程度で済むけど

で、この「上限を設ける」を突き詰めると60FPS固定派がでてくるわけだ


推薦図書/必読書のためのスレッド in ゲ製作技術 2
http://pc11.2ch.net/test/read.cgi/gamedev/1136546780/

ほー

むしろ固定派のほうが主流だわな。海外のPCゲーでも。
A宗は潜在バグ入りこみまくりんぐ。

宗派って>>173のことか

1)固定にするしない
2)同期するしない
をわけて語ると、語りやすいのかな

今の話題なら同期については語らないことにすれば、誤解も少なそう、とか

スレの大半が、すれ違いでﾜﾛﾀ

メインで3フレーム目（3/60秒）時点でヒットしたのが
リプレイを、A宗で実行してしまったら
処理落ち(5/60秒ぐらい)とんでしまった場合
5/60秒移動した座標でヒットしたことになってしまって
再現出来んのじゃね？

とか思ったり。

やっぱ、細かい固定移動を複数回しかねーな。
ゲームシステムによるけど。

関係ないけど、
http://watch.impress.co.jp/game%2Fdocs/20060326/gdc_ha.htm
ここの動画のやつ動かしてる環境って
どのくらいのスペックなのかしら？

最新マシンでもリアルタイムじゃ無理くさくね？

こんな判定祭りは、固定複数回とかむずかしそうだけど。

スマブラXは、HAVOK使いつつ、
スローモーションとか早送りあるね
すごいね。

>>235
スマブラＸでのHavokの利用方法ですが、メインである格闘部分には使用されていません。

弾幕シューティングでフレームスキップしたらダメ？

ゲーセンでフレームスキップした弾幕シューティング（翼神ギガウイングなんちゃら）は、
よくしんとか散々言われ放題だったな

うん、ダメだと思うよ

シューティングはスキップさせるよりも、処理落ちさせた方がいいね。
ただ、PCの場合は環境によって処理能力に差があるから、環境によって
難易度が変わってしまうという問題があるが。

そうだね。PCなら、fpsを表示して、処理落ちが発生しているか常にプレイヤーに知らせておくのがよいね
ハイスコアの出たプレイをリプレイデータとして保存するとして、そこに処理落ちの度合いを記録しておくのもよい