推拉玻璃钢在实施游戏时有帮助吗？

Question

我一直在比较只拉玻璃钢( in )和推拉玻璃钢(即反应班纳纳)在游戏的实现。一个比另一个有优势吗？我注意到的是：

• 推送事件使从GLFW或GLUT获得鼠标单击/按键的事件变得容易。
• 网状使用的箭头化玻璃钢的IO更少，这总是更好的。
• 看起来，对鼠标运动这样的事情只有鼠标的反应可能会导致时间泄漏。

我还错过了什么？

编辑，以减少基于意见的内容:主要目标是尽可能地表达/简洁，不漏时间。

更新：--我在上发现的一个重要问题是，似乎没有一种方便的方法可以拥有多个框架，正如文章“修复您的时间步骤”中所描述的那样。

更新2:我的方法是让我的游戏模拟线返回一个Float -> IO ()，它接受alpha值，所有GL调用都使用该alpha插值的所有内容。理想情况下，我应该能够通过MVar将这个“绘制函数”传递到另一个线程中，并在该线程中运行它。伙计，哈斯克尔太棒了。

更新3:在提出这个问题后的六个月里，我开发了一个基于的简单渲染引擎，以及“实体组件编程”的概念。在这个过程中，我发现玻璃钢的使用并没有太大的帮助。在某些情况下，Wire的表现力实际上是一个障碍。问题的中心是物体的“身份”。当定义Wire类型的值时，它没有标识，即它可以在整个网络中多次重复使用，并且每次表示不同的物理事物。这是一个巨大的痛苦，当你想要做的事情，如碰撞检测，并没有办法遍历场景图，因为它不可能存在，除非融合成一个不透明的电线。这个问题在“玩具”示例中没有出现，因为很容易精确地指定哪些对象的属性与其他对象以哪种方式交互。我相信这是任何一种玻璃钢的问题。

如果有个哈斯克尔巫师在这件事上证明我是错的，那就太棒了，但我真的看不出有什么办法。如果这个解释不是很好的话，我也很抱歉，但是如果不亲自尝试的话，这并不是那么容易理解。

Answer 1

从我所能读到的这里和那里，内特维尔和活性香蕉有不同的目的和目标。Netwire擅长对框架信号(如游戏服务器)进行建模，因为游戏服务器通常所做的是在周期性帧中将其状态发送给客户端。对于创建GUI来说，反应性香蕉将是更好的选择，因为GUI是一个纯事件驱动的模型，不能容忍时间泄漏。

在我看来，您可以同时使用这两种方法，这取决于您想要实现的方面。