ZOL论坛 > 硬件论坛 > 硬件综合讨论论坛 > DIY与攒机论坛 > 有你不知道的秘密 , 深究游戏时延问题 【转】
帖子很冷清,卤煮很失落!求安慰
返回列表
签到
手机签到经验翻倍!
快来扫一扫!

有你不知道的秘密 , 深究游戏时延问题 【转】

524浏览 / 16回复

feiyuelt

feiyuelt

0
精华
30
帖子

等  级:Lv.4
经  验:2719
  • Z金豆: 0

    千万礼品等你来兑哦~快点击这里兑换吧~

  • 城  市:广东
  • 注  册:2007-08-10
  • 登  录:2016-04-11
发表于 2013-04-10 19:29:07
电梯直达 确定
楼主
第1页:什么是输入时延

在现实世界中如果我们扳动满膛的枪机,子弹必定会马上发射出去,但是在电脑游戏中做这样的虚拟动作(通常由鼠标键盘、手柄以及其他虚拟输入设备实现)却会存在一定的延迟,这个延迟就是输入时延。


图片来源:gamasutra.com

上图是 Gamasutra 在 08 年进行的一个测试,其中编号 -1 为按动 R2 之前的最后一帧画面,而编号 0 的画面则是按动了 R2 键的画面,从这一帧开始数到编号 12 我们终于能看到主角的枪终于发射出去了,这 12 帧画面就是这个游戏中在此场景的时延,换算成时间就是大约 200 ms(毫秒)。

第2页:显示器的输入时延

当显卡完成游戏画面渲染后,就会把色彩缓存中的数据扫描输出到显示器上,如果是一般的 CRT 显示器,显卡发来的数据会被立刻显示在屏幕上。可以说 CRT 在显示效果和时延上都是目前最好的。

相比之下,目前的平板显示器都需要在现实之前对发送过来的帧画面数据进行部分甚至整帧的缓冲,如果是液晶显示器(目前最流行的平板显示器)的话还需要加上液晶分子偏转所需要的时间。

U2413 响应时间
U2413 不同灰度下的响应时间测试结果
来源:tftcentral

U2413 输入时延
U2413 的输入时延测试结果
来源:tftcentral

以 Dell 最新式的 U2413 显示器为例,根据英国网站 tft central 的测试,在标准模式下它的响应时间大约是 4 毫秒(最高 8 毫秒),信号处理需要 20 毫秒,也就是说显示信号进入显示器到画面上呈现合计需要 24 毫秒(最高 28 毫秒),此时显示端的输入时延大概相当于 1.5 帧画面的刷新时间。

当然,这台显示器还有一个命名为游戏模式的设置,在这个模式下响应时间是 9 毫秒。无论是九毫秒还是二十八毫秒,这都反映出游戏画面在显卡扫描输出信号之后所需要花费的时延。

那么电视机的情况又如何呢?以英国网站 hdtvtest 为例,索尼的 KDL46HX853 LED 3D TV 在 input lag 上的结果是 32 毫秒(以 CRT 为参考),三星的 UE55F8000 LED 3D TV 是 44 毫秒。

价格越高的显示设备似乎时延越长,这是因为越高级的显示设备内有更多的电路用于添油加醋,例如把屏幕色彩转换得更贴近某个色域(Dell U2x13 系列支持硬件色彩校准)、对低帧率画面进行运动补偿、对交错视频进行复杂的反交错处理、对画幅比例进行自动调整、执行 Overdrive 改善 LCD 液晶胞响应时间等,这些处理都会增加额外的时延,让既追求高品质显示又要有最佳游戏体验的玩家左右为难。

第3页:键鼠、游戏手柄的输入时延

上面说的是输出设备的时延,那么输入设备的时延又如何呢?输入设备自然是指鼠标、键盘,当然现在也有体感识别的输入方式,但是我们这里还是主要说说鼠标吧,因为这是在 PC 上最普遍的“击发”装置。

微软 3500 更新速率
微软蓝影 3500 的更新速率测试结果

理论上鼠标的击发取样率可以做得非常高,但是这样意义并不是很大,过快的取样速度可能适得其反,因此 Windows 7 设定的鼠标取样速度是每秒一百二十五次,或者说 125Hz,相当于八毫秒。

