Real-time 3D terrain engines using C ++ and DX9 Translation 2

Master Program (The application host)
To add our own program control layer, we will resume our own class based on the class provided by direct3d sample framewrok. The framework class cd3dapplication serves as our base class. We use it to initialize and enumerate video devices, create display modes, and process basic window messages. In this class, we will establish our own resource and device management class, control the execution of our programs and render our world. We have seen our main program class cgamehost to do the above.
The cgamehost class has many purposes. Most importantly, it is the core of our entire engine. When designing classes, we adopt manageable methods to create special single-instance classes to manage key aspects of our engines. For example, the management class will handle these tasks: rendering pipelines and user input. These self-contained management classes require a thread and a program to access and interact with them. Cgamehost serves as a container for all management classes and provides a method for re-obtaining interface access.
To create this class, we use the singleton declaration method to ensure that only one cgamehost class instance is created, and the program has a global method to access this interface. The Singleton class contains detailed details in Appendix A, "Gaia Utility Classes ". For program scalability, Singleton classes also allow class inheritance. If you need a custom main program function, you can use the insect cgamehost to derive a special main game program object to execute additional actions. The biggest benefit of using the singleton declaration method is that the cgamehost object provides access to the management object used in the engine anywhere in the program, including in the management class itself.
In addition to providing an interactive bus interface between management classes, the cgamehost class also serves as the core class of the entire program. As the shell of the entire program, this class contains all the interactions with the host operating system. In our example, we assume that the cgamehost object takes over the desktop window containing the program, and all the programs sent to the window are processed by it. We can derive our own class from the cd3dapplication class provided by direct3d simple framework to facilitate this. However, deriving your own class from this class helps us control some specific aspects of the program.
At the beginning, we will update our game world in a slightly different way from the DirectX example. The DirectX example maintains a one-to-one relationship between updating their world status and rendering each frame ). In each process, a new frame is rendered simultaneously with the new State of the entire program. These update processes occur without any type of management, so the real-time value must be used to determine how many objects are to be moved or animated in each update.
We adopt a more game-compliant approach to control time and divide the time into small steps. We call it the "tick number" (ticks). Each tick represents a fixed time interval. Therefore, every time we execute a tick, we will know the exact time. This fixed time step makes it unnecessary for us to see a real-time clock to execute more complex variable-time updates in our time ).
An intuitive criticism about the use of this fixed-time method is that he cannot make the animation run as smoothly as the variable-time method. This is a valuable concern. If we allow our game world to be updated at a specific interval, our animation will never run as smoothly as the time interval permits. However, the fixed-time method does not require only one time step. We use multiple update tick in our program.
For example, we can use a frequency to shape our game status, and then update our animation at a higher frequency. This allows us to simplify any state-machine and logical operations we use in the update program world, while providing smooth and detailed animations. For our simple engine, we set our ticks to 1/30 of a second, which is about 33 Ms. We also use this frequency and new animations, but if we want to, we can open the door at a higher frequency.
Our time-step method is implemented in the framemove () member function of the cd3dapplication of our overload. The program list is 4-1. At the same time, we added some thread management functions to ensure that our programs are synchronized with other Windows programs. Our program will be idle to know a complete tick. When this time passes, we update our game status and continue to return to the space status. If we estimate that our update does not require a tick time to process the update, our program will still spend the same amount of time. By reducing the thread priority and dropping the remaining time segment after each tick is executed, other threads have the opportunity to update.
Without such thread verification, our program will consume 100% of the available CPU. This will cause other threads waiting to run to pause and give the operating system an unnecessary burden to smoothly run all the threads. Add these measures to help the operating system efficiently implement thread management and ensure that we get the running priority when we need it most.