Deep Analysis of jetboy games (II)-core code analysis

There are two previous articles (Framework Analysis
Jetplayer class Parsing
) Introduction, I believe everyone can't wait to know how the core class jetboythread runs. Next we will gradually resolve it for you.

First, analyze the status chart of this class, as shown below:

This figure shows the cycle of our entire program: Play-running--lose. Based on this figure, we will gradually refine it. here we will focus on the introduction of running. The other two statuses are relatively simple and will not be described here.

The start_running status is further refined.

Start_running
In fact, the flowchart is divided into two parts: Event Processing (updategamestate) and drawing (dodraw), as shown in:


The above two activity diagrams are gradually refined as follows:

• The activity diagram after dodraw is refined is shown in:
  
  
  Explanation: draws real-time images of the current game based on the status.
• The activity diagram after the updategamestate is refined, as shown in:
  
  
  Resolution Description: This is a process of repeatedly obtaining messages from the message queue until the message queue is empty.

It is absolutely strange to see timer_event above. It is clearly stated in the android SDK documentation as follows:

Trigger events:
Breaking a MIDI file into individual
(Non-linear) segments and queueing up those segments for playback in
Game based on events within the game is one way jet music files are
Interactive. trigger events are an additional method for interactive
Playback.

In other words, we can define some events in the segment to trigger at a specific time. As mentioned earlier, in addition to playing sound effects, jet should have a more important feature.
Yes: the clock of the game. We can define some specific events in the segment, which is equivalent to the time slice in the CPU. Of course, many events have been defined in the Midi specification. We can
To customize the event ID range: 80-83. View the code in the program as follows:

Private Final byte new_asteroid_event = 80;
Private Final byte timer_event = 82;

These two events are used to trigger new asteroid and interface updates respectively.

So far, the entire core code process has been analyzed. This game is relatively simple, that is, by pressing the intermediate key to launch a bullet, the position of the ship is on a horizontal line with the current meteorite, the distance between the spacecraft and the meteorite is measured to determine whether the meteorite is concentrated.

Second, add additional information on the omissions

Here, we need to add that

Private timer mtimer = NULL;
Private timertask mtimertask = NULL;

The two are to implement a timer. the time on the game interface is through this Timer: the timer sends a message to the main thread to update the remaining time of the game. The specific implementation is: bind to the current thread through handler, then send messages to the main thread through handler, and process messages in handler.
Is not described here.

Summary

This instance is complicated, especially in the jet section. I also read a lot of information and then read and analyze it in detail. I will share my own analysis with you, many of them are not detailed yet.
The game itself has no playability. Its main role is to demonstrate how to use the jet engine to play the sound and how to use the jet event as the game clock. However, through this instance
After-development game development, it provides us with a good example. It is worth learning from in future game development and application development.