如果你觉得这不够快的话,可以参考这个帖子:http://www.ngohq.com/news/15043-how-to-increase-usb-sample-rate-in-windows-vista-7-a.html 或者 http://www.nextlevelgamer.com/tweaks/optimizing-your-usb-mouse-polling-rate,对取样速率进行调节,游戏鼠标可以设置为 1000Hz 看看(USB 2.0 fullspeed 模式最高只有 1000Hz 数据更新率,HighSpeed 模式的话微帧数据速率可以做到 8000Hz),如果是无线鼠标或者低端鼠标的话就没多少必要尝试了。

上面是输入、输出硬件设备的情况,那么在系统内的情况又如何呢?

第4页:操作系统级驱动栈的时延问题

从软件角度看的话,从 Windows Vista 开始,显卡驱动遵循的驱动标准被称作 WDDM,它被分为两块,即 UMD 和 KMD。

深入拆解电光火石间的游戏时延问题

UMD 是指用户模式驱动,KMD 是指内核模式驱动,其中 KMD 直接和显卡硬件对话,在操作系统的内核模式上执行。

UMD 和 KMD 之间隔着操作系统和图形 API(例如 D3D、DXVA,负责内存管理控制和 GPU 调度),两者完全隔离。而在此之前的 Windows XP 中显卡 DirectX 驱动都是直接和显卡硬件对话。

WDDM 数据递交流程

在同一时间里可以有多个 UMD 在跑,每个应用程序都有一个 UMD,如果一个 UMD 出现崩溃,也只是该 UMD 对应的应用程序受到影响(例如提示程序关闭),其他应用程序乃至操作系统都不会受牵连。

这有多重要?要知道 Windows Vista 开始,桌面都是采用 D3D 来绘制的,如果游戏或者其他图形应用导致驱动崩溃的话,那基本上就意味着操作系统的整个图形子系统完蛋了。

从安全性角度看,这当然是很好的主意,但是从性能角度而言,WDDM 会导致 DirectX 性能劣化(相对 Windows XP 的 XPDM 而言)。

在 WDDM 下应用程序发射一条 DX API Call(DX API 调用)的话,就会先交给 UMD 处理,UMD 处理完成后,就会被发送给操作系统的 D3D Command Buffer(命令缓存),由操作系统进行调度。

在 Command Buffer 填满或者画面需要“呈像(present)”的时候,里面的指令会被打包给 KMD 处理,KMD 则将指令包压进 GPU 的硬件队列里,在此时 Command Buffer 被执行清空(Flush)处理。

在 Command Buffer 填满出现清空动作的时候,D3D 会出现闲置等待,如果这个 Command Buffer 老是溢出的话,那么 Flush 或者说出现 CPU 闲置的情况就随之增加。

在 PC 系统中 DirectX 驱动栈(driver stack)的时延实际上取决于所有这些线程在系统中是如何被调度的,而帧率值的“品质”同样与此有直接关系,这是因为 Windows CPU 调度器无法确保实时调度。

深入拆解电光火石间的游戏时延问题
假设渲染时间为 33ms、游戏代码时间 20ms、扫描输出+垂直同步窗口=33ms、显示器时延 24ms

如果程序是 GPU 端为瓶颈的话,DirectX 驱动栈就能利用一个最高三帧的时延缓存(例如透过 SetMaximumFrameLatency 来控制,范围可以是 1~16 帧)来冲淡 GPU 为瓶颈时的影响(让帧率看上去更高),因此在 PC 系统上驱动栈的时延一般是两到三帧。

游戏时延
同样假设下,设定预渲染为三帧时候的状况
不过实际的情况要更复杂,因为 DX 可能会视乎情况扔掉“过期”的帧

正是因为这个原因,许多专业玩家都情愿画面撕裂也要把垂直同步禁止掉,希望籍此获得最快帧率——这都是为了减少时延。

有些游戏引入了 GPU Query 技术,强制 PC 驱动栈踢掉这些会导致时延的额外帧,不过这会导致 CPU 流水线处理指令的时候让 GPU 出现闲置等待。因此在采用这样措施的时候,最好是能确保 CPU 中闲置的硬件线程能够被驱动线程使用,实现尽量低的资源浪费。

