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

1 名前：（;´д⊂ヽ [02/04/29 16:14 ID:Gsu.P7Dk] PCならではの可変フレームレートで、かつ安定したキー入力とか演算の微分処理とか 実装したいんですが、具体的に、どういう風な構造にすればいいのか全然わかりません助けて キー入力とかタイミングに厳しい処理を別スレッドで回すとして 描画担当スレッドはどーすればいいんでしょう？ （描画途中で別スレッドにより内部変数が書き換えられるケースが出てきますよね？） 114 名前：名前は開発中のものです。 [02/05/09 21:24 ID:V/9kUMis] Win2000の場合はデバイスマネージャーの IDE ATA/ATAPIコントローラーの プライマリIDEチャネルとセカンダリIDEチャネルで設定出来る。 115 名前：名前は開発中のものです。 mailto:age [02/05/09 21:31 ID:???] >>112 ＤＭＡオフでガタつくゲームってのも、問題アリだと思うが。 116 名前：名前は開発中のものです。 mailto:sage [02/05/09 21:50 ID:???] >ＤＭＡオフでガタつくゲームってのも、問題アリだと思うが。 CPUが高速なHDのデータコピーを汗かきながらI/Oへ書き込むので 全てのアプリで停止するのだよ。特に最近のHDは高速だから、 DMAなしではやってられない。 0.3秒くらいCPUがHDの転送に専念することもしばしば。 117 名前：名前は開発中のものです。 mailto:age [02/05/09 22:01 ID:???] >>116 ゲーム中はＨＤへアクセスしないようにするべし。 118 名前：名前は開発中のものです。 mailto:sage [02/05/09 22:08 ID:???] 自アプリがやらなくても他アプリがやったり ライトバックキャッシュのフラッシュや ページアウトでアクセスが発生しちまいますな 119 名前：名前は開発中のものです。 mailto:sage [02/05/09 22:28 ID:???] >>118 そうゆう話じゃないと思われ。 他のゲームはガタつかないのに自分のゲームはガタつく！ってのが問題。 120 名前：名前は開発中のものです。 mailto:sage [02/05/10 04:19 ID:???] >>119 >他のゲームはガタつかないのに自分のゲームはガタつく そんなこと誰か書いたっけ？ 121 名前：名前は開発中のものです。 mailto:sage [02/05/10 06:45 ID:???] 誰も書いてない 122 名前：名前は開発中のものです。 mailto:age [02/05/10 19:29 ID:???] 人に頼ってちゃダメだよ。 自分から行動を起こさなきゃ。 123 名前：名前は開発中のものです。 mailto:sage [02/05/11 04:24 ID:???] >ゲーム中はＨＤへアクセスしないようにするべし。 んー、学生さんかのぉ？ Windowsやlinuxなどのような高度なOSでは、 例えば malloc() などのヒープもアプリケーション実行開始直後は 物理メモリに存在しないことしばしばなのじゃよ。 new を呼んだ瞬間、物理メモリが存在しなかったら、そこでHDアクセス。 スタックがオーバーしたら、HDアクセス。 他のアプリが使用していたメモリをHDへ書き戻す作業であることが ほとんどなのじゃがな。 ゲームなど連続描画がシビアな環境では Windows上だとガタガタに見えてしまうのも、そこが原因だったりするんじゃ。 124 名前：名前は開発中のものです。 mailto:sage [02/05/11 15:53 ID:???] >>123 >Windows上だとガタガタに見えてしまうのも 見えませんが？ 125 名前：69 [02/05/11 17:18 ID:HivZaZZA] >>101解決？しました。 FPSを表示するのにFPSの抽出を60FPSとかにすると 更新が激しくて見づらいので、2FPS等で抽出させる 別のFPS制御クラスを作っていたんだけど、 ダイアログを表示する際にこいつは関係ないと思って サスペンドしていなかった為に、デッドロックが起こっていたようです。 結果論であり、デッドロックの理由はわかりませんが。 ::CreateWaitableTimerという便利そうなAPIを発見したんで こりゃ使えると思ってFPS制御クラスに組み込んだら、 こいつしっかりCPU時間を消費しやがんの。 使えね〜、精度も低いしサ。 >>123 そういうことをやっているかどうかは知らんけど、 やっていたとしても、それは単に物理メモリが少ない場合の 回避処置でしか無いと思うんだけど。 そりゃメモリが足りなくてスワップしまくりな環境なら ゲームもカクつくよ。 126 名前：99 [02/05/11 17:22 ID:.Lvp8gPk] -------風俗の総合商社・ＭＴＴどこでも------- 〇デリバリーヘルス〇デートクラブ〇女性専用ホストクラブ〇 〇ハードＳＭ奴隷クラブ〇レズビアン倶楽部〇ホモ・オカマ倶楽部 〇変態痴女と遊ぶ会〇痴漢・覗き趣味の会〇変態同好会・各種！ ●楽しく遊べます！　090-8002-8356番 -----------美男・美女会員など多数在籍中----------- 　 www.mttdocomo.jp/ -----女性アルバイト随時募集・高収入（日払い）月100万円可能----- -----レズビアン・スタッフ●ホモスタッフ●女性専用ホストスタッフ同募----- www.mttdocomo.jp/ 127 名前：名前は開発中のものです。 mailto:sage [02/05/12 08:31 ID:???] >やっていたとしても、それは単に物理メモリが少ない場合の >回避処置でしか無いと思うんだけど。 WinXPだとか、物理メモリあっても初アクセスまではアプリ用にメモリをcommit しないというのに、何を逝ってるのかな？ １０秒後に初めてアクセスした変数がメモリにまだcommitされてないページだった らHDアクセス決定じゃん。 128 名前：名前は開発中のものです。 [02/05/12 19:48 ID:IYwn5BLg] >>127 コミットされていないページ＝スワップアウトされてHDに退避させられているページ じゃないんじゃないの？ 単に仮想メモリが物理メモリにマップされてないだけで。 MSDNでVirtualAllocのページ見てみ。 つーかイチイチメモリ確保の度にHDDアクセスする訳ないじゃん。 常識的にアホ仕様だろそれじゃ。 129 名前：名前は開発中のものです。 mailto:sage [02/05/12 20:43 ID:???] その話題はスレ違いっぽいので他でやってくれんか たとえば pc.2ch.net/test/read.cgi/tech/1017072275/ 130 名前：名前は開発中のものです。 [02/05/14 21:35 ID:ru/D90z6] 　 131 名前：名前は開発中のものです。 [02/05/19 11:18 ID:ajzZw3lo] >>128 >コミットされていないページ＝スワップアウトされてHDに退避させられているページ じゃないんじゃないの？ ↓ コミットされていないページ＝まだ存在していないページ >つーかイチイチメモリ確保の度にHDDアクセスする訳ないじゃん。 Windows はダーティなページを極力メモリに保持し続ける方針で設計されている為、 いざページをコミットしようとすると、すぐに使えるメモリが足りなくて、結果的にページアウトが発生してしまう。 当然未使用メモリがある場合は、 HD へのアクセスは無い。 132 名前：名前は開発中のものです。 mailto:sage [02/05/19 15:25 ID:???] だからスレ違いだっての。日本語わからないのか？ 133 名前：名前は開発中のものです。 mailto:sage [02/05/20 01:16 ID:???] >>132 まぁ言いたいことは分かるが あまり騒ぐと自治厨氏ねとか不本意な罵りを浴びるぞ。 134 名前：名前は開発中のものです。 mailto:sage [02/06/01 20:55 ID:???] 別に俺はここでこの話題をしてもいいと思うが… 3、4レスのためだけに別スレに移動なんてしてたら、 話の一貫性がなくなってしまうだろう。 135 名前：名前は開発中のものです。 mailto:sage [02/06/02 11:58 ID:???] だって知識が乏しい連中ばっかなんだもん 136 名前：名前は開発中のものです。 mailto:sage [02/06/03 11:14 ID:???] では貴殿の知識を開陳せよ。 他人を蔑むだけのカキコって、技術レベルに関係なくなんかむかつく。 137 名前：名前は開発中のものです。 mailto:sage [02/07/22 05:33 ID:???] 可変フレームレートってどういういうものでしょう。 60FPS出るように作って、処理が遅れたら処理落ちすれば いいだけなのでは、、、？ 3Dのゲームなら３０FPSくらいが普通でしょうか。 138 名前：名前は開発中のものです。 mailto:sage [02/07/24 05:29 ID:???] >137 v' += v * dt みたいな感じかな…。 具体的な実現方法は何パターンかあると思います。 どっかのｽﾚでそんな議論してたと思った。役に立たなくてｽﾏｿ 139 名前：ｵﾏﾝｺｰ&rlo;ｰﾟﾎﾝｨﾃ&lro; mailto:sage [02/10/26 08:35 ID:???] 140 名前：名前は開発中のものです。 mailto:age [02/11/01 08:50 ID:???] 漏れら極楽人道のageブラザーズ！ 良スレっぽいものは強制的にageてやるからな！ ￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ 　 ∧＿∧ 　 ∧＿∧ 　　　age 　（・∀・∩）（∩・∀・）　　　　age 　（つ　　丿 （ 　　⊂）　age 　 （　ヽノ　　 ヽ/　　）　　　age 　 し（＿）　　 （＿）Ｊ 141 名前：あぼーん mailto:あぼーん [あぼーん] あぼーん 142 名前：名前は開発中のものです。 [02/11/28 05:24 ID:EVnGiSza] 　　　　　＿＿＿＿_＿ 　　　 ／＿　　　　　　| 　 　 /.　＼￣￣￣￣| 　　/　　／　 ―　― | 　　|　 /　　 （･）　（･）| 　 ||| (6　　　　　　>　| 　| | |　　　　 ┏━┓|　　 ／￣￣￣￣￣￣￣￣ | | | | 　　　　┃д┃|　 ＜　正直、ageてすまん || | | | 　＼　┃　 ┃/　 　 ＼＿＿＿＿＿＿＿＿ | || |　|　　　￣　￣| 143 名前：あぼーん mailto:あぼーん [あぼーん] あぼーん 144 名前：名前は開発中のものです。 [02/11/28 07:20 ID:Ib7kWWVj] 自分の考えだと時間でDTだして変数にかけるのは駄目。 当たり判定なんかで絶対死ぬ。 面倒臭くて作ってられない。 よしんば自分は制御できても他の人はできないでしょ。 ネトゲはしかたないけど。 別に必要がないならフレーム飛ばしで対応が一番楽。 145 名前：あぼーん mailto:あぼーん [あぼーん] あぼーん 146 名前：名前は開発中のものです。 mailto:sage [02/11/29 00:07 ID:MjrDrSuB] 厳密にやろうとしなければOKでしょ。 ピンボールゲームとかビリヤードとかだとそれじゃまずいんだけどさ。 147 名前：名前は開発中のものです。 [03/06/26 13:32 ID:p0CgQeLa] 保守 148 名前：名前は開発中のものです。 [03/06/26 13:49 ID:+zxBVEy/] GDAlgorithms-listあたりの議論では、内部フレームレートは固定で、 時間軸で補間描画するのが主流っぽく見えた。 ただ、これもコンストレインツとかいろいろ面倒ごとが絡んできそうだけど。 149 名前：名前は開発中のものです。 [03/06/26 19:48 ID:5GfwaFR5] >>144 物理シュミレーションで 短い期間に衝突が起こりまくるとかかな？ でも固定フレームだとすり抜けが心配になるんだよね。 150 名前：名前は開発中のものです。 mailto:sage [03/06/27 06:02 ID:rPLXqI2z] うちは、内部処理フレームレート固定、描画処理は追いつかなければ飛ばす方向でやってます。 151 名前：名前は開発中のものです。 mailto:sage [03/06/27 06:04 ID:rPLXqI2z] >>149 固定フレームレートでのすり抜けの問題は、非固定でも同じかと。 結局、補完して判定したり、繰り返し判定しないといけないのは変わらないのでは 152 名前：名前は開発中のものです。 mailto:sage [03/06/27 08:57 ID:ixQrGkNZ] うちは、ゲームループや他のワーカースレッドではDirect3Dの命令を一切コールせずに、 独自のプリミティブ命令を描画スレッド(っていうかサーバ)に発行する形。 描画スレッドはプリミティブ命令をバッファリングして適当なタイミングで画面を構成する。 ワーカースレッドは発行したプリミティブ命令が正しく描画されたかは関与しないので、 ゲームループに描画サイクルが間に合わない場合はフレームがスキップされるし、 ゲームループが遅すぎる場合はコマ送りになる。 153 名前：名前は開発中のものです。 [03/06/28 02:00 ID:aSb9r1M8] Ｈなサイトを発見したでつよ。ここ、すごい。 plaza16.mbn.or.jp/~satchel/omanko_marumie/ 美少女のワレメ…(*´∀`*)ハァハァ 美人お姉さんのオマ○コ…(*´Д`*)ハァハァ 154 名前：名前は開発中のものです。 [03/06/28 09:56 ID:MijJhoN2] >>152 だから固定フレームレートだろ？ 155 名前：名前は開発中のものです。 [03/06/28 10:56 ID:zsEm8tDY] www.k-514.com/sample/sample.html 拾ったサンプルムービー集めたよ 156 名前：名前は開発中のものです。 [03/11/02 21:05 ID:dOIWbDqO] 固定フレームレートですり抜けが起きるか起きないかは 実装する前に予測できるじゃん 157 名前：名前は開発中のものです。 mailto:sage [03/11/02 22:35 ID:1l/gGn+E] コリジョンは厳密にやろうとすればするほど奥が深い分野だよ。 とくにリアルタイム性が必要になると(論文ネタになる、というかなったくらいだし)。 まぁ、厳密性が求められないなら、>>156のように割り切って実装するのが吉。 158 名前：名前は開発中のものです。 mailto:sage [03/11/04 09:01 ID:CMviRQzL] あれ？コリジョンスレどこいった？ 159 名前：名前は開発中のものです。 mailto:sage [03/11/04 16:54 ID:1XiY25f5] >>158 ここ？ 【Collision Detection】 pc2.2ch.net/test/read.cgi/gamedev/1015484028/ 160 名前：名前は開発中のものです。 mailto:sage [04/12/04 17:37:32 ID:mVDy3Uy+] ガイジンのいろんな開発者から話聞く限り、あっちもA宗なんか使ってないよ？ 状態遷移はB宗、表示は補間でリフレッシュレートに同期とか、 状態遷移の粒度を思いっきり上げるとか、そういうのが主流。 コンシューマやアーケードはやっぱり60fps決め打ち。 PAL圏で速度変わろうがｼﾗﾈ（ﾟ�听） PS2やXboxになろうがファミコン時代と何も変わってないのさ。 とにかく、状態遷移の粒度が変わるとどんなタイミングで何が起こるかわからんので皆嫌がる。 サンプルプログラムレベルならともかく、中規模以上のゲームでA宗って例は知らんね俺は。 だいたい日本人だけが困ってる問題じゃない。 同じ環境でコード書いてる限り、ガイジンだけが特効薬持ってたりするわけないじゃん。 あと最近のDirectXはSetDisplayModeで素直にリフレッシュレート変わったりとか、 ほとんどの液晶ディスプレイは60Hz固定だったりとか、 いろんなリフレッシュレートに対応するメリットがかなり薄れてる。 プライオリティとしては、むしろ先に解像度決め打ちを廃絶するべきだな。 161 名前：名前は開発中のものです。 mailto:sage [04/12/04 17:58:18 ID:kfKbWf9i] 本当にA宗使ってないの？ 最近出たPCの3DゲームでA宗じゃないの教えて欲しい。 162 名前：名前は開発中のものです。 mailto:sage [04/12/05 00:42:57 ID:GrFe+qNV] >>160 なんで解像度なんだよ？ リフレッシュレートの話しておきながらｗ 163 名前：名前は開発中のものです。 mailto:sage [04/12/05 13:40:24 ID:3zCSSlsK] >>161 普通にBが良いと思うよ。 Aだとフレームレートで細かい挙動が変わっちゃうでしょ。 その結果 > とにかく、状態遷移の粒度が変わるとどんなタイミングで何が起こるかわからんので皆嫌がる。 となる。 まぁ、問題にならないような状況なら好きにすればいいんじゃね？ 164 名前：名前は開発中のものです。 mailto:sage [04/12/05 15:37:20 ID:QEq2K2Fz] A宗だとリプレイも実装できないし。 165 名前：名前は開発中のものです。 mailto:sage [04/12/06 12:10:39 ID:nOjB+322] A宗でリプレイ実装できないやつは地沼 しかし解像度依存をなんとかせにゃならんのは同意 低解像度にすると画面中インターフェースで埋め尽くされるのとかアホすぎ だが拡縮に耐えられるデザインをするのは難しい 166 名前：名前は開発中のものです。 mailto:sage [04/12/08 17:57:08 ID:OfSHCP0i] > A宗でリプレイ実装できないやつは地沼 詳しく 167 名前：名前は開発中のものです。 [04/12/13 13:45:32 ID:oLS390rH] PCでB宗だとリフレッシュを変更せねばならずユーザーに嫌われる件について。 168 名前：名前は開発中のものです。 mailto:sage [04/12/13 15:00:58 ID:3e0kR3Ey] B宗のなかでもリフレッシュレート変更がいらないものにして対処 B宗1派とか > 状態遷移はB宗、表示は補間でリフレッシュレートに同期 > 状態遷移の粒度を思いっきり上げる これとか 169 名前：名前は開発中のものです。 mailto:sage [04/12/13 15:14:09 ID:aofj8uyk] >>164 フレームごとに時間を記録しておけばおｋ 再生時のフレームスキップの処理は必須 170 名前：名前は開発中のものです。 mailto:sage [04/12/13 15:23:24 ID:KD6ePPwD] 質問です。 ◆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 171 名前：名前は開発中のものです。 mailto:sage [04/12/13 19:57:15 ID:gHIs8Crz] 大丈夫か？ 172 名前：名前は開発中のものです。 mailto:sage [04/12/13 20:02:17 ID:OAPFomE2] なんでそうなる。前者は計算、後者は描画の話だらーが。 173 名前：名前は開発中のものです。 mailto:sage [04/12/13 20:34:15 ID:twbQb5tx] >>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に無理やり固定 174 名前：名前は開発中のものです。 mailto:sage [04/12/13 20:38:11 ID:twbQb5tx] >>173のユーザーCとDの例を使ってひきつづき書いてみる。 >>169の方法だと、ユーザーCのリプレイをユーザーDが再生するときには 秒間70回値更新で描画は適当(ユーザーDの環境に合わせたもの)、 ユーザーDのリプレイをユーザーCが再生するときには 秒間100回値更新で描画は適当(ユーザーCの環境に合わせたもの)、 となるのでは。 >>160にならい、状態遷移の粒度がユーザーの環境によって変化するのがA宗、とするならば、 >>169のはA宗のリプレイ再生方法でなく、B宗1派のリプレイ再生方法なのでは。 というわけで>>164-166へループ。 175 名前：174 mailto:sage [04/12/13 21:54:27 ID:ZvpPKfOH] >>174の最後2行、間違えました。申し訳ない。A宗で合ってますね。 A宗が状態遷移と描画を同じ周期で行わなければならないなんて決まりはないし、フレームスキップしてあたりまえだし。 ・状態遷移の粒度がユーザーの環境によって変化するか 　（v += a * dt か、v += a か） ・状態遷移の同期をタイマーでとるかv-syncでとるか ・ディスプレイのリフレッシュレートを、ユーザーの環境と関係ない固有の値で固定するか ・状態遷移と描画を同じ周期で行うか がごっちゃになって混乱してました。 176 名前：名前は開発中のものです。 mailto:sage [04/12/14 00:23:44 ID:JuD5jtQu] ＞A宗が状態遷移と描画を同じ周期で行わなければならないなんて決まりはないし、フレームスキップしてあたりまえだし。 　 あるいは、A宗は過激派と穏健派に分かれるということではないか。 A宗過激派・・・全てリフレッシュレートに同期。画面更新だけでなく数値積分のタイムステップも何もかもリフレッシュレートに同期。 A宗穏健派・・・（ティアリングの無い）滑らかな社会を実現するために画面更新はリフレッシュレートに同期させよう。 177 名前：訂正 mailto:sage [04/12/14 00:26:58 ID:JuD5jtQu] A宗過激派・・・全てリフレッシュレートに同期。画面更新だけでなく数値積分のタイムステップも何もかもリフレッシュレート基準。 A宗穏健派・・・（ティアリングの無い）滑らかなスクロールを実現するために画面更新はリフレッシュレートに同期させよう。 178 名前：名前は開発中のものです。 mailto:sage [04/12/14 02:01:20 ID:xwWJYjIC] 話をずらしてすまないんだけど xnew = xold + v; ってやる場合、新しい位置用のメモリ領域と、旧位置用のメモリ領域が必要になるよな？ これを描画するとき、リフレッシュレートスレの結論から x = xold + (xnew-xold) * Δt / T (T = 1フレームぶんの時間) とかやってた。 でもって、スレッド分けの最大の利点は画面更新計算の間でも位置更新の計算が出来るってことだと思うんだ。 すると、描画用のメモリ領域と、位置更新計算用のメモリ領域を分ける必要があるよな？一緒にしちゃうととんでもないよな？ つーとメモリ領域は、新旧 * 描画用、位置更新用 の計４領域？必要になるってことか。すげーな。 位置更新用のメモリ領域は、描画直前に更新が発生してたら描画用のメモリ領域にコピーされる？ コピー中に位置更新が発生しないように同期オブジェクトを一つかませば出来るような気がするんだけどどう？？ おれ、はっきり言ってバイトと卒論で趣味プログラムしてる暇ないんだけど、だれか試してみてくんない？ 179 名前：名前は開発中のものです。 [04/12/14 23:27:44 ID:uNvp6fIy] >>176-177 あー。以前STGスレで自分はA宗であると告ったら その過激派のほうだと思われたらしく リプレイの件でチクチク突っつかれた。 　 俺は、A宗を名乗る上での必要条件は ・ティアリング排斥 ・スムーズスクロール至上主義 だと思っている。 　 >>178 ＞描画用のメモリ領域と、位置更新計算用のメモリ領域を分ける必要があるよな？ ＞一緒にしちゃうととんでもないよな？ 　 なぜそう思う。 深刻なアーティファクトが出るかどうかは状況による。 作れば一見してわかる話だ。 ＞コピー中に〜中略〜だれか試してみてくんない？ 趣味プログラミングの醍醐味のひとつは 試行の自由を与えられることなのであり その権利を行使せず無為に悩むは損かと。 180 名前：名前は開発中のものです。 mailto:sage [04/12/14 23:48:04 ID:uNvp6fIy] つかリプレイとぜんぜん関係ない話してるし。ﾜﾘ。 >>172 同意。 ゲームワールドの状態遷移を再現できるかどうかの話と A宗B宗は無関係。 181 名前：名前は開発中のものです。 mailto:sage [04/12/14 23:52:15 ID:uNvp6fIy] s/ゲームワールド/各オブジェクト/ 182 名前：178 mailto:sage [04/12/15 07:18:24 ID:QtJ8QeQp] >179 描画用と更新用を一つにしちゃうと、描画の位置計算中に描画の素になるデータを書き換えられちゃわないかな？ と思ったんだけど、どうだろう。 描画が終わるまで待つんだったら、そもそもスレッド分ける意味がないと思うし。 >趣味プログラミングの醍醐味のひとつは試行の自由を与えられることなのでありその権利を行使せず無為に悩むは損かと。 う。２月まで覚えてられるかな・・・自信ねー。○|￣|＿ 183 名前：名前は開発中のものです。 mailto:sage [04/12/15 13:43:03 ID:v1gXIgbp] >>179 当初の定義は、 ・数値積分のタイムステップを環境依存させるかで A宗 B宗1派 を分けている ・描画をどうするかでは分けていない この定義だと、A宗は>>177のいう過激派しか認められないことになる。 >>179がA宗穏健派として状態遷移タイムステップをv-sync非依存にしているとしたら、 描画をリフレッシュレート同期にしていても関係なく、当初の定義だとB宗1派に明確に分類される。 A宗B宗の定義は、もう実用にはならないんじゃないか？ 元々の定義は描画にはふれず状態遷移のみにふれているため、 >>179が過激派と思われたように意図を伝えられないことがある。 代案としては…。>>175の4要素16派に分類すれば多少マシだが、あのままでは煩雑だ。 話題になるのは16派のうちせいぜい4つくらいだし、 B宗1派とB宗2派のように一つのゲームに両方採用(設定変更)できるものも。 184 名前：名前は開発中のものです。 mailto:sage [04/12/15 19:01:03 ID:h9T9p7ZJ] > 当初の定義だとB宗1派に明確に分類される。 リフレッシュレートに関する論争スレでは B宗2派とは別名、60Hz原理教のような扱いだったと思う。 彼らの経典によれば リフレッシュレートとは即ち60Hzのことであり 60Hzができない環境は窓から放り投げろ。と。 > A宗B宗の定義は、もう実用にはならないんじゃないか？ 　 Yep 185 名前：名前は開発中のものです。 [04/12/16 02:31:19 ID:tK2W+T4c] そもそもＡ宗って描画が落ちようがＣＰＵ処理が落ちようが、 ゲームの処理速度を安定させるものだと思うんだけど。 Ｂ宗のＣＰＵ処理固定主義とは根本的に違くない？ 186 名前：名前は開発中のものです。 mailto:sage [04/12/16 02:56:42 ID:hmZX33Sk] >>185 ＣＰＵ処理落ちたらゲームの処理速度は一定してないんじゃ？ Ａ宗は見掛けの速度をなるべく一定にするやり方でしょ 187 名前：名前は開発中のものです。 [04/12/16 03:35:18 ID:tK2W+T4c] あー、そうそう。 見掛けの速度を安定させるってことを言いたかった。 んでＢ宗って描画が落ちた場合はフレームスキップとかできるけど、 ＣＰＵが落ちた場合処理落ちするしかないよね？ だから何が起きても見掛けの速度を一定にしたい場合は Ａ宗しかないんじゃないかなって。 188 名前：名前は開発中のものです。 mailto:sage [04/12/16 09:18:07 ID:DxYxxvNb] なんか、変な方向にすすんでない？ A宗で書くのはつらい。 でもB宗でも見かけの速度を一定にしたい。 だから A 宗でぐるぐる回して、B宗スレッドにイベントを送信することでA宗でもB宗の記述方式ができるようにしたい。 で、そのさいの同期処理ってどーやるの？って話じゃないの？このスレって。 189 名前：名前は開発中のものです。 mailto:sage [04/12/16 19:27:32 ID:fImvV4sn] >>188 いろいろあってゲームループ総合スレになってるらしい。 190 名前：名前は開発中のものです。 mailto:sage [04/12/17 07:34:10 ID:rOSemwp/] ん？ たとえば、メインのゲームループは1/60sec決め打ちで回して、 メインのゲーム進行処理、キー入力、リプレイのロギングみたいなのは、 １/60で回ってるゲームループに同期させる。 で、絵とか音の表示やアニメは、イベントとして適当なバッファにキューイングして、 仮想フレームレート相当の時間経過とかVsyncをトリガに、ループ内か別スレッドで、 キューしておいたイベントを見ながら前回描画の経過時間を考慮しつつ 補間しながら絵を描けば、それで済む話じゃないの。 元々、ゲーム専用機のVsync同期は、Vsync割り込みを高速タイマの代用に していただけだし、なんでそこまでVsyncにゲームの進行速度まで依存させ たがる人がいるのかﾜｶﾗｿよ。 191 名前：名前は開発中のものです。 mailto:sage [04/12/17 22:48:03 ID:6ejKXcKZ] CPUパワーは資源だから。 でいいんじゃないかな。 192 名前：名前は開発中のものです。 mailto:sage [05/01/23 20:29:14 ID:Air0xk8V] >>190 VSyncの意味がわかってないようで・・・ 193 名前：名前は開発中のものです。 mailto:sage [05/01/23 20:34:37 ID:JtLG4rmH] >Vsync割り込みを高速タイマの代用にしていただけ 馬鹿に限って偉そうにダラダラ語りたがる好例。 194 名前：晒しage mailto:age [05/01/23 22:57:22 ID:34KIVQ9x] 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 195 名前：名前は開発中のものです。 mailto:sage [05/01/24 00:09:20 ID:Am/KGoi6] >>194 = >>190 だなｗ 196 名前：名前は開発中のものです。 mailto:sage [05/01/24 02:05:01 ID:QUF1Uv+C] ほんとに馬鹿だな 2chブラウザで更新チェック仕掛けとけばどんなに深くても一瞬なんだが 197 名前：名前は開発中のものです。 [05/01/24 02:50:03 ID:Pb4FhWzL] どれだけVBlank中に苦労したか・・・ヽ(｀Д´)ノ 198 名前：名前は開発中のものです。 mailto:sage [05/01/24 09:00:45 ID:MwYTmyiP] >190 モレは2Dシューティング作ってたが、内部で画面の更新をする周期と ゲームのタイミングは完全に同じじゃないと困る。 完全に同期してないと、移動キャラが一ドット進まなかったり ２ドット進んだりする。自機を移動させると かくん…かくん…という感じでほんの少しぎこちなくなる… FF7とか3Dのゲームならもともと30FPSとかでもそれなりに見えるし、 関係ないんだろうけど 199 名前：名前は開発中のものです。 mailto:sage [05/01/24 21:39:05 ID:Am/KGoi6] >>198 それは、画面の更新の2倍速以上の周期でゲームループをまわせば良いんじゃないの 200 名前：194 mailto:sage [05/01/24 21:57:23 ID:6rvdu/5R] >>195 私はあなたの主張を全力かつ必死で否定します。 何故なら私は>>190の手法に懐疑的な立場を取る人だからです。 　 >>190は状態遷移の時間ステップは1/60[s]で行うことで良いと言います。 しかし60[Hz]近傍の画面更新周波数を採用する場合に ゲームによっては許容が困難なアーティファクトを呈します。 　 ひとつは状態遷移と画面更新の共鳴によってもたらされます。 >>190は補間すると言います。これは時間tを媒介変数とする3次 パラメトリック曲線パッチに物体軌道を追従させることと推定されます。 しかしこれはプレイヤーの感じる周期的な違和感を抑制はするものの 完全に除去することが難しいことを>>190は知るべきです。 201 名前：194 [05/01/24 22:01:08 ID:6rvdu/5R] s/時間tを媒介変数とする// s/3次// 202 名前：名前は開発中のものです。 mailto:sage [05/01/24 23:52:46 ID:ZznnHdPs] アーティファクトてw 203 名前：名前は開発中のものです。 [05/01/25 00:23:51 ID:dxQ4cffY] アーティファクト 204 名前：194 mailto:sage [05/01/25 00:44:12 ID:rMY0ZJDT] 一度言ってみたかったのです。私も必死なのです。 205 名前：名前は開発中のものです。 mailto:sage [05/02/08 03:07:12 ID:TagBEX16] アーティファクトも知らないお漬物がいるな。 CGプログラマ方面ではよく使われる言葉だから、覚えておきなさい。 206 名前：名前は開発中のものです。 mailto:sage [05/02/08 17:45:03 ID:s3qPbjfn] >>205 で、アーティファクトってなんなんだい？ 俺CGプログラマじゃないからわからんよ 207 名前：名前は開発中のものです。 mailto:sage [05/02/08 19:29:36 ID:Cn4cPs8N] 一応ぐぐればわかる類の単語ではあるな 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 208 名前：名前は開発中のものです。 mailto:sage [05/02/09 13:34:04 ID:kf+/5jfh] artifact 《名-1》アーチファクト,技能(art)によって作り出したもの,人工物,加工品,工芸品,芸術品,所産, 作り事,《名-2》作為,人為的な結果[影響],《名-3》〔技術上の原因による〕不自然な結果,例えば, 不適切な統計処理の結果現れたパターンなど,《名-4》《コ》不可逆圧縮に伴う悪い副作用,動画 のブロックノイズなど,通例,複数形で モアレとかマッハバンドとかがいい例じゃないかね。 209 名前：名前は開発中のものです。 mailto:sage [05/02/09 19:30:51 ID:SbvEbW11] レスが無いからって自演しなくてもいいだろ・・・ 210 名前：名前は開発中のものです。 mailto:sage [05/02/10 20:28:57 ID:Pq8Tvl+c] 誰に言ってるんだ 211 名前：名前は開発中のものです。 mailto:sage [05/02/26 02:15:04 ID:uFYBWVD/] PCでもやっぱり内部処理と描画処理は切り分けた方が動作効率良いんですか？ 212 名前：名前は開発中のものです。 mailto:sage [05/02/26 17:30:23 ID:eTx5dUeL] pc5.2ch.net/test/read.cgi/prog/1108481342/175 pc5.2ch.net/test/read.cgi/prog/1108481342/176-177 pc5.2ch.net/test/read.cgi/prog/1108481342/253-254 描画と処理順序に関係する話題なのでなんとなく転載。 でもスレ違い気味。というより、家庭用機のハードウェアの話だし、板違いだよなあ…。 213 名前：名前は開発中のものです。 mailto:sage [05/02/27 13:00:33 ID:ouQU2Gh6] そのネタ、シューティングスレともこのスレとも関係ないよ。 一言で言うと、元スレの175は PSとかDCとかで起きてる、ハードウェアの描画パイプラインによる遅延を、 スプライト機能がないせいだ（フレームバッファのせいだ）と勘違いしている。 昔はこういうオヤジがよくいて更正に困った。 176-177はまったくの的外れ。 214 名前：名前は開発中のものです。 mailto:sage [05/02/27 13:02:05 ID:ouQU2Gh6] せっかくだから s/オヤジ/スプライトオヤジ/

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef