SHP file specifications for DUNE2 game (c) by WESTWOOD and VIRIN ================================================================== (c) by Joachim Schiele REVISION 1 What are SHP files btw? ======================= SHP is a method of saving multible graphics in one file and also be able to have some kind of compression. In this case "DUNE II" it's format80 compression mode. The "DUNE II" code is a little bit different from the one of "Command and Conqueror" hacked by Vladan Bato. Major parts of this informations are from him and only needed some little modifications to be compatible with the ones of "DUNE II". But in case you want to work with this format i think it's better if it's function is documented. Explanations and example codes are in "c", see sandtools how to code a extractor/converter for shpfiles. ============ HEAD ============ *** File: ../data/pak/dune/arrow.shp (hextype output) 00000000 : 09 00 28 00 00 00 34 00-00 00 B3 00 00 00 36 01 : ................ 00000001 : 00 00 A7 01 00 00 17 02-00 00 A0 02 00 00 21 03 : ................ 00000002 : 00 00 B3 03 00 00 0A 04-00 00 02 00 01 01 00 01 : ................ 00000003 : 0C 00 02 00 00 01 00 00-10 10 00 10 7F 00 B8 00 : ................ exampe 1 (symbolized diagram) 00000000 : XX XX YY YY YY YY YY YY-YY YY YY YY YY YY YY YY : ................ 00000001 : YY YY YY YY YY YY YY YY-YY YY YY YY YY YY YY YY : ................ 00000002 : YY YY YY YY YY YY EE EE-QQ QQ QQ QQ QQ QQ QQ QQ : ................ 00000003 : QQ QQ QQ QQ QQ QQ QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................ The XXXX(short) field has the "number of images" in it, afterwards an array of "image offsets" is following. The "number of images" field has 2byte. The offsels after the "number of images" field take 4byte each. There are "number of images" + one EOF (2byte) field. In example 1. the XXXX contains 0x0900(hex). So you have (9x 4byte + 2byte EOF) of offsetfields. (Symboliced with 36x YY fields, and 2x EE EOF fileds) EXCEPTION: ---------- There are shpfiles which don't follow this stricktly rule. If the "number of images" field has exactly 1 image in it, it may be that there is no 4byte long offsetfield aftwerwards, it's only 2byte (not 4byte!). If this is the case there is only a 2byte Offsetfield and a 2byte EOF field afterwards. But it depends, sometimes files with 1 image inside don't have this exception. You have to check this or you get in trouble. (see example 2.) *** File: ../data/pak/finale/credit43.shp 00000000 : 01 00 08 00 00 00 E8 1B-00 00 00 00 6E B6 00 6E : ................ 00000001 : E0 1B 80 4D 83 9A 9A 99-C9 01 00 81 99 20 04 EA : ................ exampe 2 00000000 : XX XX YY YY EE EE QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................ 00000001 : QQ QQ QQ QQ QQ QQ QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................ In this example there is only 1 image inside (2byte "XX XX") for the "number of images" field and followed by a (2byte "YY YY") offsetfield. And the (2byte "EE EE") EndOfFile field. Afterwards the QQ fields (imagedata) follows. ============ BODY ============ How to find the real start of a internal image in a shpfile? The body of a shpfile starts at the first "image offset" symbolized with "YY YY YY YY" (see ex. 1) in this case it would be at byte "28" and ends at byte "34-1". The END- and START-offsets of a image stored in a shpfile is calculated with the [StartOffset of the following image] - 1(byte). The "EE EE" (EndOfFile) field has the END-offset of the last image in the shpfile. But becareful with this start- and endoffsets because a image inside the shpfile doesn't start at the startoffset nor does it end at a endoffset. The images starts at [startoffset+2byte] and it ends at [endoffset + 2]. As you can see both offsets need to be moved 2byte on. Let's have a deeper look into this BODY: *** File: deathhand.shp 00000000 : 07 00 20 00 00 00 85 00-00 00 DB 00 00 00 1F 01 : ................ 00000001 : 00 00 77 01 00 00 B9 01-00 00 0D 02 00 00 57 02 : ................ 00000002 : 00 00 00 00 10 10 00 10-65 00 6E 00 8E 0C 00 0F : ................ 00000003 : 0C 0C 00 0E 0C EA 0C 00-0D 0C B8 00 06 83 0C 0C : ................ 00000004 : E8 10 07 81 0B 00 07 10-08 81 0A 10 08 10 09 81 : ................ 00000005 : 09 20 09 10 0A 81 08 30-0A 10 0B 87 07 0C 0C 0C : ................ 00000006 : EC E8 E8 00 06 8F 00 07-00 03 0C E9 E8 EC 00 09 : ................ 00000007 : 00 04 EC E8 E9 00 26 82-00 04 00 28 30 08 10 20 : ................ 00000008 : 85 08 00 10 00 10 80 00-00 10 10 00 10 56 00 6B : ................ exampe 3 As you can see this shpfile stores 7 graphics. And the first image is at 0x20. 00000002 : 00 00 00 00 10 10 00 10-65 00 6E 00 8E 0C 00 0F : ................ 00000002 : RR RR TT NN Y_ X_ NN Y_ SS SS CK CK QQ QQ QQ QQ : ................ RR : belongs always to the last image's end. in this case it's the first image in the shpfile so there can't be a EOF of a previous image. NN : simply nothing, or maybe i don't know but dune2 doesn't make use of it. TT : it's a type field, there are 4 different types: 0000: Start with format80 command || Always end with 0x80 command 0001: Always start with "0" || Always end with 0x80 command 0002: ?? || ?? 0003: can start with 0,1,2,3,4,6 || Always end with "0" Y_ : it's the y dimension of the image [hight] as you can see this field is there twice but i didn't find a reason why? both fields always match, i tested it with all shpimages from DUNE II X_ : it's the x dimension of the image [width] SS : (read as unsigned short) it's the size of the first image of this shp file + 10 so if you want to have the real size of the image it's "0x0065-a" in hex or "101-10=91" in dec. CK : (read as unsigned short) it's the ckecksum of the image, if you add all counts while decode80 together you get this value. QQ : again, it's the imagedata 00000008 : 85 08 00 10 00 10 80 00-00 10 10 00 10 56 00 6B : ................ 00000008 : QQ QQ QQ QQ QQ QQ QQ NN NN NN NN NN NN NN NN NN : ................ QQ : imagedata NN : noting -> next image So here we can see that this image usually ends with 0x80, that's because it's format80 and 0x80 means command 1 with count=0 so EOF is reached ;-) But see format80 specification for further informations. ============ CREDITS ============ I wish to thank especially Valadan Bato because of his work on CNC -Vladan Bato (bat22@geocities.com) And also thanks to the following people : -Andrew Griffin (buggy@adam.com.au) -Aaron Glover (arn@ibm.net) Denis Moeller (d.moeller@rendsburg.netsurf.de) for their work on .SHP files.