My personal thoughts on storing different types of objects for Collision Detection

(Declaration: The following object-oriented ideas are based on C ++ and 2D graphics)

In a program with a small amount of code, we may directly encapsulate the collision detection of all required objects in the class, and then

Automatic Collision Detection is performed during rendering of actions such as role movement. However, this practice has a drawback, that is, we have known the requirements,

If we need an extension program, we need to constantly add it inside the class. This obviously damages the scalability of the program,

This makes the code difficult to use. Therefore, we need the class of this role to provide an interface for external users.

The collision detection object is detected and then rendered by moving the role and other actions.

However, there is a problem here, because the collision detection objects are not unique, especially custom monster objects and map objects,

Even more different. If we provide each object with a multi-state version of the external collision detection interface, as collision detection is needed

With the increase of type objects, the number of these multi-state functions will also increase, which will make the program more cumbersome and the role will be constantly modified.

The collision detection content in the class reduces the general type, scalability, and conciseness of the role class. This method is not much better than the original one,

Therefore, we need to change our thinking.

A more effective method is to store a data structure as a container in the class, and then provide the data in the public of the class.

The interface of the container object. Then, in the external environment, the object that requires collision detection is constantly inserted into the data structure of the container. In this role

Class, the collision detection function is used to continuously traverse the elements in the container to implement the collision detection function, so that we can

Angle classes are separated from complicated ones to implement more modular functions.

However, there is still a problem that cannot be solved, that is, different types of data structure objects need to be stored in the container to provide collision detection.

Here, we can deal with it like this. We do not store very specific objects, such as monster and map objects. We only store some collisions.

Compared with the source objects, such as rectangles, circles, and triangle objects, these objects are provided in the specific objects.

The interface of the collision detection area. Using this method, we can reduce the collision detection type to a single digit to make the original complex problem change.

Simplified. However, this is not enough. If we store containers with rectangles, circles, and triangles, we need

It seems feasible to provide three external interfaces to receive different types of objects, but I still think this is not friendly and concise,

I want to use a container to store these different types of objects.

At first, I wanted to write such a Data Structure container for storage, but the memory occupied by each object is different. How can we

Let the container perform addressing and positioning? It may be a good way to save the size of the data structure, but I want a better way is to only

Saves various object pointers because the pointer size is determined only by the addressing capability of the operating system and the compiler, which means that

On a compilation platform, the pointer sizes of various data types are the same. Therefore, if we use pointers, the container can be quickly addressable.

To the elements we need.

Because of the pointer, I immediately think of the void * type. If we use a void * type container, it doesn't mean we

Can I use this container to store all data type pointers? This seems to be a good idea, but how can we change

Convert to the original specific type for calling? This requires our container to provide an additional cable indicating the data type during insertion.

So that we can use this index to determine what the collision detection object is! In addition, it does not need to be implemented by myself.

This container is provided in !!!

The specific method can be as follows:

1. First, we define an enumeration type to provide index numbers of different data types.

enum CollType{COLL_TYPE_RECT = 0,COLL_TYPE_CIRCLE = 1,COLL_TYPE_TRIANGLE = 2};

2. Then, declare a pair consisting of colltype and void * in the Angle class to be used as the elements of the list of two-way linked lists. For example:

std::list<std::pair<CollType,void*>> mCollList;

In this way, we can use mcolllist to store objects of different collision regions to perform collision detection within the class.

STD: list two-way linked list instead of linear table. There are two reasons:

#1. The insertion and deletion speed is very fast, because we may not perform Collision Detection on an object in a certain period of time, so there will be frequent deletion.

#1. When the collision detection algorithm is not optimized, we usually traverse every element of the container for collision detection. In this way, the list

The time for traversing the container is the same as that of the linear table.

(We do not consider using the tree structure to segment the region for algorithm optimization. This part will be implemented later .)

3. Provide an external interface in the role class for calling:

std::list<std::pair<CollType, void*>>& getCollList(){ return mCollList; }

4. traverse the mcolllist element in the role class for collision detection.

5. In the out-of-class environment, we can use getcolllist () to constantly add the area for collision detection.

(If there is something wrong with my thinking, you can point it out, or you have a better way to communicate with me,
Let's cheer up and make continuous progress in the world !!)

My personal thoughts on storing different types of objects for Collision Detection