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

Manage shared data resources
The engine contains different types of shared data. Data represented by these resources are accessed and shared in multiplayer games. Examples include textures, vertex caches, index caches, and rendering methods. In fact, many shared resources rely on graphics cards because they use video memory as part of their storage. The managers of these devices need to access these dependent resources. For example, the display manager needs to access all textures, vertices, and index caches so that it can process interfaces that are lost and re-obtained by the display device.
This requires some key classes. First, we define a base class for all shared resources, cresourcepoolitem. It provides a common interface that can be used by external access methods. These include basic creation and destruction of these resources, enabling and disabling shared resources, and using it as an interface function for Stream Input and Output disks. The member functions in these base classes are defined as pure virtual functions, which forces all derived classes to provide implementation based on these functions. This virtual interface allows external visitors, such as a Device Manager, to influence a set of Objects Based on the cresourcepoolitem class without knowing the specific types they represent.
With the same idea, we add a class called cresourcepool. This class is an extension of cdatepool. It is designed to handle the cash of the cresourcepoolitem class and provides additional methods to operate on these resources. Like the cresourcepoolitem class, the cresourcepool class provides a basic interface that can be used by a range. Assuming that all the cresourcepoolitem objects contain a set of standard interface methods, the cresourcepool provides the Add member function to implement iteration among all pool members and pass data to these functions. For external visitors, this provides an important process for sharing data types. For example, the video card manager can use this interface to quickly enable and disable all textures in a cdatepool object.
Shared resources are usually defined by a text string. For example, for texture, this string may be the actual path name of the source image on the disk. In addition to providing important operation methods, the cresourcepool also stores the search tables of these resource name strings. This provides visitors with a method to find shared resource objects by name. Use the map container class of the standard template library (STL) to create the "Phone Book" of the Resource Name, and provide access and search methods to locate each member in the data pool.
Finally, the cresourcepoolmanager Singleton class provides a storage warehouse for all contributed resource pools. Each cresourcepool can be created and registered in the cresourcepoolmanager object. At the same time, the index value defines the resource type stored in the data pool and the family it belongs ). These indexes can be found in the global enumeration of the cresourcepoolmanger header file. An enumeration defines the family (audio, video, and so on) that all resources may belong ). The additional enumeration defines the types of resources contained in each family.

The associated family and type indexes are stored as a 32-bit 16-bit value. This value is called cresourcecode and is used to uniquely define all resource object types in the Manager. When a new resource data pool carries a resume, they register themselves in the Manager and provide a cresourcecode object to uniquely identify themselves. External visitors can request the cresourcepool interface from the Manager using the appropriate cresourcecode to obtain access to them.
When we create actual engine resources and managers, the functions of these resource classes will become more obvious. Now, refer toSource codeFile to further explore their features. The resource files are listed at the beginning of a sheet. Listing 4.3 shows how these resource objects are created and used.