在 CPU 到 GPU 的“距离”上,Linux(甚至在某些厂商的 Windows 驱动)中的 OpenGL 要紧密得多,而且 OpenGL 可以采用名为 glFlush() 的功能强制 CPU 踢掉递交给 GPU 的指令而不是干等着推压缓存(push-buffer)片段被填满。

当然,Linux、OpenGL 都面临同样的问题,那就是只有万分之一不到的用户在使用 Linux 的桌面环境,这导致它们陷入了恶性循环:越少人使用导致性能问题、程序错误不能获得广泛的反馈,于是硬件厂商这边投入的资源也就减少,这又导致了 Linux、OpenGL 使用的进一步萎缩,而开源社区人士大部分似乎也就仅仅满足于敲敲命令行甚至认为图形界面是累赘,对图形界面乃至图形界面用户持轻蔑的态度待之。

第5页:60Hz 游戏机游戏的时延

Digital Foundry 采用游戏手柄时延监控装置(其实就是把按键信号拉出来以发光二极管呈现信号,属于定制产品,6xx 美元)和拍摄速度为 60p 摄像机对 60Hz 目标帧率的游戏进行时延测试。

这个测试考虑了游戏机的手柄输入、逻辑处理、显卡渲染、显卡扫描输出、显示器输入等整个过程,这个过程通常也被称作游戏流水线,我们将其过程涉及的时间简化如下:

1、执行视点不相依绘制调用(draw call,对场景中的单个物体渲染);

2、读取手柄输入信息;

3、执行视点相依绘制调用;

4、CPU 开始下一帧的(步骤一)处理;

5、GPU 完成帧渲染;

6、垂直同步;

7、扫描输出+平板输入时延。

Draw call(绘制调用)是指场景中每个物体的一次物料渲染动作,例如场景中有一把椅子,这张椅子需要一次纹理渲染,那么这就需要执行一个 draw call,如果椅子需要画几重物料(例如还有光照、阴影等),那就需要几次 draw call。如果画面中有 n 个物体分别进行 m 次物料渲染,那么 draw call 数量就等于 n*m。

游戏会在读取手柄输入信息之前发出与“视点不相依的绘制调用”,而读取手柄输入的动作会依据步骤二的实际情况被尽量延迟。

从手柄输入控制信号到显示器显示信号输入的时基偏差(jitter)也是会影响实际时延的。

例如,我们假设手柄输入时延是 10 ms(由于操作系统或者硬件缓存化会导致 8ms 增加到 10ms),在理想情况下手柄输入时延应该是和显示画面完全同步,也就是游戏能够在它需要的时候读取到正确的输入信号,但是在最差的情况下,游戏会错失掉手柄输入导致额外的 10 ms 时延。

第二个时延增加来自于引擎开始渲染步骤三中的“视点相依的绘制调用”命令。对于 60Hz 游戏来说,视点相依绘制调用数相对较少(除非是流式资源或者是游戏采用了纹理空间着色等让人惊叹的东西)。

理论上游戏可以在步骤二到步骤三的之间获得一个触发最后一次读取手柄输入的 CPU 中断信号,然后只对基于视点的常数进行更新,但是在实际中从听说过没有任何开发人员尝试这样做。

其实在 CPU 生成并发送绘制调用之间以及 GPU 渲染这些绘制调用的时候也是存在一些时延的。

第三个增加的时延来自于 GPU 需要在垂直同步之前有足够提前量来渲染画面,确保画帧能有一定的运行时可变性不至于缺失掉。

根据该测试一个设计为 60Hz 显示输出的游戏在游戏流水线端的时延大概是 16 毫秒,此外还得加上扫描输出的 16ms 和显示器或者电视机端的 33 ms 合计 50ms 左右的时延(依据 PS3 的 XMB 界面上进行按键响应得出这个时延值)。因此,在流畅的 60Hz 游戏机平台上,从按键到显示呈现出来的时延大概是 66.7 ms,这相当于 3~4 帧的间隔。







feiyuelt

feiyuelt


精华

帖子

等  级:Lv.4
经  验:2719
发表于 2013-04-10 19:29:27 1楼

第6页:30Hz 游戏机游戏的时延

