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

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

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

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

**名前は開発中のものです。** · 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回まででは？

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

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

37 · 02/05/02 02:33

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

過去スレより
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宗に戻りつつあるような気がする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ない。

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

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

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

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

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

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

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

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

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

グローバル変数だ！

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

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

62 · 02/05/05 03:42

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

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

HALT

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

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

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

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

69 · 02/05/05 05:40

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

69 · 02/05/05 16:00

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

69 · 02/05/05 16:02

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

69 · 02/05/05 16:08

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

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

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

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

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

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

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

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

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

85 · 02/05/06 01:44

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

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

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

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

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

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

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

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

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

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

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

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

91 · 02/05/06 18:17

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

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

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

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

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

69 · 02/05/06 23:05

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

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

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

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

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

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

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

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

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

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

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

69 · 02/05/07 11:13

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

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

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

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

69 · 02/05/08 01:33

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

**処理安定** · 02/05/09 02:02

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

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

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

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

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

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

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

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

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

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

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

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

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

有名なネタではあるが。

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

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

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

PC房ってやつですか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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