这就是差距啊。。。

这段时间应一位同学的请求，做了个吃豆子游戏。

关于吃豆子游戏应该说是很简单了吧?
尽管如此，我总是发现我做的游戏为什么就是不如先前那个叫clanLib中的吃豆子游戏例子来得流畅。(不爽啊)

除了绘画的API不相同以及图片不一样之外，算法基本上都是一样的啊。
就连人物的移动速度都调节成一样了，虽然对于任务来说是关系不大。但对于一个真正的游戏这是致命的啊。
幸好这有源代码，于是我把clanLib打开，经过比对分析,发现有个地方不一样影响到调用的时机。
我照着原理加入我自已的代码后就一样流畅了!

代码如下:
    for (;m_startTime < dwCurrent;m_startTime += 50) //这是原本的代码
     {
         for (iter = m_objects.begin(); iter != m_objects.end(); ++iter)
             (*iter)->Active(0.05f); //注1
     }

     if (m_startTime > dwCurrent )                   //这是在原本代码后面加入的代码
     {
         float fTime = (float)(dwCurrent + 50 - m_startTime);
         fTime /= 1000;
         m_startTime = dwCurrent;
         for (iter = m_objects.begin(); iter != m_objects.end(); ++iter)
             (*iter)->Active(fTime);
     }

我原来也是初看之下认为都是间隔50ms调用一次所有对象的激活。
最后想一下不对哦，比如现在的startTime 是 30ms,加上50ms. 等于80ms.而dwCurrent为40ms。
超出值,退出。下一次我的startTime还是80ms，这样中间就至少少调用了一次移动函数，浪费了一帧，
当每帧出现大量这种情况，我调用的次数基本上少了一倍。于是速度看起来就慢了一倍。
而我移动的间隔大，并且每次就是移动相同的距离，这就造成了卡的情况出现。

通过这次经验我又得出一个简单的道理，就是要在每帧都尽可能的显视出数据的变化。就好象上面的1ms的变化，每帧都要清楚显示。

唔，其实上面这段代码这样改了还是有问题(注1):当第一次startTime就小于Current,但不足50ms，而下面的代码的Active则笨蛋似的还搞
个50ms的信号送过去。

于是我又改，惊奇的放现改过后的代码与clanLib中的代码连形式都很相似了，不排除是看了他们代码受到影响了呵
float tmDiff = (float)(dwCurrent - m_startTime);
tmDiff  /= 1000; //ms转换为秒
float tmActive;
for (dffTime > 0.05; dffTime -= 0.05)
{
      tmActive = dffTime > 0.05f ? 0.05f : dffTime;
      for (iter = m_objects.begin(); iter != m_objects.end(); ++iter)
         (*iter)->Active(fTime); 
}