一位同事和我正在讨论如何在复杂的游戏中呈现场景。他认为世界是以最真实的面向对象的方式呈现递归，世界上许多演员都会覆盖像Actor.Draw（）这样的虚函数（例如Koopa.Draw（），Goomba.Draw（ ））。
相比之下，我想象今天的复杂游戏将迭代在他们的场景图上，避免虚拟函数开销，并为专门的迭代器提供更大的灵活性（例如，近远到远远到远 - 我在OpenGL和DirectX中的经验告诉我，他们倾向于批量绘制对象，并通过递归调用传递批处理上下文（即类的Draw（ ）函数会绘制）似乎是额外的参数传递开销，可以通过迭代避免。
现在有一种方法比另一种方法更受青睐吗？如果是这样，为什么？
答案 0 :(得分：1)
更新部分场景图可能会以递归方式完成。但绘图通常是通过一些空间分区数据结构和几何/渲染状态批处理来完成的，以防止过度绘制（通过前后绘制），并最小化渲染管道的状态切换（批处理）数据，绘制使用类似资源的调用并呈现状态）。通常这个绘图部分是迭代的。
您必须考虑场景的复杂程度，构图以及绘制的对象数量。对于具有更简单场景或预先获得某些信息的项目，最佳地对渲染（近 - ）进行排序将不值得计算绘图序列或批处理的实际成本。
最后，“青睐”的方法将是针对具体项目的。