How to Reduce the mouse sliding consumption when the container subset is large during game Efficiency Optimization

Author: aging man/wxsr/SaIman/Sai
QQ: 457691057
Blog: http://wxsr.blogbus.com/

If you have an as game
Development
Experience, I believe you should also know, but when there are a lot of sub-visual objects in the scenario, the mouse
The slide will cause the CPU to soar;

The main reason is that FP continuously traverses the visual object. You may have used or know that the visual object has this method getobjectsunderpoint ()

It can return the list of visible objects under the mouse point. This is also the reason why the mouse slides out of time, and of course it is more useful for assisting in the implementation of repainting and other.

Is there any way to reduce the consumption of this item? The answer is yes;

Each visual object has two attributes.

Mousechildren and mouseenabled

Mousechildren
Is used to determine whether the object's subitem supports the mouse
Mouseenabled
It is used to specify whether the object receives mouse messages.
Obviously, mouseenabled and mousechildren determine whether the object can listen to mouse events.
Key;
It turns out that as long as the two attributes are set, the high consumption of the mouse slide is reduced, because the two attributes are both set to false and are not included in the traversal tree object,

Of course, you also find that the features of the two attributes are the same. Although we can set both attributes to false, this does not mean we have to discard the mouse listening? You need to know that the mouse clicks, the mouse is released, the mouse slides, and other mouse events in the game are very dependent.

Well, this is a fact, but we can use other methods to replace them; instead of the existing mouse event method;
The method I am talking about here is the dynamic 4-tree. I believe anyone who knows this knows that the 4-tree is mainly used for search and removal, and the efficiency is quite high.
Of course, a quad-tree is not enough. We also need a collision detection method to help

The following describes the principles.
(Do not understand can go to see my post http://wxsr.blogbus.com/logs/60788934.html

)

In addition to its high efficiency, I have adopted the dynamic 4-tree because it can ignore the block object. For FP mouse events, you must click on the visible object, and if a visible object registers a mouse event
If there is another visible object on the top, it still cannot trigger the event, but the dynamic 4-tree can solve the critical needs of this game.

I will not talk much about the working principle of the dynamic 4 k tree. You can search for information or read my previous post.
The following describes how to replace the mouse event with a dynamic quad-tree;

Here we want to declare that the replacement of the mouse event I mentioned here is not completely unnecessary, at least I still need two mouse events here
Mousedown and mouseup cannot capture mouse dynamics. They can only be achieved through the interactiveobject events, but this registered container does not need
Fixed, it can be any one, as long as you think it is convenient, but the key point is that it solves a large part of the mouse-slide CPU consumption;

Next, continue. The main left and right sides of the dynamic 4 k tree are to search for visible objects within the next range of the mouse point; the ultimate goal is to efficiently return the list of registered visual objects under a certain point.
Next, we need to sort the objects first. Here we want to explain that although I have sorted the objects here, it does not affect consumption. Why? This is mainly because we can limit our search range
Narrow down the number of sorting objects. Generally, the number of searched objects within 8 seems to be your number of overlapping objects, this sorting aims to sort them by depth to low, and then
Ring, starting from the highest. checks whether the object collided with a mouse. that is to say, whether the mouse point is within the rectangle of his object range. sorting from high to low is also to meet the principle of top object priority in depth;
As long as there is a collision in this order, we can determine what the visual object is under our mouse and then jump out of this loop,
This is the main implementation process that replaces mouse events;

Of course, there are still some optimization methods. For games, most of the time, the items we play are not necessarily under the same class. How do we define their deep relationships?

This problem is actually better solved, for example, A and B
Under the two containers, they all have n subset objects. We only need to know the depth relationship between A and B to determine a level coefficient, and then multiply their sub-objects by the coefficient, for example, A and B are on the outermost layer,
Then we can assign a coefficient of 10000 to the outermost layer. The depth coefficient of the subset of A and B is 10000 multiplied by the depth of A and B plus 1 (the depth starts from 0) then, you only need to take the subset objects
Their depth, coupled with this level coefficient, can be similar as an ordered depth relationship,

For example, AB is located in the scene, the depth of A is 0, it has two sub-object a, B their depth is a-0, B-1. the depth of B is 1 It also has two sub-objects c, d their depth for the c-0, D-1
Assume that the coefficient we set for A and B is 100.
So the depth and size relationship of ABCD is
A-1001
B-1002
C-2001
D-2002
In this way, we can determine the depth of objects of different parent levels on each layer.
The same object is a PNG bitmap.
In addition to determining the depth relationship, we also need to sort non-transparent areas, that is, the precise pixel collision method. This implementation is quite simple here, every time we detect an object
The value draws a bitmapdata of a pixel and extracts whether its alpha channel value is 0.