如果游戏是设计为 30Hz 输出的话,视点不相依的绘制调用将会更多,这将能够减少时延。显示器和手柄输入的时基偏差代价、发送视点相依的时延,在 30Hz 的游戏中都会相对变小。Digital Foundry 文章中测量出来的 30Hz 游戏(例如 Forza Horizon)在时延上大概是 50 ms~66 ms(剔除扫描输出和显示器时延)。

Forza Horizon

如果 30Hz 的游戏以 60Hz 扫描输出的话,扫描输出的时延大概是 16.7 ms,再加上电视机(游戏模式)方面增加的 16.7 ms 时延,那么从按键到画面显示的时间间将低至 83~100ms。

第7页:PC 游戏的整体时延

PC 显示器现在最高可以达到 120Hz 甚至 144Hz 刷新率,这相当于 8.3 ms 到 6.9 ms。在最理想的情况下,120Hz 输出将是这样的:每帧 8.3 ms 渲染时间 + 8.3 ms 扫描输出 + 6ms 显示器输入时延 = 22.6 ms。

如果 DirectX 驱动栈缓存是 1 帧的话,这将意味着合计 31 ms,如果是两帧就是 39 ms,三帧就是 47 ms,而 47 ms 接近于 60Hz 游戏机配合高性能电视机的时延。这是 120Hz 的情况,但是如果 30Hz 输出设计的 PC 游戏,驱动栈方面导致的时延将变得非常碍眼。

如果使用 CPU 输入线程将数据直接写入到 pinned memory buffer(是在系统主内存建立的一块物理地址固定内存,GPU 可以对它实现异步访问),并且 GPU 直接从 pinned memory 中读取输入信息进行视点矩阵计算,在 GPU 渲染画面中视点相依部分之前将结果存放到常数缓存中,就能把驱动缓存化带来的问题消除掉。

在这样的情况下如果一片单芯片中档显卡能做到每帧 12 ms 的视点相依渲染,那么整个流程下来的时延就是:8 ms 鼠标 + 12 ms 画面绘制 + 4 ms 垂直同步窗口 + 16.7 ms 扫描输出 + 18 ms 电视输出 = 59 ms 总时延。

更高端的 GPU 也许能做到每帧 6 ms 的渲染性能,而游戏级鼠标可以做到 1 ms 的更新速度,再配上速度更快的显示器,将是这样的情况:1 ms 鼠标 + 6 ms 画面绘制 + 2 ms 垂直同步窗口 + 8.3 ms 扫描输出 + 5 ms 电视输出 = 20.3 ms 总时延。

PC 的开放式设计让玩家可以每年都更新硬件,因此即使当前不能达到这样的渲染性能,下一年也有望实现,这使得 PC 在游戏方面在性能上可以提供持久的优势。

第8页:分块式渲染架构的时延问题

在目前的手机、平板电脑中最常见的 GPU 之一是来自 ImgTec 的 PowerVR SGX,如果你对 GPU 比较熟悉的话就知道,PowerVR 的渲染架构被称作分块式延迟渲染架构,画面中的三角形在进行了变换后它们的属性资料(顶点位置、着色器输出,三角形索引、帧状态以及某些用于空间数据结构的开销)会被先存放到名为参数缓存(parameter buffer,这是 PowerVR 的称呼,在 ARM 类似的分块渲染架构 Mali 中它被称作三角形列表,不过 Mali 没有采用延迟渲染技术而仅仅是分块式渲染架构)的地方。

在参数缓存中,三角形的会依据可视性被重新排序、分拣,这样一来,就能让 SGX 只画那些画面最前方的三角形会被渲染,籍此减少无效渲染。

不过这样的分块渲染方式存在一些问题,例如兼容性问题、参数缓存开销问题以及时延问题。


图 a 为分块式渲染架构
图 b 为普通立即渲染架构
图片来源:OpenGL Insights

在任何时候,分块式(不管是分块式延迟还是分块式立即)渲染至少需要让 CPU、顶点单元、片元单元同时处理连续的三帧画面,这意味着至少要为此增加两帧的时延(相对传统的立即渲染方式),加上几乎是必不可少的双缓存以及手机、平板电脑那贫弱的处理能力导致的低帧率、触控屏的输入时延,这一切加起来会让分块式渲染的 GPU 在时延问题上有如噩梦。

