Go Mobile Example Audio source analysis

This is a creation in Article, where the information may have evolved or changed.

Look at this source analysis before, it is recommended to look at a simpler example of basic source code Analysis (http://www.cnblogs.com/ghj1976/p/5183199.html), some basic knowledge this article will no longer mention.

Audio's source code is the biggest change from the basic, using the Golang.org/x/mobile/exp/sprite of the Game Wizard package.

For a brief description of audio, see: Https://godoc.org/golang.org/x/mobile/example/audio

It's a running Gopher, and when it hits the wall, it makes a sound and bounces back.

This game is made using a sprite bag, a sprite pack is a 2D scene under the rendering and animation package.
There is also a glimage package under the Sprite Pack (directory in golang.org/x/mobile/exp/sprite/portable) that draws the image of the image package as a node tree through the rendering engine. The root node of this tree is the screen background to be painted. The above element is the child node of the root node.

For a code analysis of the Glimage package, see: http://www.cnblogs.com/ghj1976/p/5199789.html

Because it is the data structure of the tree, each drawing element is its own coordinate system, which involves the transformation of the coordinate system, which is set by the SetTransform function of the Engine interface relative to the parent element (parent coordinate system) of the affine transformation relationship matrix.

For the knowledge of affine transformation matrices, see: http://www.cnblogs.com/ghj1976/p/5199086.html

For more information on coordinate system transformations, see: http://www.cnblogs.com/ghj1976/p/5215707.html

Here are some specific analysis of this game implementation:

Drawing of the background

Key code

CLEARCOLOR Specifies the RGBA values used to clear color buffers.
Clearcolor (red, green, blue, alpha float32)

This method sets the color used by OpenGL ES "clear Screen", four parameters set red, green, blue, transparent values: 0 is the minimum value, and 1 is the maximum value. For example Clearcolor (0, 0, 0, 0); it is a black "clear screen".

Clear clears the window.
The behavior of Clear is influenced by the pixel ownership test,
The scissor test, dithering, and the buffer writemasks.
Clear (Mask Enum)

Mask
Bitwise OR of masks that indicate the buffers to be cleared. The three masks is Gl_color_buffer_bit, Gl_depth_buffer_bit, and Gl_stencil_buffer_bit.

You can use | Operator combines different buffer flag bits to indicate the buffer that needs to be cleared

• Gl_color_buffer_bit: Current writable color buffer
• Gl_depth_buffer_bit: Depth Buffer
• Gl_stencil_buffer_bit: Template buffering

Glclearcolor (0.0,0.0,0.0,0.0);
Glclear (Gl_color_buffer_bit);

The first statement indicates that the clear color is set to black and the second statement actually completes the task of clearing the entire window to black, and the unique parameter of Glclear () represents the buffer that needs to be purged.

Reference: http://www.xuebuyuan.com/1268040.html

Recursive drawing

After the OnPaint method, which completes the background drawing, is to do the drawing engine scene drawing, such as code entry, here is a tree node recursive drawing.

Eng. Render (Scene, now, SZ) we can see that each node that has a map is drawn recursively

Func (e *engine) render (n *sprite. Node, T clock. Time, sz size. Event) {

The hierarchical relationships of this tree node are as follows:

There is a root node, a child node:

Note that the relative conversion of a reltransform is not an affine transformation matrix, but a matrix of three point coordinates (or a point + 2 vector).

It looks like an affine transformation matrix, but it's not actually.

The reason is that the affine transformation matrix needs to be multiplied with the specific point coordinates, is the transformed matrix, and we see in the concrete drawing, the results of this reltransform calculation directly when the point to use.

The engine is drawn in Eng. In the Render (scene, now, SZ) function, the implementation of this function is in Glsprite, where the plotting logic is as follows:

ABS is an absolute abbreviation for absolute;  rel is the relatively relative abbreviation.

The specific drawing function is used (for the analysis of this function see: http://www.cnblogs.com/ghj1976/p/5199789.html)

Func (img *image) Draw (sz size. Event, TopLeft, TopRight, Bottomleft Geom. Point, srcbounds image. Rectangle)

Here are three points, namely the top left, upper right, and bottom left of the parallelogram three points.

After all the relative reltransform have been multiplied, the abstransforms is calculated on the upper left, upper right and upper left of the X, Y axis displacement, lower left than the upper left x, Y axis displacement values.

So when you pass in Draw, you have the following wording:

From the point of view of a matrix operation, the last column of a matrix affects only the other columns that do not affect the final value, only the columns, such as:

So the last reltransform to use three nodes as the three columns of this matrix is feasible.

This relative conversion, and finally the three coordinate points can be used to represent:

Sprite's animated behavior definition

We implement the behavior definition for sprites in the following way:

This definition is defined according to the following interface:

In order to invoke this behavior logic when the engine is processing:

We have a little trick here that implements this call:

The behavior function is defined as a type, and then this type implements the Arrange interface, the following code.