リフレッシュレートに関する論争

あちこちでやってるようなので、まとめない？

あまり関係無いけどプラズマディスプレイってリフレッシュレートってどのくらい？

液晶はどうなん？

液晶にレフレッシュレートはない。

まとめると、オプションでVSYNC待ちのON/OFFが設定できると
一番いい。ユーザーが自分の環境にベストなものを選ばせれば
文句ないだろう。

>>5 ？？？ ＯＦＦにするメリットて何？

ショック！フルスクリーン専用にして６０Ｈｚ固定に
しちまおうとしたら、ChangeDisplaySettingsが効かない環境があるらしいです。
それどころかフリーズまでかましてくれるらしいです。
http://www.bio100.co.jp/cgi-bin2/directx/flashviw.cgi?no=8591&reno=8582
http://www.bio100.co.jp/cgi-bin2/directx/flashviw.cgi?no=8584&reno=8582
http://www.bio100.co.jp/cgi-bin2/directx/flashviw.cgi?no=8592&reno=8582
参照。
んで、画面のプロパティからリフレッシュレートをいじるようにしたいんですけど
640*480だと72Hzまでしか設定がないんですが、アダプタの既定値に
すると60Hzで動いてくれます。
この設定でほかの環境も60Hzになってくれるのでしょうか？

ちなみに調査の結果DirectX診断ツールの設定も
意味のない環境があることがわかりました。

また、MS-DOSプロンプトを立ち上げてAlt+Enterを押してフルスクリーンにすると
640*480の60Hzになりますが、これはどうやっているのでしょうか？
逆アセできる人がうらやましいです。

とりあえず、パンピーでも確実にリフレッシュレートを60Hzにする方法ってのは
どうやるのでしょうか？

>7
PC-9821は捨ててもいいとして・・・（怒られる？）
いきなり落ちる環境があるのは痛いですね。

お使いのビデオカード、恐らくWindows環境下では72Hz以下に
設定させないようにしてるだけだと思います。

パンピーでもできる方法、ＭＳに対応してもらうしかないのでは？
それか、リフレッシュレート変更できるかどうかチェックして、
ダメならタイマ使うしかないでしょうね。

つか、環境ごとの違いを吸収してくれるものだったんじゃなかったのか！
と、いつもの怒りを吐いて今日はもう寝ます。

これは宗教問題なんだ。

命題：「『1フレーム後に、変数v がa増加する』をどのように実装するか？」

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

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

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

------------
さて、、
なにかと騒いでいるのはB宗の信徒だ。
A宗はQuake系を筆頭に、洋物3Dゲーム。
珍しいことに、FalcomのYsII ETERNALはA宗だね。（ジャップのくせに）
どうやら、A宗の「v += a * dt」は、B宗の信徒には恐るべき異端教義に見えるみたいだ。

