goodgames
04-07
最終更新:
goodgames
-
view
雑感 0003
■サーバ側パッチR6リリース
いつものページに拠れば、主要なサーバトラブルの原因に対応した、
最新モジュールR6がリリースされたとのこと。
最新モジュールR6がリリースされたとのこと。
2013/11/05零時現在、国内サーバにはまだ適用されていません。
GS機が今朝6時から停止していたところを見ると、今回も朝の適用になるのかも。
GS機が今朝6時から停止していたところを見ると、今回も朝の適用になるのかも。
これでサーバダウンが無くなると嬉しいのですが。
■G-SYNC
これやっぱりいらないと思います。
・V-SYNC OFF
・60または120fps超を維持
・60または120fps超を維持
これで何も問題ないと思います。
「ティアリングが」との意見もあるでしょうが、
少なくとも私の目では60Hzの液晶モニタに200fpsで描画しても
一度もティアリングを確認することはできませんでした。
少なくとも私の目では60Hzの液晶モニタに200fpsで描画しても
一度もティアリングを確認することはできませんでした。
実際にはもの凄い頻度でティアリングは発生していますが。
200fps/60Hz=3.333
理論的には1画面に上、中、下の3フレームが混ざって描画されるため、
激しく酷い画面になりそうです。
激しく酷い画面になりそうです。
しかし、1フレーム前の映像との差異が少ないことから、
ちらつきなどを認識することが出来ないのではないでしょうか。
ちらつきなどを認識することが出来ないのではないでしょうか。
具体的には下記のようになるはず。
画面上部 3フレーム目の上部が描画される
画面中央 2フレーム目の中央が描画される
画面下部 1フレーム目の下部が描画される
画面中央 2フレーム目の中央が描画される
画面下部 1フレーム目の下部が描画される
結局のところ、フレームが混ざっても常に「上は上、下は下」となり、
位置が狂って出力されることは無いため認識することは困難なようです。
位置が狂って出力されることは無いため認識することは困難なようです。
また200fps=0.005secの超短時間であるため、
激しく動きのある映像でも僅か5msではそれほど大きく変化しないのではないでしょうか。
激しく動きのある映像でも僅か5msではそれほど大きく変化しないのではないでしょうか。
そうだ。
これも3フレーム遅延の話と同様に高速度カメラで撮影すればすぐにわかることですね。
いずれ試してみましょう。
これも3フレーム遅延の話と同様に高速度カメラで撮影すればすぐにわかることですね。
いずれ試してみましょう。
あ、TITANはもうじき返却する予定でした。(笑)
■80ラウンド
テストだけで80ラウンド消化してしまいました。
なんとQuit率70%超。(苦笑)
なんとQuit率70%超。(苦笑)
しかし、それほどトラブルには見舞われていません。
80ラウンドのうち、推定65ラウンドがテスト用に用意した
OSからクリーンインストールしたマシンだからかもしれませんが、
特別なことは何もしておりません。
OSからクリーンインストールしたマシンだからかもしれませんが、
特別なことは何もしておりません。
多寡は不明ですが参考までにトラブル一覧を。
1.ラウンド中に音が途切れて数秒後に復活 (2回)
2.ラウンド中に同じ音が無限に続いてそのままフリーズ (1回)
3.起動時にDirectXエラーが発生 (2回) ※これは2回ともWindows8とGeForceの環境でした
4.ベータテストのマップ(名称失念)にてマップロード中にフリープ (2回)
5.サーバダウン (1回)
2.ラウンド中に同じ音が無限に続いてそのままフリーズ (1回)
3.起動時にDirectXエラーが発生 (2回) ※これは2回ともWindows8とGeForceの環境でした
4.ベータテストのマップ(名称失念)にてマップロード中にフリープ (2回)
5.サーバダウン (1回)
合計8回ですので10ラウンドに1回は何らかのトラブルが発生していますが、
ラウンド中かつ切断されてしまうトラブルは2.と5.の1回ずつだけですので、
2/80=2.5%にすぎません。
ラウンド中かつ切断されてしまうトラブルは2.と5.の1回ずつだけですので、
2/80=2.5%にすぎません。
比較的トラブル発生数が少ないと思いますが、
環境以外の点で考えられることが2つあります。
環境以外の点で考えられることが2つあります。
1.連続2ラウンド以上のプレイがほとんど無かった
2.Quitが多いため平均ラウンド時間が短い
2.Quitが多いため平均ラウンド時間が短い
結局は1.と2.のどちらも「さっさと終了している」ことになりますが、
リソースリークの可能性を考えるとクライアントとサーバの双方にとって、
チケット数は控えめの方が良いと思います。
リソースリークの可能性を考えるとクライアントとサーバの双方にとって、
チケット数は控えめの方が良いと思います。
万一トラブルが発生してもラウンド時間が短い方が
戦績が記録されない事による損失は小さくなりますので。
戦績が記録されない事による損失は小さくなりますので。
「こまめにセーブ」と同じ考え方ですね。
参考まで。
( - )