苹果的 iOS 设备都是采用 PowerVR SGX GPU,因此你很难看到在这些设备上能很好地运行基于触控输入的所谓 twitch gameplay(短促反应,大多游戏都属于此类型)游戏。

第9页:网络的时延问题

除了输入设备、主机、显示器这三者外,影响游戏体验的还有网络时延问题。


网络游戏屏幕菜单操作时涉及的事件及分时
图片来源:台湾中央研究院资讯科研所

按照一篇 onlive 发表的论文,网络延迟(从玩家发出输入命令给服务器端再返回到玩家本地屏幕上)大概在 130 ms 左右。

不过在该论文中,引用的例子是尚未投入实用的云游戏方式,也就是游戏的计算处理是在云服务器端执行,然后以 h.264 实时编码为 720p 画面返回到本地电脑上,因此还涉及到服务器端的画面压缩、本地电脑的 h.264 解压缩处理,当然,它们这里采用了一个专用的 h.264 硬件编解码器。

如果游戏是 60Hz 设计的,130ms 几乎相当于 8 帧画面。

第10页:人类自身的输入时延

除了机器的时延,很显然我们人类本身也有时延问题,因为我们需要透过眼睛或者耳朵输入电脑的声光信号,经由神经网络传递到大脑或者中枢神经处理,然后再透过神经网络将信号传递给肌肉,由肌肉控制骨骼实现输出。

有个叫 humanbenchmark.com 的网站提供了一个名为反应时间的测试网页:http://www.humanbenchmark.com/tests/reactiontime/index.php,在这里点击 start 后,网页会随机时间更改测试区域的色彩,在看到色彩变化的第一时间里你要马上点击该区域,这样电脑就会报告出你的反应时间。

根据该网站的测试统计,参与测试过的人群平均值(中值)为 215 ms,很显然,这个测试不仅仅是人体的反应时间,还有电脑输入设备、电脑显示设备的时延(显示输出+人类反应+鼠标输入),不过透过该测试我们有理由相信人类在该测试中的平均反应时间应该不少于 150ms。

第11页:测试输入时延的简单办法

输入时延是困扰玩家游戏体验的最大问题,不同性能的系统、显示设备也会有千差万别的输入时延。

要正确测量输入时延,我们需要能正确记录玩家触发输入信号和显示器正确呈现响应画面的办法。

深入拆解电光火石间的游戏时延问题

前面我们提到 Digital Foundry 采用专用的手柄监视装置配合 60p 帧率摄录机进行测试,这个手柄监控器是由 Benjamin J Heckendorn 开发的,由于是非批量生产的东西,成本极高,售价为 650 美元外加运费,一般来说除了开发人员基本上不会有人考虑购买这个东西。

它的实现原理并不是很复杂,主要是把 xbox 360 手柄按钮按下的“低电平有效”信号复制到一个有两枚驱动 IC 的电路中,从而控制点亮对应线位的发光二极管。这两枚 IC 的价格合起来不到四块钱人民币,不过要把信号线引出来并进行验证倒是挺麻烦的,加上需要动用 CNC 数控机床进行外壳加工等杂七杂八的人工成本,Benheck 他们报价 650 美元自然有他们的道理。

那么自己 DIY 一个如何呢?这当然可行,不过我们要测量系统级的输入时延,其实基本上只要看看击发武器射击时候的时延就可以了,无需引那么多线做得那么复杂。

另一个简便的办法就是找一些相对现成的单片机学习板,例如我就找到了一个比较适合做这类测试的学习板:Arduino Esplora。

arduino esplora

Arduino 是一个开源软硬件开发平台,由 Arduino 公司提供,而 Arduino Esplora 就是该公司最新的开发板项目,外形酷似一个手柄,其中的手柄电位器和 Xbox 360 的型号是一样的,除此以外还有一般手柄上常有的菱形布局四按键等,最为关键的是它在左上方提供了 TX、RX LED,可以在有输出、输入信号的时候闪亮。

Arduino 为 Esplora 提供了多个代码样例,其中的 Kart 样例就可以模拟 USB 键盘输入,这样一来只要把 Kart 样例编译(可能需要作一些非常简单的代码修改,因为默认的 Kart 按键和大多数的第一人称游戏按键并不对应)并烧录到 Esplora 就可以作为一个键盘使用,然后透过摄像机监控按键触发的 TX 信号灯为标记开始分析显示器需要多少帧才能呈现武器发射的画面。

