2,051
edits
Difference between revisions of "AGI/Specifications/Other"
Jump to navigation
Jump to search
m
AGI/Specifications/Other (view source)
Revision as of 03:05, 23 January 2011
, 03:05, 23 January 2011behaviour -> behavior
m (AGI Specifications/Other moved to AGI/Specifications/Other: subpage) |
m (behaviour -> behavior) |
||
| (26 intermediate revisions by 4 users not shown) | |||
| Line 54: | Line 54: | ||
* Command name determines the data type it operates on, the nature of its operation, and the result. For example, consider assignment commands: assignn 10, 2 means store the value 2 into the variable number 10; assignv 10, 2 means store the value of variable 2 into the variable 10; set 10 mean set flag 10 to 1. Most often you will have to memorize what each command does and the type of its operands. | * Command name determines the data type it operates on, the nature of its operation, and the result. For example, consider assignment commands: assignn 10, 2 means store the value 2 into the variable number 10; assignv 10, 2 means store the value of variable 2 into the variable 10; set 10 mean set flag 10 to 1. Most often you will have to memorize what each command does and the type of its operands. | ||
* Small internal interpreter memory occasionally overflows. This is annoying because there may be lots of free RAM at the same time. | * Small internal interpreter memory occasionally overflows. This is annoying because there may be lots of free RAM at the same time. | ||
* There are powerful commands new_room and new_room_v used to completely change the program | * There are powerful commands new_room and new_room_v used to completely change the program behavior. | ||
* There are many test commands which allow not only to check the state of variables and flags, but also the position of objects one relative to another, or relative to some special lines and areas drawn on the background (for example, control barriers or water surface). The result of tests determines the progress of the game according to the design. | * There are many test commands which allow not only to check the state of variables and flags, but also the position of objects one relative to another, or relative to some special lines and areas drawn on the background (for example, control barriers or water surface). The result of tests determines the progress of the game according to the design. | ||
* The ability to fairly easily animate objects on the screen. Note that all the images programmatically associated with objects the interpreter or the user can control, have to be first created using the VIM utility, as well as the background created using PM utility. That is, creating an animation is a two-stage process: drawing a frame-by-frame animated sequence of the object (a human figure walking but not moving) and programmatic movement of the object for which the animation is played (this creates a walking figure). We shall later discuss the interaction between the designer, the artist and the programmer. | * The ability to fairly easily animate objects on the screen. Note that all the images programmatically associated with objects the interpreter or the user can control, have to be first created using the VIM utility, as well as the background created using PM utility. That is, creating an animation is a two-stage process: drawing a frame-by-frame animated sequence of the object (a human figure walking but not moving) and programmatic movement of the object for which the animation is played (this creates a walking figure). We shall later discuss the interaction between the designer, the artist and the programmer. | ||
| Line 127: | Line 127: | ||
Logic 0 (unlike all other logics) always stays in the interpreter's memory and determines all the interpreter's actions relevant to the overall game control. This is why I decided it has to store the description of actions common to all logics of the future program (how many logics there will be I knew only approximately). These actions, I decided, would first of all include the tests if the keys I have reserved for certain actions (help, turning sound on or off, restarting the program, etc.) are pressed (see log0.asm). Besides, it should include one-time actions that show the program title screen and perform initial initializations. (Initialization code is in logic 1, log01.asm). | Logic 0 (unlike all other logics) always stays in the interpreter's memory and determines all the interpreter's actions relevant to the overall game control. This is why I decided it has to store the description of actions common to all logics of the future program (how many logics there will be I knew only approximately). These actions, I decided, would first of all include the tests if the keys I have reserved for certain actions (help, turning sound on or off, restarting the program, etc.) are pressed (see log0.asm). Besides, it should include one-time actions that show the program title screen and perform initial initializations. (Initialization code is in logic 1, log01.asm). | ||
Initialization code is executed only once and contains the commands that change the cursor shape, built-in debugger parameters, character | Initialization code is executed only once and contains the commands that change the cursor shape, built-in debugger parameters, character color, maximum score, and assign certain numeric codes to the keys I have chosen (set_key command), to be used later by the controller command to determine the state (pressed/released) of these keys. | ||
Because logic 0 is so important, here is its block diagram: | Because logic 0 is so important, here is its block diagram: | ||
| Line 432: | Line 432: | ||
* Don't "bloat" the cels, make them just large enough to fit the image. If possible, create loops of cels of variable size to make them as small as possible. Note that Thunderstorm view resources are not an example in this respect. | * Don't "bloat" the cels, make them just large enough to fit the image. If possible, create loops of cels of variable size to make them as small as possible. Note that Thunderstorm view resources are not an example in this respect. | ||
* When you create a VIEW resource, the first command line argument is the number of loops in the resource. It may happen that you have to change the number of loops in the resource as you work on a program. To do that you will have to save all cels using the S command (issued for each individual cel because it saves the cels in separate files under automatically generated names), then create a new VIEW with the required number of loops and load all cels back using L command. See VIM manual how the cel file names are generated. | * When you create a VIEW resource, the first command line argument is the number of loops in the resource. It may happen that you have to change the number of loops in the resource as you work on a program. To do that you will have to save all cels using the S command (issued for each individual cel because it saves the cels in separate files under automatically generated names), then create a new VIEW with the required number of loops and load all cels back using L command. See VIM manual how the cel file names are generated. | ||
* Drawing an animation, use | * Drawing an animation, use color reference points in each cel. Use the fact that as cels are changed the cursor stays where it was in the previous cel. (He means changing cels in the editor, not during playback by the interpreter. --VM) | ||
* Do not create animations with more than 23--24 cels. The editor may crash, at least the version we have. | * Do not create animations with more than 23--24 cels. The editor may crash, at least the version we have. | ||
* The best advisor is your experience. | * The best advisor is your experience. | ||
| Line 478: | Line 478: | ||
===MEKA=== | ===MEKA=== | ||
MEKA stands for " | MEKA stands for "Möller, Ewing and Kelly Adventure" and has been developed by AGI hackers Joakim Möller, Lance Ewing and Peter Kelly using DJGPP and the Allegro library to run under MS-DOS. It has support for both v2 and v3 games, and some routines from MEKA have been reused in Sarien, specifcally the LZW decompression routines and modified picture decoding routines. | ||
===JAGI=== | ===JAGI=== | ||
| Line 488: | Line 488: | ||
===LAGII=== | ===LAGII=== | ||
Developed by XoXus, the Linux AGI Interpreter, or LAGII (1999), runs in the Linux console using SVGAlib. Currently it supports v2 games. Fully expanded, LAGII stands for "Linux Adventure Game Interpreter Interpreter". It is distributed under the GNU GPL. | Developed by XoXus, the Linux AGI Interpreter, or LAGII (1999), runs in the Linux console using SVGAlib. Currently it supports v2 games. Fully expanded, LAGII stands for "Linux Adventure Game Interpreter Interpreter". It is distributed under the GNU GPL. | ||
<span id="Extensions"></span> | |||