框架图最终看起来像这样。 一行。 这是我们想要的完美选择。 任务可以是它们碰巧遇到的任何线程，并且没有两个线程可以同时接触API。
这里有一些细微差别。 从技术上讲，在我们的引擎中， DebugWindow2可以先于DebugWindow1 。 这完全取决于它们初始化的顺序。无需赘述，可以说有很多机制可以控制DebugWindows的运行顺序。
- 根据Unity中的屏幕分辨率缩放精灵
- 大逃杀的出现– DBFig –中
- 生产基础知识-三年后
- Robothorium验尸
- “独立游戏公司Bossa为Worlds Adrift筹集了1000万美元”：标题背后的故事
因此，将非线程安全的API集成到我们基于任务的引擎中时，这是一种无锁的方法。 尽管它永远不会等待或阻塞，但是如果ImGui本地支持它，它将以串行方式进行大量处理，这可能是并行的。 但是，这非常好，并且该方法可以与我们使用的其他API一起使用。 此外，更新UI并不是我们的性能瓶颈，因此使ImGui线程安全是安全性而非性能驱动的目标。 串行运行根本不是问题。
您将注意到有关该解决方案的信息，即我要告诉引擎的是“我希望SystemA依赖SystemB”而不显式调用SystemB。 几乎就像我想要一个类似DependsOn的语法。 问题在于，在Mana Engine中，一个关键原理是，任何系统都不需要了解其他系统。 系统仅具有有关组件的知识，并且将其解耦会使引擎如此模块化。
另一方面，令牌设置非常好，因为我可以不断向ImGuiControlsToken添加越来越多的系统来编写ImGuiControlsToken ，而RenderImGui系统永远不需要知道这些更改。 它具有真正的灵活性和强大功能，尤其是如果您要将新系统插入可能没有编写的现有系统集中，则尤其如此。 （实际上，我已经通过允许我的地形系统以相同的方式“挂接到”渲染系统来完成这种事情）。
最后，这与图形编程是并行的—一个高度并行和并发工作得以完成的地方。 这些标记仅可被视为栅栏或信号灯，系统可以在其中指示它们需要位于栅栏的哪一侧。 能够利用现有模式的游戏开发人员将习惯于采用和易于使用很重要。
这样就为进入Mana Engine的这个小高峰做好了准备。 我知道这些文章并不全面，并且在介绍有关引擎的新机制方面有些混乱。 如果我正在编写诸如课程作业或教程系列之类的书，那我早先会介绍Singleton Components。 因此，如果很难遵循，请多多包涵，我深表歉意。 但是，如果您想了解更多或有任何疑问，请在twitter（tloch14）上发表评论或@我，我将很乐意回答您的任何问题。