最重要的是,Arduino Esplora 的价格要比 BenHeck 的 Xbox360 手柄监控器便宜多了,山寨版的也就是 150 元人民币不到。

第12页:触控屏设备的输入时延测试

上面这个视频是微软应用科学小组提供的触控屏(拍摄的时候并非真正的触控屏而是一个投影设备)在不同时延级别下的光标跟随现象,其中涉及到的时延级别分别有 100 ms、50 ms、10 ms、1 ms,拍摄的速度有 1x 和 8x,其中 8x 的拍摄速度目的在于更直观地反映数模屏不同级别时延下导致的问题。

根据微软的研究(这是一年前的视频),触控屏设备普遍的时延为 100 ms,大家可以看看上面视频中的测试效果。

毫无疑问,1 ms 的光标跟随效果是最好的,但是据我所知目前的显示屏极少能做到低于 1 ms 更新的,这样的时延速度在未来的五年内似乎都不太现实。

NVIDIA 曾经在去年二月份的时候推出过上面视频中展示的 DirectTouch 技术,其实就是把触控 ADC(模数转换器)集成到了 Tegra 应用处理器里,不过从上面的视频中可以看出它的输入时延应该介乎于微软展示的 100 ms 到 50 ms 之间的状况。

要实现比较理想的触摸屏时延测试,关键是有一部能高速拍摄的摄录机,可能的话应该采用 8 倍于屏幕刷新率的型号会让对比更加直观以及降低拍摄取样间隔造成的误差,目前的触摸屏大都是 60Hz 刷新率,因此这就要求有 480 fps 的摄录机。

具备 720p 480fps 的摄录机价格都在 6 万元级别,因此在现实中不太可能以比较低的成本来实现这个测试,可行的方案之一就是降低分辨率和帧率,例如 GoPro3 Hero 黑版可以在做到 WVGA 240fps 拍摄,不过这时候镜头视场是超广角模式,因此必定会有几何畸变。

feiyuelt

feiyuelt


精华

帖子

等  级:Lv.4
经  验:2719
发表于 2013-04-10 19:29:33 2楼
第13页:写在最后

在本文中,我们尝试对大家习以为常的游戏时延问题进行了一些比较深入的探讨,涉及到了显示器、鼠标等系统硬件以及操作系统、驱动层面、多线程实现等方式软件的问题,除此以外,还有人类自身的反应速度和网络等因素。

很显然,游戏的实际时延牵涉到很多方面,未来的云游戏据说要做到在服务器端完成渲染计算,这意味着画面可能是在距离几米的家用台式 PC 或者是距离几千公里的服务器上完成渲染的,画面可能还需要经过复杂的压缩编码以降低传输带宽,中间牵涉到的时延问题就有编解码的时延问题。

头戴式显示屏可能也会在未来进入千家万户,这个东西既有优点也有缺点,优点是可以让有效可视尺寸、视野非常大,但是缺点是可能会把时延问题放大,头部的晃动更是会让问题加剧。

因为头部的晃动需要传感器记录并发送到主机进行处理并对视野、视角进行适当的更新,这就增加了一种令人感到画面拖拉的时延,这样的问题在固定的显示器上是极少存在的。

随着性能测试越来越贴近玩家真实体验,以往用 Fraps 测量 fps、frametime 等方式由于不能在硬件级上抓出帧缓存翻转信息而导致不能反应真实的显卡性能。

深入拆解电光火石间的游戏时延问题
在 VirtualDub 里进行采集,然后就可以把采集片段交给 FCAT 的 perl 脚本进行分析

之前 NVIDIA 就向外公布了名为 FCAT 的帧率分析软件,让大家可以透过高性能采集卡来采集显卡实际输出,依据叠加在每一帧上的色块判断显卡在渲染的时候是否存在掉帧、微小残缺帧等现象,而这些是目前 Fraps 无法侦测到的。

不同的游戏对时延的要求不尽相同,如果是第一人称这类 twitch gameplay(短促反应)的游戏,100 ms 时延应该是基本的要求,专业级玩家的可能需要 50ms 级别,但是对于即时战略(RTS)类的游戏可能出现 2000ms 都还能凑合玩玩。