と言ったところで、「品質」について考えてみよう(ﾆﾔﾘ

A宗は死んでもやりたくネー。
会社にそこまで尽くすのはアホらし。
１２０Ｈｚなんて１フレームの処理が間に合わないよ。
俺はＢ宗２派でいくぜ！エロゲーだけども「がんぶる」という
ゲームのシューティングステージの品質が忘れられん。

Ａ宗は３Ｄなら許す。２Ｄはなあ・・・。

Ｂ宗２派が理想だが、ChangeDisplaySettingsどうやら万能でないらしいので
どうしたものか。

Ｂｉｏの掲示板の、問題のスレッド一覧。
http://www.bio100.co.jp/cgi-bin2/directx/flashviw.cgi?mode=set&no=8576

ドライバの仕業でなく、解像度−垂直同期固定のカードがあるのか？
そういうカードでＤＯＳは動くのか？

ＤＯＳのゲームかメガデモを動かしてみればはっきりするんじゃないかな？
ＶＥＳＡのドライバいらないやつね。

私は B宗1派 です
ゲーム自体の演算と描画はタイマーを使って目的のフレームレートに
フリップは必要になったタイミングでVSYNCに同期して更新しています
邪道ですか？

DOSが動くなら、640x480x60Hzのモードは絶対あるはずだ。
理由はわからないが、ドライバ側が列挙できないようにしてるんだろうね。

DOSの頃はこんなつまらねえ事で悩まなくてもよかったのに・・・。
あ、PC-9821Ap/As/Aeが出た時は困ったな。
垂直じゃなくて水平だけど。
31KHzにされると、いままでのソフトが・・・。

Bioの掲示板てわかってない人多いね。

Windowsでコンシューマ並みのゲームを！ってのが
そもそもの間違いなのかもしれないね。

X-BOX開発者を育成するための種まきだったのかもしれんな、DirectX。

Ｂｉｏ買っちゃうような人だからしかたないよ‥

だからChangeDisplaySettingsは使っちゃダメだってば。
もしゲームが途中でクラッシュしたら解像度変更されたままになっちゃぞ。
ユーザーの意思に関係なくコントロールパネル内のセッティングを
いじるようなソフトは最悪！

１５と１７の話がずれてるような気がするのは俺だけか

ネタだろ？

ｶﾀｶﾅ使おうよ　―　ﾊﾞｲｵ

＞だからChangeDisplaySettingsは使っちゃダメだってば。
＞もしゲームが途中でクラッシュしたら
＞解像度変更されたままになっちゃぞ。
ならないよ。動的変更にしてるから。
レジストリ登録にしちゃうとなっちゃうけど。
まあ、使えないことは、はっきりしてるみたいだけどね。

ChangeDisplaySettings、まともに戻り値が帰ってくれば安全に使えるのに。
変更できてないのに「成功しました」だとぉ！？
呼ぶといきなり落ちるだとぉ！？

鬱だ・・・。

＞＞解像度変更されたままになっちゃぞ。
＞ならないよ。動的変更にしてるから。

ちなみに「Alt+Tab」するとどうなるの？
その後、ChangeDisplaySettingsを使う他のソフト起動したらどうなる？
あぁ、謎が謎を呼ぶ．．．

＞ちなみに「Alt+Tab」するとどうなるの？
この命令をうけとったら１回元の解像度に戻してやれば良いの。
ChangeDisplaySettingsを使った処理はあらかたやってみたけど
まあ、だいたい普通に処理できるよ。でも、使った瞬間に
フリーズとかあるからやっぱり使えないみたいだから
もう、悩むことも無いんじゃない？
あーあちくしょーせっかく６０Ｈｚにあわせられる関数が
みつかったと思ったのに・・・。

＞その後、ChangeDisplaySettingsを使う他の
＞ソフト起動したらどうなる？
これは考えなくて良いと思うよ。
ってかこんなの気にするんなら内容作りこめよ。
今のところＰＣはクソゲーしかないんだから

＞ならないよ。動的変更にしてるから。

ゲームがエラーで終了して、でもＯＳが無事だった場合は
解像度は変更されたままになっちゃうはず。
っていうか、そうゆう迷惑なフリーソフトが以前あった。

>25
呼んだ瞬間にフリーズする環境の方がおかしいんじゃないかと
思うんですが・・・。
呼んだ瞬間に落ちるとかいう環境、ディスプレイのプロパティから解像度変更
できるんでしょうかね。


>今のところＰＣはクソゲーしかないんだから

クソゲーしかないとは思わないけど、フリー／シェアウェアのゲームは
弾幕系シューティングばかりのような気がしますね。

とりあえず面接には持ってくんなー。もう飽きたよ。
ソースもどっかで拾ってきたようなのつついただけで、
突っ込んだ質問したら答えられなかったり・・・。
愚痴ってスマン。

＞呼んだ瞬間にフリーズする環境の方がおかしいんじゃないかと
＞思うんですが・・・。
俺にいわないでくれコイツ↓に聞いて。
http://www.bio100.co.jp/cgi-bin2/directx/flashviw.cgi?no=8584&reno=8582
うむ。良い環境だ。
まあ、フリーズするのはもしかしたら狂言かもしれんが・・・。
ほかにもそういう人がいてくれるといいのだけど。

nVIDIAか・・・。
ＯＳ何なのかわからんね。

Bio掲示板にいる方々はみなあきらめモードみたいね。
リフレッシュレートに依存するのは悪！みたいな言われようは
納得いかんけど。

>>27
FF、DQのクローンならOKですか？

リフレッシュレートを固定する仕様が世界中で一般化されると困るのは
3Dカードメーカーかな。ハードの進歩に足枷がかかるからね。
マイクロソフトは意図的に固定できなくしてるんだよ。

>31
ハードは詳しくないんですが、やっぱ幅広くリフレッシュレート変更
できるようにするとコスト高くなるんですかね？
進歩に足枷がかかる理由を他に思い浮かばないんですが、
よろしければご教授願えますでしょうか。

Windows専用機にするにしても、電源投入時は
昔ながらのテキスト画面なわけですし、どうも違うような気が
するんですが。
ここ一連の状況を見るに、ドライバの手抜きっぽい感じだし。

仮にVSyncが自由に変更できたところで、液晶ディスプレイとかだった場合はどーすんのよ。
結局VSyncに頼らないプログラミングが必要になってくると思うが。

液晶でもVBLANK待ちのフリップが効いてるって事は、
ハード側で何らかの方法で、VBLANK（的なもの）検出可能な仕組みが
提供されてるのでは？

今の液晶パネルのドライブだとビデオチップはCRTと
かわらんもんなぁ。部分書替えとかをAPIレベルで
サポートして、リフレッシュレートという概念自体
なくならないと外から見て差はないでしょ。
ちなみにうち液晶素子屋だけど、設計自体は1/60でやってます。
でもソフト屋からみればそんなのCRTの蛍光体の残光は
画質には響きませんっていっているのと同じくらい意味の
ないことだけどね。

>33
液晶だからってのは関係無いんです。
いや、ほんとに。

海外のゲーム開発系サイトでもFAQの話題だねー。
自分の製品をリフレッシュレートに依存して作っちゃった開発者が
マスター近くで気づいて青くなっていたりする。
それでもプログラマは各々の自分のやりかたしか信じないんだよな。

このスレを見ると、日本のパソゲーを遊ぶ人には、
ＶＳＹＮＣを切ってどこまでＦＰＳが上がるのか競うとか、
「自分にとって快適なリフレッシュレートを自由に設定して遊ぶ」
という世界とは無縁の時代がまだまだ続くことが分かるよ。
オレは基本は８５Ｈｚだが。

>オレは基本は８５Ｈｚだが。

120Hz見ちゃうと、85には戻れなくなる。

>37
前半部分何いってるのかさっぱりわかりません。
つまり何がいいたいのでしょうか？

>「自分にとって快適なリフレッシュレートを自由に設定して遊ぶ」
これやると恐ろしいほどバグが増えそうなのがわからないですかね。
ＦＰＳを競うゲームでも作る気ならよそでやってください。

>39
その程度でバグが増えるといっている時点で
力量の無さを露呈しているようにしか見られないのだが…

＞３９
現段階ではリフレッシュレートに依存しないプログラムを作るしか
選択肢がないというのだから、ユーザーがどのリフレッシュレートに
設定したって問題ないはず。
バグが増える増えないとかいう話ではなく、そうゆうプログラムに
するしかないんだってば。

ちなみにリフレッシュレートとＦＰＳは別物だよ。
多分わかってないだろうけど．．．

＞その程度でバグが増えるといっている時点で
＞力量の無さを露呈しているようにしか見られないのだが…
お前ゲーム作ったことあるのか？
どうせ、紙芝居系のエロゲしか作ったこと無いんだろ？
この発言はそうとしか見れないな。

>41
あのねぇ、１２０Ｈｚなんて間に合ってるゲームなんてないよ
ただ、コマ落ちと処理落ちをごっちゃにして、
ガタガタ動く情けないゲーム作ったぐらいでいい気にならないでね。

「FPSとリフレッシュレートを同期させる」オプションを付けるだけなら
ユーザーは文句はいわんだろし、プログラマのこだわりも満足させられ
るだろ?
ビデオカードからの割り込みなんてBIOS依存でoffにも出きるものだし、
もともとvsyncを返さないビデオカードやドライバもあるのだし、
それに完全に依存するプログラムを作ろうって奴の気がしれないが...

>43
VSYNC(というかVBLANK)返さないビデオカードやドライバはさすがにないと思うが・・・。
でないとフリップした時、確実に悲惨な事になる。


現状では、FPS=リフレッシュレートを実現するには、オプションを用意するとか、
環境を調べてるとかして、使える環境でのみ使うしかないんだな。

ChangeDisplaySettingsの件については、「使えない環境の方が異常」だと思う。
一応Win32 APIだし、恐らくドライバの不具合だろう。
ビデオカードのメーカーに報告しとけよ！って感じなんですがどうですかね。

それと、リフレッシュレート=FPSを前提としたプログラミングを
悪いもののように言うのはやめてほしいね。
そりゃDirectX固有の事情なんだし。

DirectXでしかゲーム作った事のない新人に家庭用機やらせたら、
リフレッシュレートに依存しないように作ったりしてな・・・。

Win32APIはあまり信用できないし・・・って、だめじゃん・・・
でも多分DirectX関係者もあまり重視していないんではないでしょうか
グラフィックカードのメーカーも機能の追加と速度の向上に必死で
不具合の無いドライバがリリースされることがほとんどないという
状況ですし もうWindowsには妥協の道しか残されていのかもしれないですね
しょせん後付けのDirectXですし
関係なさそうだけど Windowsのスレッドの精度は問題ないんでしょうか？

でも俺リフレッシュレートが120とか75があるなんて最近まで知らなかったよ・・・
ゲーム機とPC98とMSXでしかゲーム作ったことないし・・・

>VSYNC(というかVBLANK)返さないビデオカードやドライバはさすがにないと思うが・・・。
>でないとフリップした時、確実に悲惨な事になる。

そうか? プログラム組んだが、いつまで立っても先へ進まないので
調査したらVBLANK待ちで止まってた、なんて珍しくないと思うが?
そりゃあそういうBIOS設定にしているのが悪かったり、メーカーや
ドライバが悪かったりするんだけどさ、「それは自分が悪いんじゃ
ありません」と言ったところでユーザーの文句はプログラムを作っ
た側にまず来ちゃうしね。
「あんたの内部事情なんて知ったことじゃない。他のゲームは動い
ているのに、なんであんたのとこのゲームは動かないんだ!不良品
だ!」ってね。

これがPC固有の問題だということには同意。
しかし、リフレッシュレートに依存したいということは、
640x480x8bpp固定のゲームを作りたいということなんだろうか(藁
それ以外のモードでは、元々サポートしなければならないリフレッ
シュレートの規定は無いから、依存できる値なんでないしな。

Ａ宗でいいんじゃないかなぁ。
ユーザだって気にしてないんでしょ、そのへん。
実際コンシューマの3Dゲーム（マリオ６４とかGTとか）だって、
固定フレームレート（っていい方でいいのかな？）じゃないけど、
その事について文句言ってる「一般ユーザ」って見たこと無いし。

なんとなく、CDとかMDみたいなもんかな、と。
ある周波数以上はカットしたり、色々情報削って非可逆圧縮したりと、
理論上、音質悪くなってるはずなんだけど。
でも一般ユーザは気が付くことなく平気で使ってる。
一部の耳のいい方々は確かに気がつくけど、
大多数の人達にとってはどうでもいい問題なわけで。

メクラ相手に素晴らしい絵を見せようとしても無駄、とでもいうか。
そんなところに労力注ぐより、もっと別のところに力を注いで、
全体的にはもっと楽しましょうよ。

そりゃ、確かに良く出来るならやりたいとこだけど。
実際に実現するのは問題があるわけだから、
さっさとあきらめちゃったほうがいいかな、と。

でもまあ、そういう問題があることは声高に主張しつづけないと、
なんでしょうけど。

YsEはリフレッシュレートによって明らかにゲーム速度が変わっていた

>42
頭悪そう…
結局、dt 計算と補間処理出来ないだけでしょ？

>45
うーん、Win32APIが信用できないとなると、何もできなくなりますが・・・。
DirectX使えば、資源を全部占有していい事にしてくれるといいのに。
中途半端に使えるようになってて、調停はあんたらやってくれってとこが
ＭＳらしいというか何というか・・・。

>46
最近のBIOS事情には疎いのですが、VBLANKまわりの設定って
通常オンになってません？ 割り込みはともかくVBLANK取得はできると
思うんですけど。
珍しくないかどうかもまた、人それぞれになるんじゃないでしょうか。
サポートの手間はまた別問題だと思います。

解像度と周波数の規定はありますが、低い周波数を列挙できない環境があるみたいですね。
ビデオカードメーカーは低い周波数をWindowsから設定できなくしつつあるのかもしれません。
色数は関係なく640*480以下であれば、60Hzからはずしてる事はなさそうですけど。
でないとDOSやPC-UNIXが使えませんし。
電源投入時、いきなり75Hzとか80Hzにしてくるビデオカードが出てきたら
話は別ですが。


>47
「所詮はWindowsのゲームだから」って言われたくないんです。
今のところはオプションとして用意するしか道がないですけど。


>49
そういう物言いはもうやめようや。

>>41、>>42に対して>>49のようなもの言いは、なんつーか、
江戸の華というか（藁

この板一番の煽りスレになるのは最初から分かっていたこと…

このスレに限らないけど、とにかく罵倒だけとか、
まず罵倒してから講釈たれる方がいらっしゃいますが、
色々たまってるんですかねえ・・・。

牛乳飲んどけ！

>>53
カルシウム取るならヒジキもいいよ！

ストレスで抜け毛が激しい人にもお奨め、かな。

>51
社交辞令ってやつだっけ？

をう、それかも。

ケンカは止めましょう。
でも４９がアホな事に変わりはありません。

２ｃｈで「ケンカは止めましょう｣も、けっこうアブナい線いってそう。
あ、おれはれっきとしたアホだからいいの、ウンウン。

結局、結論としては

Windowsでゲーム作るなら、リフレッシュレートについては妥協するしかない。
どうしてもＦＰＳ＝リフレッシュレートにしたければ動作している環境を調べ、
オプション等で対応する。

ってとこですか？


目的の周波数が列挙できたとして、ChangeDisplaySettingsが
正しく動作しない環境については、どう思います？
（今のところBio掲示板の２例ぐらいしか知らんのですが）

俺は(WIN32 APIが）動作しない環境が異常だと思うし、
それを理由に使うべきではないというのはおかしいと思う。

ゲーマーにあんたの環境じゃWIN32 APIがまともに動作しないから動かせないよといって納得すると思う?

>61
サポートの問題と、使う使わないの問題は別だと思うんですが。
環境の違いによる動作の違いやユーザーの反応まで、細かい事まで
全部言い出したらWindowsじゃ何も作れないですよ。

ChangeDisplaySettingsを使わない状態をデフォルトとし、
使う状態はオプションで提供すればいいし、あなたみたいに
ユーザーの反応が気になる人は使わなければいいだけの事でしょう。

念のために設定ダイアログに「動かないかもしれないよ」って書いとくかな。


やはり「Change・・・はウチでダメだったからお前ら使わない方がいいぞ」ってのは
おかしいと思うんですよ。そりゃ個人が作ったアプリやライブラリの不具合なら
それでもいいと思うんですが、動かないのはWIN32 APIですよ？
ビデオカードメーカーがきちんと対応すべき問題であって、
不具合を発見したならメーカーに報告しとくべきじゃないかと思うんですがね。
発見したのが開発者なら尚更そうすべきかと。

>60
>正しく動作しない環境については、どう思います？
タイマー信者の狂言かもしれない。

>61
いいや、そういうユーザーへの対応は
「お手持ちのコンピュータのマニュアルか製造元にお問い合わせ下さい」
だ。これで大抵のアホなユーザーは自分のパソコンが悪いと思うであろう。
結局、少数側のサポートなんていつまでたってもなくならない。
ぶぅどぅーとかＮＥＣマシンやふじつーやら、特殊なもん使ってるやつは
結構いる。今更、サポートがどうたら言うことも無いだろ。
だいたい、いつまで某ビデオボードの変な制限を考慮したゲームを
作らなければいけないのか・・・。
そこまで気にするというのならDirectXの出番は無いだろ？
もしくはＤＩＢ系の関数を使うとか。

>62
>それでもいいと思うんですが、動かないのはWIN32 APIですよ？
そうだ、いざとなったらＭＳを訴えようぜ！
奴等のおかげで不毛な争いをして精神的ショックを受けたとか・・・

ところでX-Boxは、その辺(リフレッシュレートとか)どうよ？

とりあえずウチでは下のような記述で
きちんとリフレッシュレート変更出来ました。

DEVMODE devMode;
LONG lResult;

ZeroMemory( &devMode, sizeof(devMode) );
devMode.dmSize = sizeof(devMode);
devMode.dmBitsPerPel = 16;
devMode.dmPelsWidth = 640;
devMode.dmPelsHeight = 480;
devMode.dmDisplayFrequency = 60;
devMode.dmFields = DM_BITSPERPEL | DM_PELSWIDTH | DM_PELSHEIGHT | DM_DISPLAYFREQUENCY;
lResult = ChangeDisplaySettings(&devMode, CDS_FULLSCREEN);

効果無い人いたら、環境教えて頂けます？

そのやりかただと固まっちゃうディスプレイカードがあるので
過去に痛い目にあったことがあります。
ChangeDisplaySettings呼ぶのなら
手を抜かずに
DEVMODEはEnumDisplaySettingsで得られた値の中から
あなたが望むものに一番近いものを選ぶほうが吉かと‥

EnumDisplaySetting で、何故かリフレッシュレートの値が
帰ってこないんですよ… 0Hz って(^^;

だから一番近いものっていってんじゃん

この問題での一番の疑問は
世にあふれている紙芝居エロゲって画質優先だよな？
なのにそれを捨ててまで、ゲームスピードを合わせる必要ってあるのか？
ってところ。
イベントの発動タイミングをタイマでとってスクロールやなんかは
多少スピードは違っても、リフレッシュレートにあわせて
ちゃんとフリップでやったほうが綺麗じゃねーかと思うんだが・・・。
何故、タイマでスクロールやる？

ところで>66の人のプログラムは私の環境では動いてしまいます。
し、同じくEnumなんちゃらでとったリフレの値は０Ｈｚです。
ただし、Ｗｉｎ２０００にしたときは何故かちゃんと
値がかえってきました。
とりあえず報告。

>>70
紙芝居エロゲの画質って、リフレッシュレートがどうかって関係無いよ。

>71
みんな、オリジナリティ皆無の２Ｄ弾幕ＳＴＧを作ってるんでしょ。
リフレッシュレートに同期しないと弾が見づらいしさ。

一般に、ＳＴＧは技術的には初心者向け。
同人やフリーソフトには三角関数すら知らないで作ってるのが珍しくない。
同人は、まー好きに作れやと思うのだが、
市販ソフトには世界レベルに追いついて欲しいものだと願うよ。

>71
がたがたしてて汚くないか？
スクロールの滑らかさってのが皆無になるでしょ？

EnumはNT系だとリフレッシュ取れるのねん、
なんでゲームOSは9Xで取れないのかは謎だ、、、
Meは持ってないから知らんけど駄目だんだろうな

>>70
「紙芝居エロゲ」にユーザーが求めるのって、
塗りがうまいとか、女の子が可愛いとか、そういうもの。
エフェクトがきれいでも、あまり評価されない。

とりあえずティアリングが問題になるのはスクロールするゲームでしょ。
ＡＶＧ及び固定画面式のゲームなら、VSYNCに同期しなくたって全然ＯＫ。
ぐだぐだ言わずに試してみなさい。

フェードインとかしても同期なしだと汚いよ

＞とりあえずティアリングが問題になるのはスクロールするゲームでしょ。
だからさ、よく女の子がスクロールしてんじゃん。
フェードイン・アウトをやってもバシバシ線が入ってるのも
あるでしょ（内部処理だけタイマのときはこれはおこらんが
スクロールは汚い）。
俺がいいたいのはこの際ゲームスピードより
リフレッシュレートに同期を優先させた方がいいんじゃないか
ということなんだがそこらへんはどう？
ってゆうか、ＡＶＧでそこまで複雑にならないのなら、
是非Ａ宗でいって欲しいが・・・。
ゲームの始めにリフレッシュレートを測って変数に
自分が考えるリフレッシュレート÷今のＰＣのリフレッシュレート
例６０／１２０とか
を掛けておいて後はフレームごとに足すだけで問題無いかな？
ぐだぐだいわずに試してみなさい。

>>79
>俺がいいたいのはこの際ゲームスピードより
>リフレッシュレートに同期を優先させた方がいいんじゃないか

エロゲ板で「遅いマシンのときはエフェクトをはしょれ、いちいち
重たいエフェクトを見せられるとウザイ」って感じの文句を見たことあるよ。

>80
意味不明。
全然関係無い問題を出されても困る。
ゲームスピードとは全く別の問題なのだよこれは。
コマ落ちと処理落ちをごっちゃにしているように見える。
こういうことをするから、簡単にクソな部分がうまれる。

どうやらローカルな用語の意味が交錯しているようです。
コマ落ちと処理落ちの定義を明文化してください。
＞８１

６０がせっかく収束させようとしてたのに
話が元に戻りつつあるように思うのだが・・・。

同じようなコードが延々と書かれてるようでちょっと嫌。

>82
うぃす。（これで間違えたら赤っ恥だな）

まず処理落ち。
　処理落ちは例えば６０Ｈｚで動かしていて、ゲームの処理が
重たくなって毎回の垂直同期に間に合わなくなったとき。
このとき同期に一つ間に合わないとＦＰＳが６０ＦＰＳ
から３０ＦＰＳになるこれが処理落ち。
弊害としてはゲーム画面の質の低下、キーレスポンスの悪さ等。

　コマ落ちは例えば１２０Ｈｚ前提で作った物を６０Ｈｚで
動かすとき、すると１２０Ｈｚのときは
１，２，３，４，５，６・・・とならんでいたインデックスを
６０Ｈｚの場合１，３，５・・・と処理しなきゃならなくなる。
こうすると２，４が単純に消えるこれがコマ落ち。
弊害としてはゲーム画面の質の低下。

一休み。

んで、ちょっとここでスクロールのお話。
３ずつのものと３．３のものを考える。３の場合は
０，３，６，９，１２，１５・・・と増える。３．３の場合は
０，３．３，６．６，９．９，１３．２と増える。ここで
画面にはどう出るかと言うと、３の場合は
０，３，６，９，１２・・・で３．３の場合は
０，３，６，９，１３・・・となる。
ここで問題は１３のところこれが非常に汚く見える。
ということを頭にいれてレッツゴー。

んでコマ落ちの話でさっきは１２０から６０の話をしたが
６０から７５だとどうなるか？６０で
１，２，３，４，５，６・・・のものは７５では
０，１，２，３，４，４，５・・・ってなるのかな？
っつーわけでこれがコマ落ちの汚さの説明。

もちろんタイマーなんかで管理してしまうと６０と３０の
間をいったりきたりして非常に汚い。
はっきりいってタイマーで何やらやっている人は
いっそのことリフレッシュレートなんか無視して
しまった方が良い。
んで何やら問題がなさそうなＡ宗だけど、リフレッシュレートに
間に合わなければその苦労も水の泡。ので、俺のゲームは
絶対に処理落ちなどしない。どんなＰＣでも動かしてみせる！
って人向け。だから処理の軽いＡＶＧなどはこれにしよう。

リフレッシュレートを無視するとティアリング発生。

んで、何故いろんな人がごっちゃにするのかと言うと、
処理落ちがおきたときのゲームスピードの誤魔化しを
コマ落ちでするから。
大抵ＰＳなんかのコンシューマで組んでる人は、
何処までを拾うか？ってのを決めるみたいだけど、
例えば３０ＦＰＳまではコマ落ちで対処して、
それ以降は処理落ち必須。とか。

こんな説明でよろしいでしょうか？
っていうかコンシューマで組んでる人はこの辺間違うわけが
ないので俺よりそっちの人に聞いた方が信憑性あり。

実際に Direct X でＡ、Ｂ、Ｃ案それぞれのコード出して
検討してみると面白そうだけど…
見てるだけモナーなんで逝ってくる

今、ドキュメントをスムーズスクロールするテキストビュアーを作ってるんですが、
スクロール中にちらついて、MSIEの同機能の様な、奇麗なスクロールになりません。
症状からして、ここでお話されているVSINCで同期を取れば良いかと思うんですが、
ゲームじゃ無いので、なるべくDirectXを使用したくないんです。
なんとかWin32SDKレベルで解決する方法は無いでしょうか？

いまの所、スクロールのタイミングは次の３種類でやっています。

（いままで試した方法）

1)WM_TIMERを使用
→全然精度が出ない。(がくがく)

2)タイミング通知スレッドを使用
(ワーカスレッドでInterval中はSleepし、SendMessageで
メインスレッドへタイミングを通知する。)
→精度は良い(なめらか)が、ちらつく。

3)マルチメデイアタイマを使用
→精度は良い(なめらか)が、Thread同様にちらつく。
(また、マルチメデイアタイマはDLLを呼出すので、環境によってDLLの
サーチに時間が掛かり、その分起動が遅くなるので頻繁に起動／終了
するアプリには不利に感じました。)

いまの所、2)がお手軽で良い感じです。(あんまり関係ありませんが)

