问题描述
我编写了这段代码来将 SDL 游戏限制为 60 fps,这是实现 fps 计数的正确方法吗?
int fps=60;
int desiredDelta=1000/fps; //desired time b/w frames
while (gameRunning)
{
int starttick=SDL_GetTicks();
// Get our controls and events
while (SDL_PollEvent(&event))
{
if (event.type == SDL_QUIT)
gameRunning = false;
}
window.Clear();
for(Entity& e: entities)
{
window.Render(e);
}
window.display();
int delta=SDL_GetTicks()-starttick; //actual time b/w frames
int avgFPS=1000/(desiredDelta-delta); //calculating FPS HERE
if(delta<desiredDelta)
{
SDL_Delay(desiredDelta-delta);
}
std::cout<<avgFPS<<std::endl;
}
解决方法
在游戏中,通常有两个“帧率”需要担心:显示器的帧率和游戏物理的帧率。理想情况下,您以显示器的原生帧率绘制。为此,请确保将 SDL_RENDERER_PRESENTVSYNC
标志传递给 SDL_CreateRenderer()
。
对于游戏的物理特性,您可以测量两个渲染帧之间的时间,并将其用作物理时间步长,以便与显示帧速率基本匹配。优点是您的速率是自然同步的,但缺点是游戏的物理性能可能会出现精度问题,尤其是在渲染时间过长以致于显示帧率下降到低值的时候。
或者,您对物理使用固定的帧率。但是,如果您选择后者,那么您必须考虑如何处理不同步的两个帧率,但这并不能通过添加 SDL_Delay()
来解决。通常的方法是让渲染线程根据需要插入基于物理的动画。
您的代码中一个更实际的问题是 SDL_GetTicks()
以毫秒为单位为您提供时间。这不是很准确;如果您的显示器以 60 fps 运行,那么一帧需要 16.66666... 毫秒。您的计算将有高达 1 毫秒的误差,即一帧长度的 6.25%。根据游戏类型的不同,这实际上可能很明显!