macos - 在 Cocoa 中驱动主循环的正确方法

Question

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

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

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

当我第一次尝试在 Cocoa 中实现主循环时，我不知道该把它放在哪里，所以我根据 this post 创建了自己的 NSApplication 。我将 GameFrame() 直接放入 run 函数中，一切正常。

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

This article来自 apple 的描述了使用 NSTimer 执行此操作的旧方法，以及使用 CVDisplayLink 执行此操作的"new"方法。我已经连接了 CVDisplayLink 版本，但感觉......很奇怪。我不喜欢我的游戏由显示器驱动，而不是相反。

我只有两个选择使用CVDisplayLink或覆盖我自己的NSApplication吗？这些解决方案都感觉不太正确。

Answer 1

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

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

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