定帧带来的问题

游戏的心跳，往往因当前一帧运算量的不同，而有不同的delta时间。但是定帧则要求每间隔固定时间执行一次运算。

我们对于定帧的常规实现之一如下：

// 逻辑定帧的时长
float logicFrameStep;
float timeCount;

// 显示帧的心跳函数
void Update(float deltaTime)
{
    timeCount += deltaTime;
    while (timeCount >= logicFrameStep)
    {
        // 逻辑心跳
        LogicTick();
        timeCount -= logicFrameStep;
    }
}

通过此种方式，可以实现逻辑定帧的实现。

但是，当游戏需要平滑显示而逻辑却需要定帧运算时，矛盾便产生了。由于逻辑帧定时长执行，而现实帧不定时长，所以在同一显示帧中可能会运行n个逻辑帧，且n个逻辑帧的总时长不一定等于该显示帧的时长。

逻辑定帧与显示帧的错位关系

虽然定帧的方式可以确保每一逻辑帧运算后，所有数据都是正确的（起码站在逻辑的角度是这样），但是根据上图可以发现，显示帧是会存在时间富余的（逻辑帧3在显示帧1内是没有执行完的）。

因此从显示的角度看，显示帧1只进行了2帧逻辑，而显示帧2则进行了4帧逻辑，虽然显示帧1与2之间的时间比为5：7。正是因为显示帧内 逻辑定帧的比值 与 时间的比值 不同，从而导致了显示层的一个大问题 —— 抖动。

显示平滑的处理

针对抖动，笔者曾尝试用数学的方式进行矫正，但是结果证明效果并不理想，运算量提升不说，效率也不太高（使用的是最小二乘法，但是它显然不太可以胜任我们的需求）。

笔者也曾使用变速的方法让移动平滑，即当前数据离目标数据越远，则以更高速度接近，否则接近速度降低。但是这样一来会产生与逻辑相比失真的问题，且速度的变动公式会很大程度影响体验，因而该方案也被我们的项目抛弃了（这种方案是我从《梦幻西游》的摄像机移动上学来的）。

后来笔者意识到自己把简单问题复杂化了。其实问题的核心就是数值要在指定事件内变化指定大小。既然抖动是当前帧的显示与逻辑不匹配造成的，那么让显示延迟个1-2帧，不就有可以修复这种抖动了吗，毕竟延迟显示1-2帧还不太会影响用户体验（我不信《守望先锋》里早这么1帧你就会变成神枪手）。

核心代码如下：

// 经过平滑后的结果值
public double Value;

// 插入新值
// duration代表逻辑帧时长
// target代表这一逻辑帧的目标值
public void Insert(float duration, double target)
{
    __waitSeconds += duration;
    __targetValue = target;
}

// 核心心跳
// 利用__waitSeconds计算当前显示帧对应的值Value
public void Tick(float delta)
{
    if (__waitSeconds <= delta)
    {
        Value = __targetValue;
        return;
    }

    double p = delta / __waitSeconds;
    Value = Value * (1 - p) + __targetValue * p;

    __waitSeconds -= delta;
}

每个显示帧调用Insert方法收集数据。而每个显示帧则调用Tick方法计算平滑后的结果值Value。