qdosmsq:pe:struct:sprite

Sprites, Blobs and Patterns

The general format of sprites, blobs and patterns is the same. There is a header of at least 20 bytes defining the dimensions of the object and there are two sections the first defining the colour of each pixel in the object and the second how this colour should be applied to the screen. These are called the colour pattern and the pattern mask.

Name     Off Size Description
-------------------------------------------------------------------------
pto_form $00 byte object form 
         $01 byte colour mode / system sprite number
pro_vers $02 byte dynamic sprite time
pto_ctrl $03 byte sprite control
pto_xsiz $04 word width in pixels
pto_ysiz $06 word height in pixels
pto_xorg $08 word x offset (zero for pattern)
pto_yorg $0a word y offset         "
pto_cpat $0c long relative pointer to colour pattern (zero for blob)
pto_mask $10 long relative pointer to pattern mask (could be zero for pattern)
pto_nobj $14 long relative pointer to the next object

Optional

pto_opts $18 long relative pointer to options (not implemented yet)
pto_blk  $1c long pointer to sprite block
-------------------------------------------------------------------------
  • The object form, pto_form, has three values:
    • 0 = system sprite. The sprite is defined by the second byte. See the vector pv_sspr.
    • 1 = QL sprite
    • 2 = GD2 colour sprite
  • The byte pto_vers gives the time value for linked dynamic sprites.
  • The sprite control byte is %mpao0xcc.
    • "cc" stands for a cache version number. This can be incremented to signal the cache that the sprite has changed. The special value %11 causes the system never to use the cached version.
    • If "a" is 1 it signals that an alpha channel is used. See below.
    • If "m" or "p" is 1 it indicates that the colour pattern (p) or the pattern mask (m) is to be compressed. See below.
    • If "x" is 1 it signals that the optional pointer to a sprite block is present. (See below)
    • If "o" were 1 it would signal that options were present.
  • The x and y offsets indicate the origin of the sprite. For example, if the sprite is to be printed at pixel position 10,10 in channel #1 the origin of the sprite will be set at that position, not the top left of the sprite.

A dynamic sprite can be produced by linking sprites together using the pointer pto_nobj. The time values in pto_vers govern how this will appear. If the values in the sprites are t1, t2, t3 etc the first sprite will be displayed for t1 ticks, the second for t2 - t1 ticks and the third for t3 - t2 ticks and so on reverting to the first one when the chain is ended.

The colour pattern shows the colour of each pixel in the object's rectangle. For each mode the form is the same as for the screen. Thus, for modes 32 and 33 each pixel requires one word. For mode 4 there are 8 pixels per word. Each row in the colour pattern takes a complete number of words for a QL mode and a complete number of long words for other modes.

The pattern mask takes the same form as the colour pattern but the only colours allowed are black and white. That is, each pixel has either 0 or 1 allotted to it. If the vlaue is 1 the colour of the corresponding pixel is written to the screen. If the value is 0, the colour is XORd to the screen. In the case of a normal sprite its shape would be given by the 1s in the pattern mask. The colours given in the colour pattern for the corresponding pixels would be written to the screen. This includes the colour black, zero in the colour pattern. In this example pixels whose value is 0 in the pattern mask would equally have a zero in the colour mask, but this time indicating a space. However this, being the colour black, would have no effect when XORd to the screen.

When "a" in the sprite control byte is 1 the pattern mask is treated as an Alpha Channel. In this case it contains exactly one byte for each pixel in the object's rectangle. The value of each pixel determines what is to be written to the screen. For a value of 0 the pixel is that of the background. Ie the screen colour is not changed. For a value of 255 the colour of the corresponding pixel in the colour pattern is written to the screen. For intervening values the colour is a proportionate mix of the two.

Both the colour pattern and the pattern mask (or alpha channel) can be compressed. Compression is signalled by the bits "m" (for pattern mask) and "p" (for colour pattern).

The style of compression is run length encoding (RLE). Compressed data start with the four byte ID 'RLEx', where x is one of 1, 2 or 4 to indicate the item size, in bytes, that RLE is using. After the ID there is one long word containing the uncompressed size. Then follows the compressed data. This consists of a series of packets. Each packet starts with one byte with value x, say. If x is between 0 and 127 inclusive, then x + 1 uncompressed items follow. Otherwise, when x is between -1 and -128, one item follows and this represents 1-x uncompressed items.

A blob is like a sprite in that it has a shape and can be moved around the screen. However, a blob does not have any colour of its own so it relies on an associated pattern when it is written to the screen. A pattern has no shape. It consists of a block of colour which is replicated throughout the screen space. When a blob is placed on the screen it appears just as if the blob's shape was torn away from the screen revealing the underlying colours of the associated pattern.

Although the format of blobs and patterns closely follows that of sprites there are some differences:

  • A blob has no colour pattern and so has a zero pointer at pto_cpat.
  • A pattern has no origin so both pto_xorg and pto_yorg are zero. Also if a pattern is solid, it does not need a pattern mask so its pointer, at pto_mask, in this case should be zero. However, it can have a mask. In that case its colour only affects those pixels indicated by 1 in the pattern mask.
  • qdosmsq/pe/struct/sprite.txt
  • Last modified: 2011/11/03 10:35
  • by george.gwilt