In order to better understand the architecture of DX and games, but also to practice Code Reading's ability (good bureaucratic tone), I intend to read DEMO - Donuts4 (Baby Wars) in DX SDK again. I haven't read what long before I haven't read it, and I have always thought that it is worth writing. It seems that it is important to read something.
File composition
In addition to resource.h, Donuts4 has 18 CPP / H files. According to the comments inside the header file, you must first have a probably understanding of these files:
Donuts.cpp / .h is the main file of Donuts4. Inside said the game used Direct3D, DirectMusic, DirectSound and DirectInput.
STDAFX.CPP / .H Preframe file.
GameMenu.cpp / .h is used to display the menu of the game. (Why didn't I see a menu in the game ?!)
Profile.cpp / .h is used to read and write the INI file.
FileWatch.cpp / .h is used to see if some files have been modified. (Unable to understand this role ...)
Notifytool.cpp / .h appears to be an expansion of iDirectMusictool.
3DMODEL.CPP / .H A class C3DMODEL implementation. It should be an abstraction of the 3D model.
DISPLAYObject.cpp /. Implementation of Class CdisPlayObject.
3DDisplayObject.cpp / .h A class inherited in CDisPlayObject. I don't know what contact with C3DModel.
3DDrawManager.cpp / .h should be used by Manager for painting Dongdong.
INPUTMANAGER.CPP / .H Manage the type of Input.
HeightMap.cpp / .H Class CheightMap should be related to Terrain.
TerrainMesh.cpp / .h seems to be the abstraction of Mesh inside Terrain.
Terrainengine.cpp / .h terrain engine.
Particlesystem.cpp / .h particle system (did not see where ...).
Bullet.cpp / .h bullets, it is a bakery ...
EnemyShip.cpp / .h enemy is the purple thing.
Playership.cpp / .h ourselves do not seem to be appeared (because it is the first perspective).
Class in donuts.h
Two classes are declared in donuts.h. One is a very short C3Daudiopath class, one is a very huge CMYApplication class. The CMYApplication class light declaration uses 160 lines ...
I thought that Donuts should be DX's Common Framework, but it doesn't seem. CMYApplication is not inherited in capplication. But the structure and Capplication of the class is similar, and a simplified version of Common Framework or an improvement version.
Donuts only uses D3DFILE, D3DFONT, and some Util in Common.
In addition, Donuts.h also made a statement on some of Custom Vertex and the corresponding FVF.
Entrance to the program
Donuts.cpp has 96K so large, more than 2000 lines, watching a headache.
First find the program's entrance Winmain. WinMain wrote a very prominent front. In addition to setting the random seed, it is instantiated CMYApplication. It can be seen that the use of the app is two steps, the first step is Create (), the second step is Run (). This is similar to D3DAPP, in fact, this method is very good.
The constructor of CMYApplication is to initiate all the internal members of INIT. Full-eyed Hungarian ... Create () and Run () are not long, you can take a closer look.
CREATE () as an example is a declaration of a window and then exists the corresponding attribute. It is worth noting that oneTimesceneinit () is called in Create (), that is, the initialization of the game object is also done in CREATE ().
Run () is also an expected encapsulation of a message pump. There is an interesting place. When you take the message, the method used by Donuts is:
IF (Active) msg = peekMessage (); else msg = getMessage ();
Next, I still write a simple explanation: If the program is active, use peek, which can be used to do Render with idle. If not, use GET, which avoids EAT to drop the CPU. I learned again.
If there is no MSG in Wait, you can render. Render's code is very weird:
IF (m_bdisplayready) {if (m_pfilewatch-> HavefilesChange) {g_profile.getprofile (m_strprofilepath);} else {updatescene (); renderscene ();}
That is, if the file changes, it is necessary to renew the file. The document he said here should be the INI file. However, who will change the configuration file when playing games? Also or the game itself changed the configuration file (did not see Option)? Confuse ing ...
However, it can be seen that rendering is divided into two steps Updatescene () and Renderscene ().
In addition, when the Window is declared, the given MSGProc is a function of StaticMSGProc (). And this function is only a steering role and handles the message to app.msgproc ().
