C++博客-peiinterview

C++博客-peiinterviewhttp://www.cppblog.com/peiinterview/zh-cnMon, 13 Apr 2026 09:37:14 GMTMon, 13 Apr 2026 09:37:14 GMT60游戏中的渲染器架构http://www.cppblog.com/peiinterview/archive/2010/12/28/137620.html裴孝刚裴孝刚Tue, 28 Dec 2010 13:52:00 GMThttp://www.cppblog.com/peiinterview/archive/2010/12/28/137620.htmlhttp://www.cppblog.com/peiinterview/comments/137620.htmlhttp://www.cppblog.com/peiinterview/archive/2010/12/28/137620.html#Feedback1http://www.cppblog.com/peiinterview/comments/commentRss/137620.htmlhttp://www.cppblog.com/peiinterview/services/trackbacks/137620.html
渲染代码往往依赖于开发所使用的开发包。假使你直接使用DirectX或者OpenGL，你的渲染代码很有可能会直接涉及到各种DirectX或OpenGL中的概念。在代码级别，就是会牵扯进很多跟开发包相关的类，函数，结构体等等之类。

也许你会对DirectX或OpenGL做二次封装，开发出一些游戏引擎（或者只是单纯的图形引擎）。于是，现在的渲染代码就可以只跟你的游戏引擎相关（代码级别）。

无论如何，如果直接使用DirectX或OpenGL（一次封装都没做这是很烂的方式），当你移植游戏时你很有可能就会面临从DirectX到 OpenGL代码转化的问题（反之亦然）。而使用游戏引擎呢？游戏引擎隔离了底层具体的开发包（DirectX或OpenGL），但是如果要换引擎呢？换引擎这样的情况我认为是完全存在的，例如现在在Windows下开发了一个基于HGE的游戏，现在我想把这个游戏移植到Linux 下。而HGE是基于DirectX的，要移植到Linux下，你当然可以保持HGE的接口不变，而使用OpenGL重写HGE。这里，你就需要重新开发一个引擎！这很浪费时间！所以你可能会使用另一个在Linux 下运行的引擎（跨平台的引擎也可以），例如ClanLib，于是，这里就涉及到了“换引擎”的问题。

从上文我们可以看出，基于很多原因（不仅仅是要把代码做移植，好的架构还利于代码的扩展，利于开发过程---特指编码过程----的平稳进行等等之类），游戏中渲染器的架构需要得到关注。

接下来我将讨论几种不同的架构：

一．这也是最烂的方式，游戏中无论在什么地方，只要需要渲染了，就加渲染代码。其结果就是各种与图形开发包相关的东西铺天盖地。这样的代码根本没任何幽雅性可讨论。事实上，在很多游戏开发相关的书籍中早就提到过类似“将游戏逻辑和渲染分离开来”的观点。

二．这是我使用了很多次的架构方式，类图为：

Game类是一个Manager类，Renderer类里包含了游戏中所有的渲染代码，Monster是一个具体的怪物类，它没有类似于Render或者 Draw之类的接口，这些接口都被放在Renderer类里，例如RenderMonster()。当游戏需要渲染这个Monster对象时，Game对象就调用Renderer类的RenderMonster接口。

于是，现在Monster类里（基于这种架构，其他所有的精灵类以及各种需要渲染的非精灵类）就没有任何与图形开发包相关的东西。而与图形开发包相关的东西则都集中到了Renderer类里。当你要移植代码时，只需要重写Renderer类即可。

但是这种架构还是有很多问题：

1．随着游戏越做越大，游戏中需要得到渲染的物体就会越来越多。这样，每次都给Renderer类添加一个RenderSomething之类的接口（注意，除了添加接口外很有可能还要添加一些渲染所需要的对象，例如Surface之类的）。Renderer类最终将成为一个非常巨大的类，这违背了面向对象设计的原则（巨类导致的最直接的坏处就是改代码痛苦-----鼠标滚轮滚半天才找到目标代码。just a joke。）

2．事实上，Renderer类的RenderSomething 之类的接口在被调用时还需要一些渲染参数。例如渲染一个精灵类的话，就需要知道要渲染哪一帧，以及渲染到哪里之类的信息。在某些时候，这些参数会让这些接口的declaration 变的很恶心！（代码要幽雅，先把格式写好看点------当然你愿意去参加“混乱代码大赛”的话倒可以朝这个方向发展，another joke）

