独家-投资界2017年上半年IPO成绩单已揭晓：有人垄断13家公司，这些VC-PE暴利！
06-17
雷锋网出版社：本文由雷锋网转载自知乎专栏(1)(2)，已获得作者授权。
让我们从结论开始：粗略估计 Google Stadia 的控制器显示延迟约为 ms。
与本地游戏相比，Google Stadia 引入的额外延迟约为 70ms。
更新3-22：更准确的计算Google Stadia的控制器显示延迟在ms左右，实验误差在0.3±16.7ms以内。
2014年A Black Box Method在《天谕》引擎上工作时，我们遇到了FPS好但“手感”差的问题。
经过主观测试，似乎从输入到屏幕的延迟（控制器到显示延迟）可能太高。
但如何更客观地分析这种延迟呢？记得那是一个周末，我在公司绞尽脑汁。
我买不到高速相机来分析，对吗？当时我确实在淘宝上搜索过，但心里连最后的0都数不过来……现在回想起来，大概是几十万〒▽〒，鸟叔肯定不会认可的╮(╯ ﹏╰）╭绝望之中，我突然灵机一动，拜托，苹果不是刚刚发布了慢动作功能吗？我立即在周末人烟稀少的办公区一台一台地寻找手机，居然发现了一部支持慢动作的iPhone！我打开慢动作，录制了一个最简单的测试：手动控制鼠标左右移动摄像头，同时拍摄手部和显示器??屏幕，希望记录下鼠标移动与屏幕的不同步。
屏幕。
最后的结果比我预想的要好很多。
不仅可以清楚地统计出镜头和鼠标之间的延迟帧数，还生平第一次看到了显示器的刷新。
真是从上到下一行一行（其实我看到n行一起更新了）刷新了！统计镜头和鼠标之间的延迟帧数n，就知道慢动作镜头的FPS。
*n/FPS 是延迟的毫秒数。
在找到量化延迟的方法后，我使用了各种 hack 来消除驱动程序的三重缓冲（当时还是 DX9 时代），在修复了一些抖动 bug 后，问题很快就得到了解决。
当时的视频早已丢失。
今天我就用同样的方法来测试一下谷歌Stadia的延迟到底有多大！我在会场偶然遇见了浙江大学CAD图形学大师王锐教授。
我无耻地让他录一段1分钟的FPS慢动作ヾ(?°?°?)??回到酒店后我打开PotPlayer继续玩。
帧数~(????)?，一个动作的数据如下：从最左到右开始的手柄第一帧：#手柄向最右晃动的第一帧： #图片开始向右移动时的第一帧：#手柄和鼠标有很大区别。
摇杆的行程让我无法准确判断左右摇动的准确中点。
然后我将中点估计为#frame，并输入 min 计算 /median/max。
最小值：- = 40 帧 = ms 中值：- = 54 帧 = ms 最大值：- = 69 帧 = ms。
因此，我们可以粗略估计Google Stadia的Controller to Display Latency约为ms。
这个数值还是相当高的。
绝对不适合射击游戏。
o(╥﹏╥)o。
我非常失望。
更新测试计划并重新测试。
感谢战神大牛@gougou怀宏文提出了更准确的测试方法。
，减少错误：谢谢你的这篇文章，但我有一个小问题。
我需要其他测试来衡量它。
因为相机输入的旋转很可能会导致游戏代码的阻尼，也就是说检测到输入但一开始就刻意移动相机使其不那么敏感，是为了防止相机太敏感敏感的。
更值得测试的是播放控制，因为它是由玩家操作的，基本上不想造成延迟。
比如当玩家推动左摇杆时移动时，当玩家按下x键时会发生什么攻击时，如果这些延迟还是ms，那么基本上就无法玩相机平滑+摇杆死区等。
确实有需要消除的不确定因素太多。
按照上面的思路重新测试。
视频：感谢雷火技术中心主任小军过来帮我录视频，每次请人录，质量都提高了(=′ω｀=)。
视频慢动作部分的所有按钮 -> 动作的帧数记录如下：#-> #= 50 帧#-> #= 50 帧#-> #= 48 帧#-> #= 46帧#->#= 54帧 帧号间隔为(50±4)帧，平均延迟为49.6帧。
在fps慢动作中为0.7ms，误差范围在0.3±16.7ms以内。
这个结果与之前的粗略估计相差不大，原来的结论仍然有效：更准确的计算Google Stadia的Controller to Display Latency在ms左右，实验误差在0.3±16.7ms以内。
《Controller to Display Latency》为什么第一段被称为黑盒方法？因为今天有一个很棒的讲座：他对延迟的分析非常详细，回答了很多我以前只有模糊理解的模糊概念。
我上面使用的愚蠢而粗暴的方法在他的演讲中被称为“黑匣子方法”。
黑盒方法完全忽略内部细节，直接测量，可以用来分析延迟。
然而，这将导致估计不够详细。
如果估算不够详细，就无法准确预测 Throttle 来减少渲染 Workload 和 VSync 上的延迟。
这次演讲有几点我个人觉得很有趣：土豪工作室搭建了一套输入延迟闭环检测的硬件：VSync 解释得很清楚。
扫描并刷新显示器。
关闭垂直同步会导致屏幕撕裂超时+同步点。
错误 = 帧速率的一半。
良好的同步点只会稍微降低帧速率。
预测 + 自适应屏幕分辨率 = 不会错过任何内容。
VSync详细解释了延迟的每一步，可操作性很强。
提出了延迟的定义。
为了理解人为插入Throttle可以显着降低延迟这个概念，人工插入Throttle可以显着降低延迟是违反直觉的。
提出了估计Throttle的具体预测算法以及Best PracticeThrottle预测算法的反馈机制。
这个演讲非常详细，将由 GDC Vault 更新。
视频后，在此处添加链接。
#TODO This Talk 仅看 PPT 很难理解。
基本没有文字——一份好的PPT应该是这样的(〃'▽'〃)，需要和视频结合起来消费。
不耐烦的同学可以看一下我的现场速记稿，基本上记录了每一页PPT。
侵删：ControllerToDisplayLatency现场速记笔记在kilia/gdc.pdf本地游戏对比分析。
由于当时在GDC会场，没有条件测试单机/主机箱内的Latency。
大家评论里说的很中肯，本地游戏的延迟也必须测试完整。
张鹤祥：不同游戏的内部延迟不容忽视（即文章中提到的游戏收到控制信号到输出一帧画面的时间）。
如果条件允许，需要用不同类型、不同厂商的游戏进行测试，才能得到综合结果。
对于奥德赛这样的动作游戏来说，它们不需要特别低的延迟。
当使用 Xbox 进行测试时，延迟可能会高于毫秒。
蔡鸟：你需要对比一下本地连接和单机连接的延迟，然后再说其他的。
使用iPhone慢动作也是我们使用的方法。
根据我自己的测量结果，在局域网、网络和流媒体编解码延迟可以低于10ms。
夏先生：美国DF机构好像做了最新的谷歌云游戏测试，说他们用了高速摄像头。
结论是Google Cloud延迟为ms，Microsoft x1x延迟为ms。
我感觉差别不大。
今天，我花时间用同事的Steam帐户进行了测试。
关于PC版延迟《刺客信条—奥德赛》，感谢最帅的南哥提供测试账号。
测试环境 CPU i9-XGPU GTX 32G DDR4 锁定 60fps/VSync ON《刺客信条—奥德赛》Steam 版本《奥德赛》 输入延迟测试 31 帧、.17ms31 帧、.17ms33 帧、.50ms32 帧、.33ms35 帧、.83ms35 帧、. 83ms35 帧、0.83ms34 帧、0.67ms33 帧、0.50ms 平均 33.2 帧，即 fps 时 0.4ms。
实验测得的数据间隔为33±2帧，即0.5±8.3ms。
上一篇文章准确计算出Google Stadia的Controller to Display Latency在ms左右，实验误差在0.3±16.7ms以内。
可以看出，《奥德赛》本身的Controller to Display Latency就非常高。
两者简单比较一下，Google 和 Stadia 引入的额外延迟约为 70ms。
由于感觉《奥德赛》的延迟较高，所以我也拿了最近玩的FPS游戏，和同样是UBI出品的《Far Cry 5》进行了对比测试。
《Far Cry 5》Steam版17帧、70.83ms16帧、66.67ms16帧、66.67ms15帧、62.50ms17帧、70.83ms果然FPS游戏，延迟优化好多了。
实验测得平均为 16.2 帧，即 fps 时为 67.5ms。
实验测得的数据间隔为16±1帧，即66.7±4.2ms。
雷锋网版权文章未经授权禁止转载。
详情请参阅转载说明。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-17
06-18
06-17
06-18
06-17
最新文章
Android旗舰之王的过去与未来
智能手表不被开发、AR眼镜被推迟，Meta的产品经历了一波三折
为什么Cybertruck是特斯拉史上最难造的车？
更新鸿蒙3后，文杰允许你在车里做PPT了
新起亚K3试驾体验：追求“性价比”，韩系汽车仍不想放弃
阿维塔15登场！汽车配备了增程动力，理想情况下会迎来新的对手吗？
马斯克宣布创建 ChatGPT 竞争对手！ OpenAI的CEO给他泼了冷水， GPT-5可能会发生巨大变化
骁龙无处不在，是平台也是生态