我正在使用OpenGL开发一个简单的游戏，使用SDL进行显示初始化和输入，从时间的角度来看，我有两个选择。当以秒为单位的optimableTimePerFrame = 1 / theFramerateCap时，排名第一的仅是为optimizeTimePerFrame休眠的-theTimeTakenToRender。（我不完全确定这是否必要，因为这等效于使用vsync，这可能更准确。如果我的假设正确，请告诉我SDL + OpenGL是否默认具有vsync，如果没有，另一种方法是测量自渲染最后一帧以来的时间，并仅相应地调整运动。（渲染框架所花费的时间越短，实体在该框架中移动的距离越少）。在性能，减少闪烁等方面，这两种方法的优缺点是什么？
Answers:
如果您的帧时间不可预测（无论是否是您的错；操作系统可能偶尔使用资源等），将可控制的帧速率设置为略低于可达到的帧速率将对可预测的延迟起到很大作用，这可以使游戏感觉更好。
更改处理输入和呈现与输入相关的更改之间的时间间隔可能会很糟糕-即使平均而言，您在两者之间获得的延迟较小，“抖动”对于人类（有意识或无意识）也很明显。
请参阅Microsoft GameFest演示文稿框架中的内容：撕裂，延迟和帧频，以获取一些见解。Carmack也有一系列对此有用的博客文章。
另请注意，当您使用低值运行帧deltaT时，甚至当您完全使用变量时，某些数学运算可能会崩溃deltaT（以“稳定”和可预测的方式进行操作可能会变得更加困难甚至难以处理，这对事情很重要）例如重播和某些形式的网络同步）。请参阅此处修正时间步以获取一些见解。
SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);
您最终将使用更少的CPU（多任务处理者会感谢您），移动设备上的人们也会对此感到赞赏。
您永远，永远，永远，永远不要使用Sleep控制帧率。
之前已经解决了这个问题，我将带您参考另一个问题来讨论其原因。没有提到的一件事是，在典型的现代刷新频率为60Hz的情况下，并且睡眠调用的典型粒度为1毫秒，实际上不可能在帧之间正确的时间内睡眠。
我并不是说让您无所事事而屈服于CPU是件坏事。离得很远。但这与控制帧速率不同，“睡眠”是适合前者的解决方案，但不适用于后者。
相反，请检查是否经过了时间，以及是否该运行一个帧，那么就这样做，否则-如果要产生一些CPU，请在最短的时间内休眠-1毫秒。还要确保为您的平台适当设置了睡眠计时器，以便为您提供良好的分辨率；也就是说，当您发出“ Sleep（1）”呼叫时，您实际上有机会真正睡眠1毫秒，而不是15、20或30（否则情况会如此）。我相信SDL将为您自动执行此操作。
您还可以在其中添加一些松弛度，以便在接近运行帧的时间时，可以停止“睡眠”并开始平放运行直到帧运行，这可以帮助您更准确地达到所需的帧间隔。
最终看起来像是一整串的Sleep（1）调用，其中散布着偶然的帧，这没关系。您仍然可以在不需要CPU时放弃它，但是您的框架仍然可以按时运行。
设置帧速率上限可能最重要的好处是，它可以帮助防止对计算机造成实际的物理损坏。 他们忘记在Starcraft II上执行此操作，对于某些用户来说，直到修补它之前，这对他们来说是非常麻烦的（而且昂贵）。