在 Cocoa 中驱动 Main Loop 的正确方法

Question

我正在编写一个当前在 Windows 和 Mac OS X 中运行的游戏。我的主游戏循环如下所示：

while(running)
{
    ProcessOSMessages(); // Using Peek/Translate message in Win32
                         // and nextEventMatchingMask in Cocoa
    GameUpdate();
    GameRender();
}

这显然简化了一点，但这就是它的要点。在我可以完全控制应用程序的 Windows 中，它运行良好。不幸的是，Apple 在 Cocoa 应用程序中有自己的处理方式。

当我第一次尝试在 Cocoa 中实现我的主循环时，我不知道把它放在哪里，所以我NSApplication根据这篇文章创建了我自己的。我GameFrame()在我的run功能中投入了我的权利，一切正常。

但是，我觉得这不是“正确”的方法。我想在 Apple 的生态系统中很好地发挥作用，而不是试图破解一个有效的解决方案。

这篇来自苹果的文章描述了使用 的旧方法NSTimer，以及使用CVDisplayLink. 我已经连接了这个CVDisplayLink版本，但它只是感觉......奇怪。我不喜欢我的游戏由显示器驱动而不是相反的想法。

我只有两个选项可以使用 aCVDisplayLink或覆盖我自己的NSApplication吗？这些解决方案中的任何一个都感觉不太对。

Answer 1

我很好奇是否有人真正做过这件事并愿意参与进来，但这是我的理解：

Apple 推动该CVDisplayLink解决方案在主线程上进行循环，-nextEventMatchingMask:untilDate:inMode:dequeue:因为我认为它为 UI 控件提供了更好的响应能力。这可能与全屏游戏无关。（注意：您不需要替换NSApplication以使用这种形式的游戏循环。）我认为使用的主要潜在问题CVDisplayLink是它只会提前运行一帧并且它会提前进行此确定，这甚至比垂直更强同步。从好的方面来说，它可能会改善延迟。

其他解决方案包括将渲染与游戏逻辑解耦以及在主线程上定期运行游戏逻辑并在线程上渲染CVDisplayLink。但是，如果您遇到游戏驱动显示范例的问题，我可能只会推荐这样做。