A look inside The Link @ wiki - User contributions [en]

Riven tMOV resources

2010-03-10T21:06:48Z

Aaron: update the quicktime reference link (the old one was broken)

<noinclude>{{Riven}}</noinclude>
tMOV resources are QuickTime movies. For a complete reference of the format, please see [http://developer.apple.com/mac/library/documentation/QuickTime/QTFF/QTFFPreface/qtffPreface.html here].

== Codecs ==

All Riven movies use the Cinepak video codec and the Apple IMA 4:1 audio codec.

== Notes ==

Note that all offsets in the stco chunk are absolute offsets in the Mohawk archive, not offsets within the video as the format specifies.

Mohawk Sounds

2010-03-10T21:04:58Z

Aaron: I added a link to more information on ADPCM encoding

{{Myst}}
{{Riven}}
It happens that Myst, Riven and other products share a somewhat common format for storing audio data (sounds and music): we called it the ''Mohawk sounds'' format. Though this page is complete enough to correctly decode sounds (at least "by ear"), the format has a number of obscure details and unknown fields, especially those connected to data sizes. Thanks to Ron Hayter for providing details on the DVD version of Riven's tWAV resources.

The format is structured in chunks, much like the common WAV audio format. The audio data can be compressed in three ways:
* Raw unsigned PCM data, used in older games.
* Intel DVI ADPCM format, a lossy differential encoding which stores the difference between consecutive samples as 4-bit delta samples, yielding a compression factor of 4:1.
* MPEG-2 Layer II encoding - Used in the DVD version of Riven.

It's important to note that the compressed data block contains more data than necessary (in Riven): the additional data is just garbage at the end of the block, and is skipped by the Riven decoder when the sound is played. Unfortunately, the headers seem to ignore this excess data: this makes reverse-engineering of these fields very difficult, since every relation with the full resource size is lost. It's necessary to introduce an "effective resource size" excluding the excess data.

==The header==
The data block begins with the following header:
{| class="structure"
|4 bytes||mhwk_magic
|-
|unsigned long||size
|-
|4 bytes||wave_magic
|}

*''mhwk_magic'' is the string 'MHWK'. It's equal to the [[Mohawk archive format#IFF header|Mohawk format signature]]!
*''size'' is the effective resource size, minus the ADPC chunk size, minus 2.
*''wave_magic'' is the string 'WAVE'.

After this header come the chunks. Until now, 3 chunk types have been identified: '[[#The ADPC chunk|ADPC]]', '[[#The Cue.23 chunk|Cue#]]' and '[[#The Data chunk|Data]]'.

==The ADPC chunk==
This chunk holds some information about the audio sample format. Its size is not constant.
{| class="structure"
|4 bytes||chunk_type
|-
|unsigned long||chunk_size
|-
|unsigned short||u0
|-
|unsigned short||channels
|-
|unsigned long||u1
|-
|unsigned long||u2[channels]
|}

*''chunk_type'' is the string 'ADPC'.
*''chunk_size'' is the chunk size minus 8.
*''channels'' is the number of audio channels.
*''u0'' is 2 when there is the Cue# chunk, and 1 when there isn't.
*''u1'' is always 0.
*''u2'' is always 0x00400000 for both channels.

If there is the Cue# chunk, then there is additional data in the ADPC chunk:
{| class="structure"
|unsigned long||u3
|-
|unsigned long||u4[channels]
|}

*''u3'' seems to be in units of samples (maybe it's a position within the audio stream).
*''u4'' looks more like a record than a single unsigned long value, but values are obscure and I have no idea about its meaning.

Finally, the ADPC chunk is only present when there is ADPCM sound.

==The Cue# chunk==
This chunk is rare in Riven, only a few tWAV resources have it and just one resource has an interesting one (that's tWAV 3 from p_Sounds.mhk). This chunk seems to contain "cue points", in a way similar to the corresponding chunk of the WAVE format. This is much more common in other games, especially Myst.

{| class="structure"
|4 bytes||chunk_type
|-
|unsigned long||chunk_size
|-
|unsigned short||point_count
|}

*''chunk_type'' is the string 'Cue#'.
*''chunk_size'' is the chunk size minus 8.
*''point_count'' is the number of cue points.

Following this fixed structure there are ''point_count'' records; each record describes a cue point with a position inside the audio stream and an associated ASCII text string:

{| class="structure"
|unsigned long||position
|-
|unsigned char||name_len
|-
|unsigned char||name[name_len+1]
|}

*''position'' is the cue point position within the audio stream, in units of samples.
*''name_len'' is the length of the associated string.
*''name'' is the associated string (zero-terminated).

Most Cue# chunks have ''point_count'' set to 0, so they contain nothing. Riven tWAV 3 from p_Sounds.mhk has two cue points, named <code>Beg Loop</code> and <code>End Loop</code>. Please note that the chunk structure has been guessed from this single case, so the statistics is very poor :-\

I don't know if the engine uses this chunk at all.

==The Data chunk==
This chunk is always present since it contains the actual audio samples.

{| class="structure"
|4 bytes||chunk_type
|-
|unsigned long||chunk_size
|-
|unsigned short||sample_rate
|-
|unsigned long||sample_count
|-
|unsigned char||bits_per_sample
|-
|unsigned char||channels
|-
|unsigned short||encoding
|-
|unsigned short||loop
|-
|unsigned long||loop_start
|-
|unsigned long||loop_end
|-
|variable||audio_data
|}

*''chunk_type'' is the string 'Data'.
*''chunk_size'' is the full chunk size, including ''chunk_type'' and ''chunk_size'' itself.
*''sample_rate'' is the audio sampling rate (always 22050).
*''sample_count'' is the number of audio samples.
*''bits_per_sample'' is the number of bits per sample per channel.
*''channels'' is the number of audio channels.
*''encoding'' tells how the audio data is stored. It's 0 for raw unsigned PCM, 1 for ADPCM, 2 for MPEG-2 Audio Layer II.
*''loop'' means loop if the value is 0xFFFF (not used in Riven).
*''loop_start'' is the starting point of the loop (not used in Riven).
*''loop_end'' is the ending point of the loop (not used in Riven).
*''audio_data'' is the audio data stream, encoded according to encoding. In case of 1-channel ADPC audio, each byte holds 2 compressed samples (higher and lower 4 bits of the byte); in case of stereo ADPC sounds, each byte stores one compressed sample for each channel (higher and lower 4 bits of the byte).

A good reference for ADPCM decoding (which sounds right to me) can be found [http://wiki.multimedia.cx/index.php?title=IMA_ADPCM here]. Use the decoding method involving the if statements and bit-shifts, which sounds the best. It can be found near the bottom of the page.

Talk:Riven tBMP resources

2009-02-24T03:21:44Z

Aaron: citations and clarifying authorship

Aaron, I'm not entirely clear on your recent additions to the tBMP decode algorithms. Are you aware of specific images that exhibit the behaviors you describe to use a test cases, or a decoder implementation which respects those details?

[Tito] I think I've seen Aaron's effects in some compressed tBMPs. In particular, I recall being surprised by observing duplets repeating themselves, though I don't remember which tBMPs I was inspecting at the time.

[ [[User:Aaron|Aaron]] 06:55, 23 February 2009 (CET) ] I mean to go back and check specifically for this, but I'm almost completely certain that this is true. Initially, in my algorithm, I used an unsigned integer to represent the number of pixels to look back from where I started, and decremented it each time I copied a pixel. This crippled all my images, and caused weird segfaults when it rolled over after 0. This was fixed when I used a signed integer type (ie let the command copy into newly-written pixels). This is basically an implementation detail, most people would do it a different way where this doesn't matter, or use a signed integer to begin with. [also, I think that pixel-based lookbacks ignore the extra space off the edge, while duplet-based ones do not, but I'm not certain on that. I'll verify that too, but it's too late now.] I didn't realize this was new information, I just thought it was left out.

[ [[User:Aaron|Aaron]] 04:21, 24 February 2009 (CET) ] OK, I found specific examples. First of all, pixel lookbacks either never happen close enough to new rows to look back into the last row, or they take into account the extra info not in the final image (the bytes per row thing I mentioned in the article), so I'm glad I tried to confirm it before adding it. As for the others, all of these examples are from my original 5-cd riven set, and they're all from b_Data.MHK. tBMPs 99, 101, and 106 (and others) have a higher bytes per row than image width, and only appear correctly when rendered as if they were (bytes per row) wide, then cropped. tBMP 0 (and almost every other compressed image) has many repeat subcommands that ask for more data than there is available at the time. Specifically, byte 165 of the command stream of tBMP 0 is 0xEC followed by 0x08, meaning n = 6 and m = 8, so it needs 12 pixels copied from 8 pixels ago. These images only render correctly when they are allowed to read into themselves. This also happens with repeat command 0xFC. I hope this clarifies things.

Talk:Riven tBMP resources

2009-02-23T05:55:15Z

Aaron:

Riven tBMP resources

2009-02-19T19:22:49Z

Aaron: /* Subcommands, part 2: repeat operations */ Clarifying repeat commands where it copies more pixels than available at the time

{{Riven}}
This page shows the structure of Riven tBMP resources, which store game bitmaps.

==General tBMP structure==
tBMP resources store 8-bit and 24-bit bitmaps, which can be plain or compressed. Everything is in big-endian order. Each resource begins with this structure:
{| class="structure"
|unsigned short||bitmap width (pixels)
|-
|unsigned short||bitmap height (pixels)
|-
|unsigned short||bytes per row
|-
|unsigned char||compression flag
|-
|unsigned char||truecolor flag
|}

If the truecolor flag is 4 then the bitmap is a 24-bit image, and the structure goes on with height rows, each row following this structure:
{| class="structure"
|''width''*3 unsigned chars||pixel values (BGR, BGR, BGR...)
|-
|''width'' unsigned chars||unknown (zero)
|}

Note that there is only one 24-bit bitmap in the whole game! It's tBMP 24 in b2_data.mhk, and it's a secret image.

If the truecolor flag is not 4 the tBMP is a normal 8-bit bitmap and after the initial fields we find:
{| class="structure"
|unsigned long||unknown (seems always 0x030418ff)
|-
|256*3 unsigned chars||color table (BGR, BGR, BGR...)
|}

If the compression flag is 0, the bitmap is uncompressed: pixel data follows immediately as a simple block of pixels. Each pixel is a byte representing an index in the color table. Rows may be padded with filling bytes to reach the specified number of bytes per row; just discard those extra bytes. Otherwise, if the compression flag is 4 then the bitmap is compressed with a proprietary format (explained below); the compressed data block follows immediately.

==Compression details==
In compressed tBMP bitmaps, pixels are encoded as a data stream made of variable length commands. Pixels are always decoded in duplets: each command generates at least 2 pixels. The encoding is heavily based on what comes before each command, so even a little decoding bug can cripple the whole image. The commands can appear in any order inside the data stream. The first 4 bytes of the data stream are unknown and can be ignored. Many thanks to Arthur Muller for his precious help in decoding this format.

Like the uncompressed format, sometimes duplets are generated beyond the edge of the image. Use the ''bytes per row'' value to see how many duplets are in each row.

==Main commands==

They are all 1-byte commands, followed by a variable number of arguments.

{| border=1 cellpadding=4 cellspacing=0 style="border:1px #000 solid;border-collapse:collapse;"
|- style="background:#CCC"
! Command !! Action
|-
|style="font-family:monospace"|0x00||End of stream: when reaching it, the decoding is complete. No additional bytes follow. I think some bitmaps don't have this, so just stop when you have decoded enough pixels to fill the image.
|-
|style="font-family:monospace"|0x01 -0x3f||Output ''n'' pixel duplets, where ''n'' is the command value itself. Pixel data comes immediately after the command as 2*''n'' bytes representing direct indices in the 8-bit color table.
|-
|style="font-family:monospace"|0x40-0x7f||Repeat last 2 pixels ''n'' times, where ''n'' = ''command_value'' & 0x3F. No additional bytes follow.
|-
|style="font-family:monospace"|0x80-0xbf||Repeat last 4 pixels ''n'' times, where ''n'' = ''command_value'' & 0x3F. No additional bytes follow.
|-
|style="font-family:monospace"|0xc0-0xff||Begin of a subcommand stream. This is like the main command stream, but contains another set of commands which are somewhat more specific and a bit more complex. This command says that ''command_value'' & 0x3F subcommands will follow. It doesn't generate pixels itself.
|}

==Subcommands, part 1: arithmetic operations==
Subcommands are not simply 1-byte values, but are somewhat mixed with their arguments, so the full byte pattern is reported.
{| border=1 cellpadding=4 cellspacing=0 style="border:1px #000 solid;border-collapse:collapse;"
|- style="background:#CCC"
! Command !! Byte pattern !! Action
|-
|style="font-family:monospace"|0x01-0x0f
|style="font-family:monospace"|0000mmmm
|Repeat duplet at relative position -''m'', where ''m'' is given in duplets. So if ''m''=1, repeat the last duplet.
|-
|style="font-family:monospace"|0x10
|style="font-family:monospace"|0x10 p
|Repeat last duplet, but change second pixel to ''p''.
|-
|style="font-family:monospace"|0x11-0x1f
|style="font-family:monospace"|0001mmmm
|Output the first pixel of last duplet, then pixel at relative position -''m''. ''m'' is given in pixels.
|-
|style="font-family:monospace"|0x20-0x2f
|style="font-family:monospace"|0010xxxx
|Repeat last duplet, but add ''x'' to second pixel.
|-
|style="font-family:monospace"|0x30-0x3f
|style="font-family:monospace"|0011xxxx
|Repeat last duplet, but subtract ''x'' to second pixel.
|-
|style="font-family:monospace"|0x40
|style="font-family:monospace"|0x40 p
|Repeat last duplet, but change first pixel to ''p''.
|-
|style="font-family:monospace"|0x41-0x4f
|style="font-family:monospace"|0100mmmm
|Output pixel at relative position -''m'', then second pixel of last duplet.
|-
|style="font-family:monospace"|0x50
|style="font-family:monospace"|0x50 p1 p2
|Output two absolute pixel values, ''p1'' and ''p2''.
|-
|style="font-family:monospace"|0x51-0x57
|style="font-family:monospace"|01010mmm p
|Output pixel at relative position -''m'', then absolute pixel value ''p''.
|-
|style="font-family:monospace"|0x59-0x5f
|style="font-family:monospace"|01011mmm p
|Output absolute pixel value ''p'', then pixel at relative position -''m''.
|-
|style="font-family:monospace"|0x60-0x6f
|style="font-family:monospace"|0110xxxx p
|Output absolute pixel value ''p'', then (second pixel of last duplet) + ''x''.
|-
|style="font-family:monospace"|0x70-0x7f
|style="font-family:monospace"|0111xxxx p
|Output absolute pixel value ''p'', then (second pixel of last duplet) - ''x''.
|-
|style="font-family:monospace"|0x80-0x8f
|style="font-family:monospace"|1000xxxx
|Repeat last duplet adding ''x'' to the first pixel.
|-
|style="font-family:monospace"|0x90-0x9f
|style="font-family:monospace"|1001xxxx p
|Output (first pixel of last duplet) + ''x'', then absolute pixel value ''p''.
|-
|style="font-family:monospace"|0xa0
|style="font-family:monospace"|0xa0 xxxxyyyy
|Repeat last duplet, adding ''x'' to the first pixel and ''y'' to the second.
|-
|style="font-family:monospace"|0xb0
|style="font-family:monospace"|0xb0 xxxxyyyy
|Repeat last duplet, adding ''x'' to the first pixel and subtracting ''y'' from the second.
|-
|style="font-family:monospace"|0xc0-0xcf
|style="font-family:monospace"|1100xxxx
|Repeat last duplet subtracting ''x'' from first pixel.
|-
|style="font-family:monospace"|0xd0-0xdf
|style="font-family:monospace"|1101xxxx p
|Output (first pixel of last duplet) - ''x'', then absolute pixel value ''p''.
|-
|style="font-family:monospace"|0xe0
|style="font-family:monospace"|0xe0 xxxxyyyy
|Repeat last duplet, subtracting ''x'' from first pixel and adding ''y'' to second.
|-
|style="font-family:monospace"|0xf0 and 0xff
|style="font-family:monospace"|0xfx xxxxyyyy
|Repeat last duplet, subtracting ''x'' from first pixel and ''y'' from second.
|}

==Subcommands, part 2: repeat operations==

Sometimes these repeat commands will try to copy more than what is available when the command is read. In those cases, the command repeats the available segment of data until the number of duplets needed is copied. Or, equivalently, the command starts copying data that it wrote earlier.

{| border=1 cellpadding=4 cellspacing=0 style="border:1px #000 solid;border-collapse:collapse;"
|- style="background:#CCC"
! Command !! Byte pattern !! Action
|-
|various
|style="font-family:monospace"|1x1xxxmm mmmmmmmm
|
{| border=1 cellspacing=0 style="float:right;border:none;border-collapse:collapse;padding:0px 3px;"
|- style="background:#CCC"
! Command !! n !! r
|-
|style="font-family:monospace"|0xa4 - 0xa7||2||0
|-
|style="font-family:monospace"|0xa8 - 0xab||2||1
|-
|style="font-family:monospace"|0xac - 0xaf||3||0
|-
|style="font-family:monospace"|0xb4 - 0xb7||3||1
|-
|style="font-family:monospace"|0xb8 - 0xbb||4||0
|-
|style="font-family:monospace"|0xbc - 0xbf||4||1
|-
|style="font-family:monospace"|0xe4 - 0xe7||5||0
|-
|style="font-family:monospace"|0xe8 - 0xeb||5||1
|-
|style="font-family:monospace"|0xec - 0xef||6||0
|-
|style="font-family:monospace"|0xf4 - 0xf7||6||1
|-
|style="font-family:monospace"|0xf8 - 0xfb||7||0
|}
Repeat n duplets from relative position -''m'' (given in pixels, not duplets). If ''r'' is 0, another byte follows and the last pixel is set to that value. ''n'' and ''r'' come from the table on the right.
|-
|style="font-family:monospace"|0xfc
|style="font-family:monospace"|0xfc nnnnnrmm mmmmmmmm (p)
|Repeat n+2 duplets from relative position -''m'' (given in pixels, not duplets). If ''r'' is 0, another byte ''p'' follows and the last pixel is set to absolute value ''p''.
|}

Riven tBMP resources

2009-02-19T19:10:28Z

Aaron: /* Compression details */ "bytes per row" in compressed tBMP clarification, minor formatting correction

{{Riven}}
This page shows the structure of Riven tBMP resources, which store game bitmaps.

==General tBMP structure==
tBMP resources store 8-bit and 24-bit bitmaps, which can be plain or compressed. Everything is in big-endian order. Each resource begins with this structure:
{| class="structure"
|unsigned short||bitmap width (pixels)
|-
|unsigned short||bitmap height (pixels)
|-
|unsigned short||bytes per row
|-
|unsigned char||compression flag
|-
|unsigned char||truecolor flag
|}

If the truecolor flag is 4 then the bitmap is a 24-bit image, and the structure goes on with height rows, each row following this structure:
{| class="structure"
|''width''*3 unsigned chars||pixel values (BGR, BGR, BGR...)
|-
|''width'' unsigned chars||unknown (zero)
|}

Note that there is only one 24-bit bitmap in the whole game! It's tBMP 24 in b2_data.mhk, and it's a secret image.

If the truecolor flag is not 4 the tBMP is a normal 8-bit bitmap and after the initial fields we find:
{| class="structure"
|unsigned long||unknown (seems always 0x030418ff)
|-
|256*3 unsigned chars||color table (BGR, BGR, BGR...)
|}

If the compression flag is 0, the bitmap is uncompressed: pixel data follows immediately as a simple block of pixels. Each pixel is a byte representing an index in the color table. Rows may be padded with filling bytes to reach the specified number of bytes per row; just discard those extra bytes. Otherwise, if the compression flag is 4 then the bitmap is compressed with a proprietary format (explained below); the compressed data block follows immediately.

==Compression details==
In compressed tBMP bitmaps, pixels are encoded as a data stream made of variable length commands. Pixels are always decoded in duplets: each command generates at least 2 pixels. The encoding is heavily based on what comes before each command, so even a little decoding bug can cripple the whole image. The commands can appear in any order inside the data stream. The first 4 bytes of the data stream are unknown and can be ignored. Many thanks to Arthur Muller for his precious help in decoding this format.

Like the uncompressed format, sometimes duplets are generated beyond the edge of the image. Use the ''bytes per row'' value to see how many duplets are in each row.

==Main commands==

They are all 1-byte commands, followed by a variable number of arguments.

{| border=1 cellpadding=4 cellspacing=0 style="border:1px #000 solid;border-collapse:collapse;"
|- style="background:#CCC"
! Command !! Action
|-
|style="font-family:monospace"|0x00||End of stream: when reaching it, the decoding is complete. No additional bytes follow. I think some bitmaps don't have this, so just stop when you have decoded enough pixels to fill the image.
|-
|style="font-family:monospace"|0x01 -0x3f||Output ''n'' pixel duplets, where ''n'' is the command value itself. Pixel data comes immediately after the command as 2*''n'' bytes representing direct indices in the 8-bit color table.
|-
|style="font-family:monospace"|0x40-0x7f||Repeat last 2 pixels ''n'' times, where ''n'' = ''command_value'' & 0x3F. No additional bytes follow.
|-
|style="font-family:monospace"|0x80-0xbf||Repeat last 4 pixels ''n'' times, where ''n'' = ''command_value'' & 0x3F. No additional bytes follow.
|-
|style="font-family:monospace"|0xc0-0xff||Begin of a subcommand stream. This is like the main command stream, but contains another set of commands which are somewhat more specific and a bit more complex. This command says that ''command_value'' & 0x3F subcommands will follow. It doesn't generate pixels itself.
|}

==Subcommands, part 1: arithmetic operations==
Subcommands are not simply 1-byte values, but are somewhat mixed with their arguments, so the full byte pattern is reported.
{| border=1 cellpadding=4 cellspacing=0 style="border:1px #000 solid;border-collapse:collapse;"
|- style="background:#CCC"
! Command !! Byte pattern !! Action
|-
|style="font-family:monospace"|0x01-0x0f
|style="font-family:monospace"|0000mmmm
|Repeat duplet at relative position -''m'', where ''m'' is given in duplets. So if ''m''=1, repeat the last duplet.
|-
|style="font-family:monospace"|0x10
|style="font-family:monospace"|0x10 p
|Repeat last duplet, but change second pixel to ''p''.
|-
|style="font-family:monospace"|0x11-0x1f
|style="font-family:monospace"|0001mmmm
|Output the first pixel of last duplet, then pixel at relative position -''m''. ''m'' is given in pixels.
|-
|style="font-family:monospace"|0x20-0x2f
|style="font-family:monospace"|0010xxxx
|Repeat last duplet, but add ''x'' to second pixel.
|-
|style="font-family:monospace"|0x30-0x3f
|style="font-family:monospace"|0011xxxx
|Repeat last duplet, but subtract ''x'' to second pixel.
|-
|style="font-family:monospace"|0x40
|style="font-family:monospace"|0x40 p
|Repeat last duplet, but change first pixel to ''p''.
|-
|style="font-family:monospace"|0x41-0x4f
|style="font-family:monospace"|0100mmmm
|Output pixel at relative position -''m'', then second pixel of last duplet.
|-
|style="font-family:monospace"|0x50
|style="font-family:monospace"|0x50 p1 p2
|Output two absolute pixel values, ''p1'' and ''p2''.
|-
|style="font-family:monospace"|0x51-0x57
|style="font-family:monospace"|01010mmm p
|Output pixel at relative position -''m'', then absolute pixel value ''p''.
|-
|style="font-family:monospace"|0x59-0x5f
|style="font-family:monospace"|01011mmm p
|Output absolute pixel value ''p'', then pixel at relative position -''m''.
|-
|style="font-family:monospace"|0x60-0x6f
|style="font-family:monospace"|0110xxxx p
|Output absolute pixel value ''p'', then (second pixel of last duplet) + ''x''.
|-
|style="font-family:monospace"|0x70-0x7f
|style="font-family:monospace"|0111xxxx p
|Output absolute pixel value ''p'', then (second pixel of last duplet) - ''x''.
|-
|style="font-family:monospace"|0x80-0x8f
|style="font-family:monospace"|1000xxxx
|Repeat last duplet adding ''x'' to the first pixel.
|-
|style="font-family:monospace"|0x90-0x9f
|style="font-family:monospace"|1001xxxx p
|Output (first pixel of last duplet) + ''x'', then absolute pixel value ''p''.
|-
|style="font-family:monospace"|0xa0
|style="font-family:monospace"|0xa0 xxxxyyyy
|Repeat last duplet, adding ''x'' to the first pixel and ''y'' to the second.
|-
|style="font-family:monospace"|0xb0
|style="font-family:monospace"|0xb0 xxxxyyyy
|Repeat last duplet, adding ''x'' to the first pixel and subtracting ''y'' from the second.
|-
|style="font-family:monospace"|0xc0-0xcf
|style="font-family:monospace"|1100xxxx
|Repeat last duplet subtracting ''x'' from first pixel.
|-
|style="font-family:monospace"|0xd0-0xdf
|style="font-family:monospace"|1101xxxx p
|Output (first pixel of last duplet) - ''x'', then absolute pixel value ''p''.
|-
|style="font-family:monospace"|0xe0
|style="font-family:monospace"|0xe0 xxxxyyyy
|Repeat last duplet, subtracting ''x'' from first pixel and adding ''y'' to second.
|-
|style="font-family:monospace"|0xf0 and 0xff
|style="font-family:monospace"|0xfx xxxxyyyy
|Repeat last duplet, subtracting ''x'' from first pixel and ''y'' from second.
|}

==Subcommands, part 2: repeat operations==
{| border=1 cellpadding=4 cellspacing=0 style="border:1px #000 solid;border-collapse:collapse;"
|- style="background:#CCC"
! Command !! Byte pattern !! Action
|-
|various
|style="font-family:monospace"|1x1xxxmm mmmmmmmm
|
{| border=1 cellspacing=0 style="float:right;border:none;border-collapse:collapse;padding:0px 3px;"
|- style="background:#CCC"
! Command !! n !! r
|-
|style="font-family:monospace"|0xa4 - 0xa7||2||0
|-
|style="font-family:monospace"|0xa8 - 0xab||2||1
|-
|style="font-family:monospace"|0xac - 0xaf||3||0
|-
|style="font-family:monospace"|0xb4 - 0xb7||3||1
|-
|style="font-family:monospace"|0xb8 - 0xbb||4||0
|-
|style="font-family:monospace"|0xbc - 0xbf||4||1
|-
|style="font-family:monospace"|0xe4 - 0xe7||5||0
|-
|style="font-family:monospace"|0xe8 - 0xeb||5||1
|-
|style="font-family:monospace"|0xec - 0xef||6||0
|-
|style="font-family:monospace"|0xf4 - 0xf7||6||1
|-
|style="font-family:monospace"|0xf8 - 0xfb||7||0
|}
Repeat n duplets from relative position -''m'' (given in pixels, not duplets). If ''r'' is 0, another byte follows and the last pixel is set to that value. ''n'' and ''r'' come from the table on the right.
|-
|style="font-family:monospace"|0xfc
|style="font-family:monospace"|0xfc nnnnnrmm mmmmmmmm (p)
|Repeat n+2 duplets from relative position -''m'' (given in pixels, not duplets). If ''r'' is 0, another byte ''p'' follows and the last pixel is set to absolute value ''p''.
|}