游戏引擎是如何调度渲染和逻辑代码的?
前排跑题警告,想借着这个题交流一下最近捣鼓的一套渲染器的接口流程,而不是单纯局限于Unity的时钟处理。下面提到的这套接口流程还没有经过任何验证,所以如果有大佬能指出缺陷,将会是十分珍贵的。
我的目标就是使用原生的DirectX 12开发独立渲染模块,而这个模块要做到的是可以打包成动态库给其他游戏引擎使用,因此要做到本身只做纯渲染的工作,输入和输出都相对干净,同时还要尽可能绕开C++标准中没有的部分,防止踩坑,此为前提。
首先,我将整体框架解耦成:窗口,渲染器两个部分,窗口可以是最简单的Winmain + WNDCLASS,也可以是Unity或者Unreal那种丰富到极致的花里胡哨的GUI,而我认为这些窗口无论怎么千奇百怪也离不开Backbuffer, Swapchain等等,因此,我把窗口部分向渲染部分传递的数据整理下来:
有些操作是不同窗口不同做法的,这就意味着这些操作的事件需要经过窗口层传递到渲染层,这就多开一个单独存储函数指针的类型:
因为调用的主动权一直是在窗口层,而渲染层只有被调用权,因此窗口层将会持有渲染层的“引用”,这个引用将会拆解成一个void*指向类的地址,和一个存储所有渲染层应有的逻辑的函数指针列表:
这里Initialize也就是包括了整个渲染器的构造,并且返回指针,Dispose自然就是析构函数,其他两个则是窗口大小改变和每帧的绘制函数,最后,渲染层的动态库将会提供一个生成这个IRendererBase的裸函数,拼上最后一块砖:
这样如果要解耦合渲染器部分,比如打包DLL,基本只需要将GetRendererFunction函数标记为DLL导出格式,窗口层的设计就比较随意,只要保证让渲染器在窗口初始化之后再构造,在窗口销毁之前被销毁,并且每帧调用一下,就可以了。
在最原始的windows app里(忽略Debug部分)调用过程就几行,其中D3DApp是窗口:
Run内部的逻辑比较简单粗暴,就是while循环调用Draw,外加一些更新时间等操作。因为渲染器是一个多线程并行的多帧异步渲染模式,因此Draw函数逻辑很简单并不会有什么开销,唯一的阻塞就是需要等待两帧之前的GPU的渲染结果,当然这也是没有办法的事情。
通过这套系统,把可能的逻辑和渲染层的沟通都涵盖住了,如果逻辑需要更新,则通过DataPack传递进去,渲染器因为只负责把结果输出到屏幕,所以可以不设计任何数据上和逻辑上的回调。
Copyright © 广州京杭网络科技有限公司 2005-2024 版权所有 粤ICP备16019765号
广州京杭网络科技有限公司 版权所有