关于windows的时间函数(timeGetTime,QueryPerformanceCounter)不准确
当游戏中用到大量纹理处理,如Render to texture之类的操作函数的时候,很多机器上会出现获取的时间不正确.
具体表现是,假设一个实际1000毫秒的时间,游戏若有10帧,那么每帧获得的时间差应该是100毫秒左右(实际上真正的耗时也是100毫秒),但是通过timeGetTime或QueryPerformanceCounter得到的时间差,会发生前9帧是90,最后后一帧是200左右.也就是前面获得的时间比实际的时间短,后面一帧的时间比实际长很多(就像是为了弥补前面的时间错误,硬加上一段时间),长期来看时间是正常的,但会导致没帧时间的错乱.请问有没人遇到这个问题.
另外就是,以前很少机器会出现这个问题,最近越来越多机器出现这个问题.
这个情况出现是会在所有图形程序上出现的,比如我们的游戏和 <激战> 等,开了最佳效果就会出现,跑几帧,跳一帧的情况,有可能是某个微软补丁出的问题吗?
[解决办法]
两个问题混在一起了
首先游戏的渲染速度的问题, 他很少会是一个时间控制函数, 你说1秒钟绘制10帧是可以的, 但是你要精确控制每100ms绘制一帧是很难的.
每一帧都要更新一次画面, 生成画面用的时间一定都能保证小于100ms吗? 不一定. 在不同的机器上, 上场景的不同时刻, 用户的不同的操作下, 这个渲染时间都是变化的. 基本上不可能控制在刚好100ms上,总有多的时候,和少的时候. 10帧, 也许大致的时间分布是 89 120 90 130 120 80 ... 这样的, 如果前面9次都是小于100,后面的一次大于200的情况太偶然了. 往往都是一段时间内有微小的变化.
在实际实践的过程当中,如果用dx或者opengl实现, 由于程序设置的原因,可能实际的刷新速度收到显示器的刷新次数的显示, 一次垂直回显过程当中只能刷新屏幕一次. 会有可能造成实际的帧率相差较大. 这种情况存在, 但是可以通过程序设置修改它,回避它.
速度的控制是另外一个问题, 知道有帧时间不同的这个实际情况, 在设计的时候就要回避它.
我们不能假定帧时间和刷新速度是多少, 而是固定一个运动速度,计算出实际的帧时间,用速度和时间做乘法得到实际的运动距离, 这样物体的运动就不会跳跃,而是连续的稳定的
[解决办法]
帧速率在不断变化是正常的。编游戏的时候不会用定时器的，都会用查询的方式来绘制动画。
[解决办法]
你怎么知道不对?170ms和120ms你能感觉出来？
QueryPerformanceCounter是cpu的时钟，这东西具体怎么回事我不知道，不是搞硬件的，很准就是了
有一个devpartner的工具，可以进行程序性能测试，看什么地方用的时间是多少，你可以用用看，很方便的工具
