在没有对灰框架进行具体考虑的情况下,有很多方法可以处理物理&图形引擎更新,它不一定取决于您使用的框架。首先,除非您制作的AIR移动应用程序只针对具有足够硬件要求的设备,否则您不能假设每秒60帧的帧率(或任何固定帧率)。 这使你有几种选择:固定增量T.
更新物理引擎,在这种情况下任何错失框架将减慢游戏物理。不好
测量最后帧之间的实际增量t并相应地更新物理引擎以补偿前一帧的延迟。这应该在mostcase足够
如果由于某种原因,你的物理引擎需要固定的增量(例如updatePhysic(1/30);
给出了一个太不同的结果从updatePhysic(1/60); updatePhysic(1/60);
,或者如果你需要完美的帧率独立reproductible物理,像计算重播,或保持同步联网客户端物理)取代updatePhysic(dT);
通过 for(var i:int = 0; i< dT * 60; ++i) updatePhysic(1/60);
(如果增量t是否总是1/60实施多你应该积累师为下一次更新)
如果您需要最佳性能和最佳利用休息多核CPU的,你可以利用ider在单独的工作人员中更新物理引擎,但Flash Player支持,调试工具和工作人员之间的共享数据仍然是实验性的!
在任何情况下,我不明白这一点在
我想在60 fps的更新我的渲染系统,但在固定的时间间隔更新游戏逻辑,万一有落后?
,因为如果有一个“滞后”,这意味着显示器不会以60fps进行更新,即使它是(因为你在一个分离的工人进行物理上的可能性),它会显示相同再次构架。
综上所述,您可能需要运行物理引擎比图形引擎“更快”,但从不相反。
此外,在actionscript中,您不能触发比实际帧率更快的刻度: 任何对Timer,setTimeout,setInterval ...的调用都将与显示最多同步,但永远不会更快,这就是为什么您有在主循环内手动调用物理引擎几次,而不是仅设置一个刻度到60 fps,例如
您可以计算您的PhysicsSystem.update()方法中的时间增量,如果增量小于您的值,则不做任何操作期望的间隔。 – Varnius 2014-03-19 10:11:20