 |
|
|
 |
|
This is my attempt to describe how some of the Atari versions of the SAGA images were formed. Note, I have taken this information from only a few games (the few Atari ones I've been able to find). If you have any Atari versions of the other SAGA games I would like to see them so I can ensure that my routines work on all of them. The games I used are:
Basic formatThe Atari games come on two discs, the first disc contains the machine code and the game data. The second disc just seems to contain graphic data, with a small initial boot sector to tell somebody booting from that disc to use the other disc. The discs aren't read as files - just directly read from the disc; so we can treat the whole disc as a data file. The files are drawn with a graphics resolution of 320 x 200. The Atari screen mode restricts colours to 5, but these can be allocated from a base of 128 different colours. White is always used for text and Black is always used for the background. Assuming that origin is at the top left of the screen. The area used for images starts at (24,0) and extends to (304,159). This leaves a miniscule space of screen of 4 lines for text descriptions! On areas where the image is smaller than normal the text uses the extra lines. The image data for the first image starts at 0x297, and the images follow sequentially. The image data seems closely related to the PC image data. The Header
Note, the size doesn't always seem to lead perfectly to the next image, you may have to skip 0x00 bytes until you reach the header! The Graphics ChunkThis is followed by the graphics chunk. The graphics are rended by a simple RLE encoding scheme: read byte if byte has bit 7 set read byte1, byte2 repeat ((byte & 0x7F) + 1) times plot byte1, byte2 endrepeat else repeat (byte + 1) times read byte1, byte2 plot byte1, byte2 endrepeat endif Note, due to the low amount of colours, the graphics data is set at 2 bits per pixel, with each two bits representing a colour index from 0 - 4. All the x pixel values are plotted twice. For example the value 0xa5 would be turn into eight pixels as:
To confuse issues, this version plots y first, rather than x. It always provides the next two y values after the encoding. So the plotting order is: get byte1, byte2 plot byte1 increase y plot byte2 if y > MaxY y = MinY increase x (in blocks of 8 pixels) endif Stop plotting when the x offset (in blocks of 8 pixels) gets greater than maxX (in blocks of 8 pixels). Beyond this until the end of the graphics chunk the data is undefined. Complex images are formed by overlaying other images over a basic image. VariationsThere are a couple of variations to the above format, both Voodoo Castle and The Count are in a slightly more basic format - bit 7 of the counter byte does nothing special - all counter bytes are treated as counters. Also, it matches the end of a column on y >= ylen. Image 55 on The Count is corrupt on the discs I have, but doesn't seem to be used in the game. The Sorcerer of Claymorgue Castle and The Hulk fill up the second disc totally, meaning that the image for the inventory is kept on the first disc at an index of 0x9890 Bytes 0xb390 to 0xb410 correspond to the content of sector 360 (0x0168) which contains the volume table of contents of the disk (mostly a bitmap of used sectors). This is not part of the graphics data and should be skipped. For the code below, this sector was edited out by hand with a hex editor. CodeThe code is relatively simple to extract the images from the originals. Here is the C code I was using to test my extraction routines. It
uses the allegro library and will save the image as Output<image>.bmp. The CLI parameters
are: The version flag should be y for Voodoo Castle and The Count You will also need a palette file. I stole this one from Atariwin :-) Note the C is not very good and was evolved and hacked during my tests! ImagesThe extracted images:
|
