Blorb extensions for Infocom graphics                        version 0.1
-------------------------------------

Author: Kevin Bracey ([email protected])


This document specifies an extension to Blorb 1.1 to handle the original
graphics of the four Infocom V6 games.

The aim is to make it possible to convert the Infocom graphics to Blorb
without any loss of functionality. That way V6 interpreters only need to
handle Blorb with some minor extensions, rather than having to cope with two
totally different resource formats.

Conversion of the TLH and Sherlock sounds to Blorb was straightforward, and
these have been uploaded to the IF Archive. The only remaining issue is the
correct frequency for one of the TLH sounds.

For the graphics, the consensus is that the optimal versions are the IBM MCGA
(MG1) versions.

The MG1 graphics are designed for a 320x200 resolution screen, and use a
maximum of 14 colours per image. An extra transparent colour is also
supported. The games will readily scale themselves to different resolutions,
sizes and screen sizes proportions.

There are three peculiar features to the MG1 graphics.

   1) Images with zero height and/or width (in Zork Zero and Arthur)
   2) Images with no palette (in Zork Zero and Arthur)
   3) Images with no data (in Zork Zero, Shogun, and Arthur)

The first two cannot represented in Blorb 1.1, as PNG and JPEGs must have
both width and height >= 1, and PNGs must have a palette. Item 3 can be dealt
with (inefficiently) by having a totally transparent PNG.

To handle these features, this specification add two extensions to Blorb.
Support for these extensions by interpreters is optional, and their use is
strongly discouraged for any purpose other than conversions of Infocom
graphics.


* Rectangles

A third of picture is a rectangle. A rectangle has only size, but no
contents. A rectangle exists for the purposes of @picture_data, and
@erase_picture, but its use in @draw_picture or @picture_table is an error.
Indeed, the IBM Infocom interpreter crashes if asked to plot an image with
no data.

A rectangle is described by a "Rect" chunk:

     4 bytes   "Rect"    chunk ID
     4 bytes   8         chunk size
     4 bytes   px        picture width
     4 bytes   py        picture height

Rectangles are used by Zork Zero, Shogun and Arthur. Either or both of the
width and height may be zero.


* The Adaptive Palette Chunk

This chunk contains a list of pictures that change their colours according to
the pictures plotted before - these will be known as adaptive-palette
pictures.

       4 bytes       'APal'       chunk ID
       4 bytes       num*4        chunk length
       num*4 bytes   ...          adaptive palette entries

Each entry is 4 bytes, of the form:

       4 bytes       number       picture resource number

If this chunk is present:

  * All pictures in the Blorb file will be PNGs or Rects.
  * All PNGs will be indexed-colour (colour type 3).
  * All PNGs will use only colour indices 2-15.
  * All PNGs will have no more than 16 entries in their PLTE chunk.
  * PNGs may have a tRNS chunk marking colour 0 only as fully transparent,
    in which case colour index 0 may also be used. No other forms of the
    tRNS chunk are valid.

However, the following rules still apply from the PNG standard:

  * Any bit depth of PNG is valid (1,2,4 or 8 bits per pixel).
  * The PLTE chunk is required by the PNG standard, and it must have
    sufficient entries to cover every colour used in the PNG, even in
    adaptive-palette pictures.
  * The PLTE chunk may not have more entries than can be represented
    by the PNG's bit depth.
  * The PNGs may have gAMA, cHRM and sRGB or iCCP chunks describing the
    colour space. Interpreters should make every effort to support at least
    gAMA. For the Infocom graphics at least, cHRM, sRGB and iCCP are
    probably beyond the call of duty.

These restrictions, though intricate, serve to make the interpreter's life
easier at the expense of constraining the creator. The constraints are
natural given the form of the original Infocom graphics.

The interpreter should keep track of the "Current Palette". This will be a
14-entry table, covering colour indices 2-16. For ease of implementation,
this will probably be a 16-entry table, whose first two entries are not
significant.

Whenever a picture *not* listed in the APal chunk is plotted, its palette (as
derived from its PLTE, gAMA, cHRM and sRGB/iCCP chunks) should be copied into
the Current Palette. If its palette has fewer than 16 entries, then only
those entries of the Current Palette are changed. (Possible interpreter
implementation: transform the PNG's PLTE chunk according to the gAMA, cHRM,
sRGB chunks, then copy it into your Current Palette which is always in the
screen colour-space. With libpng, use png_get_PLTE, after calling
png_update_info).

Whenever a picture listed in the APal chunk is plotted, its palette should be
ignored, and it should be plotted with the Current Palette. (Possible
interpreter implementation: strip out the PLTE, gAMA, cHRM and sRGB/iCCP
chunks from the PNG, and insert the Current Palette as its PLTE. Or with
libpng, use png_set_PLTE before reading the data).

Behaviour is undefined if any adaptive-palette pictures are plotted before
a non-adaptive picture has been plotted.

If picture caching (through @picture_data or otherwise) is implemented,
special attention may need to be paid to ensure that adaptive images that are
cached are still appropriate for the Current Palette when plotted. It would
appear that the Zork Zero does reset the cache after a palette change, but
this has not been exhaustively investigated.

Alternatively, for the full retro-gaming experience, the pictures can be
handled in the same way as the Amiga and IBM MCGA interpreters, as follows:
Use a 16-colour screen mode. Copy non-adaptive pictures' palette (apart from
the first two entries) into the screen palette when plotted. Use colour
indices 0 and 1 for the window background and text respectively. This mimics
the IBM MGA and Amiga display, where drawing a picture can change the colours
of graphics already on the screen, but it is not the preferred rendering.

Shogun and Journey do not use any adaptive-palette images, but on some
platforms the effect of pictures already on the screen changing colour is
visible. To give an interpreter the ability to do this if desired, and to
signal that optimisations may be possible because of the limited nature of
the graphics, the Blorb files for Shogun and Journey contain an empty APal
chunk.

You are viewing proxied material from gopher.661.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.