>スクロール中にちらついて、MSIEの同機能の様な、奇麗なスクロールになりません。

あれは隠しAPIを使っているのです。

>>88
描画は一旦メモリDCに描いてから、最後に画面にBitBltするようにして、
WM_PAINT使って描画してるなら、WM_ERASEBKGNDに何もせずにTRUE返す。
GDIだけで処理してるなら、これでちらつかなくなると思うよ。

その程度では、ちらつきとリフレッシュレート同期は関係ないぞ。
まさかとは思うが、BitBLT使わないで毎回再描画してるせいでは
ないか?

>88
ちらつくって？
何が原因なのか判断する為の情報が少なすぎ。
しかも垂直同期取る気でいるし・・・ウィンドウモードでは
垂直同期なんて取ったって意味無いよ。
というわけでここでは場違い。

IEのスムーズスクロールは別にVブランク見てないですよ。

IEだけでなく、マウスカーソルの移動なりウィンドウサイズの変更なり
高速な環境なら見てくれるといいのになあとは思うけど、
VSYNC割り込みの機構が必要なので無理でしょうね、やっぱ。

監視さえできれば割り込みは無くてもなんとかなる。

>んで何やら問題がなさそうなＡ宗だけど

えっと、問題はあります。精度の低いマルチメディアタイマで
フレーム間Δtを求めるのは当てになりませんし
（高リフレッシュレート環境だと平気で0msとか返ってきたりする）
パフォーマンスカウンタを使っても、WindowsはマルチタスクOSですから
単にFlipでループするだけでもディスプレイと同期したΔtが求まりません。
結局、B宗2派クオリティへの到達は微妙です。

