********************* HeliOS motor routines ********************* ---------------- What are motors? ---------------- HeliOS motor functions are small "robot-like" sub-programs which run under interrupt control and perform a variety of different functions which can be used singly or in combination to set up automated "background" programs to do virtually anything. Motors are fast optimised machine coded routines which are controlled entirely by pre-defined data structures and which run synchronously with the other HeliOS interrupt driven functions. The data structures which you use to program HeliOS motors act as control interfaces which your foreground program can access and change freely at any time. The motor routines use the information from the control data structures during each operation cycle to determine their behaviour. Once installed the motor routines run continuously under timed interrupt but they can be temporarily disabled or their behaviour can be modified as required by programming the parameters of the control data structures. ------------------------------------------------- What do we mean by "background" and "foreground"? ------------------------------------------------- By "background" processes we mean those processes which can be set up to run automatically under the HeliOS operating system in strict timing with the video refresh rate. Once started these "background" processes will run unattended "in the background", entirely (if necessary) without any further attention after they have been installed. By "foreground" processes we mean those processes which constitute our main game program which in turn sets up the background processes, interacts with the user, and finally closes everything down. The "foreground" process is really what you normally think of as your "main" program, containing all the structure and logic defining the overall game. ---------------------------------------------------- What do we mean by "synchronous" and "asynchronous"? ---------------------------------------------------- HeliOS runs its graphical control routines in a strictly timed loop which is synchronised to the video refresh rate. In general you will want changes to the parameters controlling your game objects to be updated regularly and strictly in time with each other and the video display. This means that ideally all your dynamic game control functions should run together with (or "synchronised" with) each other and the HeliOS operating system. This is what we mean by running "synchronously". All synchronous routines must be very fast (like HeliOS motors), and only absolutely essential routines should be used in the main interrupt driven code in order to maximise efficiency. Any routines which do not HAVE to be synchronous should be carried out by your "foreground" program. The main "foreground" program can be loosely timed to run alongside the synchronous code but is not time-critical, in the sense that it does not matter if certain operations take longer than a single game "frame". The "foreground" code should be able to run out of sychronisation with the main strictly timed interrupt code when required without any detrement to the game operation. This is what we mean by running "asynchronously", and non time-critical asynchronous code will often run "out of step", lagging behind the fast synchronous code. Provided that everything is well designed there will be no problem running two such separate game code systems, and indeed it is virtually impossible to avoid the necessity of doing so. ------------------------------------ How do we set up "synchronous" code? ------------------------------------ If you run any code using HeliOS motor functions, or object "Before" and "After" functions, all routines thus implemented will automatically run synchronously with the HeliOS operating system. If you do not use these facilities you will have to implement your own timing scheme, which can get complicated. Remember also that in this case you will probably not be gaining in speed or efficiency because HeliOS is highly optimised as a functional unit and ensures that there is a minimum of system overhead in running your code. Doing it yourself and avoiding HeliOS functions will almost certainly result in your code being larger and slower, so the best method of implementing synchronous routines is to use the fast tools provided within HeliOS. Some synchronous processing can be carried out within the HeliOS system by using the "Before" and "After" code of your graphical objects, and in some cases this will be advantageous because your code will be run directly "together" in time with the processing of the object itself. This allows an object to be processed completely as a coherent time unit before any other object (which may be dependent on the first one) is processed. However, in general, using motors intelligently will result in much faster code than incorporating lots of "Before" and "After" code sequences, so try first to implement whatever you can using motors. To implement synchronous code you should: 1. Try to use motor functions 2. When necessary use object "Before" and "After" functions 3. When all else fails use your own independent scheme ----------------------------------------------------------------------- Are there constraints when designing synchronous and asynchronous code? ----------------------------------------------------------------------- Timing and speed are the big "enemies" (or amusing adversaries) of all game programmers: the challenge is always to get the computer to do more and more in less and less time. Inevitably certain routines need to be fast or a game will fall apart in terms of both appearence and playability: slow or "variable speed" games often look terrible and are usually annoying and unsatisfying to play. It is vital that the sharing of the game code between the time critical routines and those which do not matter should be carefully designed and implemented: this is what the mechanics of game programming is all about. The idea in general is that "synchronous" code must be absolutely tight and fast, running always with its fixed time frame, but "asynchronous" code can be more relaxed, running as fast as possible but able to be flexible and take more time when necessary. There are two main concerns in this area of speed and timing: 1. The "logistics" of real time dynamics and object interaction There are often difficulties arranging parameter updates to work correctly in conjunction with each other when you have multiple events and objects. Essentially a computer is a serial processing machine and has to be "artificially" programmed so that it can "apparantly" run synchronised simultaneous processes. Events which apparantly occur together, such as simultaneous collisions, need to be coded so that the general "physics" of the game world simulates real-time instantaneous actions. This type of underlying connective dynamics needs to be very well designed and requires every effort to be made to keep the code fast and coherent so that events are represented precisely in terms of timing and duration. Any tools (such as HeliOS motors) which transparently arrange multiple synchronised processing operations are very useful to a game programmer in this context. HeliOS motors help you by: a. Running "connective" functions very quickly and efficiently b. Facilitating the creation of fully synchronised code c. Helping to effectively simulate parallel object processing 2. Constraints of speed to maintain a good game framerate. There is never enough time (because computers are not fast enough!) to carry out all the processing you ideally require at a full synchronised refresh rate. Unfortunately "getting out of synch", or falling behind the video refresh rate with the graphical object updating processes causes a very marked deterioration in game performance and appearance. There is always a problem of timing and speed involved in any game design: we need to update everything every frame, but we lack the time to do so. Effectively this forces us to do as much of the processing as possible independently of the "synchronous" game system, and to keep all the code within the "synchronous" system as fast as possible. Many general purpose routines need not run synchronously, and in general you can implement many aspects of user-interaction in non-time-critical asynchronous foreground code. HeliOS motors help you to create code in which the synchronous speed dependent functions are very efficient and easily controlled by the slower asynchronous code. When you use motors for time critical code the computer is never actually running your high level (slower) code during its speed critical processing. Instead the CPU runs through the fast motor functional code which merely takes its parameters from data structures set up by your foreground code. ------------------------------ A summary of why to use motors ------------------------------ The HeliOS motor routines are an important part of the interrupt-driven game operating system for four main reasons: 1. They are very fast and efficient, with a minimum of execution "overhead". 2. They run "synchronously", in step, frame-by-frame with all the other interrupt driven HeliOS functions. 3. They allow cross-connection and interaction between separate processes because they can program each other and change the actions of other sub-programs in the HeliOS system. You can do "clever" things....... 4. They are ridiculously easy to program and often provide a much simpler and faster means of doing something than any code you could write in your foreground program. ------------------ When to use motors ------------------ The only circumstance where you absolutely HAVE to use a motor function is for accessing the blitter directly while in HeliOS mode. Because their use is not in general compulsory, and because they provide an unusual type of functionality unseen in any other language, it is easy to simply ignore the HeliOS motor functions as being "too much trouble to learn". Although you can indeed avoid using motors, you are strongly advised to become familiar with them because they are uniquely powerful, they are very fast, and they are extremely easy to use. In general you should use motors wherever possible for most automated interactions between HeliOS graphical objects. These uses might include: * Object path calculation and movement * Gravity and force field motions * Collision outcomes * Linked motions * Blitter functions * Functions which MUST run synchronously * Automatic limiting of data structure field values * Copying of data areas * Any time or timing critical routines ------------------------- A summary of using motors ------------------------- Motor functions only work in HeliOS mode, and the philosophy behind their use is that you set them to work in conjunction with the data structures which control the HeliOS operating system. By using motor functions to synchronously control dynamic interactions between data structures, you can effectively set up free-running automated background programs which carry out the bulk of your game code. This leaves your "foreground" code free to carry out simple program logic and interaction with the user on an asynchronous basis. The HeliOS motor functions allow fast and efficient performance of simple operations on a frame-by-frame basis (synchronously) with other functions performed by the interrupt driven HeliOS system. This means that you can use motors to "drive" the motion paths of graphical objects on screen, to govern interactions between objects, to copy data from one graphical data structure to another etc. etc. One of the most interesting and useful features of motors is that they can be set up to program each other in quite complex ways. It is easy to set up any motor to work in conjunction with the results generated from other motors......this leaves room for great creativity! Motors come in a variety of forms, most of which do very specific things. Please read the individual documentation files on each motor type. ********************************************************************* End *********************************************************************