在构建我的类看起来像这样的游戏引擎时,我一直在遇到这个问题:
interface Entity {
draw();
}
class World {
draw() {
for (e in entities)
e.draw();
}
}
这只是伪代码,大致显示绘图是如何发生的.每个实体子类都实现自己的绘图.世界以无特定顺序循环遍历所有实体,并告诉他们逐个绘制自己.
但是使用基于着色器的图形,这往往是非常低效或甚至是不可行的.每个实体类型可能都有自己的着色器程序.为了最小化程序更改,需要将每种特定类型的所有实体绘制在一起.简单类型的实体(如粒子)也可能希望以其他方式聚合其绘图,例如共享一个大的顶点数组.并且它通过混合变得非常毛茸茸,并且某些实体类型需要在某些时间相对于其他实体类型呈现,或者甚至在不同时间通过多次实现.
我通常最终得到的是每个实体类的某种渲染器单例,它保存所有实例的列表并一次性绘制它们.这并不是那么糟糕,因为它将绘图与游戏逻辑分开.但是渲染器需要确定要绘制的实体子集,并且需要访问图形管道的多个不同部分.这是我的对象模型往往变得混乱,有许多重复的代码,紧密耦合和其他坏事.
所以我的问题是:这种高效,多功能,模块化的游戏绘图的优秀架构是什么？