设计日志四：保留模式的逐渐完善

设计日志四：保留模式的逐渐完善

到目前为止，选择保留模式的设计在3D场景和UI渲染上的表现都比较理想。虽然其中也有一些问题，但通过参考其他图形引擎、游戏引擎，以及UI框架如WPF，似乎主要的问题都已经有比较好的解决方案。

另：保留模式其实应该翻译成“保持模式”，叫保留模式容易理解成“reserved mode”而不是“retained mode”。

【资源共享】
这个大家都比较熟。在立即模式下，资源共享是托付给实体层来做的，比如显示10个一样的sprite，就由实体层把一张图画10次。而保留模式下，是需要图形模块自己来管理的，也就是要有10个sprite对象实例，它们引用同一个纹理对象。

这就涉及到如何管理对资源的共享和引用。不过当今大多数引擎都是用的蝇量模式（flyweight pattern），通俗的说就是有个ResourceManager管理所有资源的生存期，显示对象的实例引用其中的资源。XNA也是走的这一条路，尽管它主要是一个立即模式API。实现了资源共享，显示对象的实例就比较轻量级了，因为重量级的模型、纹理、骨骼都在ResourceManager里，而实例里只有位置、替换的材质、动画进度等信息。

一般来说，资源都是在启动关卡时装载、退出时卸载。但如果要支持超大连续场景，则需要资源的滚动装载，这时ResourceManager必须知道那些资源正在被使用，也就是说资源需要增加一个引用计数。这样，引用计数为0的资源就可以被卸载以便腾出空间来加载别的资源。提供了这种支持的引擎比较少，Ogre是个例子。使用引用计数的话，计数增减的正确性很重要，一旦出现内存泄露就是比较大的