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

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

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

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

当我第一次尝试在Cocoa中实现主循环时，我不知道将其放置在何处，因此我每个this post创建了自己的NSApplication。我将GameFrame()正确地放在了run函数中，一切正常。

但是，我不认为这是“正确”的方法。我想在Apple生态系统中发挥出色的作用，而不是尝试破解一个可行的解决方案。

apple的This article描述了使用NSTimer的旧方法，以及使用CVDisplayLink的“新”方法。我已经连接了CVDisplayLink版本，但感觉.... odd。我不喜欢游戏由显示器驱动而不是由显示器驱动的想法。

我是使用CVDisplayLink还是覆盖自己的NSApplication的仅有两个选择吗？这些解决方案都不是很正确。

最佳答案

我很好奇，看看是否真的有人愿意这样做，但这是我的理解：

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

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