@@ -113,9 +113,9 @@ called when that transition is requested.
113
113
114
114
=head3 Life cycle
115
115
116
- The application initializatin process happens in a few steps. When you
117
- first instantiates it it does no proper initialization. The idea is
118
- that you should be able to do custom processing after you have the
116
+ The application initialization process happens in a few steps. When
117
+ you first instantiates it it does no proper initialization. The idea
118
+ is that you should be able to do custom processing after you have the
119
119
game object.
120
120
121
121
Once you're ready, you can call "setup", which is composed of the
@@ -138,6 +138,38 @@ This is where the actual screen is initialized.
138
138
139
139
=back
140
140
141
- Once the setup is completed, you can call "run"
141
+ Once the setup is completed, you can call "run", which will transition
142
+ the game to the "start" state and start the SDL loop.
143
+
144
+ =head3 The main loop
145
+
146
+ The Jogo framework is designed to work multi-threaded, that way, the
147
+ main loop won't have any time-oriented interruptions, the only thing
148
+ that will generate new iterations in the main loop is SDL events.
149
+
150
+ The only event that is handled by the main loop is the
151
+ Jogo::EVENT_MAJOR_STATE_CHANGE type of event, which is reserved as
152
+ SDL_NUMEVENTS - 1 (the last SDL user event type). Every other event is
153
+ directly delegated to the currently active controller.
154
+
155
+ In order to request a major state change, you can use the
156
+ request_transition method in the actual application, which will
157
+ enqueue a new SDL event asking for that transition. The idea of
158
+ inserting that event in the regular SDL queue is to offer fair support
159
+ for multi-threading. So any thread can request a major state change.
160
+
161
+ =head3 Custom transition code
162
+
163
+ When the transition is declared as a code ref, the framework won't do
164
+ any change at all, it will just invoke that code. So the code should
165
+ do the transition itself. There are two attributes of the application
166
+ that are relevant here, one is "state", which stores the current state
167
+ name and "active" which stores the currently active controller.
168
+
169
+ There is a helper method called "transit_to" which will look for the
170
+ name of the target state, gather and resolve the name of the
171
+ controller and initialize it, using any additional argument in the
172
+ "new" call. It then sets the name of the state and the active
173
+ controller.
142
174
143
175
=cut
0 commit comments