三．我始终记得一句关于面向对象设计的话：“面向对象是用来模拟世界的”（大致是这样的）。这句话其实真的可以作为面向对象开发的一个指导性原则，它会让你在架构系统时变得很容易。因此，套用这句话的话，上面那种架构方式就出现一些让人觉得别扭的地方了。怪物对象为什么不能自己渲染自己？（难道一个人表现自己的能力都没有？烂比喻！）按照那条原则，怪物类理所应该拥有一个Render之类的接口！

于是，架构二稍微做了些变化：

我们让每个需要渲染的物体，这里是Monster，都有一个Render接口以及一个Renderer对象指针。在创建该精灵对象时，Game类把自己创建的Renderer对象指针传给该精灵对象。该精灵对象再保存该指针到mRender成员。当渲染时，Game类不再直接调用Renderer对象里的 RenderSomething之类的接口，而是很自然地调用Monster的Render接口。然后Monster的Render接口再通过自己保存的 Renderer对象指针调用其RenderMonster接口。

这里，我们为了让设计更贴近真实世界，就多加了一条依赖关系。（这其实纯碎是某些完美主义程序员的癖好-----for instance, me :D）

四．这可能是种被普遍使用的方式：

类图为：

这里不再有Renderer类了，精灵也不再象方式三中的那种“虚假”的Render了。取而代之的是，精灵类（以及其他需要渲染对象）自己直接使用图形引擎来渲染自己，自己也保存渲染所需要的信息，例如那个mImage。

这种方式的缺点在于：每个需要渲染的物体就都会与图形开发包相关。当然如果代码组织得当，在移植时也不是很费劲。但是它造成了代码层次上的相关性，让我觉得不是很好。（代码相关性：例如要涉及到图形引擎的类（例如Image ），还要包含一些图形引擎头文件，这样一折腾就让我觉得很不爽）

总结了以上四种方式，我在这里试着提出一种个人觉得更为好的架构方式（因为还没在实际的项目中实验过，所以只能说“试着”）。

关于渲染所需要的渲染信息，其最基本的信息就是类似于Surface，Image之类的用来代表该物体外观图片的对象。又由于图片资源的一些属性，很有可能还会涉及到一些辅助加工资源的变量（例如对于一个精灵，某一帧对应于图片上的矩形区域）。

这里涉及的问题就变为：一个需要被渲染的物体，除了其渲染代码与特定的图形开发包相关外，其渲染信息数据也与图形开发包相关。如何尽可能地把这些代码与逻辑部分代码分离？

于是我得到了如下的架构形式：

每一个需要渲染的物体都拥有一个其自己的渲染器，然后每个特定的渲染器还有一个其特有的资源管理器（这里主要管理图片资源-----事实上只是作为一种资源加工器而已）。

这种方式其实就是上面提到的方式二的改进版本，把方式二中的那个巨类分割开来。而为了更方便地进行渲染，Monster在创建MonsterRenderer对象时可以把自身作为参数传给MonsterRenderer并让其保存。这样，又多了条依赖关系：

有时候，对于一个精灵而言，为了灵活地配置其部分属性（这部分属性如果硬编码的话很有可能就是一些常量或者宏），我们还要为精灵增加一个属性读取器，它会从外部配置文件读入属性-----事实上这不是本文讨论的范围-----例如使用一种XML解析库来从XML配置文件中读取数据，可以这样设计：

如果精灵渲染信息数据也需要由外部文件配置，并且与那些属性被放在同一个配置文件中（这可能不是种好的习惯），这样，PropertiesReader和MonsterResMgr就会从同一个XML配置文件中读取数据。我们可以这样解决这个问题：

所有配置数据都由PropertiesReader读取，Monster负责创建PropertiesReader对象，然后把该对象指针传给 MonsterRenderer对象。事实上，因为MonsterRenderer对象保存有Monster对象指针，所以完全可以访问到 PropertiesReader对象

裴孝刚 2010-12-28 21:52 发表评论

]]>屏蔽输入法http://www.cppblog.com/peiinterview/archive/2010/12/10/136057.html裴孝刚裴孝刚Fri, 10 Dec 2010 06:36:00 GMThttp://www.cppblog.com/peiinterview/archive/2010/12/10/136057.htmlhttp://www.cppblog.com/peiinterview/comments/136057.htmlhttp://www.cppblog.com/peiinterview/archive/2010/12/10/136057.html#Feedback0http://www.cppblog.com/peiinterview/comments/commentRss/136057.htmlhttp://www.cppblog.com/peiinterview/services/trackbacks/136057.html