碰撞检测模型在物理和逻辑上保持分离

    Builder类以正确的格式将基本图形数据提文给硬件。由于每个Builder类依赖于平台，它们和工厂一样创建和处理硬件相关的数据。这种结构允许对每个平台上的组件进行近似最优的调整。当然，有人反映C4-+4反慢。
    这里所谈的是低层碰撞检测，即回答两个模型是否相交。如果你已经写过碰撞检测库.就知道它非常具有层次性.原因是精确地给出碰撞检测的结果非常花时间。采用层次性的好处是.如果通过简单的运算就可以作出否定的回答，那么无需进行后续的非常耗时的计算。
    碰撞检测的方法有多种，我们在这里并不一一解释它们。下面给出的例子是在两个模型之间实现层次的检测检测结构，编写一个，P1断多个物体是否相交的高级碰撞检测组件作为练习留给读者。
    注惫到大多数物体都具有层次结构，而在MODEL组件中我们曾定义了一个层次框架，看上去这个层次结构正好可以用于进行碰掩检测。
    事实是，这种做法并不怡当。尽管大最的游戏开发工程采取了这种做法，但它们忘记了一个事实，即碰撞检测组件应该完全与图形组件无关。这是因为碰撞检测组件与图形组件之间共享的数据只在表面上相似。由于对每个图形对象进行精确的碰撞检测计算非常耗时，用于碰撞检测的模型的细节应该远远少于被绘制的模型。此外，在一般情况下仅仅采用最简单的模型作为碰撞检测的对象也不合理，因为在碰撞检测过程中还需要一些辅助数据，而与模型无关的数据不能被放皿在模型中。正确的做法是让绘制模型和碰撞检测模型在物理和逻辑上保持分离。并且根据实际情况选择和生成碰撞检测模型。
    显示了一个碰撞检测组件的体系结构。碰撞组件中最重要的类被称为Unit，这个名字经常让人混淆。一个Unit定义了一个抽象几何实体，可以对它进行碰撞检测。unit的派生类则描述了用于碰撞检测的具体的图形对象。
    这是一个不易维护的系统。如果存在n个Unit派生类，那么加入一种新的图形对象意味着要增加O(n)个碰撞测试代码。由于C伞+缺乏基子this类型和动态类型的多态性，这意味若要实现更多冗长沉闷的代码
    理论上，给定~-个Unit.可以用dynamic_cast来确定它是什么并选择合适的测试方法。但是.dynamic_cast被禁止使用.因为它涉及到虚函数表和RTfl的使用。一个变通的办法是通过向Unit类中加入自己的简单的KM
    尽管fopen及其所属的缓存10这一族函数很有用，但多数游戏不能全依靠它们。在控制台程序中，通过标准C库接口读入文件实在太慢，何况1509669文件系统有有非常严格的数目限制.即8.;文件名格式和每个目录下最多有OX个文件或目录。现代游戏牵涉到成千上万的文件.所以很明显不能采取这种方式。即使在陀类型的平台一长.调用Cope。之类的函数也逐渐成为性能的瓶颈。尽管这些函数对硬盘操作很快，但是打开很多文件并填充缓存所带来的延时也会极大地损害性能。透成游戏没有响应。
    针刘内存碎片的问题，加载尺寸变化极大的多个文件通常是一个快速且效果不错的方法，特别是在内存吃紧的时候。既然C标准库不运行控制分配内存的数目以及何时分配，我们屁要一种完全避开它的方案。
    因此，在资源管理组件的最核心部分，系统应当:
.基本上没有延时地加载文件:
.以较小的延时成批加载文件;
.游戏运行时异步加载文件并且不选成形响:
.有效地管理内存。这些任务由资源管理软件包中的BNDL组件完成。