翻译《real-time 3d terrain engines using C++ and DX9 》（2）

主程序（the application host）
为了添加我们自己的程序控制层，我们将以Direct3d sample framewrok提供类为基础来简历我们自己的类。框架类CD3Dapplication将作为我们的基类，我们使用它来初始化和枚举视频设备，建立显示模式和处理基本窗口消息。在这个类之上，我们将建立我们自己的资源和设备管理类，控制我们程序的执行和渲染我们的世界。我们通过见了我们的主程序类cGameHost来做到以上几点。
CgameHost类有许多目的。 最重要的是，它是我们整个引擎的核心。我们在设计类的时候采用可管理的方式，创建特殊的单实例（single-instance）类来管理我们引擎的关键方面。例如管理类将处理这些事情：渲染管线，用户输入等。这些自包含的管理类需要一个线程，一个程序访问他们及与他们交互的方法。cGameHost就作为一个所有管理类的容器并且提供重新得到接口访问方法。
建立这个类我们使用singleton声明方式来确保只建立唯一一个cGameHost类实例，并且程序有全局方法来访问这个接口。关于singleton方式的类在附录A中有详尽的细节“Gaia Utility Classes”。对于程序可扩展性的考虑，使用singleton的类同样允许类继承。如果需要自定义的主程序功能，那么可以虫cGameHost派生一个特别的游戏主程序对象来执行附加的动作。使用singleton声明方式的最大好处就是可以在程序的任何地方，包括在管理类自身,cGameHost对象都提供对引擎中使用的的管理对象的访问方法。
除了在管理类之间提供一个交互的总线接口，cGameHost类也作为整个程序的核心类。这个类作为整个程序的壳（shell）,包含了所有与主机操作系统的交互。在我们的例子中，这就以为这cGameHost对象接管了包含程序的桌面窗口，所有发送到窗口的程序都由它来处理。我们可以通过从由Direct3D simple framework中提供的CD3Dapplication类派生我们自己的类来的到这个便利。然而，从该类中派生自己的类有利于我们控制程序的某些特定的方面。
作为开始，我们将以一种与DirectX样例稍不同的方式更新我们的的游戏世界。DirectX样例在更新他们的世界状态和渲染每一帧之间维护一个一对一的关系（one-to-one relationship）。在每个过程中，跟新整个程序状态同时渲染一个新的帧。这些更新过程在没有任何类型的管理的情况下发生，所以实时值必须用来决定在每次更新中有多少个物体要移动或者是动画。
我们采用一种更加以符合游戏的方式来控制时间，把时间分成很小的步子，我们称之为”滴答数”（ticks），每个tick代表一个固定的时间间隔。因此，我们每次执行一个tick，我们就知道经过的确切时间。这个采用固定时间步长的方法可以使我们不必去见识一个实时的时钟以在我们的时间里执行更加复杂的可变时间更新（variable-time）。
一个直觉的关于使用这种固定时间方式的批评就是他不能让动画像可变时间方式那样平滑的运行。这是一个有价值的担心。如果我们让我们的游戏世界在某个特定的时间间隔更新，那么我们的动画绝不可能像时间间隔允许的那样平滑的运行。但是，固定时间方式没有要求只能使用一个时间步长，我们在我们的程序中使用多个更新tick.
例如，我们可以使用一个频率更形我们的游戏状态，然后在一个更高的频率更新我们的动画。这让我们能简化我们更新程序世界使用的任何状态机（state-machine）和逻辑操作，同时提供平滑的，富有细节的动画。对我们的简单引擎来说，我们规定我们的ticks为一秒的1/30，也就大约33毫秒。我们同样使用这个频率跟新动画，但是如果我们愿意，可以让门以一个更高的频率打开。
我们的时间步长（time-step）方法是在我们重载（overload）的CD3Dapplication的成员函数FrameMove（）中实现的，程序清单4-1。我们同时增加了了一些线程管理函数来是我们的程序通其他windows程序和平的同步。我们的程序将会空闲知道一个完整的tick过去。当这段时间过去，我们更新我们的游戏状态，然后继续回到空间状态。如果我们估计我们的更新不需要耗费一个tick的时间来处理更新，我们的程序仍然花费等量的时间空间着。通过在执行完每个tick后降低我们线程的优先权和放弃剩余的时间片段来让其他的线程有机会更新。
如果没有这些线程核查，我们的程序将会耗费100%的可用CPU。这将导致其他等待运行的线程挂起，给操作系统一个不必要的负担来让所有的线程平滑的运行。增加这些措施帮助操作系统高效的实行线程管理并且确保我们会在我们最需要的时候得到运行优先权。