| 1 | SHP file specifications for DUNE2 game (c) by WESTWOOD and VIRIN
|
|---|
| 2 | ==================================================================
|
|---|
| 3 | (c) by Joachim Schiele <js@dune2.de>
|
|---|
| 4 | REVISION 1
|
|---|
| 5 |
|
|---|
| 6 | What are SHP files btw?
|
|---|
| 7 | =======================
|
|---|
| 8 | SHP is a method of saving multible graphics in one file and also be able
|
|---|
| 9 | to have some kind of compression. In this case "DUNE II" it's format80
|
|---|
| 10 | compression mode. The "DUNE II" code is a little bit different from the one
|
|---|
| 11 | of "Command and Conqueror" hacked by Vladan Bato. Major parts of this
|
|---|
| 12 | informations are from him and only needed some little modifications to be
|
|---|
| 13 | compatible with the ones of "DUNE II". But in case you want to work with
|
|---|
| 14 | this format i think it's better if it's function is documented.
|
|---|
| 15 | Explanations and example codes are in "c", see sandtools how to code a
|
|---|
| 16 | extractor/converter for shpfiles.
|
|---|
| 17 |
|
|---|
| 18 | ============
|
|---|
| 19 | HEAD
|
|---|
| 20 | ============
|
|---|
| 21 |
|
|---|
| 22 | *** File: ../data/pak/dune/arrow.shp (hextype output)
|
|---|
| 23 | 00000000 : 09 00 28 00 00 00 34 00-00 00 B3 00 00 00 36 01 : ................
|
|---|
| 24 | 00000001 : 00 00 A7 01 00 00 17 02-00 00 A0 02 00 00 21 03 : ................
|
|---|
| 25 | 00000002 : 00 00 B3 03 00 00 0A 04-00 00 02 00 01 01 00 01 : ................
|
|---|
| 26 | 00000003 : 0C 00 02 00 00 01 00 00-10 10 00 10 7F 00 B8 00 : ................
|
|---|
| 27 | exampe 1
|
|---|
| 28 |
|
|---|
| 29 | (symbolized diagram)
|
|---|
| 30 | 00000000 : XX XX YY YY YY YY YY YY-YY YY YY YY YY YY YY YY : ................
|
|---|
| 31 | 00000001 : YY YY YY YY YY YY YY YY-YY YY YY YY YY YY YY YY : ................
|
|---|
| 32 | 00000002 : YY YY YY YY YY YY EE EE-QQ QQ QQ QQ QQ QQ QQ QQ : ................
|
|---|
| 33 | 00000003 : QQ QQ QQ QQ QQ QQ QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................
|
|---|
| 34 |
|
|---|
| 35 | The XXXX(short) field has the "number of images" in it, afterwards an array
|
|---|
| 36 | of "image offsets" is following. The "number of images" field has 2byte. The
|
|---|
| 37 | offsels after the "number of images" field take 4byte each. There are
|
|---|
| 38 | "number of images" + one EOF (2byte) field. In example 1. the XXXX contains
|
|---|
| 39 | 0x0900(hex). So you have (9x 4byte + 2byte EOF) of offsetfields.
|
|---|
| 40 | (Symboliced with 36x YY fields, and 2x EE EOF fileds)
|
|---|
| 41 |
|
|---|
| 42 | EXCEPTION:
|
|---|
| 43 | ----------
|
|---|
| 44 | There are shpfiles which don't follow this stricktly rule. If the "number of
|
|---|
| 45 | images" field has exactly 1 image in it, it may be that there is no 4byte long
|
|---|
| 46 | offsetfield aftwerwards, it's only 2byte (not 4byte!). If this is the case
|
|---|
| 47 | there is only a 2byte Offsetfield and a 2byte EOF field afterwards.
|
|---|
| 48 | But it depends, sometimes files with 1 image inside don't have this exception.
|
|---|
| 49 | You have to check this or you get in trouble. (see example 2.)
|
|---|
| 50 |
|
|---|
| 51 | *** File: ../data/pak/finale/credit43.shp
|
|---|
| 52 | 00000000 : 01 00 08 00 00 00 E8 1B-00 00 00 00 6E B6 00 6E : ................
|
|---|
| 53 | 00000001 : E0 1B 80 4D 83 9A 9A 99-C9 01 00 81 99 20 04 EA : ................
|
|---|
| 54 | exampe 2
|
|---|
| 55 |
|
|---|
| 56 | 00000000 : XX XX YY YY EE EE QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................
|
|---|
| 57 | 00000001 : QQ QQ QQ QQ QQ QQ QQ QQ-QQ QQ QQ QQ QQ QQ QQ QQ : ................
|
|---|
| 58 |
|
|---|
| 59 | In this example there is only 1 image inside (2byte "XX XX") for the
|
|---|
| 60 | "number of images" field and followed by a (2byte "YY YY") offsetfield.
|
|---|
| 61 | And the (2byte "EE EE") EndOfFile field.
|
|---|
| 62 | Afterwards the QQ fields (imagedata) follows.
|
|---|
| 63 |
|
|---|
| 64 | ============
|
|---|
| 65 | BODY
|
|---|
| 66 | ============
|
|---|
| 67 |
|
|---|
| 68 | How to find the real start of a internal image in a shpfile?
|
|---|
| 69 |
|
|---|
| 70 | The body of a shpfile starts at the first "image offset" symbolized with
|
|---|
| 71 | "YY YY YY YY" (see ex. 1) in this case it would be at byte "28" and ends
|
|---|
| 72 | at byte "34-1". The END- and START-offsets of a image stored in a shpfile is
|
|---|
| 73 | calculated with the [StartOffset of the following image] - 1(byte).
|
|---|
| 74 | The "EE EE" (EndOfFile) field has the END-offset of the last image in the
|
|---|
| 75 | shpfile.
|
|---|
| 76 | But becareful with this start- and endoffsets because a image inside the
|
|---|
| 77 | shpfile doesn't start at the startoffset nor does it end at a endoffset.
|
|---|
| 78 | The images starts at [startoffset+2byte] and it ends at [endoffset + 2].
|
|---|
| 79 | As you can see both offsets need to be moved 2byte on.
|
|---|
| 80 |
|
|---|
| 81 | Let's have a deeper look into this BODY:
|
|---|
| 82 |
|
|---|
| 83 | *** File: deathhand.shp
|
|---|
| 84 | 00000000 : 07 00 20 00 00 00 85 00-00 00 DB 00 00 00 1F 01 : ................
|
|---|
| 85 | 00000001 : 00 00 77 01 00 00 B9 01-00 00 0D 02 00 00 57 02 : ................
|
|---|
| 86 | 00000002 : 00 00 00 00 10 10 00 10-65 00 6E 00 8E 0C 00 0F : ................
|
|---|
| 87 | 00000003 : 0C 0C 00 0E 0C EA 0C 00-0D 0C B8 00 06 83 0C 0C : ................
|
|---|
| 88 | 00000004 : E8 10 07 81 0B 00 07 10-08 81 0A 10 08 10 09 81 : ................
|
|---|
| 89 | 00000005 : 09 20 09 10 0A 81 08 30-0A 10 0B 87 07 0C 0C 0C : ................
|
|---|
| 90 | 00000006 : EC E8 E8 00 06 8F 00 07-00 03 0C E9 E8 EC 00 09 : ................
|
|---|
| 91 | 00000007 : 00 04 EC E8 E9 00 26 82-00 04 00 28 30 08 10 20 : ................
|
|---|
| 92 | 00000008 : 85 08 00 10 00 10 80 00-00 10 10 00 10 56 00 6B : ................
|
|---|
| 93 | exampe 3
|
|---|
| 94 |
|
|---|
| 95 | As you can see this shpfile stores 7 graphics. And the first image is at 0x20.
|
|---|
| 96 |
|
|---|
| 97 | 00000002 : 00 00 00 00 10 10 00 10-65 00 6E 00 8E 0C 00 0F : ................
|
|---|
| 98 | 00000002 : RR RR TT NN Y_ X_ NN Y_ SS SS CK CK QQ QQ QQ QQ : ................
|
|---|
| 99 |
|
|---|
| 100 | RR : belongs always to the last image's end. in this case it's the first image
|
|---|
| 101 | in the shpfile so there can't be a EOF of a previous image.
|
|---|
| 102 |
|
|---|
| 103 | NN : simply nothing, or maybe i don't know but dune2 doesn't make use of it.
|
|---|
| 104 | TT : it's a type field, there are 4 different types:
|
|---|
| 105 | 0000: Start with format80 command || Always end with 0x80 command
|
|---|
| 106 | 0001: Always start with "0" || Always end with 0x80 command
|
|---|
| 107 | 0002: ?? || ??
|
|---|
| 108 | 0003: can start with 0,1,2,3,4,6 || Always end with "0"
|
|---|
| 109 | Y_ : it's the y dimension of the image [hight]
|
|---|
| 110 | as you can see this field is there twice but i didn't find a reason why?
|
|---|
| 111 | both fields always match, i tested it with all shpimages from DUNE II
|
|---|
| 112 | X_ : it's the x dimension of the image [width]
|
|---|
| 113 | SS : (read as unsigned short)
|
|---|
| 114 | it's the size of the first image of this shp file + 10 so if you want to
|
|---|
| 115 | have the real size of the image it's "0x0065-a" in hex or
|
|---|
| 116 | "101-10=91" in dec.
|
|---|
| 117 | CK : (read as unsigned short)
|
|---|
| 118 | it's the ckecksum of the image, if you add all counts while decode80
|
|---|
| 119 | together you get this value.
|
|---|
| 120 | QQ : again, it's the imagedata
|
|---|
| 121 |
|
|---|
| 122 | 00000008 : 85 08 00 10 00 10 80 00-00 10 10 00 10 56 00 6B : ................
|
|---|
| 123 | 00000008 : QQ QQ QQ QQ QQ QQ QQ NN NN NN NN NN NN NN NN NN : ................
|
|---|
| 124 |
|
|---|
| 125 | QQ : imagedata
|
|---|
| 126 | NN : noting -> next image
|
|---|
| 127 |
|
|---|
| 128 | So here we can see that this image usually ends with 0x80, that's because it's
|
|---|
| 129 | format80 and 0x80 means command 1 with count=0 so EOF is reached ;-)
|
|---|
| 130 | But see format80 specification for further informations.
|
|---|
| 131 |
|
|---|
| 132 | ============
|
|---|
| 133 | CREDITS
|
|---|
| 134 | ============
|
|---|
| 135 |
|
|---|
| 136 | I wish to thank especially Valadan Bato because of his work on CNC
|
|---|
| 137 | -Vladan Bato (bat22@geocities.com)
|
|---|
| 138 |
|
|---|
| 139 | And also thanks to the following people :
|
|---|
| 140 |
|
|---|
| 141 | -Andrew Griffin (buggy@adam.com.au)
|
|---|
| 142 | -Aaron Glover (arn@ibm.net)
|
|---|
| 143 | Denis Moeller (d.moeller@rendsburg.netsurf.de) for their work on .SHP files.
|
|---|
![(please configure the [header_logo] section in trac.ini)](/Dune2/chrome/site/your_project_logo.png){kind=logo}