＃ま、リフレッシュレートは上げられますが。

あと、フレーム単位の演出が使えませんね（B宗1派もだけど）。
整数ドットスクロールとか数フレームごとのフラッシュとか
数フレーム周期の振動とか、意外と使用頻度高いですし。

無駄な負荷増えまくりそうでヤダ……。

>>95
今思いついたんだが、
リフレッシュ・レートが分かれば、
描画落ちしていなければdt固定にできるんじゃないだろうか。

＞描画落ちしていなければdt固定にできるんじゃないだろうか。
だから>79で俺がそういってるんだが・・・
しかし、問題はそこではないって84,85,86でいっているんだが
どうよ？

>>98
おおぅ、申し訳ない。ここ数日来てなかったもんで（ぉぃ

冷静に考えてみたら、他に原因がある気がしてきました。
GDIの使い方をもう一度考えてみます。
(一応90さんのおっしゃられたメモリDCでBitBltはしてます。WM_ERASEBKGNDにTRUEも)
スレッド汚して申し訳ありませんでした。

念の為言っとくけど、VSYNC同期ウンヌンはフルスクーリンのアプリのみに
適応される事柄だからね。ウインドウモードではVSYNC同期できないんで。
ウインドウをドラッグして左右に動かすと、ティアリングを再現できるよ。

>101
全くもって同意。
なんか勘違いしてる人多いよね。

> ウインドウをドラッグして左右に動かすと、ティアリングを再現
よくわかりません。特になにも起こりませんが‥

はあ。そうですか。ウィンドウモードでも WaitForVerticalBlank の有り無しで
ティアリングの現れ方に明確な差が出ますが。

>ウインドウをドラッグして左右に動かすと、ティアリングを再現できるよ。

これは当然。なぜならウィンドウのドラッグ時の描写はDirectDrawではなく
Windows (GDI) がやっているから。

>104
一瞬で終わるフリップに対して、WaitForVerticalBlank で
待った後に BLT では垂直帰線終了までに
描画が終わるとは限らないのですよ。

試しに640*480の画像を10ドット飛ばしくらいで
右にスクロールさせてしばらく眺めていると、
ズレた時の様子がよくわかりますよ。

>104
不毛な争いはやめ。
ウィンドウモードで垂直同期に合わせてしまうと
ティアリングの線が毎フレーム同じようなところにできて
しまって、逆に合わせないときよりもきたなくなってしまう。
ので、ウィンドウモードのときは垂直同期は取らない方がいい。
という結論を出した感じのする会社はリーフとかアリスソフトが
そんな感じで作ってある。

A宗を使ってみようかと思ってふと思ったのですが、下手したら当たり判定のすり抜けが起きますよね。
当たり判定をバウンディングボックスから線形補間にしなくてはなりませんが、
途中でキャラが消滅した場合など前途多難ですね。鬱だ・・・

>103
>>ウインドウをドラッグして左右に動かすと、ティアリングを再現
>よくわかりません。特になにも起こりませんが‥

あなたは「ティアリングが気にならない人」に分類されます。
日本の成人男性の７割が「気にならない人」らしいので、安心してください。

ウィンドウモードでのFlip()の中身は単なるBitBlt()だということが
わかっているのだろうか...
最近はビデオカードによっては違うのか？
オーバーレイサーフェイス使ってるとか。

もうウィンドウモードの話は良いですから、本来の話題に切り替えてください。

早く結論が聞きたいのであげ。

全部読んだか君たち。

Yonda

もう話すことないって。

