游戏开发中的实时进程通信
如果您制作的游戏架构将系统组件（IE、渲染、物理、逻辑、输入、脚本等）拆分为不同的线程，那么您如何处理需要实时通信的情况？
例如，如果脚本想要在屏幕上绘制一个框，那么理想情况下，当渲染组件发出“FrameDrawn”事件时，它会执行此操作，以便在每个帧绘制结束时将框绘制在屏幕顶部。 如果脚本组件和渲染组件位于彼此不同的线程上，这怎么可能呢？
If you make a game architecture that splits up system components (IE, rendering, physics, logic, input, scripting, etc) into different threads, how do you handle cases where real-time communication is necessary?
For example, if a script wants to draw a box on the screen, it would ideally do this when the rendering component issues a "FrameDrawn" event so that the box would be drawn on top of the screen, at the end of each frame draw. How is this possible if the scripting component and the rendering component are on different threads from each other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
通常，渲染线程是唯一将内容绘制到屏幕上的线程。 但是，由于线程可以通信，因此脚本线程可以告诉渲染线程“嘿，我想在下一帧绘制一个盒子”。
我们的项目处理线程通信的方式采用两种方式之一。 对于动态编辑的内容（对象列表、移动车辆等），我们创建一个互斥体，用于在更改数据时锁定数据。 如果渲染器想要绘制它，但更新线程正在删除该对象，则渲染器将不得不等待。 对于其他事物，例如 ui，我们只需由 ui 线程写入并由渲染器读取的全局标志，因此不需要互斥体。
Typically the rendering thread is the only one to ever draw things to the screen. However, since threads can communicate, it's possible for say the scripting thread to tell the rendering thread "Hey, I want to draw a box next frame."
The way our project handles thread communication is in one of two ways. For something that is dynamically edited - lists of objects, moving vehicles, et cetera, we create a mutex that locks the data when it is being changed. If the renderer wants to draw it, but the update thread is deleting that object, the renderer will have to wait. For other things, like the ui, we just have global flags that are written by the ui thread, and read by the renderer, so no mutex is required.
您所要求的实际上是不可能的，这就是为什么一般规则是只有一个 UI 线程。 如果另一个线程想要在屏幕上显示某些内容，它应该向 UI 线程发送一条消息，UI 线程将在渲染时显示该消息。
What you're asking for isn't really possible, which is why the general rule is to only have one UI thread. If another thread wants to show something on the screen, it should send a message to the UI thread which will show the message when it is rendering.
大多数游戏将拥有大量数据和根据需要引用该数据的某些子集的多个线程。 线程之间的通信很少是显式的，更常见的是隐式的，通过一个线程引起的数据更改来完成，并稍后由第二个线程注意到。 这些更改受到互斥体、信号量或其他低级同步原语的保护。
对于您的绘图示例，脚本线程将更改 GUI 组件和渲染线程中的一些数据，下次渲染 GUI 时，将看到新数据并相应地绘制框。
但请记住，大多数游戏开发人员不会像您的示例中那样对事物进行如此多的线程处理，部分原因是使用共享大量数据并依赖低级锁定来确保正确性的模型很难有效地做到这一点。 理想情况下，更多的游戏开发人员会转向共享较少数据的模型，但由于软实时呈现响应要求，这很困难。
What most games will have is a massive pile of data and several threads referring to some subset of that data as needed. Communication between threads is rarely explicit and more commonly is implicit, done through a change in the data caused by one thread and noticed later by a second thread. The changes are protected by mutexes, semaphores, or other low-level synchronisation primitives.
For your drawing example, the scripting thread would change some data in the GUI component and the rendering thread, next time it renders the GUI, would see that new data and draw the box accordingly.
Bear in mind however that most game developers don't thread things quite so much as is in your example, partly because it's difficult to do that effectively with a model that shares so much data and relies on low level locking for correctness. Ideally more game developers would move towards a model that shares less data but that is difficult due to the soft-real-time presentation response requirements.