一个理想的游戏平台应该是这样的:1 ms 级别的输入设备、10 ms 以下时延的广角显示设备、能够每帧只需 8 ms 左右完成渲染的单芯片显卡、单线程性能极强的多核处理器,当然还需要一个不错的驱动程序、系统环境以及游戏代码设计。

目前来看最佳的游戏体验平台属于 PC,但是随着移动设备的崛起,厂商、用户花在台式机甚至笔记本电脑的资源、时间都会减少,而移动设备的性能和台式机相比要落后 6~10 年以上,因此在这类设备上的最佳游戏体验只能达到 6~10 年前的水准,触摸屏(100 ms)比传统输入(~50 ms)设备高一倍的时延问题可能会让这些体验更加难受:p

【白金之星】

【白金之星】


精华

帖子

等  级:Lv.8
经  验:36573
发表于 2013-04-10 19:37:42 3楼
这个太专业了

mzlywy0944

mzlywy0944


精华

帖子

等  级:Lv.4
经  验:2583
发表于 2013-04-10 20:26:23 4楼
复杂。。。。。学习了。

小鸡鸡的同桌

小鸡鸡的同桌


精华

帖子

等  级:Lv.8
经  验:27649
发表于 2013-04-10 20:27:54 5楼
无语了

zlyylhs

zlyylhs


精华

帖子

等  级:Lv.8
经  验:45338
发表于 2013-04-10 20:34:09 6楼
木有力气看完呀~

yxjabc522

yxjabc522


精华

帖子

等  级:Lv.3
经  验:1191
发表于 2013-04-10 20:35:58 7楼
好复杂的说,我知道鸡蛋好吃,但不知道是那个鸡下的

lele37889

lele37889


精华

帖子

等  级:Lv.3
经  验:1083
发表于 2013-04-10 20:36:29 8楼
同感,,太专业,有些地方不懂,,不过我知道CRT显示器,延迟低,以及网络延迟。鼠标延迟,至于显卡和 CPU,显示器之间的延迟,今天学习了! 不过大体明白了一些。不算懂

评分:+Z金豆 10  已有 1人参与评分

展开

80c52

80c52


精华

帖子

等  级:Lv.1
经  验:90
发表于 2013-04-10 20:38:01 9楼
看不懂啊大哥还是说中文吧

gejian

gejian


精华

帖子

等  级:Lv.9
经  验:69720
发表于 2013-04-10 20:38:23 10楼
这种事儿就是游戏厂商优化的事儿,它们不好好优化,就想拿硬件来找原因
生化奇兵3,开垂直同步就卡,而狙击手幽灵战士2跑30帧左右都是嗷嗷流畅
归根到底都是游戏厂商水平问题

飞天一蛤

飞天一蛤


精华

帖子

等  级:Lv.10
经  验:162971
发表于 2013-04-10 21:09:25 11楼
支持

悄悄爱摇滚

悄悄爱摇滚


精华

帖子

等  级:Lv.7
经  验:20478
发表于 2013-04-10 21:16:18 12楼


帮顶.................................................................

xingwen933

xingwen933


精华

帖子

等  级:Lv.4
经  验:1708
发表于 2013-04-11 08:06:24 13楼

yanbinbinwow

yanbinbinwow


精华

帖子

等  级:Lv.3
经  验:1020
发表于 2013-04-11 20:17:57 14楼
对 第10楼 大格格 说:
=========================

我也正在玩生化奇兵无限,开完垂直同步有点卡,但是不像是画面的卡顿,而是鼠标延迟十分严重。我一直奉行FPS游戏不开V-sync

feiyuelt

feiyuelt


精华

帖子

等  级:Lv.4
经  验:2719
发表于 2013-04-14 15:22:43 15楼
对 第11楼 飞天一蛤 说:
=========================

给力

feiyuelt

feiyuelt


精华

帖子

等  级:Lv.4
经  验:2719
发表于 2013-04-14 15:23:31 16楼
对 第12楼 悄悄爱摇滚 说:
=========================

大爱
高级模式
论坛精选大家都在看24小时热帖7天热帖大家都在问最新回答

针对ZOL论坛您有任何使用问题和建议 您可以 联系论坛管理员查看帮助  或  给我提意见

快捷回复 APP下载 返回列表