让我们假设您有一个非常简单的游戏，它具有单线程和基本循环，例如“ while(running) { get_input(); update_world_state(); update_video(); }”。在这种情况下，您最终得到“ UPS = FPS”（并且没有理由单独跟踪UPS和FPS）；并且如果GPU难以跟上整个游戏的速度（例如，如果您每秒获得15帧），那么与图形无关的事情可能会花费比它们长4倍的时间，即使您拥有8个CPU等待GPU完成时什么也不做）。

作为一种选择，如果您有2个线程，其中一个线程执行“ while(running) { get_input(); update_world_state(); }”，而另一个线程执行“ while(running) { update_video(); }”怎么办？在这种情况下，没有理由期望UPS与FPS有任何关系。这里的问题是，大多数游戏不够智能，无法处理可变的计时，因此您最终会得到类似“ while(running) { get_input(); update_world_state(); wait_until_next_update_starts(); }”的名称，以确保游戏不能运行得太快（例如，因为update_world_state()被频繁调用，所以它们应该以每小时20 Km的速度以每小时200 Km的速度移动）。根据事物的不同，您可能会获得60台UPS（无论FPS是多少）。但是如果CPU跟不上游戏，游戏可能会/仍然会变慢，并且您可能会获得20个UPS（无论FPS是多少）。当然，如果世界状态没有改变，更新视频是没有意义的。因此，您希望图形循环更像是“ while(running) { wait_for_world_state_update(); update_video(); }”，其中wait_for_world_state_update()确保FPS wait_for_world_state_update()在UPS保持正常运行时立即返回而没有任何延迟） ）。

除此以外的下一步是“滴答作响”。在这种情况下，您可能有一个高优先级线程监视用户输入并为输入事件分配时间戳（例如“在时间= 12356，用户发射了主要武器”）并将它们存储在列表中。然后，您可能有第二个线程（优先级较低，以避免弄乱用户输入时间戳的准确性），其主循环如“ while(running) { next_frame_time = estimate_when__next_frame_will_actually_be_visible(); update_world_state_until(next_frame_time); update_video(); }”，其中update_world_state_until()使用一堆数学来预测特定时间点的游戏状态将是什么（并在考虑用户时间戳的同时消耗已存储的用户输入事件的列表）。在这种情况下，UPS并没有任何意义（您只关心FPS）。这也要复杂得多（由于在任何时间点都涉及计算世界状态的数学运算）；但是最终结果就像拥有“无限UPS”，而没有每帧多次更新世界状态的开销；并且它可以让您隐藏任何图形延迟（例如比预期时间晚16.66毫秒）；这使其比其他选项要好得多（平滑得多，性能问题导致仿真速度变化的可能性也大大降低了，等等）。