Design log 4: gradually improving the retention Mode

Design log 4: gradually improving the retention Mode

So far, the design of retention mode is ideal for both 3D scenarios and UI rendering. Although there are also some problems, by referring to other graphics engines, game engines, and UI frameworks such as WPF, it seems that there are already better solutions to the main problems.

In addition, the retention mode should be translated into the "retention mode", which is called the "Reserved Mode" rather than "Retained Mode ".

[Resource Sharing]
Everyone is familiar with this. In the instant mode, resource sharing is done by entrusting the entity layer. For example, if 10 identical sprite instances are displayed, the entity layer places a picture 10 times. In the retention mode, the graphic module needs to manage it by itself, that is, there are 10 sprite object instances which reference the same texture object.

This involves how to manage resource sharing and reference. However, most engines today use the flyweight pattern. In short, there is a ResourceManager that manages the lifetime of all resources and displays the resources referenced by the instance of the object. XNa also follows this path, although it is mainly an instant mode API. With resource sharing, instances that display objects are lightweight, because heavyweight models, textures, and bones are all in ResourceManager, the instance only contains information such as location, replaced material, and animation progress.

Generally, resources are unloaded when the level is loaded and exited. However, to support ultra-large continuous scenarios, resource rolling loading is required. At this time, ResourceManager must know that those resources are being used, that is, resources need to be added with a reference count. In this way, resources with 0 reference count can be detached to free up space for loading other resources. There are few engines providing such support. Ogre is an example. When reference counting is used, the correctness of counting increase or decrease is very important. Memory leakage is a big leak. In. net, there is another mechanism that can be used, that is, weakreference ). Objects pointed to by weak references can be recycled without common references.

[Virtual set problem]
If you have written a Win32 program, you should know the virtual ListBox. When the set is very large and has thousands of elements, it is very inefficient to add all the elements to The ListBox. Therefore, you need to use the virtual ListBox, only the total number of elements is provided. The element content is provided only when an element is actually displayed. This is also a typical retention mode efficiency problem.

If the engine is self-written, you can use the Immediate Mode to handle this situation. Many commercial engines also expose underlying d3d or GL objects for extension. Some common situations can be solved directly in the engine. For example, The ListBox of WPF is always virtual, And the uielement of the element is created only when the element is displayed. The same policy can be applied to our UI module. Similarly, a class can be used to process the name labels on the top of a character in a scenario, instead of creating a display object for each role.

[Interaction Problem]
Interaction can be regarded as the strength of the retention mode. The engine of the retention mode has sufficient information to provide selection support.

There is no doubt that the UI Layer provides complete user interaction, but this also causes the UI module to depend on the input module, at least the input message structure. Depending on the different design ideas and requirements, you can separate the UI Layer from the graphics engine as a module on the graphics module and input module. You can also define your own message structure in the UI part, the input is converted into the message structure of the UI by being glued to the Object layer. The former may be better, because the UI system may need other dependencies, such as supporting scripts.

For some materials, we recommend that you define each module as an interface, and then you can access other modules through interfaces everywhere. This method only decouples the modules from the implementation. In terms of the logical structure, the modules are still coupled.

For display objects in a scenario, interactive support cannot be done too much; otherwise, the operations of the game itself are limited, surpassing the role of the graphics engine. In addition, the entity layer does not necessarily use the information of graphical resources for intersection testing, but simply uses the logic of the role to enclose the box or use the physical engine in a complex manner. In most cases, the data structure of the resource of the graphic object is optimized for display, which is not efficient for physical detection. For example, the d3dxmesh intersect tests whether the light is intersecting with the model, and it needs to traverse all the triangles. The physical engine uses data structures such as the eight-tree to reduce the number of detected triangles by several orders of magnitude.

Of course, graphical objects can also reference a physical model resource. However, the graphic engine itself contains a simple physical system. In reality, most graphics engines also contain some physical system functions. After all, physical engines have been independently developed in recent years. As the game becomes more complex, the independence of the physical module is also a matter of time. It is better to prepare for the early stage and separate the collision detection part into a simple physical module. In this way, the physical layer can use this simple physical module or replace it with a professional physical module.