1,510
edits
Difference between revisions of "AGI/Specifications/View"
Jump to navigation
Jump to search
Wikify and fill in differences from SGML. Work complete
(→VIEW test commands: -- syntax highlighting) |
(Wikify and fill in differences from SGML. Work complete) |
||
| Line 6: | Line 6: | ||
==Introduction== | ==Introduction== | ||
VIEW resources contain some of the graphics for the game. Unlike the picture resources which are full-screen background images, view resources are smaller sprites used in the game, such as animations and objects. They are also stored as bitmaps, whereas pictures are stored in vector format. | VIEW resources contain some of the graphics for the game. Unlike the picture resources which are full-screen background images, view resources are smaller ''sprites'' used in the game, such as animations and objects. They are also stored as bitmaps, whereas pictures are stored in vector format. | ||
Each view resource consists of one or more loops. Each loop in the resource consists of one or more cels (frames). Thus several animations can be stored in one view, or a view can just be used for a single image. The maximum number of loops supported by the interpreter is 255 (0-254) and the maximum number of cels in each is 255 (0-254). | Each view resource consists of one or more loops. Each loop in the resource consists of one or more ''cels'' (frames). Thus several animations can be stored in one view, or a view can just be used for a single image. The maximum number of loops supported by the interpreter is 255 (0-254) and the maximum number of cels in each is 255 (0-254). | ||
Note: Except when noted otherwise, 16 bit data is stored in little endian format (i.e. the value has the least significant byte stored first, and the most significant byte stored second). Most word values in AGI are stored like this, but not all. | Note: Except when noted otherwise, 16 bit data is stored in little endian format (i.e. the value has the least significant byte stored first, and the most significant byte stored second). Most word values in AGI are stored like this, but not all. | ||
| Line 14: | Line 14: | ||
<span id="ViewFormat"></span> | <span id="ViewFormat"></span> | ||
==VIEW resource format== | ==VIEW resource format== | ||
Following tables show the format of the view, loop | |||
and cel headers. | |||
The first four bits of the last byte of the cel header tell the | |||
interpreter how to handle the mirroring of this cel (explained later). | |||
The last four bits represent the transparent color. When the cel is | |||
drawn on the screen, any pixels of this color will show through to the | |||
background. All cels have a transparent color, so if you want an | |||
opaque cel then you must set the transparent color to one that is | |||
not used in the cel. | |||
===View header (7+ bytes)=== | ===View header (7+ bytes)=== | ||
| Line 32: | Line 44: | ||
Note: Two of these loop references CAN point to the same place. This is done when you want to use mirroring (more on this later). | Note: Two of these loop references CAN point to the same place. This is done when you want to use mirroring (more on this later). | ||
===Loop header (3+ bytes)=== | ===Loop header (3+ bytes)=== | ||
| Line 58: | Line 71: | ||
</pre> | </pre> | ||
===Cel data=== | |||
Cel data | |||
The actual image data for each cel is stored using RLE (run length encoding) compression. This means that instead of having one byte for each single pixel (or 1/2 byte as you would use for 16 colors), each byte specifies how many pixels there are to be in a row and what colour they are. I will refer to these groups of pixels as "chunks". | The actual image data for each cel is stored using RLE (run length encoding) compression. This means that instead of having one byte for each single pixel (or 1/2 byte as you would use for 16 colors), each byte specifies how many pixels there are to be in a row and what colour they are. I will refer to these groups of pixels as "chunks". | ||
| Line 81: | Line 89: | ||
If the color of the last chunk on the line is the transparent color, there is no need to store this. For example, if C was the transparent color in the above example, you could just write AX BY 00. This also saves some space. | If the color of the last chunk on the line is the transparent color, there is no need to store this. For example, if C was the transparent color in the above example, you could just write AX BY 00. This also saves some space. | ||
Mirroring | |||
===Mirroring=== | |||
Mirroring is when you have one loop where all the cels are a mirror image of the corresponding cels in another loop. Although you could do this manually by drawing one loop and then copying and pasting all the cels to another loop and flipping them horizontally, AGI views provide the ability to have this done automatically -- you can draw one loop, and have another loop which is set as a mirror of this loop. Thus, when you change one loop you change the other. This is useful if you have an animation of a character walking left and right -- you just draw the right-walking animation and have another loop a mirror of this which will have the left-walking animation. Another advantage of cel mirroring is to save space -- it doesn't make much difference these days, but back when AGI was written the games were designed to run on 256K systems which meant that memory had to be used as efficiently as possible. | Mirroring is when you have one loop where all the cels are a mirror image of the corresponding cels in another loop. Although you could do this manually by drawing one loop and then copying and pasting all the cels to another loop and flipping them horizontally, AGI views provide the ability to have this done automatically -- you can draw one loop, and have another loop which is set as a mirror of this loop. Thus, when you change one loop you change the other. This is useful if you have an animation of a character walking left and right -- you just draw the right-walking animation and have another loop a mirror of this which will have the left-walking animation. Another advantage of cel mirroring is to save space -- it doesn't make much difference these days, but back when AGI was written the games were designed to run on 256K systems which meant that memory had to be used as efficiently as possible. | ||
| Line 104: | Line 113: | ||
It seems that not all versions of the interpreter require this, however -- I was working with version 2.917 when I was testing this out, but I noticed that version 2.440 did not require this. I will attempt to try this with all different interpreters and provide a list of which ones use this in a future version of this document. But it is best to put these bytes in just in case, as the views will still work regardless. | It seems that not all versions of the interpreter require this, however -- I was working with version 2.917 when I was testing this out, but I noticed that version 2.440 did not require this. I will attempt to try this with all different interpreters and provide a list of which ones use this in a future version of this document. But it is best to put these bytes in just in case, as the views will still work regardless. | ||
Description | |||
===Description=== | |||
All the views in the game that are used as close-ups of inventory items have a description. When a player "examines" these (in some games you can select "see object" from the menu), they will see the first cel of the first loop of this view and the description of the object they are examining. This is brought up using the show.obj command. | All the views in the game that are used as close-ups of inventory items have a description. When a player "examines" these (in some games you can select "see object" from the menu), they will see the first cel of the first loop of this view and the description of the object they are examining. This is brought up using the show.obj command. | ||