この手のスレって、大抵最初の1/3程度で結論出てるだろ(藁
現状追認なら結論はとうについているし、それ以外では
「現状に満足すべきでなく積極的に働きかけるべき」という書き
込みがあったが、言い出しっぺの法則ということで頑張ってくれよ。
to 書いた奴

まとめとくか。

今のところWindows（+DirectX）環境では、家庭用ゲーム機のように
リフレッシュレートと完全に同期したゲーム画面は作れません。
その理由としては、
１：DirectXのSetDisplayModeでは、リフレッシュレート変更不可。
２：ChangeDisplaySettingsを実行できない「異常な環境」が存在する。
３：このような事情でも構わないと考えている開発者が存在する。

対策としては、
・ユーザーの実行環境を調べ、可能であればリフレッシュレートを変更する。
　ただし上記２に引っかかる可能性もあるので、オプションとして提供
　した方が無難。
・目的のリフレッシュレートにできなかった場合は、現在のリフレッシュレートを
　もとに移動量を計算したり、うまくコマ落ちさせたり、タイマを使うなどで
　対処する必要がある。
・リフレッシュレート変更できるようにしろ！と、ＭＳやビデオカードメーカーに
　働きかける。


補足や訂正があればよろしく。
誤解やミスがあるかもしれんが、罵倒だけのレスは勘弁な。ストレス発散はよそでやってくれ。

＞２：ChangeDisplaySettingsを実行できない「異常な環境」が存在する。
これは設定する構造体のdmSizeメンバに値を入れていなかったから
かもしれない。話をややこしくしてすまん。Gumaより。

>116
対策に追加：
・ティアリング覚悟でVSYNCを無視して画面更新する。
（FlipじゃなくてBltを使う。）ウインドウモード時とコードが
共用できて便利。また自分の好きなfpsで作れる。

>118
「対策」っていうにはちょっと違うような・・・。
つまらん突っ込み申し訳ない。

>118
その話は86でもう俺がしてるんだが、なんでここの人は
同じような内容を何度も書きこむかね？
こんなの全部呼んだって５分もかからないだろう。
プログラムの分厚いマニュアル本に比べたら屁みたいなもんなのに
どうして読まないで書きこむのかね？そんなに長文が嫌いなのか。

まとめに追加だからいいんじゃない。

>A宗を使ってみようかと思ってふと思ったのですが、下手したら当たり判定のすり抜けが起きますよね。

内部処理は100fpsあたりで固定で、描画のときは
各フレームのオブジェクト座標と姿勢を求めるのに補間使うってのはどない？

>122
なるほど〜 レンダリングはスレッドにして常に全力で回して、
ゲームループで暇な時にSleep混ぜてやればいい感じですね
#スレッドの中でDrawPrimitiveしていいのか知りませんけど...
そのうちやってみます

ふと思ったんですが、リフレッシュレート同期／非同期に関わらず
「自分の好きなＦＰＳで作るメリット」って何かあります？

>>123
スレッドの中で使用できないんだったらどうやって使うんだろう・・・

>>124
・誤差ゼロ
・フレーム単位の演出が可能

s/誤差/実行環境による誤差/

またまた補足。フレーム単位の演出ってのは、
１フレームあたり整数ドットスクロールとか、
２フレームのフラッシュとか、
３フレームあたり１コマのアニメーションとか、
４フレーム周期の振動とか、
５フレームでウィンドウの改ページとか、そゆの指します。
ゲーセンや家庭用ゲーム機では結構お目にかかれるハズ。

実際、映画・CGアニメーション・VJ・モーションタイポグラフィなど
映像の世界でも、意外にフレーム単位の操作は多用されてるんですわ。
fps可変だとそういうテクニックが一切封じられてしまうので
映像技術者的見地からするとかなりキツイです。

>122
>123
本気で読まないんだね。84,85,86を通して線形補間の意味のなさは
説明されてるでしょう。まず、こんなことを言ってるぐらいだから
処理落ちとコマ落ちの違いがまだわかってないんだね。
いいですか？Ａ宗なんてやったって絶対に綺麗なスクロールなんか
できないんです。Ａ宗の唯一の利点はユーザーが自分の考えるリフレッシュレート
でやってくれたときのみ綺麗にみえるという程度なんです。
まず、Ａ宗のフレームごとのｄｔの計算方法はわかっているのですか？
処理落ちとコマ落ちの対処の違いはわかっていますか？
ｄｔの計算は
「自分の考えるリフレッシュレート÷現在のリフレッシュレート」
です。この定数の何処に線形補間が入るのか聞きたいぐらいです。
もし、１フレームにかかった時間を毎回求めているなら、
それは処理落ちとコマ落ちを全く理解していないことになります。
理解していないのなら84,85,86を読んでみてください。

>126-128
どうもありがとうございます。
リフレッシュレートと非同期だと、あまり意味ないっぽいですね。
（目立たない、程度で我慢するなら別でしょうけど・・・）

おれのような意見については皆さんどう思いますか？
「リフレッシュレート固定するのはいいが、
60Hzはやめてほしいんだよな。眼がチカチカしてさ。」

>131
しょうがねーんだよ。８５Ｈｚとかにあわせても
処理落ちしちまったら、６０Ｈｚのときより眼がチカチカする
ようになるんだから。それにほかのいろんなリフレッシュレート
に合わせるように作っても自分が想定したリフレッシュレート
以外になるとどうせ駄目。Ａ宗のやり方が駄目なのは説明
あったでしょ。

>131
家庭用ゲーム機とかゲーセンでも目がチカチカしますか？

>>30
インターレースだからじゃない？

>>134 のリンクは >>133 の間違い。
寝ぼけてます・・・スマソ

えー、趣味でDirectXいじくってるＢ宗のアーケードプログラマですが、
なんつーか、何を言いたいのかよく分からないんですけど(汗)。

>Ａ宗の唯一の利点はユーザーが自分の考えるリフレッシュレート
>でやってくれたときのみ綺麗にみえるという程度なんです。

>ｄｔの計算は
>「自分の考えるリフレッシュレート÷現在のリフレッシュレート」

Ａ宗ってったら基本はSDKのサンプルのDonutsみたいなの指してますよね？
「自分の考えるリフレッシュレート」なんて存在しないでしょ。

一番基本的なとこから確認なんですが、滑らかに時間を進めるため
DonutsみたくtimeGetTimeで毎フレームΔtを求めたりせずに
リフレッシュ・レートがＲHzだとしたら(１÷Ｒ)sに固定してみる、と。
スクロール速度vxをＮpixel/sとすると、
フレームあたまの移動量vx×Δtは(Ｎ÷Ｒ)pixelで固定ですよね。
これはＲがどんな数字であれ「滑らかなスクロール」じゃないんですか？

んで、122はゲームの処理はマルチメディアタイマとかでＢ宗、
描画はガリガリとFlipのループで、Ｂ宗でステップ実行した結果から
補間しながら行うことだと理解したんですが。
（これも実装するとなるといろいろ面倒だろうなー）

s/timeGetTime/GetTickCount/
うー、精度の低いほう使ってたか。ヤなサンプルだなー。

>136
>フレームあたまの移動量vx×Δtは(Ｎ÷Ｒ)pixelで固定ですよね。
>これはＲがどんな数字であれ「滑らかなスクロール」じゃないんですか？
残念ながらそうはならないんです。
それが滑らかに見えるときはvx×Δtが整数のときのみなんです。
まあ、もっと汚いのはキャラクタのアニメーションだと思いますが。
３Ｄなんかでは常にこんな感じなので気にするだけ無意味なんですが、
２Ｄだとさすがに気になります。

138です。さっきサンプルのプログラムを作って実験してみたところ
ガタガタになりませんでした。すいません。
勘違いしたのは、私の２Ｄゲームが１２０Ｈｚでは処理落ちしてた
からでした。ので、vx×Δtで大丈夫みたいです。
ってその辺の説明は86あたりに書いてありましたね。

結局、タイマは使わず、開始時点で移動量計算してやるのが
ベストって事ですね。

リフレッシュレートを返してこないクソドライバは
どうしてくれよう・・・。

DirectX BBSに、また盛り上がりそうなネタが・・・
http://www.bio100.co.jp/cgi-bin2/directx/flashviw.cgi?no=8795&reno=no

>141
いや、この人SetDisplayModeの方使ってるじゃん。
誰か、ここ教えてやれって。

>140
>リフレッシュレートを返してこないクソドライバは
>どうしてくれよう・・・。
だから自分で何秒間かかけてリフレッシュレートに
合わせてＦＰＳを測ればいいんではないかと・・・マシンごとに。

リフレッシュレートに関しては、DirectXBBSよりここの方が
有意義だな・・・。

あっちは「妥協」が合言葉になってますね。

ゼロ返してくるとなると、計算するしかないですね・・・。
無負荷でループまわして、タイマで計測するのがベストでしょうか。

リフレッシュレートの値返すのってそんなに手間なのかなあ・・・。
ドライバ担当者が手を抜いてるとしか思えん。

的外れかもしれないが、リフレッシュレートをユーザーが入力する(いちおう自動判定も付けて)ようにしてそれにあわせて動かす方法はダメなの?

GetDeviceCapsでリフレ拾うのはNTでしかだめなんだねえ。

>145
>あっちは「妥協」が合言葉になってますね
まったくです、一部の人の暗黙の了解的なことになってしまってて
進歩が無いですね。ほかの技術に関してもそうですね。
もう行く意味はないかな？

>146
リフレッシュレートをユーザーが入力するってどうやるつもりなの？

>>146
Ｘ−Ｗｉｎｄｏｗの設定のようなものを想像した（藁

>148

>まったくです、一部の人の暗黙の了解的なことになってしまってて進歩が無いですね。

普通の掲示板でこの話題を扱ったらディベート合戦が始まるのは目に見えてるのですが・・・

リフレッシュレート→垂直同期

>150
だったら、納得がいくまで話し合えばいいのにあそこの掲示板は
どうやら絶対的な常連がいるらしくて面白くない。他の技術に関しても
そうで常連さんにわからないことは聞いても意味が無いみたいです。
>151
ところで何が言いたいのでしょうか？
垂直同期信号の出るタイミングがプログラムで変えられないので
困っているのですが・・・ユーザーに設定させるその方法とはいかに？

>>152
多分>>146=151が言っているのは
>>136の意見に対してリフレッシュレートの取得ができませんという意見が
あったため、取得するのではなくユーザーに現在のリフレッシュレートを
入力させたらどうかという事ではないでしょうか
リフレッシュレートを最適な値へユーザーに変更してもらうという解釈も
できると思いますが・・・ちょっと言い過ぎってかんじ

>ユーザーに現在のリフレッシュレートを
>入力させたらどうかという事ではないでしょうか
なるほど、しかし、プログラムで測れるんだからユーザーの手を
煩わせるまでもないというのが結論かな。

>150
>普通の掲示板でこの話題を扱ったらディベート合戦が始まるのは目に見えてるのですが・・・

そしたらこのスレッドの存在を教えてやればいい。
このスレッド全部読んで、自分が採るべき方法がわからない奴は
DirectXでゲーム作るのやめた方がいいと思う。

それにしても結構有意義なスレッドになったな。

>プログラムで測れる

ソースコードｷﾎﾞｰﾝ

>156
おいおい頼むよ。143の人が言ってることをそのままプログラムに
直すだけだって。要するに、フリップを使ってループさせながら
ＦＰＳを測ると自然とＦＰＳと現在のリフレッシュレートがいっしょの値に
なってくるはずじゃん。もちろんループの中身は空で何秒間か測って
誤差を散らすようにする。これでわからんのではどう説明すべきか・・・。

>>157
>これでわからんのではどう説明すべきか
だからソースコード希望なのでは？
派閥毎のコアになるソースがあると、説明不要で便利だと思うけど。
多分156は、具体的にどう実装すべきか、一例が知りたいんじゃないかな。

long　　fps = 0;
{
　　long　　begintime = timeGetTime();
　　while((begintime-timeGetTime())>(10*1000)){
　　　　g_pDD->WaitForVerticalBlank(DDWAITVB_BLOCKBEGIN,NULL);
　　　　fps++;
　　}
　　fps /= 10;
}
こんな感じになるんでしょうか？

>159
まてまて、ループの条件式は本当にそれで満足か？

・・・逆・・・鬱だ氏のう・・・
long　　fps = 0;
{
　　long　　begintime = timeGetTime();
　　while((begintime-timeGetTime())<(10*1000)){
　　　　g_pDD->WaitForVerticalBlank(DDWAITVB_BLOCKBEGIN,NULL);
　　　　fps++;
　　}
　　fps /= 10;
}
timeGetTimeの値によってはとんでもないことになるけど
大体このような感じなんでしょうか？ もしかして俺わかってない？

また間違えた・・・氏んでも償いきれない・・・
今度からちゃんと試してから書こう・・・

>>162
>今度からちゃんと試してから書こう・・・
この板ほんと、こういう人多い…。

>162
まてこら、それじゃ、わかんねー奴不安になるだろが。
というわけで、俺もサンプル。
この掲示板ってインデントどうなってんかわからんけど、まあ、いいや。
double Begin,End;　　//始めの時間と終わりの時間
double Count;　　　　//フレームごとのカウント数
double Second;　　　 //計測する時間（１／１０００秒）
double Refresh;　　　//リフレッシュレート

Begin = timeGetTime();　　//始めの時間を取得
Second = 10000;　　　　　 //１０秒間測る

//無限ループ
while(1){
WaitVSync(1);　　　　　//垂直同期待ち

Count++;　　　　　　 　//カウントを増やす

End = timeGetTime(); 　//終わりの時間を取得

//１０秒以上経過したら抜ける
if(End - Begin >= Second)break;
}

//リフレッシュレートを出す
Refresh = Count / ((End-Begin)/1000.0);

>>163-164 うへ、すみませんでした
申し訳ないので俺の分もきちんと訂正
long　　refreshrate = 0;
{
　　long　　begintime = timeGetTime();
　　while((timeGetTime()-begintime)<(10*1000)){// 10秒間のループ
　　　　g_pDD->WaitForVerticalBlank(DDWAITVB_BLOCKBEGIN,NULL);// VSYNC検出
　　　　refreshrate++;// 検出回数カウント
　　}
　　refreshrate /= 10;// 10秒間の検出回数を1秒間の値にするため1/10にする
}

164です。
あっ、俺も間違えた。
Count = 0;
で初期化してないから駄目じゃん。
やっぱり、こんなチイセーマスに書いてちゃ駄目だねぇ。
鬱だ・・・氏のう・・・

先ほど>>164と>>165のコードを試してみたんですが
私の環境ではディスプレイのプロパティのリフレッシュレートが
何であろうと必ず74を返してきます
ちなみに私の環境は
OS : Windows2000
グラフィックカード : ViperII (S3 Savage2000)
テストに使用した画面のモード : 640 x 480 8bit
ディスプレイのプロパティは60Hzでしたが計測結果は74でした、どうして？

>ディスプレイのプロパティは60Hzでしたが計測結果は74でした、どうして？
それは７４Ｈｚか７５Ｈｚだから。
そうじゃなかったら不良品決定。捨てちまえよ。

もしかしたら、DirectX診断ツールの方だね。
普通ここ↓にある奴。「上書き値」って所を死ぬ気で探す。
C:\mssdk\bin\DXUtils\dxdiag.exe
これ効く奴は効くんだけど効かないのは効かないみたい。
ディスプレイのプロパティとどっちが優先なのかは不明。

あとは開発者ならコントロールパネルの方のリフレッシュレートの
設定も見ておくと良いかも。ランタイムバージョンには無いんだね。

それと確かめてもらいたいのは、今現在のリフレッシュレートって
ディスプレイのボタン（ハードのね）をいじるとみれるでしょう。
話はそれから。ってかそんなのも知らんのか？
一言、言わんと気がすまん。

ところで「ディスプレイのプロパティ」って何を指してるの？

168じゃないけど。
どうしても揃わないなら、計測値の方を信用せざるを得ないね。

俺のディスプレイは古いので、リフレッシュレートとか出す機能が
ありまっせん。

>>168 変なところに腹を立てるなよ
>それは７４Ｈｚか７５Ｈｚだから。
そんなこたわかってるって、結果の値は74だから74と書いておくのが筋だろ

開発者ならわかって欲しかったんだけどここでもしWinAPIがリフレッシュレート
を返しますとなった場合やレジストリの設定を読めばリフレッシュレート取得
できるという場合に、はたしてそれは実際のリフレッシュレートと一致するのか
ということを気にかけてほしかったよ
俺の環境が異常なのかもしれないけどね、正常なドライバをリリースしてくれないのは
S3に限ったことではないし、もしかしたら他の環境でも起こりえるのではないでしょうか

>>169
ディスプレイがなんであろうと、
リフレッシュレートを出す機能とは関係がないと思うが・・・

>171

168の言ってるのは「ディスプレイについてるボタンを押すと、
　現在のリフレッシュレートが表示される機能」の事じゃないの？

そう思って169みたいな事を書いたんだけど、違う？

VSYNC初心者向け
http://www.yo.rim.or.jp/~sawara/stg/stg20.html

168ですが、170と171がいっていることは意味不明です。
全然会話の内容に繋がりがないのに気づきませんか？
とりあえず、まともな人間なのは169の人だけですね。
168で俺の教えた方法での報告しねーで「気づいて欲しかった」
とか意味不明だし。173はあながちはずれでもないがMS-Dosモード
進めてどうする。

とりあえず、170は172に書いてある内容だけでもどうなん？

そろそろ寝ようと思ったんすけど、なんか荒れそうなので・・・。
171については、171さんの誤解を招くような書き込みをした
私が悪いのかもしれません。
話の流れから理解してもらえるとは思ったんですが。

173については、VSYNCがどういうものかわかってない人には
いいんじゃないでしょうか？

Gumaはいるか？お前に惚れた馬鹿がいる。じゃないが、
あんまり荒らすなよ。
結局お前、自分の正しさを強引に他人に認めてもらおうってだけだろ。
無駄な論争せんで、ゲームの中身で勝負しろ。

＞176
＞あんまり荒らすなよ。
こんな無駄な発言をしながら「荒らすな」だってさ。

＞無駄な論争せんで、ゲームの中身で勝負しろ。
お前、その前にプログラマなら理論で勝負しろよ。
もうエロゲでもなければ一人でゲームなんて作る時代じゃ
ないんだから。分業制なんだから勝負も何もないだろ？
それにこのスレなかなか有意義になっただろ？

>177
176が荒らしに決まってるだろ。
ムキになるとはお前Guma本人？

＞ムキになるとはお前Guma本人？
うん。そう。（84あたりで顔真っ赤にして解説してる奴とかそう）
口が悪い人ならいくらでも許せるがタダの馬鹿はゆるせん。
それこそ論争や話し合いでムキになる人は好きだけど、馬鹿は嫌。

あーあ。もういいって。やめなよ

>180
了解

176=178=180
ナイスフィッシング！

>182
いや、名無しさん＠お腹いっぱいが
青の人と緑の人がいる。

>183
いまいち

あげ

こんなページを見つけたんだが、誰の？

http://www.interq.or.jp/gold/ken-k/K_K/gokuhi/g2.htm

今更ですが、

> んで、122はゲームの処理はマルチメディアタイマとかでＢ宗、
>描画はガリガリとFlipのループで、Ｂ宗でステップ実行した結果から
>補間しながら行うことだと理解したんですが。
>（これも実装するとなるといろいろ面倒だろうなー）

いちお検証してみたけど、面倒っていうか死ぬ気が……。
原理上、ある程度の描画遅延が発生するのは避けられないし。
スレッド分けしないで、こんなんでどうです？

double gameTime = timeGetTime();
double drawTime = gameTime;

double gameDTime = 1.0 / 60; // ゲームの処理は毎秒60回
double drawDTime = 1.0 / refreshRate;

for (;;) {
　　while (gameTime < drawTime) {
　　　　gameTime += gameDTime;
　　　　step(); // ステップ進行
　　}
　　drawTime += drawDTime;
　　draw(drawTime); // 時刻drawTimeの状態を補間して描画
　　Flip();
}

訂正：timeGetTime()→0.0
考えてみたら、全然意味がなかった。

>186
関係無いけど俺はＥＬが嫌いだ。

>>136

いまさらですが。

>DonutsみたくtimeGetTimeで毎フレームΔtを求めたりせずに
でも、毎回これやらないと処理が重くなったときに
ゲーム内の時間の進みが遅くなりませんか？

>190
136じゃないけど。
だから、その処理が重くなったときを処理落ちっていって、
それの対処はコマ落ちをさせることでするの。
１回処理落ちをすると次の描画は次の同期信号待ちになるから、
つまるところ、内部処理を１回だけ進めてやればいい。
２回落ちたら２回進めてやればいい。
だから必要なのは毎回のΔtじゃなくて１フレームにかけるΔtの
値だけってことでしょ？
ここ全部読んだ？全然話読まないんだね？いい加減うんざりするよ。
同じような質問ばっかりで。

実践してないのに質問するから見当違いな質問になる。
とりあえず作ってみれば分かるよ。

ひさしぶりにage

もう語る事ないってばぁ。

いまさらだけどさ。

＞いいですか？Ａ宗なんてやったって絶対に綺麗なスクロールなんか
＞できないんです。

絶対とか言ってるし。アンチエリアス処理すれば?
補色みたいな色が交互にあるような絵じゃなけりゃ綺麗になるよ

＞実際、映画・CGアニメーション・VJ・モーションタイポグラフィなど
＞映像の世界でも、意外にフレーム単位の操作は多用されてるんですわ。

普通映画は２４コマでNTSCとかは３０コマ。
アニメ映画も２４コマだけどアニメーションは１２とか８とか。
ビデオとかにする際３０コマにする時点でエリアス発生確定。
５コマに一回アニメーション止めたり
６コマ目に５コマ目の映像を混ぜたり色々方法あるけど、
この時点でフレーム単位の厳密さなんて無意味。
映画をビデオで見てフレーム単位のエフェクトが台無しだとか思うか普通?

単純に映像一般では時間ではなくフレームを基準にしているんだってことでしょ。
12や24や30が60になったところで、その辺は変わんないです。

それとNTSCはインターレースで毎秒29.97フレーム、
59.94フィールドで事実上60コマね。

ふと心づいたが、

＞６コマ目に５コマ目の映像を混ぜたり色々方法あるけど、

混ぜるってのは面白そうなアプローチかも知れませんな。
B宗１派60fpsの映像を適当にブレンドしながらリフレッシュレート分に伸長。
実験してみるか……。

まあでもあまり一つのやり方に固執するのも良く無いね。
このスレで優勢に話をすすめているB宗もネットゲーとかになれば
お手上げだしね。
あと二人格闘ゲーぐらいじゃないと描画の負荷が一定にならないから
(Quakeなんかフレームレート高い時と低い時で5倍くらい差が出るし)
余計なウエイト入らない非同期の方がスムーズに見えたりするし。
描画スレッドと内部処理スレッドを分けれるものも、今度は
処理のリエントラント化が限り無くダルいしオブジェクトの同期で
さらに処理が重くなるし別スレッドからは直接描画用の命令叩けない
し、なるべく描画と処理は同じスレッドで処理したいもんなあ。

それよりもWindowsはOpenGLでリフレッシュレートとの同期が取れない
のが腐ってる！もう、冗談じゃねえよ。

>>198 あなたなかなかわかってらっしゃいますな。
もっともな意見でうなずきまくってます。

ごめん。ちょっと舌足らずだったっす。

＞単純に映像一般では時間ではなくフレームを基準にしているんだってことでしょ。
これはそうなんだけど僕が言いたかったのは
”フレーム単位で処理したいのは作る時に解り易いから”
であって、どうせずれる可能性あるんだから、
”最終的に出来上がったモノのエフェクトがフレーム単位で厳密でなきゃ嫌だから”
って訳じゃないでしょ?
ってことっす。

だから”できるだけ見た目同じになるようにプログラムすればいい”
んであって、完全に同じフレームレートに固執しなくてもいいんじゃ
ないかなーって思った訳でして。

>>197
>混ぜるってのは面白そうなアプローチかも知れませんな。
>B宗１派60fpsの映像を適当にブレンドしながらリフレッシュレート分に伸長。
>実験してみるか……。

これはいいね。
おれの認識では A宗=3Dゲーム用、B宗=2Dゲーム用なのだが、
(異論のある人いる？)
2Dゲームで、ハード的に想定したリフレッシュレートより上になって
しまう場合の弊害はかなり解決するのでは。
サブリミナルタイプの、本当に1フレームだけの効果に対しては完璧
ではないけど、人間の目と認識能力ではそれほど違和感はないん
じゃないかな。

↑現段階で実用的なテクニック、みたいな書き方はおかしいですね。
ハードウェアのパワーやVRAM量の問題があるのだし。

>B宗１派60fpsの映像を適当にブレンドしながらリフレッシュレート分に伸長。
悪いとは思わないけど、そんな余裕があるなら
A宗でアンチエリアスかけた方がいいんじゃない?

>>203
あたしゃＢ宗理想主義者なもんで(笑)。
Ａ宗でうまく動いてるゲーム見ると心が揺れ動きますが。

ft

前前から疑問に思っていたことが
ここで討論されていたので思わず書き込んでしまいました。
自前でVSYNCを検査する・・ってすごい
方法で感激してます。そういう方法があったのか〜
VSYNC取得関数が動かない　＝　諦め
という思考方法だったので^^;

ずいぶん前になったのでちょっとおさらい。

>◆A宗:「v += a * dt」
>v-syncに同期。リフレッシュレートは任意。
>◆B宗1派:「v += a」
>タイマーに同期。一定間隔で値を更新する。
>◆B宗2派:「v += a」
>v-syncに同期。何らかの方法でリフレッシュレートを固定する。

んで、

>このスレで優勢に話をすすめているB宗もネットゲーとかになれば

なぜ？
別にv-sync同期じゃなくても、タイマーからdt算出すれば出来るんじゃない？
フルスクリーンとウインドウモードサポートするならv-sync当てにならんし。

◆◆◆結論◆◆◆
３Ｄゲーム：A宗
２Ｄゲーム：B宗1派

議論の余地無し。常識です。

>>207
>別にv-sync同期じゃなくても、タイマーからdt算出すれば出来るんじゃない？
それは、どっちかつーとＡの方に入るンじゃない？

>それは、どっちかつーとＡの方に入るンじゃない？
いや、リフレッシュレートに同期ってあるからさ。
フレームレート同期だったらわかるけど。

あうあう、3DでもＢ宗のほうが楽だにゃー。

ところで最近気合入れてＡ宗やってみたんだけど、
そんなに面倒じゃないよ。
と、いうわけで３Ｄも２ＤもＡ宗にします。
ただ垂直同期信号取らないビデオボードもあるけどこれは
サポート外だな。暇があったらタイマでしょぼしょぼにサポートしてやるぜ。
ぶぅどぅ信者お前等だよ。

かくして２派は和解を見るのであった。

>>211
３Ｄカードをアップグレードしてもfpsに変化のない３Ｄゲーは糞です。
（デイトナとか(ﾜﾗ）

いや、そりゃ30fpsとか低い数字で固定したりはしないけど。^^;

時代の流れから行くと、今後は液晶モニタが主流になっていくはず。
そうなるとV-Syncに頼るようなコーディングは古臭いものになって
いくのだろうか。

有機ELディスプレイ萌え〜

んでも、アナログRGBとか、リフレッシュレートのある規格で
映像送ってたら、液晶だろうが意味ないような気が。
その辺どうなってるんでしょう？

>>216-217
そもそも垂直同期信号ってディスプレイが出すんだっけ？
ビデオアダプタの方だった気がするんだけど。
詳しい人解説希望。

この辺はハード屋さんに訊いたほうがいいのかなあ。

リフレッシュレートは
一秒間に何回ビデオカードからモニタに画像を転送しているか＝画面の更新頻度
ってことですよね。
別に液晶になろうがデジタル転送になろうが関係ないですよね。
ページフリッピングによる一定間隔の画像更新を行う以上、更新に
同期しないけりゃティアリングが発生しますし。

ビデオアクセラレータと液晶コントローラが完全に一体になって、
画像データ読み出し方式が全く違うものが出てくる可能性がない
わけじゃないでしょうが。

液晶にはティアリングはないでしょ？
上から下に向かって画像更新されるわけじゃないから。
むしろ問題になるのは残像じゃない？

>>221
VRAMをページフリップした瞬間に液晶の全画素データが更新されると思ってるの？？
ページ単位でビデオカード→モニタに画像データを転送してるんだよ？
一つのページの転送中にページフリップしたら、ティアリングが発生しない
わけがないということが理解できないのだろうか。。。

ビデオカメラには外部同期って仕様のものもあるけど、
一般には、垂直同期信号の発生はビデオカード上のタイミングジェネレータ
で行なう。ディスプレイはそれを受け取って、その信号に従って
同期を行なう。

で、ビデオカード->モニタの転送のバンド幅が一画面分のデータ量ｘピクセルクロック
より広くない限り、ティアリングは発生するでそ。

・DVI情報広場
http://www.geocities.co.jp/SiliconValley-Bay/9439/
全然解決になってないじゃん、これ。(T-T)

DirectX8ではリフレッシュレートの変更ができるようになってるみたいですが
きちんと動作してます？
どなたか動作検証された方がおられましたら教えてください。

DirectXのスレとどっちに書こうか迷ったんですが、こちらに。

>>225
あっさり撃沈。駄目だった。期待してたんだがつかえね。
でも、最近就職するのに就職作品にChangeDisplaySettings使ってる
けどどの会社でもあっさり動いてくれているみたい。
動かないのはVoodooとか変なボードだけみたい。
そりゃ垂直同期信号取ってくれないようなものじゃ無理だよね。

>>225
だめだった環境を教えてくださいよ。
せめてビデオカードの名前だけでも。

>>227
妙だ。Win2000にすると動作可能。Win98では不可。
ビデオカードはSPECTRA8400（GeForce2GTS)。
状況としてはリフレッシュレートがすべて0と言われる。
Win2000ではそれなりに動作可能。
あとプログラム的に注意することは何かある？

って言うか最近のグラフィックカードだとSwapBuffersした時に
勝手にリフレッシュと同期してくれるよ。
GeforceとG450とRage128で確認出来た。これから出てくるカードも
そうなるだろう。
だからオレはもうリフレッシュレートとの同期については考えない
ことにした。余計なバグを生むことにもなるし。
そうするとやっぱB宗はやっていき辛くなるんじゃないかな(PC業界ではね)。
これからは非同期バリバリのネットゲーの時代だし、そうすると尚の事
タイミング処理をリフレッシュレート主体でやりにくくなる。

>>229
なんでネットゲーだと自動的にＡ宗になるん？

>>230
いや別にB宗でやろうと思っても構わないんだけど、やり辛く無い？
普通はサーバーや多数のクライアント同士で共通の時間軸を設ける
だろうけど、それはリフレッシュレートじゃないだろうしね。
全ての通信を同期させればいいだろうけどインターネットじゃ無理
だし、リアルタイムなゲームでもメッセージを受け取ったら処理って
構図はかわらないと思う。
タイミング処理と描画処理を別々の時間軸でやるのも手だけど、
そんなことしたら複雑だし、そもそも何の為にわざわざリフレッシュレート
と同期してるのかわからなくなる。
本当はもっと色々と理由があるんだけど、無理なわけじゃないんで
色々チャレンジしてみればいいんじゃないかな。

今Ａ宗使ってゲーム作ってるんだけど、フレーム単位の
アニメーションはどうすればいいのだろう？
例えばシンプルなやつだと、キャラの点滅とか。

>>232
いや、つーかそれって関係ないだろ？
その点滅だって何秒に何回するのかってのが仕様としてあって
しかるべきであって無い時点でゲームの仕様から考え直せよ。
ってレベルじゃん。時間とフレームがどう繋がるのがわからないなら
自分で考えて見ることをお勧めするが・・・・・・。

>>233
分かってない人発見。
１秒間に６０回点滅するとして、もしＦＰＳが３０だったら
どうなると思う？点滅がまったく無くなる、もしくは
キャラが完全に消える。ＦＰＳが４０とかでも、かなり
不規則な点滅になってしまう。
Ａ宗を使うならフレーム単位のアニメーションは使えないぞ。

>>234
まあそれ言ったらB宗でも、
「１秒間に６０回点滅するとして、もしＦＰＳが３０だったら
どうなると思う？点滅の速度が半分になる」って具合なわけだし
A宗でもフレーム毎に表示、非表示を切り替えれば一応それらしく
見える。A宗でもB宗でも結局FPSによって点滅の速度は変わっちゃう
んだし。

>>234-235
いや、俺はどっちかっていうとユーザーにリフレッシュレートを
変えてもらう派なんだけど。コンシューマに逝ってから興味が
無くなったっていうかフレームに合わせるのが当たり前っていうか
垂直同期に合わせないとティアリングって結構致命的じゃんって感じだし。
アニメーションもそうだね。実際にいくらリフレッシュレートを
上げたとしてもコマ落ち状態になるだけでゲーム画面としての
綺麗さは６０Ｈｚでフレーム単位で処理した方が綺麗だしね。
これいうとユーザーに設定させるのは酷だとか、リフレッシュレート
を上げれば綺麗に写るようにしとかないと駄目とか言われて叩かれるから
どうとも言えないんだよね。
234の言うこともわかるよ。アニメーションは確かにリフレだけを上げれば
綺麗に見えるなんてことは無いからね。実際にやってしまうと
ただコマ落ちした素人が作ったエロアニメみたいになっちゃうしね。
俺はどっちかっていうと異なる環境でのゲーム速度の一定より
アニメーションの綺麗さをとるからね。

フレーム毎の点滅つったら50%半透明みたいな効果狙う場合が多いし
αブレンディングでやっちゃえばどっちの宗でも問題感じなかったりで。

＃あ、いや、分かり易い例として持ち出した話なのは承知してるよ

あー訂正。
αブレンディングと組み合わせれば、点滅やアニメーションのパターンを
無理やり補間して、何とか綺麗に誤魔化せるって話でござる。うぃ

>>237
点滅と半透明は違うって〜。
普通ゲームで使われる点滅って、敵が弾に当たった時とか、
自分が敵の弾に当たってしばし無敵状態になってる時とか。
半透明じゃそれらしい雰囲気がでないのよ。

単なる点滅なら、A宗だってFPSに同期させればいいんじゃない？
点滅期間を0.5秒間として、100FPSなら50回、60FPSなら
30回点滅することになる。

環境によって点滅の回数は異なるが、着弾を示すための画面
効果なら問題ないだろう。
効果ではなく、本格的に作画した2Dアニメーションでは問題
だろうが、そもそも2DアニメーションをA宗で作るやつはいな
いので問題ない。

>>239
それは先入観なんじゃないのかなあ。
昔からゲームやってる人は点滅してる時が無敵だったからそう見えないと
それっぽくないっての。そんな自己満足的な表現よりもっと映える
表現探した方がいいんじゃない？ゲーム制作者(orおれを目指す者)だったら。
昔はその程度の演出しか出来なかったけど今は違うじゃん。

×おれを目指す者
○それを目指す者
おれなんか目指さないっちゅーの

>>239
あースマネー。おっしゃる通りだった。
今、実際に試したけど誤魔化せられんかった。
鬱んなったんで氏んどくわ

敵に弾が当たってるのに、何の反応もないゲームって寂しい。
やっぱり白く点滅してくれると「効いてる効いてる。うふふふ♪」
って気分になるよな。それって洗脳されてるのかな？

>>244
うむ、俺も白く点滅がベストの表現な気がした。
2Dシューティングに限定だが。

>>245
じゃ、３Ｄゲーで「当たってるぅ」って表現はどうゆうのがベストだと思う？
洋ゲーみたく血噴出したりとか？

※[HIT 100p]

>>246
加算半透明とモーション

2Dは元来がデフォルメの世界だから白点滅でもいいけど、
3D物はグラフィック的には一応リアリティーベースだから、
白点滅で着弾確認はいかがなものか？

着弾したら小さく爆発して、小さい破片が飛び散るとかして欲しい。
打ち込むほど敵機がボロボロになっていくのはいいね。
蒼穹愚連隊とか。

>>249
カワイイ系のゲームで、敵がウサギさんとかの場合どうする？

敵がウサギさんなら、かわいく「あいたっ！」って絵で反応しないとダメっ！
かばうように手を上げたり、目をつぶったり、目がバッテンになったり。

ウサギの耳から血を流すのはいかがでしょうか。

ボウガンが突き刺さるのはいかがなものか。

ボウガンが突き刺さったら小さく爆発して、小さい肉片が飛び散るとかして欲しい。
打ち込むほどうさぎの体がボロボロになっていくのはいいね。

ニンジャウォリアー思い出したのはオレだけだろうか>>254
「兎をあがめよめよめよ」

>>254
ｳｹﾀ
どこがカワイイゲーだ

話を戻すが、テレビアニメのエフェクトをコマ送りして見れば
B宗の必要性が分かるのではないかと存ずる。
１フレーム（２フィールド）×６コマとかそんな感じのザラにあるし。

リアル系ではＡ宗でオッケーオッケーなんだけどね。

アニメでなくても、いっつぁそにー、とか、まぁつぅだ、とかでも可。

テレビアニメは1秒８コマ(相当)（...だった）。
（映画の24コマ／秒の３コマずつを１単位にしている。
これを約30コマのテレビに変換(テレシネ)していた。
最近のデジタル処理のはどうやってるのか知らない）

テレ朝とかすでにフルデジタルで30コマベースの所も多いと聞いた。
（多重ズームとかフィルムだとオプチカル合成じゃなきゃ絶対むりな
処理とか最近バンバン使ってるとこ多いし）
変換は30コマベースでやると誤差が大きいから60フィールドベースで
処理してるはず
だから静止画でみると2重写しでぶれてるコマが結構混じる
（セル画という物も過去の物になりつつあるのだな）

>テレビアニメは1秒８コマ(相当)（...だった）。
そんなん場合によって全然違うって。
同じアニメでも時と場合によって全然変わる。
>変換は30コマベースでやると誤差が大きいから60フィールドベースで
てかなんで60フィールドベースとかって考えになるんだ。
君の頭の中は整数でしか考えれんのかね？

>>261
259じゃないけど、俺も元アニメーターにそう聞いたけどな？
もちろん例外はあるけど、大概はそう……って話だったような。

用語の問題かもしれんが、２４コマベースの３コマ撮りである。

>>262
最近のは例外ありまくりですぜ、旦那。

ＣＧが使われてるシーンだけ妙に滑らかになるよな。＞アニメ
いや、いいけど。

ゾイドとかな。>265

あげ

ゾイドとかな。>266

安心するスレだ。
自称プロが素人レベルのこと論じ合うなんてほのぼのしてるネ。

ネタが尽きてもageまくれー♪

リフレッシュ論争なんてあったんだ。
人間の目なんて60Hz越えてしまえば、同じでしょ？
60Hzで間に合うように調整かけるのがコンシューマ業界の王道なんだけどな。
古のギャラクシャンもパックマンも60Hz死守してるじゃん。
PCだったら70Hzが基準になるのかな？いやPCゲーの経験はないんだけどさ。
70FPS以上だと目が快適になるのかなー。

ちなみに NTSC->PAL への移植は丁寧なメーカならきちんとスケジュール切って
物にもよるけど、１ヶ月ほど時間をかけるよ。
作業が発生するのはＰＧだけではないので。
もちろんローカライズの作業はフレームレートだけではなく、テレビの色合いやら
十字架の完全撤廃、宗教用語の完全撤廃などもあるんだけど。

>>269
むしろプロが素人を啓蒙するスレじゃないのか。

一般の人の目であれば 60Hz で十分だと思うよ。
PALだと50Hzだけど、それでも実用的だし。
その時のマシンパワーで60Hzにほぼ確実に間に合うように作るのが
基本ではあるよね。３Ｄ時代からなかなか思うようにはいかなくなってきたけど

50Hz はさすがにぴかぴかするぞ。
特にインターレースはひどい。

東日本で蛍光灯とか見ると点滅してるのがわかったりするな。

>>271
そーゆー問題じゃない
>>9を読め

どうでもいいが、「宗」がうぜースレだな。
「式」「案」「型」…なんか変えて欲しかった

すんません、終わってる話題ですが、消えるのはもったいないんでageさせてください。

あがらなかった(^^;

ふむふむ。

大麻信者氏ね。

FPSとリフレッシュレートを勘違いしてるヴァカがたくさんいる・・・

First Person Shooting

>>282
違い、教えてほしいよ・・・。

Frame Per Second とリフレッシュレートは違うのですよ。

>>282
終わってるスレageて煽ってどうする（藁
違いが解らねぇ奴はどうせ説明しても理解出来んだろうからほっといてやれよ

fpsがリフレッシュレートを越えても「見ることができない」ってことだよ。

FPS=一人称シューティング(例: doom, quake)

viperV550（だったと思う）がぶっ壊れたからvanta2000とかいう
安いやつ買ってきてつけたのだが、なんか画面サイズ1152*864だと
リフレッシュレートが最大で６０台しか設定できない。
1280*1024だと７５とか設定できるのになんで1152*864だけ異常に
低いリフレッシュレートしか設定できないんだろうか。
これって陰謀？

>>289
その通り。
陰謀です。

ZSNESとか60Hzで同期してる気がするんだけど
なんかやってるんかな。
うちのGeForce2MXたん（ドライバ12.90）、
DirectXのプロパティのリフレッシュレート強制設定も効かんのに。