游戏中的几秒计算同时保持 60 FPS
我有一个需要几秒钟才能完成的算法。我正在尝试将其实现到我正在创建的 60fps Flash 游戏中。我想知道 ActionScript3 中是否有一些规定可以中断计算以便更新框架并随后继续计算。可能没有，所以我假设最好的方法是执行 x 毫秒的计算，测量之后的帧速率，然后如果帧速率小于，则调整下一帧的计算运行时间或大于 60 fps。这样做的缺点是游戏无法以稳定的 60fps 运行...
关于如何（最佳地）在 AS3 中执行大量计算同时保持帧速率还有其他想法吗？
编辑：对于好奇的人（计算，也许我应该说算法）： 我正在为游戏 AI 对象创建一个运动规划库（运动规划的一种用途）。该算法类似于迭代数千次的 RRT（快速探索随机树）。
演示链接：http://www.swfcabin.com/open/1279044355
点击查看运动计划。圆可以向任意方向以固定大小“推力”。
另外 - 没有线速度阻尼（即摩擦）。
I've got an algorithm that takes more than several seconds to complete. I'm trying to implement it into a 60fps flash game i'm creating. I am wondering if there is some provision in ActionScript3 to interrupt a computation in order to update the frame and continue the computation afterwards. There probably isn't, so I'm assuming the best method would be to perform the computation for x milliseconds, measure what the frame rate is after, then adjust the time the computation will run for next frame if the frame rate is less than or greater than 60 fps. The drawback with this is that the game won't run at a steady 60fps...
Any other ideas on how to (optimally) perform a large computation in AS3 while maintaining the framerate?
EDIT: For the curious (the calculation, perhaps I should have said algorithm):
I'm creating a motion planning library for game AI objects (one use for motion planning). The algorithm is along the lines of a RRT (rapidly exploring random tree) that iterates thousands of times.
Demo link: http://www.swfcabin.com/open/1279044355
Click to motion plan. The circle can "thrust" at a fixed magnitude in any direction.
Also - there is no linear velocity damping (i.e. friction).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你能分阶段进行“计算”，然后每帧只进行一个阶段直到完成吗？将其分成您知道可以放入框架中的块，并随着时间的推移进行。
几个例子：
我在一个游戏中计算了实体之间的视线。时间比较长，硬件也不是很强大，所以我们每一帧只更新一个物体的视线。玩家的视线每隔一帧更新一次，敌人在中间的帧中循环更新。
相反，如果您要基于大型数据集进行计算，请将数据划分为较小的块，并且每帧仅执行一个块。例如，如果您需要找出距离您的飞船最近的恒星，并且有一百万颗恒星，则可能每帧只需要计算一千颗。
也许您的计算不容易映射到其中任何一个；如果你有一个你想要完成的事情的例子，那将会非常有帮助！
Can you do the "calculation" in stages, and then just do one stage per frame until it's done? Split it up into chunks that you know can fit into a frame, and do it over time.
A couple of examples:
One game I worked on computed line of sight between entities. It took a long time and the hardware wasn't very powerful, so we only updated the line of sight for one object each frame. The player's line of sight was updated every other frame, and the enemies were updated round-robin in the intervening frames.
If instead you're calculating something based on a large dataset, partition that data into smaller chunks and do only one chunk per frame. For instance, if you need to figure out the closest star to your ship, and there are a million stars, maybe only do a thousand per frame.
Maybe your calculation is not easily mappable to either of these; if you have an example of what you're trying to accomplish it would be very helpful!
根据计算的类型，您可以编写一个 Pixel Bender 内核，使用 ShaderJob 在后台进行处理：
http://www.boostworthy.com/blog/?p=243
http://www.huesforalice.com/project/47
另外，这里还有另一个链接，指向如何在 Actionscript 中实现伪线程的教程：http://blogs.adobe.com/aharui/2008/01/threads_in_actionscript_3.html
Depending on the type of your calculation you could write a Pixel Bender Kernel that does the processing in the background using a ShaderJob:
http://www.boostworthy.com/blog/?p=243
http://www.huesforalice.com/project/47
Alternatively here is another link to a tutorial how to implement pseudo threading in Actionscript: http://blogs.adobe.com/aharui/2008/01/threads_in_actionscript_3.html
更新：
Flash Player 自从11.4
后台工作人员允许在后台执行任务，而不会阻塞主工作人员，这似乎非常适合您的需求。作为一个不错的奖励，在多核 cpu 上，后台工作程序将能够并行运行，而不会减慢主工作程序的速度。
不过，AIR mobile 目前不支持 iO 上的工作程序（AIR 4.0 和 AIR 13 beta）。
此外，正如其他人已经说过的，寻路不应该那么长！您应该考虑使用另一种算法，因为Rapid听起来与需要几秒钟才能完成的算法不兼容。最著名的寻路算法是A star (A*)
UPDATE:
flash player has been supporting workers since 11.4
background workers allow to perform tasks in the background without blocking the main worker which seems perfectly suited to your needs. As a nice bonus, on multicore cpu, background workers will be able to run in parallel without slowing down the main worker
AIR mobile doesn't support workers on iOs for the moment though (AIR 4.0 & AIR 13 beta)..
Also, as already said by others, path finding should not be so long ! you should consider using another algorithm, because Rapid does not sound compatible with an algorithm that takes more than several seconds to complete. Most famous path finding algorithm is A star (A*)