结合Processing.js和Web Workers的强大功能

时间:2009-08-23 15:09:23

标签: javascript processing.js web-worker

我一直在阅读有关Javascript语言中两个(相对)新概念的内容 - Web Workers和John Resig的令人敬畏的Processing.js(好吧,不是一个新的'Javascript概念',但你得到了我的想法)。两个很好的例子都徘徊在互联网上,但我还没有找到一个有效地采用这两种技术的例子。它看起来非常有趣和强大,所以我想我最好试一试。

然而,我无法找到最好的脚本设计来集成他们两个......在我看来,通常,当使用Processing.js时,某些类在 >'处理 - 应用'。它允许您使用类似Java的语法来解决此问题。但是,这些类只能在Processing-application中访问 - 这很明显。但后来我们得到了Workers ......在this惊人的例子中,Javascript函数对象首先在一个单独的脚本中定义,如果需要Worker-usage,则Worker-script导入该对象的原型和种类'螺栓'本身就在它上面。

对我来说,这两个似乎不是“可互换的”,因为当你在Worker脚本中时,你无法访问在Processing-application中定义的类。可能有一个原因,因为类似处理的类肯定不是很像Javascript。据我所知,我将不得不在我的Worker脚本中对类进行类似的定义(以新函数原型的形式) - 这对于可维护性来说不是很好,而且看起来非常糟糕的设计对我而言,即使我仍然是这个主题的新手。

我忽略了什么吗?我想要一些不应该的东西吗?或者我只是误解了一些基本概念?

感谢您的帮助!

修改

继续尝试弄乱工人的原型,以便“塑造”它就像它应该工作的对象一样,但很快意识到这不是可行的方法。

让我们尝试使用大纲: 我有一个类'Ball',除了存储二维位置之外几乎什么都不做。在每个draw()周期,Processing.js调用其update()方法,这使得Ball采用新的位置。之后,调用display()方法,让Ball在当前位置绘制一个小圆圈。

开始时没什么复杂的。现在,假设确定球的新位置是一个非常昂贵的操作 - 例如,如果它涉及球通过'复杂'引力场的运动。如果必须在绘制之前每次进行此计算,则至少会导致一些延迟。但是,如果您设法同时执行此操作,则可能会更顺畅地运行。所以,我发现我可以给Ball类在其属性列表中添加一个额外的'位置'数组,它将保存所有连续的位置。当球被实例化时,它会创建一个新的工人,它将开始计算位置,每次完成一个位置时,它会将一条消息回发给Ball,其中包含一个新的二维位置。然后Ball会将这个推到它的位置数组,所以每次它必须更新它的位置时,它只会走到阵列中的下一个记录。

总而言之 - 好的或坏的想法?如果好,有关如何设计的任何建议吗?

5 个答案:

答案 0 :(得分:3)

3D游戏物理模拟(如在xbox360上)通常以固定速率运行,与帧速率无关。这是因为物理分析太复杂,无法进行分析,因此您需要进行数值近似,因此需要确定性地同步误差。额外的好处是帧率与物理性能分离,因此您可以在5hz更新物理和插值等。

所以你描述的模型正是专业人士的表现。

答案 1 :(得分:1)

  

您无法访问在Processing-application中定义的类,   当你在你的工作人员脚本。可能是有原因的

这是为了防止多个工作人员同时更改相同的共享数据而导致的错误。在消息中,数据被复制,每个Worker都有自己的副本,因此不必担心同时写入会导致错误。这是一种避免处理它的并发错误的简单方法,而程序员不必担心它(没有信号量或同步等)

答案 2 :(得分:0)

在这个例子中,位置的计算必须在绘制球之前完成 - 所以异步处理没有意义吗?

p5本身非常同步 - 有一个中心 draw 方法可以完成所有绘图。

Web工作人员也无法访问dom,因此无法用于绘图。

对于像游戏这样的基于事件的更复杂的应用程序,可以使用网络工作者。

答案 3 :(得分:0)

只是一个想法......但在signal processing中你所做的是提出一个采样率,将模拟信号切换成数字信息。关键是要保留足够的信号来重建原始信号。就像使用128,192等从音乐文件中翻录MP3一样

因此,如果您以数学上可定义的方式移动球(即沿抛物线),您应该能够将路径转换为一组近似于模拟路径的坐标。这些坐标比完整路径计算得快得多。它也是可调的(通过改变采样率)。

我知道这并不能解决有关Processing.js或Web Workers的任何问题。只是一个想法,可以帮助您更有效地执行这些计算。

答案 4 :(得分:0)

这个想法让我想起了谷歌的任务队列理念被整合到Google App Engine中。

http://code.google.com/appengine/docs/python/taskqueue/

这可能会帮助你。

对于我的asynch在线棋盘游戏,我将实施一个系统,其中保存消息历史,以便玩家可以看到当轮到他们时发生了什么。发生的每件事都会获得一个唯一的ID,每当玩家收到任何消息时,它都会跟踪他们收到的最新消息。然后,当他们回来时,他们可以看到他们收到的最后一条消息所发生的所有事情的快速动画。

如果我在客户端没有等待时需要服务器来处理某些事情,我将使用任务队列