我正在考虑这样一个事实,即施加每秒帧数限制在延迟和性能方面并不理想,因为监视器仍然有机会更快地显示某些东西(假设没有垂直同步,主要是为了稳定)。
但是,我想到这个过程可能会对音频子系统(或输入设备)产生影响,假设每秒帧数也控制引擎本身的全局循环(几乎所有 3D 加速应用程序都是如此)。
操作系统上的声卡/音频设备是否具有可能相关的“赫兹”概念?我们是否假设应用程序的全局循环越快,音频子系统的延迟就越好?
我正在考虑这样一个事实,即施加每秒帧数限制在延迟和性能方面并不理想,因为监视器仍然有机会更快地显示某些东西(假设没有垂直同步,主要是为了稳定)。
但是,我想到这个过程可能会对音频子系统(或输入设备)产生影响,假设每秒帧数也控制引擎本身的全局循环(几乎所有 3D 加速应用程序都是如此)。
操作系统上的声卡/音频设备是否具有可能相关的“赫兹”概念?我们是否假设应用程序的全局循环越快,音频子系统的延迟就越好?
音频通常根本不受影响。音频有一个单独的缓冲区,您可以提前填充,可能需要一百毫秒或更长时间,并且无论您的游戏循环在做什么,声卡都会从该缓冲区播放。
如果您在游戏循环中填充该缓冲区,则返回游戏循环的时间过长可能会导致声音缓冲区为空并听到循环声音。为了避免这种情况,开发人员要么使用大缓冲区,要么从后台线程填充缓冲区。
正如您可能猜到的那样,音频已经以某种延迟运行,这与游戏试图始终保留在缓冲区中的数据量成正比。这通常不那么明显,因为无论如何声音在现实生活中传播的时间都是不可忽视的。专业音频应用程序必须保持这个缓冲区很小以实现低延迟和响应能力,但它们不需要担心图形帧......
至于输入,是的,它经常受到影响。如果游戏没有将渲染速率与输入处理速率解耦,那么在输入的过程中会有一些额外的延迟。在输出的过程中总会有一些额外的感知延迟,如果您将输入延迟视为从执行一个动作到看到它生效之间的时间。但是,感知到的延迟可能比模拟延迟大,因为受影响的实体可能在比下一帧中显示的更早的时间步长发生了变化。
通常,游戏处理和显示器是不耦合的,因此降低显示器的 FPS 不会影响中央游戏处理,其中包括输入(可能还有音频)之类的东西。
这篇文章很好地解释了它,包括将 FPS 与游戏速度相关联的不同选项。